Service Broker Presentation

In the next few posts I want to cover some interesting things I'm doing with Service Broker.  

I recently architected and rolled out Service Broker as a replacement for various queueing and asynchronous execution models that did not scale.  It was a tough sell initially because we already thought we were SOA (Service-Oriented Architecture) and were already using JMS.  What I showed was that using JMS doesn't automatically obviate the need for asynchronous messaging in the data tier.  And just because we are already SOA doesn't mean we can't buy a lot of performance by going SODA (Service-Oriented Data Architecture).  We would want to use Service Broker and go "SODA" for anything that is heavily data-dependent and asynchronous.  

The roll out of Service Broker was a complete success.  Like any good architect, I started small with one section of our application that was already asynchronous to the user.  The problem was, it was still synchronous to the Java tier.  I call it "asynchronously synchronous".  Our largest customer had a full 1/3 of their JVMs running at zero CPU utilization and totally thread-starved.  All threads were waiting for JMS-called stored procedures to finish.  I rewrote this so JMS simply popped a message onto an SB queue and then returned control for further Java processing.  After the stored procedures were finished the result sets were passed to another JMS queue for further processing.  So we wrote a push queue in Service Broker that would automatically send the results of the procedures to the JMS queue.  It would have been faster and quicker to write a pull queue and poll for changes, but we were all very excited to demonstrate as many of the features of SB as possible.  

Doing this rather small amount of code refactoring we were able to determine that we can decommission about 1/3 of our JVMs.  That's a huge savings in licensing for WebSphere and Windows.  And it only took about a month from design to rollout.   

There are lots of Service Broker presentations on the web, but what I haven't found is a presentation that argues the merits of Service Broker side-by-side with JMS (or equivalent).  Our shop, like many, is also leery of putting any additional processing logic at the data tier.  The concern is that the data tier is already generally the bottleneck, so, why make it worse?  I believe I address those concerns in this presentation as well.  You can download the ppt file here.  Here are the slides: