Comparing Service Broker with other messaging technologies
An often asked question about SQL Service Broker is how it compares with other products offered by Microsoft such as MSMQ, BizTalk server, WSE and its successor Indigo. So I thought I’ll take a shot at answering this politically provocative question. [These are my personal opinions].
First, Service Broker is not just about messaging. Rather it is a solution for using SQL Server as a platform for building asynchronous database applications. Several large applications like SAP and PeopleSoft leverage database tables for building queues for asynchronous processing. Service Broker implements queues as first-class database objects to provide high-performance and ready-to-use features such as ordering, locking and activation. As applications scale-out, distributed asynchronous systems require reliable messaging. Service Broker provides such messaging in the database engine using a binary transport protocol.
Comparing with BizTalk Server
BizTalk can also do reliable messaging between SQL Server instances; but in addition to that it can maintain state, orchestrate workflow, use a variety of transports, convert message types and change the message body. BizTalk can also do messaging between SQL Server and other data sources such as Web services, Exchange, etc. If the application simply requires transferring XML documents or binary messages between SQL Server instances, then Service Broker is sufficient but for any of the other features, BizTalk would be required. (It should be possible to build a custom BizTalk adapter for Service Broker.)
Comparing with MSMQ
MSMQ is available on a variety of platforms and can be used from any Windows application. It provides both transactional as well as non-transactional messaging with optional reliability. However, MSMQ applications that use transactional messaging as well as database access require two-phase commit for coordinating transactions. Service Broker allows applications to perform data updates and messaging in the same transaction over a single client connection. Service Broker also provides the notion of conversations, or long-running messaging and the limitation on message size is much larger (2GB). MSMQ offers an HTTP SOAP transport variant and can interop with MQSeries, but Service Broker only works on a proprietary binary protocol between SQL Server instances.
WSE is an add-on to the .NET Framework for providing Web service capabilities with evolving protocol specifications. Indigo is a project under development to provide communication infrastructure based on the Web services architecture. The focus is to provide a variety of messaging styles – reliable, ordered, secure, transactional, etc over a variety of transports – HTTP, SMTP, raw TCP/IP, etc with interoperability. The goal of providing a generic Web services standards-based communication platform goes beyond what Service Broker offers. However, Indigo cannot achieve the asynchronous connectivity of SQL Server applications that Service Broker provides. It is not hard to imagine using Service Broker as yet another transport-layer (channel) for Indigo or WSE to provide reliable messaging. Any volunteers for writing a ServiceBrokerChannel? (see MSMQChannel, UDPChannel, SMTPChannel)