Implementation

Feb 11, 2009 at 10:47 PM
Has anyone tried this yet?
Feb 11, 2009 at 11:01 PM
No one has yet put it into production and told me about it.  I can offer guidance in validating whether it will work in your scenario and advice if you run into problems implementing it.
Mar 12, 2009 at 7:16 PM
Edited Mar 12, 2009 at 7:17 PM
Hi,

I'd like to use this as a replacement for the MSMQ binding to obtain durable storage. Transactional queues are stored in the file system and do not provide a great way for recovery after a server failure. So database would solve that issue.

My intention is to create this as a generic pub sub service. Do you have a more recent version of the code?  Do you think this would work for this purpose?
Mar 12, 2009 at 7:28 PM
Yes, the main benefit of SSB over MSMQ is that the data is stored in the databsae.  There is no built-in support for pub/sub in Service Broker or WCF, but you could certianly build a pub/sub solution on top of this.

What's there is the current version of the code.

David
Jun 22, 2009 at 12:56 PM

Well, I tried to use it with an eye on going to production. So far there are 2 big problems:

  1. It's impossible to configure a Ssb endpoint in the config file (WCF complains about the parentage of the SsbBindingElement);
  2. If an exception is thrown the queue could be disabled as a result. It is a "normal" mode of operation for Service Broker Queues, but with WCF such exceptions are mostly silently swallowed (it is a one way protocol, after all), so there is no visible indicators at all. I'd say David should add an event on the host to handle "something bad happened" situations. It applies also to the case when the queue was disabled from the start. The .exe running the ServiceHost is not ever informed about it.

(2) is more-or-less expected in Service Broker Queue apps, but WCF adds an extra layer of mystery between "real" errors and what the container do (or doesn't) see. If the container is a minimalistic Windows service knowing nothing about what services are run inside it (it's all supposed to be in the config file) and about contracts they are exposing, it can not even check for possible error conditions. It means that the burden of checking for database errors goes to the services... but they don't know they are published via Ssb.

Give me a stupid but 100% reliable way to report errors in the production environment... if we can't report them to the client, at least report them to the host.

 Alexander

Jun 24, 2009 at 5:38 PM

I stand corrected... WCF is amazinly extensible and with some subclassing of ServiceHost and tweaking app.config I've got a nice sql exceptions interceptor. All I have to do is to decide which ones are recoverable and how to recover from them except by recycling the ServiceHost. BTW, I've added "SenderEndsConversationAfterSendProperty" setting for shoot-and-forget scenarios - it saves the need to recycle the client proxy.

Oct 27, 2009 at 7:42 AM
Edited Oct 27, 2009 at 7:53 AM

Any one tested this with SSIS?


Actually right now am looking for a good solution to implement Service broker in our project....

We have a silverlight application which deals with huge data repository...

so sometimes we need to create the extract file from our prod Db, For that we are using SSIS.


My requirement is I need to integrate the SSIS execution with our silverlight Web app using service broker,

because i can use service broker queue for this....


Is that possible?

Nov 9, 2009 at 7:57 AM
Edited Nov 9, 2009 at 7:59 AM

Hi guys,

 

Is there any updates at all on this? The post dates don't show the year so I cant asses if the last update on this was october 2009 or previous year.

 

This would be a very valuable addition to the WCF infrastructure specially a great candidate over the MSMQ binding to avoid the 4MB size limitation of queue messages.

 

10/11/2009

Nov 9, 2009 at 7:59 AM
archnae wrote:

I stand corrected... WCF is amazinly extensible and with some subclassing of ServiceHost and tweaking app.config I've got a nice sql exceptions interceptor. All I have to do is to decide which ones are recoverable and how to recover from them except by recycling the ServiceHost. BTW, I've added "SenderEndsConversationAfterSendProperty" setting for shoot-and-forget scenarios - it saves the need to recycle the client proxy.

archnae can I get a copy of the code you wrote to capture the host errors. Are you resetting the SSSB queue?