Anyone out there using this? It's fabulous.

[Mr. Arnold]

I mean the ability to call a Web service or a WCF service with Service
Broker using CLR code that's running on SQL server is very good. I am
programming this in a project for a client that's being done at this time.

The ability to have SQL server triggers push things like XML and XML
serialized objects into queues, the Service Broker using CLR to pull things
off the queues, Service Broker using CLR calls a Web service that has access
to the BLL and DAL layers and then in turn the send things off to other SQL
server queues, like using MSMQ. It's like using WCF with end-points and
everything, but it's on SQL Server.

Other processes like a Console or Windows service application running on the
back-end working with the MS SQL server queues is something I didn't know
that could be done, until two weeks ago.

It's fabulous stuff.

http://www.devsource.com/c/a/Using-V...R-Integration/
http://msdn.microsoft.com/en-us/library/ms345108.aspx

[raylopez99]

I don't know what you are talking about, but suppose you send a
message to this Service Broker, turn off your machine, and come back a
week later. Won't it time out? Or will a reply be waiting for you?

Don't really see the utility of this "guarantee" unless you can do the
above.

RL

Mr. Arnold wrote:

[Mr. Arnold]

"raylopez99" <ra********@yahoo.comwrote in message
news:e4**********************************@k24g2000 pri.googlegroups.com...

>I don't know what you are talking about, but suppose you send a
message to this Service Broker, turn off your machine, and come back a
week later. Won't it time out? Or will a reply be waiting for you?

You don't send messages to the Service Broker. A client application that
uses the SQL Server queues send messages to the queues. One would think that
if the client knows SQL server is down, it won't send anything to the
queues, just as if the application knows that a SQL server table is down and
not to be writing data to tables knowing that it's down.

The data is held in the queues just like it's held in a SQL server table,
until the Service Broker that runs on SQL Server retrieves that data out of
the queue to process it, which transactional queue processing can be done as
well with data being rolled back into the queue, if all transactions in the
queue do not complete in a given transaction.

Also, any application that can access the SQL server can access the queues
to send or receive messgaes by use of T-SQL statements with in-line code or
by using Stored Procedure as well. The data is going to be held in the
queue, until the queue is cleared by a command to clear the queue or a
program retrieves a message off of the queue.

>
Don't really see the utility of this "guarantee" unless you can do the
above.

It's guaranteed if you the developer knows what you are doing. That's the
key.

And I suggest that you go get the book for 2005 that was tossed in may face
and figure it out, because one can use MSMQ, Named Pipes, WCF, .Net
Remoting, and now MS SQL server queues to send messages to other programs
using a queuing process, very powerful stuff.

http://www.amazon.com/Pro-Server-200.../dp/1590599993

I talked with another developer that's showing me what is happening with the
SQL Server Service Broker. He indicates that the solution that now uses SQL
Server Broker has speed-up processing of things a great deal faster now
than before.

My usage of this technology is a communications link between two search
engines that the USAF, other military and DOD personnel are using, along
with other things the solutions are doing. One the USAF already has and
implemented, and the other one it has just purchased to be implemented--
make them communicate, make them work and save data to SQL server on both
sides of the bridge.