USB-Like Universal Ports Type for Enterprise Service Bus, Part 1: Problems with current ESBs

Learn about basic functionalities of the current ESBs and some of the problems with current ESBs

In this installment, part 1 of this series, you will first learn about the basic functionalities of the currently available Enterprise Service Buses (ESBs). In this part 1, you will also learn about some of the difficulties in the use of the currently available ESBs. In the later installments of this series you will learn about the new concept of the Universal Ports type for ESB. Universal Ports provide solution to the many of the problems that the current users of the ESBs experience. A Universal Port works analogous to the USB port of a computer, which is to connect devices of varied kind to connect to the computer. In a similar manner a Universal Port can be used to connect to any application to the ESB and, indirectly, to the other applications. These applications may employ disparate forms of services to expose some or all of their functionality and still use a single port type.

Dr. Waseem Roshen, Master IT Architect, IBM  

Waseem RoshenDr. 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 62 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.



26 August 2011

Also available in Chinese Russian Japanese Vietnamese

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.

Applications connecting through ESB using specific port types
Applications connecting through an ESB

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.

Six application connections using pont-to-point integration approach
Applications connecting in point-to-point approach

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.

Protocol Mismatch Problem
Protocol Mismatch Problem

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.

Data Format Mismatch Problem
Process Summary

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

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=753891
ArticleTitle=USB-Like Universal Ports Type for Enterprise Service Bus, Part 1: Problems with current ESBs
publish-date=08262011