Thanks for reaching out. I am a bit worried by this statement
They’ve started down the road of a homegrown “service bus” (really a single process that marshals RabbitMQ messages to webservice calls to Java or .NET back-end processes)
because this approach is likely to destroy good part of the potential benefits of messaging. The great advantage of messaging systems is the ability to receiver a message, update the data store and send out other messages in a single atomic step.
This is how NServiceBus started back then with MSMQ but now it supports this mode of operation on all transports thanks to the Outbox.
Having a single process that receives messages and translates them to webservice calls breaks this because the service being called can’t really send anything to the next service in the chain, at least not in an atomic way and that atomicity is something that makes building complex distributed systems manageable. Without it you need to deal with partial failures (e.g. data updated but messages not sent or vice versa) in each and every component of the system.
In the principle NServiceBus is not that different from the good old days J2EE message-driven beans. I am not sure if there exists a modern version of this idea in the Java space but worst case you should be able to put together something that runs in Java and works like NServiceBus or message-driven beans i.e.
- the infrastructure receives a message (from RabbitMQ)
- it looks up for handlers that match the message
- it opens a transaction with a data store
- passes the invocation to these handlers along with the transaction context
- the handlers return the messages they would like to send out
- the infrastructure stores the outgoing messages in that transaction that the handlers used
- it inserts a marker that the received message had been processed and commits the transaction
This is how the Outbox works. Such a lightweight framework would provide solid foundations for further extensions because it clearly separates the business code (the message handler) from the infrastructure (managing transactions and messages).