次の方法で共有

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

  • Anonymous
    January 13, 2006
    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.
  • Anonymous
    January 13, 2006
    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.