|
...integration model for it, including key user roles. These roles are fulfilled using meta-data that describes the service endpoints, such as the service interface and policy requirements and capabilities. The ESB manages this meta-data through registry, which supports configuration, connection, matchmaking, and discovery of service endpoints. Some typical mediation patterns that are used to satisfy endpoint policies are explored, and usage patterns are described in which the ESB is used to implement real SOAs.
INTRODUCTION
Many papers in this journal discuss service-oriented architecture (SOA)--what it is and its benefits and value propositions. Other papers describe tangible implementations of SOAs. This paper abstracts and learns from these and similar experiences to identify the essential characteristics of an Enterprise Service Bus (ESB): the meta-data that describes service requestors and providers, mediations and their operations on the information that flows between requestors and providers, and the discovery, routing, and matchmaking that realize a dynamic and autonomic SOA.
In particular, this paper explains how the ESB provides the tools and runtime infrastructure to realize the promise of SOA formulated in the iconic "publish-find-bind" triangle (see Figure 1) that was popular in the early days of the SOA revival caused by Web Services (see Reference 1). As illustrated in Figure 1, the ESB manages and exploits meta-data describing interaction endpoints as well as the domain models used to describe the capabilities of those endpoints, it supports configuration of links that bridge between capabilities demanded by service requestors and those offered by service providers, dynamically matching requestors with providers and in the process establishing and enacting contracts between those interaction endpoints.
[FIGURE 1 OMITTED]
This paper is structured as follows: we begin with an overview of the main characteristics of the ESB, followed by a detailed discussion of the concepts of the ESB programming model and the standards supporting those concepts. We conclude with a description of ESB use cases and usage patterns.
ESB IN A NUTSHELL
The ESB enables an SOA by providing the connectivity layer between services. The definition of a service is wide; it is not restricted by a protocol, such as SOAP (Simple Object Access Protocol) or HTTP (Hypertext Transfer Protocol), which connects a service requestor to a service provider; nor does it require that the service be described by a specific standard such as WSDL (Web Services Description Language), though all of these standards are major contributors to the capabilities and progress of the ESB/SOA evolution. A service is a software component that is described by meta-data, which can be understood by a program. The metadata is published to enable reuse of the service by components that may be remote from it and that need no knowledge of the service implementation beyond its published meta-data. Of course, a well-designed software program may use meta-data to define interfaces between components and may reuse components within the program. The distinguishing feature of a service is that the meta-data descriptions are published to enable reuse of the service in loosely coupled systems, frequently interconnected across networks.
What do we mean by "publishing" a description of a service? Descriptions of the services available from a service provider can be made accessible to developers at the service requestor, possibly through shared development tools. The ESB formalizes this publication by providing a registry of the services that are available for invocation and the service requestors that will connect to them. The registry is accessible both during development and at runtime. Components such as J2EE ** EJBs ** (Java ** 2 Enterprise Edition Enterprise JavaBeans **) or database-embedded functions may be published as services, but not every J2EE EJB is a service, and not every J2EE EJB is accessible by means of the ESB. In general, EJBs need additional meta-data, and possibly additional bindings, published to the ESB registry in order to make them available as services.
Publication of the service requestors and providers allows their meta-data to be administered through the ESB registry and enables their relationships and interactions to be visualized and updated. Nonetheless, ad hoc requestors and providers may also connect to the ESB without first being registered, for example, subscribers to a "publish/subscribe" topic. In that case, their interactions will not benefit from the full dynamic capabilities of the ESB, described later.
The ESB populates the registry with meta-data about services in three different ways. When services are deployed to the runtime environment, they can be simultaneously and dynamically added to the ESB; meta-data associated with components already deployed can be explicitly added to the ESB; or the ESB can discover services and service interactions that are already deployed and incorporate meta-data describing them in the registry.
Note that the ESB is the infrastructure for interconnecting services, but the term ESB does not include the business logic of the service providers themselves nor the requestor applications, nor does it include the containers that host the services. Hosting containers and free-standing applications are enabled for interaction with ESBs with varying levels of integration, depending on the range of protocols and interoperability standards supported. Most containers (e.g., J2EE application servers, CICS*, Microsoft .NET **) integrate with an ESB across the SOAP/HTTP protocols, but fewer have direct support for SOAP/JMS (Java Messaging Service) over a particular brand of JMS provider. After the ESB has delivered its payload to a container, its responsibilities are fulfilled. Within the container, the service invocation may be redirected among the machines in a cluster, or it may be responded to from a local cache. These are some of the normal optimizations within an application server environment, and they complement the routing and response capabilities of the ESB between the service providers it interconnects. Similarly, the ESB is the connectivity layer for process engines that choreograph the flow of activities between services. The process engine is responsible for ensuring that the correct service capabilities are scheduled in the correct order. It delegates to the ESB the responsibility for delivering the service requests, rerouting them if appropriate.
A core tenet of SOA is that service requestors are independent of the services they invoke. As a result, it is not surprising that the ESB is essentially invisible to the service requestors and providers that use it. A developer can use an API (application programming interface), such as JAX-RPC (Java API for XML-based RPC [remote procedure call]) to a Web service, or distribute messages with the WebSphere* MQI (Message Queue Interface) to a message queue, without considering whether these requests are flowing directly to the service or are traversing an ESB. Similarly, a service provider can be written as a J2EE EJB or a servlet without any specific application code to make it accessible through an ESB. Despite this, one of the values of the ESB is that it takes on the responsibility for many of the infrastructure concerns that might otherwise surface in application code. Thus, although developers can use APIs for service invocation, they do not need to add logic to deal with security, for example.
The ESB virtualizes the services that are made available through the bus. The service requestor, both in its application logic and in its deployment, does not need to have any awareness of the physical realization of the service provider. The requestor does not need to be concerned about the programming language, runtime environment, hardware platform, network address, or current availability of the service provider's implementation. In the ESB, not even a common communication protocol need be shared. The requestor connects to the bus, which takes responsibility for delivering its requests to a service provider, offering the required function and quality of service. Not surprisingly, the infrastructure of the bus is itself virtualized, allowing it to grow or shrink as required by the network and workload which it is supporting.
The flexibility that comes from an SOA, and the virtualization it implies, is fully realized by the dynamic nature of the ESB. All the meta-data, conditions, and constraints...
NOTE: All illustrations and photos
have been removed from this article.
More articles from IBM Systems Journal
Colombo: lightweight middleware for service-oriented computing., December 01, 2005
Web services navigator: visualizing the execution of Web Services., December 01, 2005
Business-driven application security: from modeling to managing secure..., December 01, 2005
Events and service-oriented architecture: The OASIS Web Services Notif..., December 01, 2005
Models for semantic interoperability in service-oriented architectures..., December 01, 2005
Looking for additional articles?
Search our database of over 3 million articles.
Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication
name or publication date.
About Goliath
Whether you're looking for sales prospects, competitive information, company
analysis or best practices in managing your organization,
Goliath can help you meet your business needs.
Our extensive business information databases empower business
professionals with both the breadth and depth of credible,
authoritative information they need to support their business
goals. Whether it be strategic planning, sales prospecting,
company research or defining management best practices -
Goliath is your leading source for accurate information.
|
