Setting up a Rhino Service Bus ApplicationPart I
Part of what we are currently doing at Hibernating Rhinos is work on some internal applications. In particular, we slowly update our existing applications to do two things:
- Make sure that we are running a maintainable software package.
- Dog food our own stuff in real world scenarios.
In this case, I want to talk about Rhino Service Bus. Corey has been maintaining the project and I haven’t really followed very closely on what was going on. Today we started doing major work on our order processing backend system, so I decided that we might as well ditch the 2.5+ years old version of Rhino Service Bus that we were running and get working with the latest.
I was so lazy about that that I actually didn’t bother to get the sources, and just got the nuget package.
Install-Package Rhino.ServiceBus.Castle
Install-Package Raven.ServiceBus.Host
That got me half way there. No need to worry about adding references, etc, what an awesome idea.
Next, I had to deal with the configuration. Here is how you configure a Rhino Service Bus application (app.config):
<configuration> <configSections> <section name="rhino.esb" type="Rhino.ServiceBus.Config.BusConfigurationSection, Rhino.ServiceBus"/> </configSections> <rhino.esb> <bus threadCount="1" numberOfRetries="5" endpoint="msmq://localhost/Orders.Backend" /> <messages> <add name="HibernatingRhinos.Orders.Backend.Messages" endpoint="msmq://localhost/Orders.Backend"/> </messages> </rhino.esb> </configuration>
As you can see, it is fairly simple. Specify the endpoint, and the ownerships of the messages, and you are pretty much done.
The next step is to setup the actual application. In order to do that, we need to define a boot strapper. Think about it like a constructor, but for the entire application. The minimal boot strapper needed is:
public class BootStrapper : CastleBootStrapper { }
Again, it doesn’t really get any simpler.
The next step is somewhat of a pain. A Rhino Service Bus project is usually a class library (dll). So if we want to run it, we need to host it somehwere. RSB comes with Rhino.ServiceBus.Host, but the command line interface sucks. You need to do this to get it running:
Rhino.ServiceBus.Host.exe /Action:Debug /Name:HibernatingRhinos.Orders.Backend /Assembly:.\HibernatingRhinos.Orders.Backend.dll
And honestly, who ever thought about making it so complicated? Give me something to make this simpler, for crying out loud. Moron developer who no consideration of actual system usability.
Oh, yeah, that would be me. Maybe I ought to fix that.
Anyway, that is pretty much everything you need to do to get RSB up & running. Here is a sample test consumer:
public class TestConsumer : ConsumerOf<TestMsg> { public void Consume(TestMsg message) { Console.WriteLine(message.Name); } }
And that is enough for now. See you in the next post…
More posts in "Setting up a Rhino Service Bus Application" series:
- (01 Dec 2011) Part II–One way bus
- (30 Nov 2011) Part I
Comments
The <messages> <add name="some assembly" /> ...
part is IMO confusing, NServiceBus suffers from the same problem - there's nothing intuitive about it, and unless you know that name is actually a name of an assembly holding your messages there's no way you can figure it out on your own.
There is a typo - the nuget-package ist "Rhino.ServiceBus.Castle" instead of "Raven.ServiceBus.Castle".
Yeah! Ravens vs. Rhinos!
this made me laugh "Oh, yeah, that would be me. Maybe I ought to fix that."
There are plans for v3 for you to be able to define your own conventions and do auto-wiring. Even the ConsumerOf<T> is a bit ceremonial and I hope to introduce conventions for as wel.
Krzysztof, I don't think that this is really that bad, honestly. I think that once you get the idea about consumers, it is pretty simple from a tech standpoint. But the major hurdle is with architectual view of the thing
Daniel, Thanks :-) Fixed
Just want to take the opportunity to say we have been using RSB in production for several years. It is rock solid. Thank you, Ayende.
@Nick, please..
What is the configuration story when you have a heavily firewalled endpoints living in the DMZ and backoffice networks and all you have is port 80/443 for communication?
Jean, That is pretty much the same as far as this config is. The IT guys have to enable the connection, but that is pure IT work (enabling MSMQ over HTTP)
Let's say I'm using Rhino Service Bus with Rhino Queues, and I have a server application on one side of a firewall, and a client application on the other.
Would I be correct in assuming that, when using Rhino Queues, I only need to open an outgoing firewall port from the client to the server (that is, any responses would use an existing connection)?
cocowalla, No, those are two independent channels
@Ayende I'd rather not have an open port listening on the clients if it can be avoided.
Is there no facility to have the client receive subscription notifications over the same channel (in callback fashion), so the client doesn't have to listen on a port? So the client would establish an outbound connection to the server and that connection would be kept open and used for callbacks from the server?
Cocowalla, It shouldn't be very hard, but it isn't something that RQ is doing right now.
@Ayende I'm not that familiar with the RSB or RQ code bases, so it seems a bit of a daunting task - any pointers on where to start?
Cocowalla, You need to look at the Protocol directory, this is where most of the transport stuff is happening. Basically, you need to change that from a push model to a pull model
Comment preview