Somewhere over the past year, the enterprise service bus (ESB) gained ascendancy over the traditional enterprise application interface (EAI) method of messaging.
Yet while starting application development with a standard interface rather than customizing an interface after an application has been built may be in vogue, multiple questions remain about what exactly defines an ESB. Large vendors, like BEA Systems Inc. and IBM, are rushing into the ESB market, concerning those whose bread and butter has been the ESB.
"The market has gotten flooded with ESBs over the past eight months," said Jonathan Bachman, senior director of product marketing for Sonic Software Corp. "You've got everything from traditional integration brokers to application servers getting called ESBs. It undermines the category; it obliterates it in fact."
In response to the situation, Sonic has laid itself bare, seeking to make the product that first established the ESB label a reference point for what an ESB should be and how it should operate.
The key, according to Bachman, is that the "ESB endpoint creates an extensible, flexible abstraction that doesn't affect the service. It doesn't have to send a message through a hub. It can work locally."
Changes to the interface shouldn't require code changes to the services, and changes to the service shouldn't require code changes to the interface. In a nutshell, it's the loosely coupled paradigm at work.
Yet simplicity isn't necessarily baked into the cake. While the design concept behind the ESB may be easy to grasp, Bachman noted that there are 110 "major parts" to the Sonic ESB.
"It can make it hard to do a comparative analysis," he said. "When you're looking at two products side by side, it's not always apparent what the similarities and differences are."
For instance, the Sonic ESB contains multiple workbench editors and mediation specifications. An XSLT style sheet editor or the ability to create XQuery expressions for XML data may or may not be important to you. Likewise, Sonic's basic six-step process for message handling (mediation) may vary wildly from other ESB offerings, or it may be the same thing dressed up in different terms.
To dispel some of the confusion over terminology, Sonic included an 11-page glossary of terms at the end of its reference model document.
On top of the standard ESB, there are also value-added services for service-oriented architecture creation and management. Those value-adds include handling business process workflow, external partner orchestration and database access, among other functions.
While an ESB can offer those tools, Bachman was quick to point out that it is not a one-stop SOA tool.
"An ESB is a home for your services, but it's only part of an SOA, not the whole thing," he said.
The key capabilities and properties to a "distributed services architecture," according to Sonic, are:
- New services and new service types can be implemented through configuration, without the need to write programs.
- An ESB service interface can be changed without requiring coding changes and a consequent development cycle to recompile and deploy that service.
- Service instances can be remotely provisioned in ESB containers located anywhere on the network, allowing flexibility to deploy new functionality and to manage performance through load-balancing or multiple service instances. This allows the deployment of services to the physical location where they may perform best, due to host processing capability or proximity to other resources.
- Local access to configuration artifacts needed by services, providing quick service startup and ability to run even in the event that a network failure prevents access to the ESB repository.
- Automatic distribution of ESB service implementation and configurations across a distributed network for deployment of new or changed services.
- The distributed ESB service containers and communication brokers can be managed using the same underlying messaging infrastructure that is used for service communications, with the ability to partition communications for scalability and reliability.
- Events, including entry and exit of services invoked by an ESB process, can be tracked to manage process execution across even a highly distributed deployment.
- Automatic load balancing across multiple instances of a service in support of performance and reliability goals.
- Continuous Availability Architecture provides high reliability multi-protocol messaging through back-channel replication of message data from primary to secondary brokers. This ensures continuous, ordered delivery of messages in the event a communication broker fails.
- Dynamic Routing Architecture allows messages, including Web services requests and responses, to be automatically routed across a federated multi-hub deployment of brokers. This permits messages to enter any broker in the ESB and be routed to the correct destination, regardless of the domain that hosts this destination, subject to enforcement of security rights.
Bachman recognized that variations will occur between products, but argued that it is becoming essential for ESBs to lay out what they do in concrete terms. The new Java Business Integration (JBI) specification perhaps might prove beneficial in this arena.
"It's still early on, but JBI begins the standardization of the ESB container," he said.