Take the Enterprise Service Bus
Web services evolve to a model that makes a network of collaborating services a reality
by Lee Sherman
Web services have gone a long way toward providing a standards-based means of building and integrating large-scale, distributed, enterprise systems. But Web services alone aren't enough to work with services-oriented and event-driven interactions across the extended enterprise.
If they are to integrate enterprise applications within larger business processes, enterprise architects must be prepared to work with additional heterogeneous interfaces for which there are as yet no established standards, and they must include workflow, process management, security, and administration in the overall infrastructure.
To achieve these undertakings, many are turning to a somewhat different model that builds on Web services to address the wider world of enterprise applications and to do so in a way that is flexible, scaleable, and secure. The enterprise service bus (ESB) is a new kind of middleware that supports services-oriented interactions among enterprise applications. Like the hardware bus in a PC, the ESB intelligently routes data flowing through enterprise systems, adapting and transforming that data as required by various systems.
The ESB is primarily concerned with the program-to-program communications necessary to support services-oriented interactions and combines messaging, transformation, and content-based routing into a single off-the-shelf product.
"ESBs have emerged because of the growing need for general-purpose enterprise communication backbones. This is the whole concept of the enterprise nervous system gradually coming to life, step by step and without fanfare," said Roy Schulte, Gartner analyst.
According to Schulte, ESBs replace a hodgepodge of separate, middleware products such as remote procedure calls (RPCs), object request brokers (ORBs), and message-oriented middleware (MOM). ESBs provide the features of all of these within a common infrastructure that makes maximum use of evolving standards such as Web services and Java Message Service (JMS).
A New Approach
Web services are often described as a component-based distributed architecture in which one application calls upon the services of another to perform a particular function. The ESB model, in which there is a set of intermediary services that support the functions mentioned previously, is fundamentally more flexible and inherently more scaleable because it provides access to a core set of common functions without having to rewrite all of the applications that require those functions. Instead of one application simply consuming the services of another on an ad hoc basis, proponents of the ESB model envision a network made up of collaborating services.
While they share their fundamental capabilities, ESBs differ from traditional integration brokers in their architecture. Instead of a hub-and-spoke model, in which the server is the hub and the applications are the spokes, ESBs have a distributed architecture that attempts to execute some services nearer to the application itself, rather than in a central hub.
ESBs support services-oriented architectures (SOAs) by implementing SOAP and leveraging Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI). In addition, ESBs make extensive use of XML-based content routing and transformation.
"Most application developers now understand the importance of services-oriented architecture, and a growing minority also appreciate the importance of event-driven architecture," said Schulte. "These architectures require powerful forms of program-to-program communication, which is what ESBs provide. You can do SOA and event-driven applications on conventional middleware, but it is easier to implement them on a uniform, general-purpose backbone with ESB features. Moreover, the growing use of Web services standards is bringing a level of compatibility between platforms that was previously unavailable in any communication middleware."
Gartner describes two basic kinds of ESBs. The first relies entirely on SOAP and is essentially the same as what is commonly referred to as a "Web services broker." The second supports SOAP and HTTP along with a variety of additional protocols in an effort to provide an entire communications layer for SOAs. Of the companies covered in this Architect's Toolbox, Cape Clear's 4 Server product is in the first camp, while Fiorano Software's ESB, Sonic Software's ESB, and SpiritSoft's Spiritwave are in the second. Outside the scope of this toolbox are companies such as Actional, AmberPoint, Computer Associates, Confluent Software, Infravio, and Westbridge, which although they provide the basic capabilities of an ESB, focus more on Web services management (performance monitoring, provisioning, availability, and security).
Indeed, one way of thinking about ESBs is that they are an evolution of Web services management products that add value beyond basic communication in the areas of message validation, transformation, security, content-based routing, and additional means of discovery and delivery such as publish and subscribe.
According to Gartner, the major functions of an enterprise service bus include:
- Message transformation – To enable program-to-program communication among different applications, each of which employs a different interface, an ESB must be able to transform data into a common data format that is understood by both the sending and the receiving applications.
- Content-based routing – The ESB can determine the destination of a given message based on the content of that message, freeing the sending application from having to know anything about where a message is going to end up.
- Publish and subscribe – Publish-and-subscribe mechanisms employ an event-driven model in which an event that occurs in one application can trigger an action in another.
About the Author
Lee Sherman is a regular contributor to Enterprise Architect. Contact Lee at .
Back to top
|