What is Service Broker?

Question

Can someone explain to me what Service Broker is please? And what is the purpose of it? How is it different to send mail? Ive read through alot of material, and I understand that its about sending messages, but I dont understand the point of writing code to send and receive messages on the same system. What is the real life use for this?

*sorry if this sounds idiotic.

Thanks!

---

You are so wise...like a miniature budha covered in fur. -Anchorman

Answer 1

This should give you some idea for starters: http://technet.microsoft.com/en-us/library/ms166104.aspx

Answer 2

Service Broker doesn't have anything to do with e-mail.

Forget the terminology in the middle of this.  You write an application to interact with a database.  That application performs INSERTs, UPDATEs, and DELETEs in order to modify data.  In a typical application design, your application connects, issues a request to SQL Server to execute an INSERT/UPDATE/DELETE, waits for SQL Server to complete the request, return a result, and then your application continues on.  You could also design your application to do the following: connect to your SQL Server, the INSERT/UPDATE/DELETE request to a table in the database, and then continue on with whatever else it is coded to do - in the background, some other process reads the contents of the table you wrote the INSERT/UPDATE/DELETE to and executes the actual statement that you placed in the table.

The advantage of the second design option is that you don't have to wait for the request to be completed before your application/user can go on to the next task.  The disadvantage is that your application/user never received positive confirmation that their request succeeded.

In Service Broker terminology, that request that you sent (INSERT/UPDATE/DELETE) is a message.  The table that you wrote the INSERT/UPDATE/DELETE to is called a queue.

You use Service Broker, or any message broker (MSMQ for example), when you want to perform reliable asynchronous processing.  You don't need to wait for the action you requested to be performed, you just need to know that it will get done.  When you write a check to pay your credit card bill, you aren't going to stand around and do nothing until you receive confirmation that the credit card company applied your payment to your account.  You put the check in an envelope, stick it in your mailbox, and then forget about it.  Your mail carrier is responsible for picking up the mail.  The postal service is responsible for all of the actions necessary to transport your check to your credit card company.  Someone at the credit card company is responsible for opening up the letter and making whatever entries in their system that are necessary to post the payment to your account.  Someone else at the credit card company is responsible for depositing the check in their bank account.  Their bank is responsible for communicating with your bank and performing all of the actions necessary to actually transfer funds from your bank account to your credit card company's bank account.  Etc.  This all boils down to asynchronous processing.  All you have to do is send the directive and then get on with your life, you don't have to hang around and be involved in receiving confirmations of every step in the process.

---

Mike Hotek BlowFrog Software, Inc. http://www.BlowFrogSoftware.com Affordable database tools for SQL Server professionals