DispatchFailed

When trying to understand why your application doesn't seem to be processing the messages you are sending, it can be helpful to detect and monitor message dispatch failures from the WSE2 messaging layer. This is the purpose of the static SoapTransport.DispatchFailed event. You can hook this event anywhere in your application and have your callback invoked when a transport fails to dispatch an incoming message to a registered input channel. Here's the code to do this:

[MTAThread]
static void Main(string[] args)
{
SoapTransport.DispatchFailed +=
new SoapTransport.DispatchFailedEventHandler(OnDispatchFailed);

...

}

static void OnDispatchFailed(object sender, SoapTransport.DispatchFailedEventArgs e)
{
Console.WriteLine("Dispatch Failed!");
}

The sender is the transport that failed to dispatch and the DispatchFailedEventArgs has a property called Message that is the SoapEnvelope that could not be dispatched.

Note that this event is not fired by the built-in HTTP transport that is hosted under ASP.NET. It is fired by soap.tcp and soap.inproc. Custom transports that use the SoapTransport.DispatchMessage method to dispatch incoming messages will also fire this event.

Soap.Udp 0.1

This is the first release of a custom WSE 2.0 transport that I have been writing to support SOAP over UDP, including IPv4 multicast. You can download the source here.

And yes, I know it's not perfect (that's why it's release 0.1), but hopefully it will illustrate some concepts for those that are writing other custom transports.

Note that the source code is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License.

A SOAP MQ Transport for WSE

John has a link to a SOAP MQ Transport for WSE 2.0. An interesting read for me as I've recently been looking at the transport code inside WSE 2.0 and giving some more consideration to transports that are, in essence, uni-directional. This has led to some improvements in the dispatching engine to better handle the WS-Addressing headers and make responding over uni-directional transports much simpler. Transport registration is also handled via config now instead of just the programmatic model.

One of the things we've learned from this exercise is the need to get transports running with true async I/O. Anyone who looks through the Tech Preview carefully enough will see that parts of the messaging layer handle async mode by using BeginInvoke on a delegate that then calls code that does I/O. We defaulted to this model in some places to give people a bit of a jumpstart but it doesn't scale well if the I/O blocks - as more connections are made, more threads are consumed and block. The application just can't scale. Suffice to say that several parts of the transport code are getting an overhaul.

I was also very happy to read some of the comments about what you can do with 2.0 - "message-oriented programming model, allows implementing of peer to peer programs, or event driven applications. Web services that leverage WSE can now be hosted in multiple environments including ASP.NET, standalone executables, NT Services, etc." - as this was something that I personally wanted to show everyone - SOAP and the WS-* protocols can be applied in lots of different ways beyond plain request/response models and to lots of different application types. There's a whole new world waiting...if only I had more time to write more code...

WS-Trust and WS-SecureConversation Sample

I've just finished up a sample that illustrates the WSE 2.0 Tech Preview support for WS-Trust and WS-SecureConversation. It does some things that the samples in the product don't fully illustrate including:

• inheriting from the SecurityContextTokenService to create a service that is it's own token issuer,
  
• inheriting from the SecurityContextTokenServiceClient to build a custom SoapClient for the service,
  
• using two DerivedKeyTokens for each request and response to generate new signature and encryption keys for each exchange
  
• implementing all the above using TCP as the transport
  

Of course, it's just a sample and doesn't include everything that would be needed for a production implementation, for example full authentication and authorization. You'll need Visual Studio 2003 and the WSE 2.0 Tech Preview installed to build and run right out of the gate; if you don't have VS 2003, it should be possible for you to compile the code from the command line or use your favourite tool. I hope to talk a little more about some aspects of the code in future posts.