Some of our partners are telling us that our software needs to interact with an Enterprise Service Bus. After researching this a bit, my instinct is to say that this is just buzz speak for saying that we need to have a platform-indpendent way to pass messages back and forth. I'm just trying to get a feel for what our partners are telling us. Am I correct in dismissing our partners' request as just trying to get our software to be more buzzword-compliant, or are they telling us something we should listen to (even if encoded in buzzspeak)?
Can someone explain an Enterprise Service Bus to me in non-buzzspeak
esbintegrationmessagingsoa
Related Solutions
Messaging tends to concentrate on the reliable exchange of messages around a network; using queues as a reliable load balancer and topics to implement publish and subscribe.
An ESB typically tends to add different features above and beyond messaging such as orchestration, routing, transformation and mediation.
I'd recommend reading about the Enterprise Integration Patterns which gives an overview of common patterns you'll tend to use in integration problems which are all based above a message bus (though can be used with other networking technologies too).
For example using open source; Apache ActiveMQ provides a loosely coupled reliable exchange of messages. Then you can use Apache Camel to implement the Enterprise Integration Patterns for smart routing, transformation, orchestration, working with other technologies and so forth.
Let me try to clarify those terms to you:
Bus in context of ESB architecture should not be considered as simple queue for message dispatching. To allow integration of different services, ESB provides much more. Important additional functionalities of ESB:
- Routing. Messages can be routed to different services, depending on message content or endpoint specification.
- Message Transformations/Mediations between different formats
- Transport protocol conversion. ESB should be able to seamlessly integrate applications that use different transport protocols (JMS, HTTP/S, pure TCP, etc.)
- Message enhancement. Messages can be enriched with missing data before further processing.
- Security
- Management and Monitoring
Those functionalites are provided by services that operate within ESB. Services connect to each other via endpoints - uniform, unique "addresses". Messages dispatched between endpoints are using unified transport (method/protocol that encapsulates message's payload). Application that natively use different transport, need to connect to ESB via suitable adapter - service that will provide necessary transport conversion. This way applications that use ESB are decoupled from each other and don't need to provide conversions themselves.
Of course, those are only very brief descriptions of terms. Remember, Enterprise Service Bus is only catch-term for specific kind of architecture (or concept), but it is not standardized in any way. So specific implementations can be very different from each other. If you are interested in standardized ESB, you can take a look at JBI (Java Bussiness Integration). There are several open-source implementations of JBI avalable, among them Apache ServiceMix, Mule, OpenESB. Very good introduction to ESB technologies is presented in "Open Source ESBs in Action" book published by Manning.
Best Answer
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...
So when your customer asks for ESB compatibility, they want things like the above. From an application standpoint, this also implies...
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."