WSE2 is finally out, so I’m finally out from underneath an NDA. Phew, I feel like I can breathe again…
Most of my work with WSE2 thus far has been dealing with the core messaging model and transport system. I’ve learned a lot from working with it, and I’ll be blogging about some of the interesting things I’ve noticed. However, before I dive into the gory details, it’s best to describe an overview of the WSE2 messaging architecture.
WSE 2.0 offers three different layers of abstraction for dealing with messaging. Which layer you choose to program against depends largely on who you are and what you’re trying to accomplish. People who have been playing with the Tech Preview bits will recognize the following:
The Service Model: This layer is at the top of the abstraction stack, and is closest to ASMX in terms of programming model. At this layer, you’re dealing with classes and methods. On the server side, you have the SoapService base class and methods decorated with [SoapMethod]. At the client side, you have the SoapClient base class. If you use the service model, you can build secure services with full support for policy, all without ever having to touch a SoapEnvelope unless you want to.
The SoapPort Model: This layer is more message-oriented than method-oriented. At this layer, you’re not using [SoapMethod]. Instead, you’re inheriting directly from SoapReceiver and implementing the Receive( SoapEnvelope e ) method. Similarly, on the client side you’ve got SoapSender and its single Send( SoapEnvelope e ) method. At this layer, the XML message is right there in your face, ready for you to do whatever you want with it. The SoapService class from the Service Model itself inherits from SoapReceiver, so the Service Model is really just a specialization of the more abstract SoapPort model. The pluggable Input/Output filter pipeline (which, IMHO, was the coolest feature of WSE1) also operates at this level of abstraction.
The Transport/Channel Model: This is the lowest-level programming model. It’s unlikely that you’ll every really have to touch this unless you’re implementing a new network transport for WSE2. Code at this level is concerned about taking messages off the wire and dispatching them to the appropriate SoapReceiver for processing. This layer operates almost entirely behind the scenes, but does a lot of really important work.
Architecturally, the biggest change since the Tech Preview bits has occurred inside the Transport/Channel model. A lot of this change seems to have been driven by the adoption of the WS-Addressing spec and the subsequent pervasiveness of EndpointReferences. The Transport/Channel model that shipped with WSE2 is nothing short of extremely cool, and I’ll be posting more about the things that excite me about the new architecture over the course of the next few days. I’m also putting the finishing touches on some sample code that implements a soap.smtp:// transport, which I’ll post when it’s ready.
