Service Bus Abstraction Layer?

[Matt Johnson]

Pardon my ignorance, but is there any project that provides a common
abstraction layer for different service bus implementations?

Something similar to how CommonServiceLocator works for IoC
containers?

I'm writing an app that will be licensed in two ways. 1) a "licensed
edition" that will run on premesis, and 2) a "hosted edition" that
will run in the Windows Azure cloud.

I would like to use Rhino Service Bus for the licensed edition, and
Azure Service Bus for the hosted edition. It would be great if there
was an easy "provider model" implementation, such that I could just
swap in the desired service bus. Otherwise, I fear I may have tons
of "if (hosted) { azuresb } else { rhinosb }" code scattered
throughout my app.

Thoughts?

[Corey]

Not that I'm aware of. It should be fairly simple to provide your own abstraction though.

[Tom Cabanski]

I looked at this exact problem and after putting together some spikes pulled back.  It is actually quite a bit harder on the receive side than you would expect.  I strongly suggest you avoid writing an abstraction and just pick an implementation.  Service buses tend to be pretty opinionated and different once you get past the act of sending simple messages.  

BTW, Azure service bus will work just fine with an on premises installed app.  It is actually pretty cheap for what it provides.  That's the direction we went.

As a side note, check out  https://github.com/ProjectExtensions/ProjectExtensions.Azure.ServiceBus.  It is a very easy to use library that lets you work with Azure service bus like you do with Rhino or NServiceBus.  NServiceBus has also added support for Azure queues and can be licensed for OEM use (though it may not be cheap).

Enjoy!

Tom

[Tom Cabanski]

I looked at this exact problem and after putting together some spikes pulled back.  It is actually quite a bit harder on the receive side than you would expect.  I strongly suggest you avoid writing an abstraction and just pick an implementation.  Service buses tend to be pretty opinionated and different once you get past the act of sending simple messages.  

BTW, Azure service bus will work just fine with an on premises installed app.  It is actually pretty cheap for what it provides.  That's actually the direction we went.

As a side note, check out  https://github.com/ProjectExtensions/ProjectExtensions.Azure.ServiceBus.  It is a very easy to use library that lets you work with Azure service bus like you do with Rhino or NServiceBus.  NServiceBus has also added support for Azure queues and can be licensed for OEM use (though it may not be cheap).

Enjoy!

On Wednesday, March 14, 2012 12:50:38 PM UTC-5, Matt Johnson wrote:

On Wednesday, March 14, 2012 12:50:38 PM UTC-5, Matt Johnson wrote:

[Corey Kaylor]

It also looks like NServiceBus supports Azure now as well, not sure on the details or what aspects are supported. Might be a decent option to consider.

--
You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/2zItG4pzSSYJ.

To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.

[Matt Johnson]

Yeah, I saw the NServicebus on Azure thing. I was leaning towards
Rhino just because of cost, but I may take another look. If I can
build around NServiceBus and then just switch out it being backed by
MSMQ or Azure Queues, then that also gets the job done.

Thanks for the advice and the info about the Azure ServiceBus
extensions.

-Matt

On Mar 15, 7:01 am, Corey Kaylor <co...@kaylors.net> wrote:
> It also looks like NServiceBus supports Azure now as well, not sure on the
> details or what aspects are supported. Might be a decent option to consider.
>
>
>
> On Thu, Mar 15, 2012 at 7:42 AM, Tom Cabanski <t...@cabanski.com> wrote:
> > I looked at this exact problem and after putting together some spikes
> > pulled back.  It is actually quite a bit harder on the receive side than
> > you would expect.  I strongly suggest you avoid writing an abstraction and
> > just pick an implementation.  Service buses tend to be pretty opinionated
> > and different once you get past the act of sending simple messages.
>
> > BTW, Azure service bus will work just fine with an on premises installed
> > app.  It is actually pretty cheap for what it provides.  That's actually
> > the direction we went.
>

> > As a side note, check out  https://github.com/**ProjectExtensions/**
> > ProjectExtensions.Azure.**ServiceBus<https://github.com/ProjectExtensions/ProjectExtensions.Azure.ServiceBus>.

[nightwatch77]

Implementing a common service bus abstraction could be difficult at first glance but IMHO it can be done quite easily if you don't go too deep into a particular implementation.

Basically you have to abstract two things: 

1. A message bus interface (IMessageBus) that you will use for sending messages

2. A dispatcher for incoming messages that will deliver them to their handlers

1) is quite simple as long as you dont try to abstract too advanced features that not all service buses provide. But the basic Send and Publish methods are supported everywhere so there should be no problem.

2) is more tricky because you have to 'plug in' into the underlying service bus implementation, intercept the messages and handle the dispatch yourself. RSB, for example, provides something like ICustomMessageHandler (or sth like that) that you can use for that purpose.

    And if you want a dispatcher example you can find one here (that's my code, btw) :  http://code.google.com/p/nginn-messagebus/source/browse/trunk/NGinnBPM.MessageBus/Impl/MessageDispatcher.cs 

Best regards,

RG

> > To post to this group, send email to rhino-tools-dev@googlegroups.com.

> > To unsubscribe from this group, send email to

> > rhino-tools-dev+unsubscribe@googlegroups.com.