An Example
A short example involving the aforementioned order-entry application illustrates how the messaging process works. To keep the example simple, let's focus on the entry of an order into the order-entry subsystem and the printing of a pick list at the warehouse as part of the order-fulfillment subsystem. Figure 3 shows the physical configuration of the application.
The order-entry application enters the order and checks inventory at the front end while the customer is still on the phone with the order-entry clerk. When the order-entry process is complete, you need to send the order to the warehouse for fulfillment processing. This warehouse process involves printing a pick list, using the pick list to pull the products in the order, then packing and shipping the products.
Before invoking any application code, you have to write Service Programs, and a developer or administrator has to set up database structures to define Messages, Dialogs, Conversations, and Conversation Groups. You need to add these definitions to SQL Server at the sending and receiving Service Broker locations.
Figure 4 shows schematically the Order Entry and Pick List Service Programs. The Order Entry Service Program simply begins a transaction, initiates a Dialog with the Pick List Service Program, sends a Message to it over the Conversation, then commits the transaction. All processing of the Message then occurs asynchronously, leaving the original program to continue with other processing. As I mentioned, the Pick List Service Program is either pre-started by some outside SQL Server transaction or process or started by an incoming message. Figure 4 shows the Internet/intranet and Service Broker infrastructure as a cloud connecting the two Service Programs.
Like a Windows application, a typical Service Broker application follows a standard message-processing loop design. On startup, the program enters an endless loop, waiting for Messages to process. This loop is broken only when one of three things occurs: Either the program receives a Message, a preset timeout interval expires with no Messages received, or the program terminates based on the number of Messages it has processed or some other application-specific criteria.
The first thing the procedure does in the message-processing loop is issue a database BEGIN TRANSACTION operation. This operation protects the entire Message send-and-receive process in a transaction and lets Service Broker automatically replace the Messages in the Queue if a failure or rollback occurs.
After starting a transaction, the procedure waits for either a Message or the expiration of the timeout interval. If a timeout occurs, the program simply rolls back the transaction and terminates. If a Message comes in, the procedure processes it. In this case, the application logic does whatever is necessary to satisfy the request and may return a response Message to the originator or other cooperating application. Finally, after processing the Message, the program ends the Conversation, commits the transaction, and continues waiting for another Message or for a timeout to occur.
Service Broker's Place in the Middleware World
Now that you see how Service Broker works, one natural question is, How does Service Broker compare with other middleware products such as MSMQ? Microsoft's answer to this frequently asked question is that Service Broker deals with transactional delivery of messages between multiple databases. MSMQ, on the other hand, lets applications send messages between distributed programs where a database might not be involved. You should use Service Broker whenever you have distributed, multidatabase SQL Server applications that perform such tasks as
- data collection and database update
- application deserialization (e.g., parallel stored-procedure execution)
- SQL Server farming (e.g., distributing requests to multiple servers)
- deferred processing (e.g., time-shifting workload to off-peak hours)
I've only scratched the surface of Service Broker's capabilities. Service Broker supports strong security features that I didn't discuss in this article. It also comes with performance-monitoring and troubleshooting functionality and many other capabilities that wouldn't fit in this overview article. I hope this introduction motivates you to dig deeper into SQL Server Service Broker's capabilities and see what it can do for you and for your company.
End of Article
Prev. page
1
2
[3]
next page -->
