Conversations. Just as Messages are the building blocks of Dialogs, multiple Dialogs can be grouped together (at the time that they're defined) into Conversations. A Conversation is a long-running, reliable, asynchronous exchange of Messages between two endpoints. It can involve multiple Dialogs.
Conversation Groups. Every Conversation is part of a Conversation Group. A Conversation Group is a group of Dialogs that perform some set of related tasks, usually to implement a business function. An example is the order-fulfillment process that needs to begin after an order-entry application accepts an order. The originating Service Broker assigns a Conversation Group ID (CGID) to each Conversation Group. This CGID identifies a group of Conversations that work together to accomplish a distinct task. The CGID is also a globally unique ID (GUID) that the receiving procedure can use as a database table key in case the application needs to maintain any kind of application state related to processing the Message. If maintaining state is a requirement, the database is the natural place to store this state, and the application can use the CGID as the key of a table that stores the state information.
From the database standpoint, a Conversation Group defines as a unit a grouping of Dialogs that in turn define a logical unit of work that Service Broker can complete or roll back. For example, an order-entry application might have three separate processes: order entry, order billing, and order shipping. These three entities define a Conversation Group. With this architecture, you can accept and validate an order while the customer is on the phone. Then, the order-entry subsystem can engage in Dialogs with the billing and shipping subsystems in parallel and asynchronously. When each of those processes completes, they can send Messages back to the order-entry subsystem, indicating that the transaction is complete and that SQL Server can commit it.
Queues. Queues store Messages at the originating location before transmission and at the destination before processing. Service Broker uses both send and receive Queues to protect the end-to-end integrity of Messages. Queues hold multiple sets of related Message types.
Service Programs. Service Programs are responsible for performing the processing logic associated with writing and reading a Message in the Queue. A Service Program can be either a stored procedure in the target database or an external program. An incoming Message can activate the Service Program, or it can be started by some event external to SQL Server such as a program execution request issued by a scheduled task. Service Programs run as part of each SQL Server 2005 instance.
One major benefit of this architecture is its integration of the messaging system's management and operation within the database. Thus, when you're backing up and recovering the database or transporting the database to another system, the state of the Queues and of the application automatically travels with the database, and the same procedures that protect the database's integrity can protect the Queues. This means that the Queues are backed up, recovered, and so on along with the database data. This integration with the database automatically takes advantage of advanced database features such as log shipping, database mirroring, and failover clustering.
Routing and Load Balancing
Although Conversations and Dialogs move Messages between two Service Broker instances, the process might involve several intermediate Service Brokers. For example, the originating Service Broker (SB1) in Figure 2 sends a Message to the receiving Service Broker (SB4 or SB5). However, this Message might go through one or more intermediate Service Brokers, such as SB2 and SB3, before reaching the target Service Broker.
The advantage of this architecture over a classical message-handling architecture is that the Service Brokers can route encrypted data to the next Service Broker in a chain without having to fully decrypt the data in transit. In contrast, an external messaging system such as MSMQ has to decrypt, analyze, re-encrypt, then forward the message at each intermediate point. This ability to route encrypted data without decrypting it makes the Service Broker solution more efficient.
You can also use Service Broker to improve scalability by implementing load balancing. By defining several target Service Programs, you can spread the messaging load across multiple Service Brokers at multiple target locations.
Prev. page
1
[2]
3
next page 
