Following up on
post about SQL Server 2005 Service Broker, I've been writing a SOAP message
transport for the Web Services Enhancements (WSE) 2.0 to move messages using
ServiceBroker whilst still gaining advantage of the security, policy, addressing
features of WSE2.0.
It's important to say that this is purely for fun because it involves
installing WSE2.0 on top of the beta .NET Framework 2.0 and there is no way in
which the WSE team or the .NET framework team are going to support that kind of
The solution files and source code are all in this zip file here which you
can download and play with.
I started with the December Community Tech Preview of SQL Server 2005 and the
accompanying Visual Studio 2005 build - these are available from
MSDN Subscriber Downloads for
you to get hold of.
Following up on my
I've already created constructs in SQL for SoapMessage, SoapContract and
also that post details creating some services and queues: SendingService,
SendingQueue and ReceivingService, ReceivingQueue. The services and
queues aren't set in stone here but the SoapMessage/SoapContract stuff is baked
into my code.
The implementation is not perfect by any means and I'm sure that there are bugs in there
but it seems to work reasonably well in terms of both synchronously and
asynchronously sending/receiving on both one-way and two-way conversations.
In terms of the structure of it, there are a number of projects as below;
AsyncUtilities - a simple library with a couple of helper classes
that try and make the wrapping up of existing asynchronous code (such as
SqlCommand.BeginExecuteReader) easier to deal with.
BrokerUtilities - this provides a simple library that lets me send
and receive messages through the ServiceBroker. It's just using dynamic SQL
and ADO.NET 2.0
BrokerTransport - this implements the WSE2.0 transport itself,
making use of the BrokerUtilities library to send messages backwards
SQL Service Broker Scripts - this contains a single script to
create my SoapMessage and SoapContract definitions and a couple of test
Test Applications - contains 3 test applications. The first 2 are
simple console applications that send/receive messages through Service
Broker. The third is a Windows application that needs to be run twice and
then has a "conversation with itself" :-)
By way of some explanation (as there are no comments in the code)...
This project contains a class named AsyncResultWrapper - I
something very similar to this the other day - it's just a little class
to help make the wrapping up of another class which does asynchronous
operations a little easier.
The other class here is CompletedAsyncResult which is a trick
implementation of IAsyncResult which always will return "Done"!
immediately. There's a place where I need this later on.
There's a class called SqlUtility here which makes open
SqlConnections for me and transactional SqlCommand instances
which are expecting CommandText rather than stored procedures etc. Note that
the view here is that given a database server and a database name we can
generate a connection string and connect to the database (i.e. we just
assume that we can use integrated security) - if that wasn't the case then
you'd need to tweak this class and possibly also the soap.broker Uri
that I'll talk about later.
The other two classes are MessageReceiver and MessageSender
which are static classes offering methods for sending XML through
ServiceBroker. Essentially the methods look like;
void MessageSender.SendMessage( DatabaseServer, DatabaseName,
DestinationService, SendingService, XmlMessage )
List<XmlReader> MessageReceiver.ReceiveMessage( DatabaseServer,
DatabaseName, ReceivingQueue )
There are corresponding asynchronous versions of these methods as well.
Internally they're very simple in that each uses dynamic SQL to send/receive
messages and also there's an assumption in the sending of messages that each
single message will be sent in its own unique dialog and that it's ok for
the receiver to receive everything off its queue without checking
conversations. What I'm really saying is that I don't do conversations
Note also that when ServiceBroker is sending for you it needs to know
about the SendingService and the ReceivingService but when it's receiving it
needs to know about the ReceivingQueue. That's how the programming model
This implements the WSE 2.0 transport on top of the BrokerUtilities
library. Implementing a WSE 2.0 transport isn't too bad (at least at the
level that I've done my implementation here which is less than bulletproof).
The first thing you've got to do is go ahead and implement
ISoapTransport and you'll spot that in my BrokerTransport.cs
file. This interface is really about returning implementations of
ISoapInputChannel and ISoapOutputChannel based upon a transport
address that you're given by the WSE. Note that I make a fairly simple
assumption about the mapping between EndpointReference and
input/output channels which is probably not quite right in all scenarios.
In terms of the input and output channels - they're in
BrokerInputChannel.cs and BrokerOutputChannel.cs - these make use
of the underlying BrokerUtilities code to send/receive messages
synchronously or asynchronously.
The other interesting thing here is the BrokerUri class which is,
again, a very simple thing. In terms of addressing a SOAP message to travel
through ServiceBroker I've said that we'll use a Uri that looks like this;
soap.broker:<database server name>-<database
soap.broker:<database server name>-<database name>-queue:<queue
This needs a bit of explanation. When you're sending a SOAP
message you need to stick an address on it to say where it's going to. This
address will look like
soap.broker:myServer-myDatabase-service:DestinationService and that's
enough to get us where we want to go. However, ServiceBroker also wants to
know where did it come from? in order to begin a conversation.
Consequently, when sending, you still have to supply a ReplyTo
address on your SOAP message with something like
So, that's possibly OK and that's what my code expects. However, when
you're receiving messages with ServiceBroker you actually pull them
from a queue rather than receiving them "for a service". Consequently, if
you want to listen for SOAP messages with this transport you need to use a
Uri like soap.broker:myServer-myDatabase-queue:MyQueue.
If you run the sample applications you'll see how they're set up.
The main test application here is just called TestApplication. It
uses the "lower level" SoapSender and SoapReceiver model of
programming in WSE.
The idea is that you run two of these applications and they "talk" to
You set up each instance as a "sender" by specifing its service name and
the service name it sends to. You also need to have it listen as well so you
specify the queue that it reads from.
Once you've got two of them up and running you click "Ready to Listen" on
both of them and then on one of them you click "Send First Message". That
instance will then generate a shape, draw it and send it to the other
instance. That second instance will then draw it, wait a little while before
generating its "reply shape" and sending it back. They then just go back and
forward sending shapes to each other.
If you use my SQL creation script to generate Services/Queues then you'll
have the same names as me and that will let you use the "Send Defaults" and
"Receive Defaults" buttons to pre-populate the form with the right values
based on that script.
The second set of applications here are called Sender and
Receiver and they're console apps which speak to each other. The names
of the queues and services are baked into the code here so if you use this
you'll need to have the same queues/services that I have.
The idea here is that you run both Sender and Receiver.
Every time you hit return on the Sender it will send a message to the
Receiver which will then send a reply. Both sides of the conversation just
write their messages to the console when they receive them. Again, this is
using the "low level" SoapSender/SoapReceiver API rather than the higher
SQL Service Broker Scripts
This is a single SQL script which sets up the required SoapContract,
SoapMessage and, if you want to, also creates some services and queues
which the demos make use of.
If you want to make use of the transport it's important to remember that
WSE 2.0 doesn't just know about it but has to be told via way of a
configuration file change. The configuration file should look something like
this (as a miniumum);
Microsoft.Web.Services2, Version=220.127.116.11, Culture=neutral,
That's pretty much it - I'm not planning to do any more with this
transport unless someone comes back and has something interesting to do with it
or would like to change it. If someone does take it and improves it or fixes it
then feel free to drop a comment here saying that you've done so as it'd be
interesting to see.
Fri, Feb 25 2005 2:05 AM