Architectural (broker) place of SQL Service Broker

Hi,

I am struggling with the position SSB could take in an SOA. If I would want a broker in the general sense, meaning an intermediary sitting between applications which exchange information through messaging, would SSB be a good candidate? I know Biztalk is probably the primary candidate, but in my scenario I would end up with Biztalk apps with empty orchestrations. Also, I think Biztalk is more expensive to manage. So I am looking for a lightweight broker for a simple SOA targeted at application interoperability, no fancy business processes in sight.

I look forward to some responses.

Kind regards,

Neeva

It would be a good candidate if a lot of your processing is going to be taking place in the database (because SB resides in the db). You can write apps that connect to the db and handle SB messages...but they still have to connect to the db. If you don't plan on that, and want to stay away from BizTalk, you can always write an app that uses Messages Queues (the kind that you configure on your server). Does that help?
Tim|||

Hi Tim,

I understand what you say. The problem is that I don't know upfront where processing will take place. The goal is to have a message broker which acts as an intermediary between applications that exchange messages. I do not want to build point to point connections between these applications. My guess is that I then would have to build an intermediary application on top of SSB which would handle all the messaging via an 'SSB-enabled' database. But then I must be capable of calling other applications (possibly through webservices) from SSB, and return the response via the intermediary application to the calling application. This all sounds rather complex and that, I think, is mostly a sign that it is not the best solution. Also, the mix of webservices and SSB messages doesn't feel right.

I would certainly appreciate your comments!

Kind regards,

Neeva