When to use SQL Server Service Broker

Use SQL Server Service Broker for asynchronous transactional messaging from applications where transactional throughput and scalability is required, as well as rehydratable and failure resistant transactional consistency is required.  The example would be that an ASP.NET web application should be able to accept web orders and send the orders to service broker.   If the SQL Server goes down, the ASP.NET application should be able to continue to take and queue orders and submit them to the SQL Server when it becomes available.  This also increases throughput and scalability because SQL Server will process the messages when it gets to them.  Also, SQL Server, after a failure will come back up and continue to process the orders.  When users visit the site, the ASP.NET application can then read the response to messages and give users the status of their orders.

Comments (2)
  1. Mr.Null says:

    Fabulous stuff Eric..A large part of my work day is consumed over dealing with the after effects of a poorly designed enterprise application that is in dire need of a more consistent and scaleable transactional messaging design. We could benefit greatly by a defferred processing model. This sounds like a path worth exploring. I’ll have to mention this it to one of my colleagues if I can get past all the buzzing.

  2. Eric Charran says:

    Glad to hear it! Look for news from Microsoft coming soon about federated database server architecture. I’ll try to post more about it in the future, but essentially its all about extending service oriented architecture into the database layer, enabling SQL Server as a hybrid applicaiton platform. Service Broker is essential as part of this.

Comments are closed.

Skip to main content