Looking for SQL Service Broker Users


Are you someone that’s interested in using Service Broker together with WCF? If so, would you like to answer a few questions? I went surveying for SSB users at a Microsoft MVP event last night, but now is your chance to participate as well. I got to talk to five or six casual and not-so-casual SSB users, including SSB champion enthusiast Harry Pierson (second place: Jesus Rodriguez). Here are some points that I picked out where I’d like some more data.

  1. Are you interested in SSB because you’d like to have your service closer to the database? How close is close enough to the database?
  2. Are you interested in SSB because you need durable, duplex messaging between two services? Do you need exactly-once-in-order message delivery?
  3. Are you interested in using SSB from WCF because you want a better asynchronous messaging experience than MSMQ? What makes you prefer SSB to other queuing products?
  4. Are you interested in having your data contracts defined in WCF, SQL, or both?
Comments (4)

  1. Michael Collins says:

    I run what, I guess, would be called a micro-ISV.  I have a corporate website that is hosted by a third-party web hosting provider.  I have a homegrown CRM solution that interfaces with my website.  As new users sign up, or as users interact with my website, my website sends event information to my CRM system for tracking, such as contact requests, requests for evaluation licenses, etc.  I am currently using service broker for this solution.  My website will post events to the service broker queues, and periodically, my CRM system will connect to the database and download and process the events.  It would be great if I could implement scenarios like this and others using service broker.

    To answer your fourth question, I would probably prefer to define contracts in both WCF and SQL.  I usually like to define things like schemas and contracts in SQL as an extra check, as well as at the service layer.

  2. terryweiss says:

    Nicholas, for certain operations that are set- or batch- based, you can’t get close enough to the database for efficiency.

    The problem is that SSB looks, walks and smells like a service: it is asynchronous, it uses messages and contracts, defined dialogs, stateless etc. And what you really want is to be able to construct the system such that it doesn’t matter what service responds to a message, but with MCF, ASMX and SSB, you have to sweat the details because each are different.

    I would like to be able to plug a message into a queue and decide dynamically whether to route the message to a sproc or to an external service. And I don’t want to change the structure of the message to do so.

    As for SSB – while there is great appeal for MSMQ, small and midsize (and some large ones I have been in as well) companies often don’t have the skill to manage it and therefore are afraid of it. Ditto most developers. SQL is almost ubiquitous, SSB is easy to learn and T-SQL is easier to learn and to deploy.

  3. Mathew Adams says:

    Hi there. We are looking at WCF and SSB to replace our current (proprietary) messaging stack. Our main interest is durable, duplex messaging between two services with exactly-once-in-order (from a given endpoint) message delivery. We’ve got a hub-and-spoke (i.e. one to many) delivery model. We got our fingers burned with MSMQ back in the day – clients just weren’t familiar with the kind of management and monitoring tasks they needed to perform, so a hand-rolled SQL Server 2000 based solution worked for us.

    However, we are now looking to move forward, and WCF+SSB appeals because a) we’re not in the "fundamentals" business, so why would we want to build a messaging stack these days b) it offers familiar manageability

  4. Sam Gentile says:

    Yup, I’m still stuck in Seattle and I still feel like crap. Tomas just went off to the airport and I