Easy access to a service-based enterprise integration model, Part 4: Enterprise Service Bus

Introduction

Web services are designed to address some of the application heterogeneity problems encountered in large enterprises. However, the Web service itself does not provide a complete solution to resolve the heterogeneity problem. In particular, they are not intended to handle a mismatch between the transport protocols used by the service consumer and the service provider application. The problem associated with this mismatch is the problem of interface mismatch. This type of mismatch is usually caused by the result of mergers and acquisitions. One possible solution is to rewrite these applications against the new Web service to eliminate these mismatches. But often there is not enough developer resources or there is not enough time to perform such a large number of tasks.

In this case, the Enterprise Service Bus (ESB) provides an excellent solution to the problem of heterogeneity in large systems. An ESB is an integral part of a service-oriented architecture (SOA). It provides a comprehensive, flexible, and consistent approach to integration. In the ESB pattern, the service consumer and the service provider do not interact directly; they communicate through the bus. The bus provides a number of features, including protocol conversion, data transformation, and core functionality based on content and context routing. You will learn about these features and other common features described in the following two sections.

Another reason to consider using an ESB is that it is sometimes necessary to guarantee the submission of a message for contractual or legal reasons. In these cases, you need to use a service other than the Web service. An example of such a service is an asynchronous service that uses messaging software, such as the IBM®WEBSPHERE®MQ series. Message submission can be guaranteed by persisting messages on the requester and server side of the network.

Core functions

By reading the object request agents (ORB) and asynchronous messaging in part 2nd of this series, you can see that both technologies provide some form of basic routing based on content or context. This content-or context-based routing forms the framework of the ESB. Therefore, there are two types of ESB that are commonly used:

An ESB based on an orb product, such as IBM Websphere®application Server. Typically, these products are very powerful in processing Web services, XML, and java™ remote method calls (RMI). The cost of using these products is fairly low and very easy to set up. However, it is less scalable for a large number of transactions and more diverse applications.

ESB products based on asynchronous messaging software, such as WebSphere MQ. An example of this type of ESB product is IBM WebSphere message Broker. These ESB products have a high degree of scalability in transaction volumes and in the processing of more diverse applications. But these products are more expensive and require a longer setup time. These two types of products are generally interoperable. For example, IBM WebSphere Enterprise Service Bus can interoperate fully with an ESB based on WebSphere message broker.

Content-based routing by itself is not enough to solve all the heterogeneity problems in large enterprises. Specifically, there is an increasing number of communications protocols, including HTTP, HTTPS, Internet ORB Protocol (Internet Inter-ORB PROTOCOL,IIOP), Java Remote method Protocol (Java remoted methods Protocol, JRMP) and Transmission Control Protocol (Transmission control PROTOCOL,TCP). Therefore, you will find that the service consumer may be set up to use only one protocol, but the service provider would prefer to use a different protocol. If there is no tool for converting one protocol to another, it is difficult for a service consumer to communicate with a given service provider. The requirement associated with this requirement is that the data format that the user prefers may be different from the data format used by the service provider. Therefore, a tool that provides this data conversion is also required. In general, the least functionality provided by the ESB includes:

A route based on context or content.

Protocol conversion.

Data conversion.

If these minimum features are included in a component, the component becomes the service bus that provides virtualization, so applications do not need to communicate directly with each other. Figure 1 shows a schematic diagram of this indirect interaction.

Figure 1. Indirect interaction through an ESB