![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Web services are designed to deal with some of the heterogeneities of the applications encountered in a large enterprise. However, Web services by themselves don't provide a complete solution to the problem of heterogeneity. In particular, they're not designed to deal with the situation in which there's mismatch between the transport protocols being used by the service consumer and service provider applications. Related to this mismatch is the problem of interface mismatch. Such mismatch conditions are usually the result of mergers and acquisitions. One possible solution is to rewrite these applications in terms of new Web services so that the mismatches are removed. But many times there aren't enough developer resources nor is there enough time to perform such a monumental task.
In such conditions, the enterprise service bus (ESB) provides an excellent solution to the problem of heterogeneity of a large system. ESB is an integral part of a Service-Oriented Architecture (SOA). It provides a comprehensive, flexible, and consistent approach to integration. In an ESB pattern, the service consumer and service providers don't interact directly; instead, the communication is through a bus. The bus provides many functions, including the core functions of protocol transformation, data transformation, and content- and context-based routing. You'll see these and other common functions described in the next two sections.
Another reason for considering the use of an ESB is that sometimes delivery of messages must be guaranteed due to contractual or legal reasons. In these cases, services other than Web services need to be used. An example of this type of service is the asynchronous service using messaging software, such as IBM® WebSphere® MQ series. The delivery of the message can be guaranteed by persisting the message on the requester and server side of the network.
In reading about object request brokers (ORBs) and asynchronous messaging in Part 2 of this series, you saw that both of these provide some form of basic routing based on content or context. This content- or context-based routing forms the backbone of an ESB. Thus, there are generally two types of ESBs that are available:
- ESBs based on an ORB product, such as IBM WebSphere® Application Server. Usually these products have strengths dealing with Web services, XML, and Java™ Remote Method Invocation (RMI). These products are comparatively low cost and easy to set up. But they are less scalable in terms of the volume of the transactions and dealing with a more diverse set of applications.
- ESB products based on asynchronous messaging software, such as WebSphere MQ. An example of such ESB products is IBM WebSphere Message Broker. These ESB products are highly scalable in terms of transaction volumes and in terms of dealing with a more diverse set of applications. But these products are more expensive and require a little more set-up time. Usually the two types of products are interoperable. For example, IBM WebSphere Enterprise Service Bus is completely interoperable with a WebSphere Message Broker-based ESB.
Content-based routing alone is not enough to address all heterogeneities found in a large enterprise. In particular, there's a proliferation of communication protocols, including HTTP, HTTPS, Internet Inter-ORB Protocol (IIOP), Java Remote Method Protocol (JRMP), and Transmission Control Protocol (TCP). So you may find that a service consumer might be set up to use one protocol, but the service provider might prefer a different protocol. Without a facility to transform a protocol into a different protocol, it's difficult for the service consumer to communicate with a given service provider. Related to this need is the requirement that the data format preferred by the consumer may be different from the data format employed by the service provider. Thus, there's also a need for a facility that can provide this data transformation. In summary, the minimum functionalities provided by an ESB are:
- Context- or content-based routing.
- Protocol transformation.
- Data transformation.
With these minimum features included in a component, the component becomes a service bus that provides virtualization so that the applications don't need to communicate with each other directly. Figure 1 shows this indirect interaction schematically.
Figure 1. Indirect interaction through an ESB
The ESB, with these functionalities included, provides the following types of virtualization:
- Location and identity virtualization: The service consumer doesn't need to know the location of the service provider. In addition, the service consumer is unaware of who the provider of the service is. Any one of a number of service providers can service a request. This also allows the services providers to be added or removed without disruption to the service.
- Interaction protocol: The service consumer and service provider don't need to share the same protocol or interaction style. For example, a request coming in as SOAP over HTTP can be serviced by a provider that only employs Java RMI over IIOP.
- Interface: The service consumer and service provider don't need to agree on a common interface. The ESB reconciles the differences by transforming the request message into a form expected by the service provider.
The virtualization of these aspects lets an ESB provide transparency of the service provider implementation to the service consumer both during development and at deployment time. The ESB takes responsibility to deliver service requests to an appropriate service provider, and the service provider responds to the service request without knowing where the request is coming from.
Additionally, the ESB itself is invisible to both the consumer and the provider. Application logic can consume or provide a service without ever knowing whether the connection is a direct one or an ESB has been employed. So the decision whether to use or not to use an ESB for connection is a deployment-time decision. No change to the application code is needed.
An ESB supports several interaction types between applications, including:
- Synchronous (or request/response)
- Asynchronous (or one-way)
- Publish and subscribe
An ESB also allows specification of nonfunctional requirements by the participants, and an ESB provides services to implement these requirements for the service participants. These nonfunctional requirements are usually referred to as quality of service (QoS) requirements and may include performance and reliability, data encryption, authorization of service requests, and automatic auditing of service interactions.
You can also commonly find a number of optional functions in a particular implementation of an ESB pattern. These additional functions, along with the core functions, are called mediation patterns. The additional features included in an ESB are:
- Data enrichment: Augment the message payload from an external source so as to match the requirement of a service provider. The external source may be a database.
- Distribution: Multiple consumer applications can subscribe to a particular type of message and ESB, which distribute the message to those applications.
- Correlation: This provides a facility to derive a complex event from multiple messages or from an event stream. The facility relies on the rules for pattern recognition and rules for forming the complex output message.
Usually there are also some utility functions included in an ESB implementation. These utility functions include logging, exception/error handling, and monitoring capabilities.
To implement the core functionality of an ESB, you need several conceptual components. Figure 2 shows these minimal components schematically.
Figure 2. Components of an ESB
Here are some brief descriptions of these components and what they do:
- Adapters: Adapters are specific to each input and output mechanism. An input or output mechanism specifies a message type and a transport protocol. For example, there's a separate adapter for Web services that involve SOAP over HTTP. Similarly there's separate adapter for handling Java RMI calls over IIOP. These adapters allow an ESB to interact with applications using a variety of input and output mechanisms. You need adapters for both synchronous interactions, such as HTTP and Web services, and asynchronous calls, such as WebSphere MQ input and output nodes.
- Dispatcher: The dispatcher component acts as a centralized entry point into the ESB. It receives a request from the adapters and passes it to a task dispatcher for routing and message-transformation work. The dispatcher also provides basic content-based routing functionality.
- Request handlers: Each service has its own request handler. The service-specific parameters to the routing engine are provided by the request handlers, and then the request is handed over to the routing engine for appropriate task execution.
- Data transformer: This is a key element of an ESB. It transforms the data received in the request to match what's required to invoke the service. In other words, it bridges the gaps between service interfaces.
- Routing engine and task dispatcher: These two components are responsible for transformation and routing the request to the service delegates.
- Service delegates: The delegates are the providers' endpoint-specific components that use the adapters to communicate with the service provider endpoint. Delegates provide more coarse-grained abstraction about the semantics of communication with the provider endpoint; hence, they are specific to endpoints. Adapters, on the other hand, abstract more fine-grained protocol mechanisms to connect to the endpoint.
Turning to actual deployment issues, note that there are four known patterns for deploying ESBs. These patterns and conditions under which each of these patterns should be employed are:
- Global ESB: This requires a single ESB and is suitable for a small
enterprise or a single line of business (LOB). In this case, all the services
are available to all the participants.
Figure 3. Global ESB
- Directly connected ESBs: This involves more than one ESB, which are connected directly.
This pattern employs a common registry so that the services are
visible throughout the enterprise. This pattern can be employed to,
for example, connect a set of packaged applications, such as SAP
applications, to the rest of the enterprise. These packaged applications
usually have their own ESB, which connects different modules, such as
customer relationship management (CRM) and enterprise resource
planning (ERP). For example, the SAP modules are connected by their own
ESB, called NetWeaver. NetWeaver can be connected to, for example,
WebSphere Enterprise Service Bus,
to provide connectivity between SAP applications and other
applications (C++, Java, or J2EE).
Figure 4. Directly connected ESBs
- Federated ESBs: These are similar to the directly connected ESBs pattern in that
multiple ESBs are connected. However, one of the participating ESBs has
a master-slave relationship with the other ESBs and exerts control on
what's accessible to the participants. This third pattern can be used
by moderately autonomous departments in an enterprise that wants to
share its services with other departments.
Figure 5. Federated ESBs
- Brokered ESB: In this pattern a broker is employed to mediate between
connected ESBs. Each ESB has its own registry and controls what type
of interactions are allowed outside of its own domain. This pattern
can be used by autonomous departments that develop and deploy their
own services but want to expose a select group of services to the
rest of the enterprise.
Figure 6. Brokered ESBs
An ESB is an architectural pattern that supports virtualization and management of service interactions between communicating participants. It provides connectivity among service providers and requesters, facilitating their interactions even if they're not exactly matched. This pattern can be implemented using a variety of middleware technologies. The most powerful and scalable ESB uses WebSphere Message Broker, which is based on WebSphere MQ. However, if cost is an issue and ease of setup is also a consideration, you can employ WebSphere Enterprise Service Bus, which is based on IBM WebSphere Application Server. IBM also offers WebSphere DataPower SOA Appliances integration devices, which can provide additional out-of-the-box security features and XML processing.
Learn
- Read SOA-Based Enterprise Integration to learn more about SOA.
- Learn more about WebSphere Enterprise
Service Bus.
- Read Getting Started with WebSphere
Enterprise Service Bus V6, one of many helpful IBM Redbooks®.
- Learn more about WebSphere Message
Broker.
- Read WebSphere Message Broker
Basics, one of many helpful IBM Redbooks.
- Learn more about WebSphere DataPower SOA Appliances.
- Read
IBM
WebSphere DataPower SOA Appliances Part I: Overview and Getting Started, one of many helpful IBM Redbooks.
- Read Patterns
of Enterprise Application Architecture, an excellent resource for integration
patterns.
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services
applications.
- Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Stay current with developerWorks technical events and webcasts.
- Browse for books on these and other technical topics at the
Safari bookstore.
- Check out a quick Web services on demand demo.
- Get an RSS feed for this series. (Find out more about RSS.)
- In the
Architecture area on developerWorks,
get the resources you need to advance your skills in the architecture arena.
- Get an introduction to IT architecture in the
New to architecture section in the
Architecture area on developerWorks.
- Find resources to help you architect enterprise and software systems in
free IT architecture kits from IBM.
- Visit
IT architecture resource-roundup to start getting answers to your most pressing architectural questions.
- Get the basics on architecture disciplines from enterprise and application to infrastructure and operations in
Exploring IT architecture disciplines.
- Start with
Enterprise architecture essentials to get an overview of the skills and competencies, tools and techniques, and learning resources associated with architecting at the enterprise level.
- Start with
Application architecture essentials to get an overview of the skills and competencies, tools and techniques, and learning resources associated with architecting at the application level.
- Start with
Information architecture essentials to get an overview of the skills and competencies, tools and techniques, and learning resources associated with architecting at the information level.
- Discover the advantages of using modeling tools from IBM Rational in
Implement model-driven development to increase the business value
of your IT system (developerWorks, Jan 2006).
Get products and technologies
- Download
IBM product evaluation versions
and get your hands on application development tools and middleware
products from DB2®, Lotus®, Rational®, Tivoli®,
and WebSphere®.
Discuss
- Participate in the discussion forum.
- Get involved in the developerWorks community
by participating in developerWorks blogs.
- Participate in the
IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture.
Dr. Waseem Roshen is an IT architect in the Enterprise Architecture and Technology Center of Excellence of IBM Global Business Services in Columbus, Ohio. He works on enterprise architecture and integration. He's also a Sun Certified J2EE Architect, has published 60 articles, and has worked on 24 patents.
