I've been playing around with the Web Services Enhancements 2.0 (WSE) tech preview recently for an article I'm writing for Advisor. The feature that is the most pleasant suprise is the new messaging model to support the integration of Web services into more traditional applications. To support this paradigm, the WSE 2.0 programming model lets an application become either a "sender" of SOAP messages or a "receiver" or both. You do this using the SoapSender and SoapReceiver classes found in the Microsoft.Web.Services.Messaging namespace to encapsulate the process of communicating using SOAP using a URI.
In addition, the SoapSender and SoapReceiver classes support sending and receiving messages over three transports: using an in-process mechanism that doesn't touch the network layer, TCP, or HTTP. Each protocol uses a specific URI format. For example, in order to send a message to a Web service you could use the SoapSender class to send a SoapEnvelope (simply a DOM document and found in the Microsoft.Web.Services namespace) like so:
Dim e As New SoapEnvelope()
e.Body.InnerXml = "
e.Context.Action = "urn:www.quilogy.com/getrates"
e.Context.ReplyTo = New _
Dim sender As New SoapSender(New Uri("soap.tcp://localhost/rates"))
Here's the resulting SOAP message that's sent:
<q:GetConsultingRates xmlns:q='urn:www.quilogy.com' />
To receive this message an application would have to create a class that inherits from SoapReceiver and overrides the Receive method:
Public Class RatesReceiver : Inherits SoapReceiver
Protected Overrides Sub Receive(ByVal e As SoapEnvelope)
'Extract the parts of the SOAP message using the DOM
The receiver class can use the SoapEnvelope.Context.Action to determine what action to take and parse the SOAP envelope to extract parameters. A receiving application must also register the URI to process messages for using the SoapReceivers class:
Dim r As New Uri("soap.tcp://localhost/rates")
Dim rates As New RatesReceiver()
Of course, once the sender sends the message to the receiver, the roles are reversed and the receiving application must then become the sender by constructing a SOAP envelope and sending the response via the SoapSender class.
The cool thing is that if an application registers both endpoints for this communication then WSE makes the calls entirely within the process and doesn't invoke the network layer.
WSE 2.0 also includes SoapClient and SoapService classes to make the process of sending and receiving a little easier and these look forward to the classes in Indigo. Of course, in practice one would likely want to further abstract the invocation of the SoapClient class so the client doesn't have to work with the SoapEnvelope at all.
I see alot of potential in this messaging model since it allows for the creation of true service-oriented applications by providing the underlying infrastructure on which you can build. For example, you could use this model to create a seamless application where the presentation layer communicates in-process with the domain layer when offline and uses HTTP when in a connected environment.