|
The Role of the ESB
ESBs provide a multitude of services for an enterprise committed to optimizing IT in support of business processes.
by Peter Varhol
October 19, 2006
Enterprise Service Bus (ESB) sounds as if it should be a grand concept. In the era of the service-oriented architecture (SOA), you hope to find an orchestration of services. This is especially true if the services consist of a combination of different types of applications and code, from Web services to legacy code. It is logical to assume that some mechanism must kick off services, pass messages between them, and restart services when they die.
Yet the widespread use of ESB has not caught on within the industry. Leading vendors in the ESB market, such as Sonic Software and Cape Clear, remain healthy and growing, but not at breakneck speed. And while larger organizations, such as IBM and BEA, have also rolled out ESB offerings, you did not see many enterprises in a big rush to implement one.
Why has the industry been so slow in the uptake of ESB technology? Two reasons come to mind, and neither of them reflects poorly on the future success of the technology. These issues deal with maturity and complexity.
The first roadblock to widespread ESB adoption is the maturity of the SOA within an enterprise. Enterprises that adopted an ESB tend to have advanced plans for SOA and a sophisticated SOA infrastructure. If you are simply experimenting with services, then you are likely to find that an ESB is overkill for meeting your present needs.
The second is the complexity of an ESB implementation. To begin with, messaging is complicated. With the services layered on top and the standards supported, you will find the modern ESB a challenge to understand and configure correctly. As with lots of middleware, ESB implementations are highly dependent on the platforms, infrastructure, applications, and perhaps, even the phase of the moon.
These issues speak to development of the ESB concept that is still necessary. Complexity is vital because ESBs perform difficult and complex tasks, across a wide variety of operating systems, software, and embedded devices. But too much of this complexity still comes through to IT professionals who have to install, configure, and maintain the software. In order for the ESB concept to be widely adopted, more of this complexity has to be abstracted away from the users.
The ESB's Roots
The tenets of the ESB grew out of messaging software. The most notable is the Java Messaging System (JMS). JMS messaging helps you establish asynchronous communication channels between applications and application components that were not designed to work together. It provides a well-understood mechanism for tying together these types of applications. Not surprisingly, you will find that JMS is the basis of many ESB solutions, such as those from Sonic Software and Cape Clear.
Messaging between applications and application components is at the heart of the ESB concept. For example, there are circumstances where it's absolutely vital for a message to be received and processed. In the commerce sector, it's necessary to have a reasonable level of certainty that a purchase, credit confirmation, or stock order is received and processed. And there are circumstances, such as in the health care, defense, or space sectors, where failure to receive and process a message can have catastrophic consequences.
Conceptually, both messaging and Web services deliver data to other components. So, the growth and development of JMS into a Web services and SOA backbone was a natural progression.
Back to top
|