Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

An Introduction to the Service Broker Expand / Collapse
Author
Message
Posted Wednesday, June 29, 2005 4:16 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, October 28, 2005 7:13 AM
Points: 18, Visits: 1
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sSampath/anintroductiontotheservicebroker.asp

HTH,
Srinivas Sampath
Blog: http://blogs.sqlxml.org/srinivassampath
Post #195536
Posted Wednesday, June 29, 2005 10:41 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, July 31, 2007 8:20 AM
Points: 885, Visits: 1

Great article.

Any thoughts on this as a MSMQ replacement?  especially with the release of MSMQ 3.0.  I have yet to find a solid roadmap for MSMQ, this may be the next "big step" for MS. 

 




Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"
Post #195584
Posted Thursday, June 30, 2005 2:26 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, September 29, 2014 4:53 PM
Points: 2,693, Visits: 1,207

Nice article.

However, I've yet to see a "real world" example for Service Broker, anyone got any links?

 



Hope this helps
Phill Carter
--------------------
Colt 45 - the original point and click interface

Australian SQL Server User Groups - My profile
Phills Philosophies
Murrumbeena Cricket Club
Post #195613
Posted Thursday, June 30, 2005 6:46 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, October 9, 2012 5:54 PM
Points: 99, Visits: 22

Thanks for this article. I am curious- how would you continually read the queue- Would you do so with an endless loop or a timer or something?

Thanks,
Nate

Post #195671
Posted Thursday, June 30, 2005 7:31 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, January 30, 2014 10:08 PM
Points: 1,038, Visits: 444

Any options for some sort of event driven queue - ie, when a message is received, SQL will call a stored proc?  Kind of like a trigger I suppose.

Sounds very much like MSMQ - I suppose it does make sense to store it in the DB.  I'm yet to find the time to actually play with SQL 2005   Of the hundreds of articles I have read about it, this is the first to talk about the service broker - nice to know it exists! 




Post #195716
Posted Thursday, June 30, 2005 11:15 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, September 25, 2014 9:01 PM
Points: 1,113, Visits: 705
Nate:

Look up WAITFOR in the SQL Server 2005 Books Online.


--
Adam Machanic
SQL Server MVP
SQLblog.com: THE SQL Server Blog Spot on the Web
Post #195958
Posted Friday, July 22, 2005 11:11 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, December 27, 2013 4:57 PM
Points: 10, Visits: 193

One of the biggest limitation of Service Broker, when contrasted with MSMQ, is that Service Broker in its existing form in Sql 2005 works only when the two End Points are in Sql Server 2005, whereas MSMQ is wide open to any application having capability to write to the queues not just database applications.

I will clear my last point using the following example. I have an application (written in C++ many years ago), which receives real-time info from a vendor. Currently, I write the info to MSMQ so that no matter how fast info comes, I do not loose it, so I just put it on MSMQ queue. Next, I have another application, in C#, which picks up the message from MSMQ and executes a Stored Procedure on SQL Server, which writes to a table, which has triggers. So, this C# app can continue to process these messages at its own pace.

If Service Broker would have allowed interaction from external apps, I would let my C++ app to write directly to a Service Broker queue. Subsequently, the internal logic within the Service Broker would take the message from the Service Broker queue and process them in the same manner as explained above (execute SP, trigger etc.). This way I can get rid of my C# application and rely solely on Sql Service Broker queueing.

Can the above task/process be achieved by using just Service Broker and bypassing MSMQ completely?

On a different note, I know I can enhance my application by removing triggers and posting messages to Service Broker queue and then process them one by one by reading them from the queue, and processing them further as explained above. This will scale my application better.

But my more imperative need is to have as few in-between applications as possible (like the C# app) and let Service Broker do the work what my app is doing in C#.

Any suggestions, improvements which I can achieve in my approach?

Thanks




Post #203634
Posted Thursday, July 28, 2005 9:12 PM


SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, February 15, 2012 9:18 AM
Points: 415, Visits: 4

Srinivas Sampath,

I was very interested in your article as I am looking at Service Broker closely for my own personal research for an article.  Where did you get your diagrams?  Are they original?   If not, well, you know the circumstances.  If they are orignial, I would like to reference them in my next article.  Of course, I will put your name on them.

Thanks a bunch! 


 




All the best,

Dale

Author: An Introduction to SQL Server 2005 Management Studio
Post #205535
Posted Tuesday, August 30, 2005 11:33 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, October 28, 2005 7:13 AM
Points: 18, Visits: 1

First off, I apologize for my late response to this thread. I did not have an account with SQL Server central and have just now created one.

To answer your question, the diagrams were created by me (just the brain wave that you get ). Sure you can use them.



HTH,
Srinivas Sampath
Blog: http://blogs.sqlxml.org/srinivassampath
Post #215382
Posted Tuesday, August 30, 2005 11:39 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, October 28, 2005 7:13 AM
Points: 18, Visits: 1

First off, I apologize for my late response to this thread. I did not have an account with SQL Server central and have just now created one.

Interesting question. I did think about this when I originally read about SSB and people do ask me this question when I deliver sessions on SSB. SSB sure comes close to MSMQ in several ways, but the first thing that I would consider before using SSB is: Do I want to do asynchronous operations in the database? If so, then SSB is for you. Second, SSB requires that both ends of your communication are SQL Server 2005. If this is the case, then again SSB is for you. Third, if you do require transactional message processing (and the above two points hold good), then SSB is for you, since transactional semantics are built in.



HTH,
Srinivas Sampath
Blog: http://blogs.sqlxml.org/srinivassampath
Post #215387
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse