If you'd like to understand more about how to do messaging in WSE and would like to see the  three levels of messaging within WSE in action then why not register for my first MSDN webcast here?.  I'm going to be presenting it on Mon 9 Aug at 1PM EST (GMT -8). 

I'll be covering some of the demos from the Keith Ballinger presentation from TechEd San Diego that I presented in Amsterdam, along with some new material.  Here's the abstract:

Using messaging systems to support application functionality allows technical solutions to better match business problems.  WSE 2.0 provides messaging implementations that range from low-level explicit messaging through to high-level, more transparent models.  This webcast demonstrates various messaging levels within WSE including a custom WS-Eventing sample and how message, network addresses, intermediaries and queues need to become first-class citizens of your application. Learn how messaging can enable you to create powerful web services applications that cross machine and network boundaries.

I've put these details on my updated presentations page as well.

Dave Bettin writes about his experiences doing a user group presentation on Indigo.  His main disappointment was that few attendees seemed to know about Indigo or the existing ASMX web services in .NET.  This got me thinking about how to get the message out about distributed apps, service-orientation and Indigo.  Is it the case that most developers need to be educated about the benefits of scalable, distributed, service-oriented apps or is it that they don't need these approaches to solve their business problems?

Dave's feedback is similar to Clemens' experience earlier in the year, where he spoke of the difficulties selling the relevance of Indigo today before he settled on explaining the 'why' over the how.  Both Dave and Clemens' experienced the same difficulty making the connection between Indigo and developers' jobs today.  Clemens' says that one of the barriers is that people think Indigo is only going to be relevant for 'Big Apps', when in fact it will be important to anyone who builds apps that expose functionality to other apps. 

One argument is that in order to get more interest in Indigo we need to educating developers about the benefits of services and distributed apps and get them to stop writing monolithic apps and start separating the logic across tiers and services.  We need to teach them more about the benefits of the services and distributed application approach, such as scalability.  Sam Gentile touched on this sentiment when he wrote that most .NET developers don't grok distributed computing. 

The other position regarding evangelising Indigo is mentioned by Alex Lowe in a comment on Clemens' post, is that:

Of course, we know that in the real world there are lots of applications that don't expose functionality to other applications. There are plenty of line of business applications for small and medium businesses that don't require ASMX, Remoting, and in the future Indigo.

Alex also has a summary post on his position where he says that the number of applications that need (and by extension, developers) that actually need to know about how to architect scalable applications is low.  He argues that bloggers are a distorted sample because they represent the group that need to build scalable distributed applications and they are generally well up on things.

I'm interested what other people think.  Is the problem that most developers don't understand the benefits of service-oriented distributed applications or is it that most developers are writing apps that wouldn't benefit from service-oriented distributed applications?  What business application scenarios are most likely to benefit from adopting service-orientation and Indigo?

private ISoapInputChannel channel = null;
private void Form1_Load(object sender, System.EventArgs e)
{
   // Get our channel that's listening for incoming messages
   channel = SoapTransport.StaticGetInputChannel(
      new Uri("soap.tcp://localhost:8088/admin"),
      SoapChannelCapabilities.ActivelyListening);
}

private void button1_Click(object sender, System.EventArgs e)
{
   // When we're ready, process the messages off the in-memory queue
   SoapEnvelope message = channel.Receive();
   String messageBody =
      message.GetBodyObject(typeof(String)) as String;
   this.listBox1.Items.Add( messageBody );
}

In the Form_Load event the channel is retrieved from the SoapTransport.StaticGetInputChannel method, based on the channel listening on a particular network address (in this case using tcp) with particular capabilities (the options are ActivitelyListening, meaning the channel should create a listener at that address, or None, meaning the channel should connect to an existing listener).  As messages are received they are placed in an in-memory queue managed by this channel.  When the Button_Click event is fired the next message can be retrieved from the channel by calling the Receive() method which returns a SoapEnvelope from which the body can be unpacked.

Here are some photos and conference highlights from TechEd Amsterdam (completing my backlog of blog posts).  Aside from what I've blogged already, the highlights of the conference for me were:

• Being there when Don Box spoke for the first time about BOA.  See here for a summary of BOA postings. [update: The concept of Business Oriented Agents (BOA) was a joke designed to send up the hype about the 'next new thing' and the lack of clarity in press reporting about concepts such as SOA.  Unfortunately the joke was not clearly understood and some people are understandably upset about it.  This post was my only reference to it and I apologise if any readers felt mislead.]
• Hanging out with the other Indigo guys and others who I'd met at PDC and TechEd US.
• Meeting many people from the UK community at the BoF and Chalk and Talk sessions.  Thanks to everyone that came along and those who had the courage to spend some time on the park bench answering questions and making statements.
• Increasing my list of UK Microsoft bloggers - welcome Johnny Hall (XP afficionado) and Peter Foot (Compact Framework MVP)

Here are some photos from TechEd Amsterdam, completing my backlog of posts.

Some of the 6,000 drums at the start of the keynote.	Delegates enjoying the 3D presentation that finished the keynote.
Pat Helland trying out his Wizard costume in the speaker lounge.	Heidi, one of the amazing organising team, showing a way to deal with the size of the RAI conference centre.
A "family photo" of all of the Microsoft Regional Directors at the Staff and Speaker Dinner on Friday.	The Boom Chicago Team making fun of the competition for Best Speaker evals between Kimberly L Tripp, Rafal Lukawiecki and Steve Riley

I hosted a lively session on what Service Orientated Architecture really means at TechEd Amsterdam.  While it was a Birds of a Feather session, I decided to run it as a park bench format in order to take advantage of having David Chappell, Michele Leroux Bustamante and John Hooper (blogless MCS UK Architect) come to the session.  Here were some of the interesting discussion points that came up:

• There was some agreement that SOA is a pragmatic marketing term that unites many existing architectural principles around SOAP. 
• The closest agreement about a definition for SOA was that it was based around common architectural principles of encapsulation, loose coupling and messaging.
• There was some discussion about whether asynchronous messaging was a necessary part of service orientation. My feeling is that since you can achieve synchronous patterns over asynchronous communications that having asynchronous messaging capabilities is extremely useful.
• Although it's possible that these principles could be applied without SOAP, it's the fact that Microsoft, IBM, BEA and others have agreed that SOAP will be the lowest common denominator that is the pragmatic reason behind the current push for SOA.
• David made a point that service orientation will be whatever Indigo supports when it ships.  Shipping software always wins.  I think there's a lot of merit in this argument, but to the extent that SOA is based on generic architectural principles it is worth considering using these principles in systems that are design today (as Clemens demonstrated all conference).  If SOA principles help solve your business problems today then it's definitely worth starting today rather than waiting for Indigo.
• Some delegates were suspicious that using Indigo would enable them to interoperate with other systems that didn't use Indigo.  There was some confusion about the idea that Indigo will provide an object model that can be used to develop a system that has the capability to send messages between the systems that are based on interoperable WS-* specifications.
• The four tenets of service orientation are necessary but not sufficient for a system to be considered a service oriented architecture.  Some people thought they were too technologically focussed because they were tied too closely to XML technologies.
• David mentioned that the best SOA installation he'd seen was using CORBA several years ago - it had support for finding services, common schemas etc.  Michele backed up the need for shared industry schemas based on some of her experienced.
• John Hooper was interested in Pat Helland's assertion that services should not share transactions, which led into the difference between WS-Transactions (classic two-phase commit) and WS-BusinessActivity (compensating transactions).
• A delegate who was learning about the topic came up to the chairs and spoke about what he'd learnt at TechEd.  This was great to hear and generated a lot of discussion.  Clemens' presentations clearly had some impact with many in the audience.

Here's me with David Chappell after the session.  I've been a fan of his since reading Understanding ActiveX and OLE when I started Microsoft programming.

Clemens' session on his ProseWare application at TechEd Amsterdam last week was one of the best conference sessions I've seen.  Proseware is "an industrial-strength, robust, service-oriented example application that newtelligence has designed and implemented for Microsoft".  The application clearly demonstrates how to go about building services today with currently shipping technology, reinforcing that there's no need to wait for Indigo to start building service oriented apps!  I'm hoping that we see a public release of these bits soon on MSDN.

Points that grabbed me:

• Guidance on where to use messaging patterns: Use the OneWay pattern where there is no intelligent immediate reply or no reply is needed, use Request Response pattern where a message asks a question that can be answered immediately (in under a second) and use the Duplex pattern when a message asks a question that can be answered later as the service has capacity (e.g. anything that takes over a second).
• Clemens showed how to achieving 'near enough' reliable web services with HTTP and services that use MSMQ transactional queues behind the service interface.  If there were any problems placing the message onto the queue then an exception would be returned inside a SOAP fault response.  He optimised this further by using a void response type on the web service method, even though it was not marked as OneWay, so that if there were no problems placing the message on the queue then the web service response message would be small.
• ProseWare is based around a repository of XML schema files which he uses to dynamically generated the 'message' classes in the application using pre-build steps.
• All of the service projects shared these schemas rather than having any project references linking to the binaries (services are autonomous).
• The pre-build step inserts ISerializable attributes onto the message classes so that they can work with Remoting.
• These message classes are used as the only input parameter to all of the public web service methods.  These classes leverage XML Schema's support for allowing any element or any attributes to come through, which is a powerful way of allowing for future extension to the message.  Dare goes through this in one of his previous posts.  The XML Serialization attributes look similar to this:

[System.Xml.Serialization.XmlAnyElementAttribute()]
public System.Xml.XmlElement[] Any;

[System.Xml.Serialization.XmlAnyAttributeAttribute()]
public System.Xml.XmlAttribute[] AnyAttr;

• Clemens showed how to use the properties in COM+ 1.5 in XP/2003 to set the home directory for an application, meaning it is possible to use a .NET config file to store the config. He's blogged about this previously here and here.
• He created his own object pool to create something similar to the ADO connection pooling but for COM+ objects.  He simply pops a component out of the pool and pushes it back when he's done, avoiding the excessive overhead when calling new in a COM+ environment (which has to create the pipeline connections).  He has also blogged about this JIT activation pooling here and here.
• He mentioned how LRPC, which is used under the covers in ES, is the fastest way to go cross-process on a single machine.  In order to get this benefit you need to use the JIT activation pooling in order to avoid having the performance gains wiped out by the cost of creating ServicedComponents (again, something Clemens' previously blogged).
• The nice part was that Clemens had done the hard yards and built an application installer that handled created the SQL Server and Windows user and group accounts.  He even showed where he'd found bugs in the OS and how he'd had to work around them.  Information like this is priceless (well, worth a lot of contracting dollars) if you're ever working in a situation where you need to achieve these outcomes.