none
help understanding usage of Service Broker

    Question

  • Hello,

    I am trying to learn/understand Service Broker and how it works and more importantly, what is the practical use of it?
    Just like anything else, I googled on this and I kind of got very basic understanding on how to configure one(again, very basic) but what I could not comprehend in what Situations it is used??

    Most of the videos/blogs, I referred say it is 'asynchoronizing messages systems that can send messages across sql sever databases ....' but what I do not understand like where is it required??
    Does any body have good references that explain in what situations service broker is used?? Any help is appreciated.

    In short, I would like learn about the practical usage of Service broker. Thank you


    Hope it Helps!!

    Tuesday, November 19, 2013 3:28 PM

Answers

  • say it is 'asynchoronizing messages systems that can send messages across sql sever databases ....'

    Yes, that's one of the main advantages.

    Additonal to Jason a real example from my site: We have a ERP software and when a user changes the description of an item, a PDF file will be created.

    This is started by a trigger, which simply sends a message to a queue; done within a millisecond. A process triggers on queue notification, exports the description, converts it's to PDF and copy the file to the final destination; this take for a file about 20 second. Imagine this would be done syncron in the trigger; this would kill every performance, especially if you update the data in a batch.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Marked as answer by Stan210 Tuesday, November 19, 2013 5:54 PM
    Tuesday, November 19, 2013 3:52 PM
  • I've written a couple of service broker applications, and the main benefit I have seen is asynchronous processing and scalability.

    For example, let's say you want to have some expensive process (like calling a powershell script through xpcmdshell) run whenever a certain condition is met.  Without service broker, the calling transaction has to wait for that long process to complete.  With broker, you fire a message off and the outer transaction completes.  The expensive or long-running process finishes outside the scope of that transaction, which is great for high-volume environments.

    For scalability, broker is very good at handling large numbers of transactions in order.  It always processes messages in chronological order, and the engine can spin up multiple instances of the queue monitor procedure if needed, so it dynamically multi-threads as volume dictates.

    It's also handy for sending data across servers. Using routes and endpoints this is very configurable and can be easily failed over to a different server or database with a few small changes.

    • Proposed as answer by SathyanarrayananSMVP Tuesday, November 19, 2013 3:48 PM
    • Marked as answer by Stan210 Tuesday, November 19, 2013 5:54 PM
    Tuesday, November 19, 2013 3:39 PM

All replies

  • I've written a couple of service broker applications, and the main benefit I have seen is asynchronous processing and scalability.

    For example, let's say you want to have some expensive process (like calling a powershell script through xpcmdshell) run whenever a certain condition is met.  Without service broker, the calling transaction has to wait for that long process to complete.  With broker, you fire a message off and the outer transaction completes.  The expensive or long-running process finishes outside the scope of that transaction, which is great for high-volume environments.

    For scalability, broker is very good at handling large numbers of transactions in order.  It always processes messages in chronological order, and the engine can spin up multiple instances of the queue monitor procedure if needed, so it dynamically multi-threads as volume dictates.

    It's also handy for sending data across servers. Using routes and endpoints this is very configurable and can be easily failed over to a different server or database with a few small changes.

    • Proposed as answer by SathyanarrayananSMVP Tuesday, November 19, 2013 3:48 PM
    • Marked as answer by Stan210 Tuesday, November 19, 2013 5:54 PM
    Tuesday, November 19, 2013 3:39 PM
  • say it is 'asynchoronizing messages systems that can send messages across sql sever databases ....'

    Yes, that's one of the main advantages.

    Additonal to Jason a real example from my site: We have a ERP software and when a user changes the description of an item, a PDF file will be created.

    This is started by a trigger, which simply sends a message to a queue; done within a millisecond. A process triggers on queue notification, exports the description, converts it's to PDF and copy the file to the final destination; this take for a file about 20 second. Imagine this would be done syncron in the trigger; this would kill every performance, especially if you update the data in a batch.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    • Marked as answer by Stan210 Tuesday, November 19, 2013 5:54 PM
    Tuesday, November 19, 2013 3:52 PM
  • Thank you Olaf, Jason and Raju. 

    Olaf/Jason,

    do you have any ideas on few scenarios I could create in my test envirnoment to play with SB at a basic level. I think that would help me in understanding better. I understand the therotical part of SB like sends message and the recevier does some "action" after the message is recevied.  With a simple db like Adventureworks, could you think of how I can use SB. Any help is highly appreciated.


    Hope it Helps!!

    Tuesday, November 19, 2013 4:11 PM
  • I wrote a little example as a blog article, but it's in German; you may use an online translator to get it in your preferred language: http://olafhelper.over-blog.de/article-26077104.html


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Tuesday, November 19, 2013 5:40 PM
  • Thank you. I will look into it..

    Hope it Helps!!

    Tuesday, November 19, 2013 5:54 PM
  • two scenarios I could suggest

    1) make a scenario where you have an orders system, which sends messages to a warehouse system to check  stock, and a credit system to check balances. And the order is only dispatched when both systems send approval messages

    2) I have a service broker implementation that sends messages from 1500 remote sites to a central repository, much like replication would, but its easier to manage once the code is written, than to try an administer replication for 1500 sites.    This scenario takes careful planning, and it was robust naming conventions which made it infinitely expandible.  i.e I don't care if its 1500 sites or 2000.   By building a deployment of scripts and correct naming conventions, the customer can just keep adding.   Another bonus was not having to open up the usual port 1433 to accept replication (and any other tsql) on the firewall to all 1500 sites, but to use broker endpoints, which can be any port, and broker endpoints only accept valid broker messages (with certificate encryption).. so in theory, way more secure...  The downside of service broker is that its hard to troubleshoot if something goes wrong, and its 100% custom code....  No replication wizard etc...

    Tuesday, February 04, 2014 7:28 AM