Can someone explain an Enterprise Service Bus to me in non-buzzspeak?
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)?
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...
- 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."