Chris Chen has a nice description of messaging use cases from resin-interest:
I think integration is interesting, but more relevant are the use
cases surrounding each type of system.
*) BAM - lightweight for super fast and scalable message brokering for
things such as stock market price streaming (no need for persistence)
or twittering type messages. The main thing here is “as fast as
*) JMS/persistent subscriptions - These are for those that broker
highly mission-critical data. The primary interest here is “as
reliable as possible”. Speed is less of a concern compared to the
data. Inherently, this type of use conflicts with BAM. Transactions
will bog down the speed.
*) ESB/SOA activities - these, in my view, are for those that require
high data/service compatibility and integration. The message here is
“as promiscuous as possible”. The focus is on the adapters and being
able to communicate and connect to many different systems.
I think all of them centers around a hub-spoke model. It’s possible
to integrate all of them together through layers. The lowest layer
(in this case, BAM) focuses entirely on speed. A secondary layer can
add the reliability that can be similar to XEP persistence. Possibly
a persistence component that subscribes and listens to any topic/queue
that requires such a service and separately deals with reliability. A
third component can create a set of adapters to connect to different
systems. This third component mainly focuses on data/message