Java – Message Oriented Middleware (MoM) Vs. Enterprise Service Bus (ESB)

You can use a transformation broker without a service bus, and vice versa. In terms of specific products I don't think any one is purely one or the other because of the way each complements the other. Some products are stronger in the one area, other stronger in another. Perhaps a choice needs to be made based on which function best covers an individual problem.

A broker may have better built-in "lego blocks" for constructing a transformation chain than an ESB product does. A broker pressed into service as an ESB may be crushed under load and not scale well, or may lack robust journaling and tools for dealing with journals.

Some ESBs allow database updates to be rolled back and queues to be replayed into a corrected application once an egregious error in logic has been uncovered and fixed. I don't think most brokers integrate that level of transactional support. For this to work at all your "transactions" almost have to be business events (a sale, a renewal, a change of ownership, etc.) rather than something like RPCish "database updates."

Although ESB is based on messaging, it is not "just" messaging and not just a buzzword.

So if you start with plain old async messaging, the early networks tended to be very point-to-point. You had to wire up (i.e. configure through some admin interface) each connection and each pair of destinations and if you dared to move anything around invariably something broke. Because the connection points were wired by hand these networks never achieved high connection density. The incremental cost was too high and did not scale. There was also a lot of access control and policy embedded in the topology. The lack of connection density actually favors this approach to security, even though it inhibits flexibility.

The ESB attempts to address these issues with...

• Run-time resolution of destinations/services/resources
• Location transparency
• Any-to-any connectivity and maximum connection density
• Architected for redundancy, horizontal scalability, failover
• Policy, access control, rules externalized from topology
• Logical messaging network layer implemented atop the physical messaging network layer
• Common namespace

So when your customer asks for ESB compatibility, they want things like the above. From an application standpoint, this also implies...

• Avoiding message affinities such as requirements to process in strict sequence or to address requests only to specific nodes instead of to a generic network destination
• Ability to resolve destinations dynamically at run time (i.e. add another instance of a queue and it automatically starts getting traffic, delete one and traffic routes to the remaining nodes)
• Requestor and provider apps decoupled from knowing where each other "lives". Requestor makes one connection, regardless of how many services it might need to call
• Authorize by policy rather than by topology
• Service provider apps able to recognize and handle dupes (as per JMS spec, see "functional duplicate" due to session handling)
• Ability to run multiple active instances of a service provider application
• Instrument the service provider applications so you can inquire on the status of the network or perform a test without sending an actual transaction

On the other hand, if your client cannot articulate these things then they may just want to be able to check a box that says "works with the ESB."