Introduction

In a Service- Oriented Architecture (SOA), an Enterprise Service Bus (ESB) is a critical and important component of the infrastructure. An ESB is used to indirectly connect applications which employ disparate forms of services as shown in Figure 1. These different forms of services include web services, RESTful services, asynchronous services such as the services which use MQ, CORBA-based services, DCOM based services, and Java RMI. These services employ different communication protocols and message forms. For example web services use HTTP as the communication protocol and SOAP as the message format type while asynchronous services may employ MQ as the communication protocol and XML as the message format.

Currently available ESBs provide a number of core functionalities to connect applications which employ disparate forms of services. However, in these currently available ESBs, each application connects to the ESB using a specific port type as shown in Figure 1. The port type used by a given application is determined by communication protocol and message format type used by that application. There are a number of problems associated with the use of these specific port types by the applications. You will learn about these problems and inconveniences in a later section of this installment, part 1 of this series.

We start out the next section of this installment by first providing an introduction to ESBs by outlining some of the problems that are inherent in point-to-point connections between applications and how the use of an ESB helps to solve these problems. Next, in section three of this installment, you will learn about the various problems related to the use of different ports types by various connecting applications in the currently available ESBs. The last section of this installment will contain a few concluding remarks.

ESB Core Functions

The purpose of this section is to provide an introduction to an ESB by briefly describing the three core functions and the related problems of connecting applications with heterogeneous services using point-to-point connections approach.

Connection Scalability and Routing

Consider a medium size company that needs to integrate six applications. The connections required to connect these six applications are shown schematically in Figure 2.

You can see that the number of required connections in this case is 15. This number is equal to number of distinct pairs of applications in the integration scheme. Similarly it can be shown that in case of ten applications the number of connections required will be 45. Thus we can conclude as the number of applications increases, the number of connections required quickly explodes in a non-linear fashion. This is termed a hairball problem because it can clog any network. In fact, it can be shown that if an enterprise has N applications to be integrated, the number of connections required in the point-to-point approach is

N(N-1)/2

This is easy to understand because the number of distinct pairs of applications is also N(N-1)/2 . Hence, we can conclude that the point-to-point integration scheme is not suitable for integrating a large enterprise and another solution should be found that has better scalability.

Enterprise Service Bus provides an excellent solution to the connection scalability problem and therefore is suitable for medium-to-large enterprises that need to integrate a significant number of applications. In the Enterprise Service Bus interaction style, the applications do not interact directly with each other. Instead, the applications connect to the bus and the bus provides the means for connections among the applications. This indirect interaction is shown in Figure 1, which shows six applications interacting among themselves through the use of the Enterprise Service Bus. The most important thing to note from Figure 1 is that the number of connections needed is only six. This number is substantially less than the number of connections needed for six applications in the point-to-point scheme (that is, 15). Another important thing to note from this figure is that the number of connections needed is equal to the number of applications being integrated. Therefore, if we had ten applications we only need ten connections. This number of connections is very small compared to the number of connections needed in the point-to-point approach (that is, 45).

An ESB achieves the capability to indirectly connect applications by providing content and context based routing. Thus the requesting application does not need to know the address of the target application or even which application is providing the service.

Protocol Mismatch and Protocol Transformation

The communication protocol mismatch problem arises because in a large enterprise different applications typically employ different protocols for communications. In other words, in the real world a proliferation of these protocols exists, including HTTP, HTTPS, JRMP, IIOP, and JMS. Because of this proliferation, sometimes a protocol mismatch will occur between the service consumer application and the service provider application. Therefore, without a facility to transform one communication protocol to another, the service consumer application will not be able to invoke the service offered by the service provider application. This problem is shown schematically in Figure 3.

Therefore, another core functionality that should be included in an ESB is a protocol transformation facility that can translate one protocol into another. With this transformation facility, the applications using different protocols can interact with each other. It is important to point out that currently available commercial ESBs already support protocol transformation. For example, it is quite common to transform from HTTP, which is used for synchronous message exchange, to MQ asynchronous messages. For this purpose a correlation ID is used to tie request and response MQ messages.

Message/Data Format Mismatch and Transformation

One more heterogeneity problem is the problem of data/message format mismatch. This problem refers to the fact that sometimes the data format provided by the service consumer and the data format required by the service provider application do not quite match. This prevents applications from interacting with each other as shown schematically in Figure 4.

Therefore, another core functionality that needs to be provided by an ESB is data or message transformation. Most of the available commercial ESBs provide this functionality employing different techniques. For example, XML Style sheets can be employed for transforming between different forms of XML including SOAP. When this functionality is combined with the other two ESB functionalities, the applications are easily able to connect and interact with each other, even when their interfaces and protocols do not match completely.

Miscellaneous Other Functionalities

In addition to meeting these three functional requirements, an ESB also implement services for meeting non-functional requirements such as performance and reliability, auditing, and security. Furthermore, many commercial ESB products offer other optional services such data enrichment, distribution of messages, correlation, and monitoring.

These functional and non-functional requirements can be met by a single product or a group of products. In other words, ESB is basically a pattern, which does not necessarily have to be implemented as a single product.

Problems with Currently Available ESBs

In the currently available ESBs, each application connects to the ESB using a specific port type as shown in Figure 1. The port type is determined by the type of service used by an application to expose its functionality. For example an application which exposes its functionality through a web service must use a port type which caters to HTTP as the communication protocol and SOAP as the message format. In other words, a given application must connect to the ESB through a specific port type, with the port type determined by the communication protocol and message format used by the application. This method of applications connecting through a specific port types is cumbersome and inconvenient for many reasons. Some of these reasons are:

• Many times, because of the changed requirements or runtime environments, an application wants to switch communication protocol. However, this also requires a change in port type on the ESB side, and will almost certainly require building of another port type. This obviously takes time and resources.
• A common situation is where an application wants to use multiple protocols for exposing different functionalities. This is often the case for the mainframe COBOL applications, where a given application exposes some of its functionality using Web Services, while at the same time; it exposes another set of functionalities through the use of a messaging protocol such as MQ. Once again, this requires building new port types at the ESB end to cater to both types of protocol, which is very inconvenient as it requires both time and resources.
• In the currently available ESBs, it is very difficult to extend the use of the ESB to the newly formed communication protocols. This is because it requires changes on both the application end and the ESB end. On the ESB side, it requires developing of completely new port type.
• Because each application must connect to the ESB through a specific port type, it takes quite a bit of efforts to configure the ESB for the use of by an application. Theses efforts may include building of a new port type, deploying it in an ESB, and configuring ESB for the use of the specific port. All this makes it difficult to connect large number of applications through the use of the ESB, and hence results in a scalability issue.
• Also, because each port must be deployed and configured separately, it is difficult to maintain and update an ESB.

Conclusion

In this installment, you learned about some of the problems of integrating applications which use disparate form of SOA services and how the core functionalities of the present day ESBs address these problems. You have also learned that there are additional problems related to the use of different port types in the currently available ESBs. These problems are not addressed by the currently available ESBs.

In the next installment, to overcome the short comings of the present day ESBs, you will learn about a new ESB type. This new type of ESBs would employ a single universal port type which can cater to most or all application types which employ disparate services types to exposes some or all of their functionalities. This will eliminate or drastically reduce the need for developing and deploying new port type for each new application type. The new universal ports type would lead to a large number of benefits including much greater code re-use. The benefits of the use of Universal ports type will be elaborated in a later installment.

Resources

Learn

• A recent book : "SOA-Based Enterprise Integration" is an execellent source for a step-by-step approach to SOA and Web Services.
  
  
• In the SOA and Web Services area on developerWorks, you will find articles, tutorials, standards, and other technical resources for web services and SOA.
  
  
• A very good source on the basics of ESB is Chapter 8 of the book : "SOA-Based Enterprise Integration"
  
  
• Another execellent source on the basics of ESB is a developerworks paper: Services-based enterprise integration patterns made easy, Part 4: Enterprise service bus"
  
  
• For information on IBM's premier ESB product, WebSphere Message Broker (WMB), visit Message Broker Information Site"
  
  
• For information on a low cost ESB product from IBM, visit WebSphere Enterprise Service Bus
  
  
• For information on hardware-based ESB products, visit WebSphere DataPower SOA Appliances
  
  
• To learn more on communication protocols such as HTTP, visit: HTTP
  
  
• An execellent source for information on SOAP meassage format is SOAP Wikipedia
  
  
• 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.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Dr. Waseem Roshen has a PhD from The Ohio State University, Columbus, Ohio (USA) and has over 18 years of practical experience in the Information Technology (IT) field. Currently Dr. Roshen works as an IT Architect in the Enterprise Architecture and Technology Center of Excellence at the IBM Corporation. He has extensive experience with distributed computing, including service-oriented architecture (SOA). In addition, he has expertise in custom development, integration architecture and J2EE (now known as JEE). His currents interests include SOA and web services, Quantum Computers, and Cloud Computing. Dr. Roshen has over 60 publications and 37 patents and is a member of IEEE and the IEEE Computer Society. He is the sole author of the book: SOA-Based Enterprise Integration: A step-by-step guide to services-based application integration.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• ESB Core Functions
• Problems with Currently Available ESBs
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers