January 17, 2013 at 2:52 pm
jimbobmcgee (1/16/2013)
Secondly, the complexity. XML is not fun to work with. XML is especially not fun to work with in SQL Server. Sure, anyone can write a basic XML document; I'm sure most of us can also put something together with a nice set-based FOR XML statement and some of us can even get that data back out with the functions built into the XML datatype but that still leaves a lot of people (good, upstanding, professionals in their field) whose eyes just glaze over at the very sight of it. Besides, good XML (with schemas and transforms and validation and such) is a pain in the rear that even the most capable of us usually want to avoid.
I agree with the obtuseness of Service Broker. But there is no requirement to use XML in any implementation of Service Broker. The messages are just binary messages they can be anything you want them to me. But if you are passing a bunch of different parameters to a service via the actual message XML is a typical way... but it could just as well be a comma delimited string.
However my implementations have used service messages basically just to wake up a service and perhaps hand it an ID of a row in a request table. The request table contains the actual data to be processed in SQL data columns so we don;t have to mess with XML. I also put the conversation handle in there to facilitate better communications especially for multi-threaded services. This has worked out much better than trying to pass data back and forth in Messages.
Finally, there needs to be a one-way message queue implementation. The way service broker is set up it really expects an actual conversation where the client and service actually talk back and forth at least once. Many times all you need is to queue up a request and never expect a response. This is ugly to implement with service broker because by default they expect and end conversation message to be sent.
While it might not have broad appeal there are specific scenarios where this is truly the best and most efficient way to implement a mechanism where two asynchronous processes need to access an external service and it needs to be coordinated within a transaction involving table updates.
The probability of survival is inversely proportional to the angle of arrival.
January 18, 2013 at 12:29 pm
Miles Neale (1/17/2013)
Steve Jones - SSC Editor (1/17/2013)
I'm not advocating Service Broker over other queue mechanisms.
Steve,
From the article and the discussion I took away that you are in favor of the SB technology and whatever architecture is appropriate for the particular IT solution should be investigated, and potentially used.
...
No worries. Looking back at the piece I can see it's ambiguous. I mention SSSB, and then say "I still think this is a great way to build applications, especially distributed ones, using queues instead of linked servers, ETL, etc."
I meant messaging and queues in general, but the "this" is ambiguous. I should have clarified and said messaging/SOA architectures instead.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply