CTS400 Using Web Services Enhancements v2.0 for Messaging Over Multiple Machines and Networks

My notes on this nice talk by Keth Ballinger

The first 15 minutes was a bit slow to get going in that we talked about messaging at a high level before drilling down to the subject: WSE 2.0. Amongst this Keith said that the solution to messaging problems is less transparency and more explicitness.  Transparency means you see an object and you can't really tell that it's remote.

Keith put up his IP address 10.4.2.28 and built a one way method, except he skipped the one way bit.  It's a web service method to accept suggestions.  Lots of people in the room had notebooks with wireless networking, but no one could get to Keiths machine.

using System.IO;
using System.Web.Services.Protocols;

[WebWethod]
[SoapDocumentMethod(ParameterStyle=SoapParameterStyle.Bare]
public void Suggest(string Suggestion)
{
 // take the string and write it to a file
}

Now he wants to create a listbox on a windows form that accepts suggestions and shows them in the list.  This can be done with WSE 2.0.

using Microsoft.Web.Services2.Messaging;

ISoapInputChannel channel = null;

Form_Load()
{
channel = SoapTransport.StaticGet(new SoapChannelCapabilities.Listening()"soap.tcp://some_url );
}

Button1_Click()
{
SoapEnvelope Message = channel.Receive();
string suggestion = message.GetBodyObject();
ListBox1.Add (suggestion);
}

After creating this winforms app Keith added a proxy method to his Services1.asmx.  The proxy method had a one line call that forwarded the message to the soap.tcp url created above.  It was pretty nice.

Talking about errors, today you have to extract fault codes from the soap faults that are returned by a failing web service and decide what to do about that.  Keith hopes that this will be easier in the next two years.

Next keith talked about gateway design patterns which just means a web service that receives a message and sends it somewhere else, maybe based on content.

Another design pattern is pub/sub.  Which is pretty will known in messaging circles.  There are two pub/sub models 1) the server pushes the data with the event notification and 2) the client pulls the data after the event notification.

Keith next showed us a coding demo using an eventing library that he's written.  He plans to make this downloadable.  It includes a user control that he dragged to the form and entered properties for the endpoint where the events are received it was soap:tcp://localhost:888/.  He updated the other windows client so that it sends an event to this endpoint when it comes in.  So now we have a web service service1.asmx that forwards the suggestion to a windows forms app which has a listbox showing the suggestions and also forwardes it to the "managers app" that receives an event to monitor all the suggestions.  Keith had a little bug in the first build, he entered the endpoint as a string in double quotes.  It needed to be a URI.  The corrected lines were:

source = new Eventing.EventSource (new URI("soap:tcp://localhost:888/"));
source.start();

Someone asked if this was like starting a port on BizTalk Server 2004.  Keith said this is just WSE a little light weight sort of thing, nothing as robust or industrial as BizTalk.

We all clapped when the demo worked, because it was pretty cool.

The dialog design pattern is a virtualised connection to someone for a lengthy period of time. If you use dialogs and queues together you can have messages come and go on the equivalent of a permanent virtual connection.  He calls the queues databases.

Long running operations is a key gain of messaging.  Code looks like this (there was no time for the demo).

queue q = new MSQueue();
msg = q.Receive();