We have been using FubuMVC for a while now and one thing for sure is that it’s like a drug and when you start using you don’t want to stop. The conventions, behaviors, model binding, diagnostics, all of which is pluggable makes for a very good platform to build upon.
A while back we kept thinking it would be really nice to have FubuMVC w/ behaviors for our message handling pipline on our service bus (which is currently using Rhino.ServiceBus). I then began a proof of concept and it turned out to be completely possible.
This proof of concept demonstrated a few possibilities and seeded ideas for others with the help of Dru. Listed here are a few them.
- POCO message handlers including sagas which no longer requires implementing ConsumerOf<T>
- Instead of _bus.Reply(message) message handlers just return a message
- Instead of _bus.Publish(message) message handlers expose an event Action<object> Publish to invoke instead
- Custom error handling beyond retryCount = 5
- Handle specific error and place back in the queue at the end of the line
- Handle any errors that don’t make sense to retry
- Redirect to another chain / handler for error conditions
- An HTTP Server and framework for each deployed endpoint
- Bottles to begin leveraging more modular based deployments
- FubuMVC.Diagnostics for every message handler
- FubuMVC.Instrumentation (an extension to the diagnostics) to give us performance metrics on all of our message handlers
- Possibility to have a runtime management UI around Rhino.Queues, which is one area it lacks pretty severely
We have since began to use FubuTransportation running inside FubuMVC.SelfHost and are already getting many of the benefits described above. Someone has already mentioned getting this working for NServiceBus, and I have talked with Dru about MassTransit and looks to be possible there as well. In future posts I will start talking about more specifics on how to wire up something like this in one of your own applications.