This is a rhetoric question, so you don't need to bother replying. It's just that I've been thinking a lot about how to integrate messaging into Spring and I haven't found the answer yet. The big problem is pairing database and JMS transactions to get guaranteed delivery/rollback. The obvious solution is global transactions, which I've used successfully in the past. For a variety of reasons this is no longer an option for me, the best reason being that I cannot afford global transactions anymore.
Spring provides a very elegant replacement for stateless session beans, and claims it cannot replace other EJB artifacts, including MDB's, which is probably correct.
In fact, combining two transactions, regardless of their types, is delegated by Spring to JTA, for all the right reasons. However, at least to me this does not mean Spring is not fit to provide an answer for my messaging question. Actually, the answer is as perfect as it is simple: rethink the messaging requirements, shift the messaging paradigm and do everything in one transaction: the database transaction.
Shifting the paradigm could mean: shifting from guaranteed delivery to best effort delivery. Best effort delivery does not necessarily mean try once and if that fails don't try again. It could mean: create the message and keep retrying until delivery, which may never occur.
Creating the message could mean storing the message in a database table first, then start the first delivery attempt. Delivery then means confirmed delivery. This would require the client to be first of all idempotent, secondly to actually confirm every message it receives to the sender. Until then the sender should continue resending, keeping in mind a realistic timeout. Once the message has been received a callback could be invoked, to continue or complete the business transaction.
If I'm not mistaking, whether the message has been successfully send and delivered or not is no longer important when working inside a database transaction, it's the registration of the message that's important.
I was just wondering if other people out-there have come up with any solution that addresses the delivery problem differently than global transactions.