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.