I was recently involved in a proof of concept with a customer who was interested in sending lightweight messages/notifications to 8000 endpoints using the Service Bus.  The idea being that as soon as an item is ready for the endpoint, a notification or “tap on the shoulder” would be sent to the client end point, at which time they would do a pull for their larger message set (in our case, via BizTalk).  This could be used for areas such as a load approval notification, supply chain shipping notifications, etc.

One of the requirements was that the 8000 endpoints needed to be heterogeneous. Azure certainly allows these scenarios (see http://www.microsoft.com/windowsazure/interop/), but I wasn't able to find any good examples of how these different technologies were mixed together in a single solution.   I needed to prove out the concept for the customer that yes, you can indeed leverage Java, PHP and other REST-based technologies against the Azure Service Bus.

Here is what our solution looks like:

Starting from the bottom, we have a console host application (in black), called ServiceHoster in the solution.  This is what exposes our endpoints.  In this particular case, we are exposing two end points per known relationship, one called Service1, and the other called Service1-buffer.  In the real world, we have a separate registration process where client registers with an internal system and can elect a particular endpoint type; however, in this scenario, we just want to prove out what is possible.  The host is actually hosted inside of an Azure worker role to give us the scalability that a console host doesn’t provide.

On the right side of the picture is the sender application (in yellow), called MessageSender in the solution.  This application works by sending messages at randomized intervals to both types of endpoints (Service Bus, and Message Buffer).  Again, since it is just a simulation, imagine this is an event that is fired within BizTalk and kicks off an orchestration.  The orchestration fires for a known, previously registered endpoint and a message is sent to that endpoint alone (as opposed to both Service1 and Service1-buffer as shown here).

Finally, on the left side of the picture are our heterogeneous clients. The client in blue is our NETRichClient application.  This application is event based, and leverages the netTcpRelayBinding binding to talk directly to the WCF service and have a callback fired back to it so it can react to an event.

The other two clients use polling to talk to their respective message buffers.  One client in red is a .NET message buffer client, called MessageBufferClientSample in the solution. This client opens a connection against it’s Message Buffer and then constantly polls to perform a destructive read against any messages that are present in the buffer.

Finally, and most importantly for the interoperability portion, is the Java client. I chose to leverage http://www.jdotnetservices.com/, which provides an open source AppFabric SDK for Java developers.  In fact, I basically just made a few modifications to their PollingService sample that is provided in their demo application.

Side note, before you ask, my only modifications were to enable logging in the startPolling() method; a few println() statements; configuration changes to provide my Azure namespace, owner, and shared secret; and I commended out the createMessageBuffer(..) call because I created the buffer in the ServiceHost application. But that’s all, I promise.

To enable logging in the solution, just make the call (in UseService.java):

private static void startPolling(String messageBuffer){

// enable logging
com.persistent.appfabric.common.LoggerUtil.initLogging("C:\\appfabriclog.txt");

// other code below

}

Similar to the MessageBufferClientSample application, the Java app also performs a destructive read on the message in it’s buffer.

What are we really trying to achieve here?  We are actually trying to achieve lightweight pub/sub with topic based notifications and durable messages – but that’s not coming until vNext.

Running the Code

When you open the Visual Studio solution, all of the EXE projects should be set to start at the same time.  The console should output that “All Service are Started.”  After that happens, click the Start button in both the the NETRichClient (Service1) and the MessageBufferClientSample (Service2-buffer) applications.  Also start your java application, via the command:

java –jar [path_to_polling_sample_jar] Service3-buffer start

The Java client should output that it has started polling.  In the statement above, it is polling against the Service3-buffer endpoint.

What is Happening

What does this look like when everything is running?

What is happening here? Basically, the sender sends messages to Service1,Service1-buffer, Service2, Service2-buffer, etc.  If someone is listening on Service1, Service2, or Service[N], great. They will receive a callback .  If not, that’s OK and the message is lost (fine for this particular scenario). 

The message also gets pushed to Service1-buffer, Service2-buffer and Service[N]-buffer.  If the message is read and destroyed by the time the MessageBufferPolicy allows, then the client can react to that notification.  If not, the notification expires after a configured period of time and is removed from the buffer (the Service Bus handles this for us).

So, as you can see, the Message Buffer is actually the way we achieve interoperability across the Service Bus to multiple types since the buffers actually leverage REST under the covers.  But you can also see how it could be advantageous to have the type of eventing that the netTcpRelayBinding binding provides.  Hopefully this shows you how you can achieve both.

You can download the C# code here.