An Enterprise Service Bus (ESB) provides efficient means to connect applications among themselves and to share data and functionalities. These applications may employ disparate form of service to expose some or all of their functionalities. This is shown schematically in Figure 1 for the currently available ESBs. The most important thing to note from this figure is that each application connects to the ESB using a specific port type. In other words, each port type caters to applications of a specific type which use specific communication protocol and message/data format type to expose their functionalities.
Figure 1. Applications connecting through conventional ESB using specific port types
In the first installment you also learned about some of the common problems in the use of currently available ESBs which use specific port types. These problems and inconveniences include use of multiple communication protocols by an application, switching of communication protocol by an application, extending the use of ESB to new communication protocols, scalability to large number of applications, and general maintenance and update of an ESB.
To overcome these short comings of the present day ESBs, a new ESB type was proposed in the second installment, Part 2 of this series. This new type of ESBs would employ a single universal port type which can cater to most or all application types as shown in Figure 2. This will eliminate the need for developing and deploying new port type for each new application type and would lead to much greater code re-use.
Figure 2. Applications connecting to an ESB using a single port type (Universal Port)
In order to understand the concept of the Universal port type, an analogy with the computer hardware such as a PC would be helpful. Before the advent of USB ports, in order to connect different devices such as a printer, a flash memory, or a removable hard drive, to the computer, the computer required the existence of the different port types. Each port type catered to a specific device type. Thus, to connect a printer to the computer a specific port type would have to be built into the computer. Similarly, a different port type had to be present in the computer to connect an extra hard drive. However, more recently with the invention of USB ports, the need for separate port types for each device type has been eliminated and now almost any device could be connected to the computer using a single port type called USB port.
This new type of ESB with Universal Ports offer a large number advantages over the conventional ESBs. Some of these benefits are on the ESB side while others are on the connecting applications side. We will first discuss the benefits on the ESB side in the next section.
On the ESB side, the most important benefits of the use of Universal Ports are:
After the Universal Ports are in implemented on the ESB, most of the users of the ESB will see huge simplification in the use of the ESB. This simplification primarily will result from the ease with which Universal Ports can be configured. Since code behind each would be the same, the only important configuration element will be to associate a Universal port with the port on the Machine or Computer on which the ESB is running. This will be a great simplification compared to the current situation in which almost all ports are custom ports and there is proliferation of the type of ports. It is also important to note that the Universal Port is a very light weight component compared to the present ESB port components. The only purpose of a Universal Port is to determine the communication protocol being used by a connecting application and then to forward the request to the appropriate protocol processor in the body of the ESB as shown in Figure 3.
Figure 3. Universal Port as a light weight component with most processing occuring inside the body of the ESB
It will be easy to extend the ESB to service new communication protocol. In fact, it will make it possible to install a new protocol processor by downloading the code and registering the new protocol with the ESB. To understand this extendibility, consider the analogy with a new hardware device connecting through an USB port. The code, called driver, is usually downloaded from a web site and it gets registered. In a similar manner, that is all one has to do to start using a new protocol using an ESB port.
Code Reuse and Ease of Maintainability and Updates
In the new scheme, a single copy of the code for each protocol will reside in the body of the ESB. This will be in sharp contrast to the present implementations of ESB, where in the code for each protocol belongs to individual ESB ports and multiple copies of the same code can exist in different ESB ports. Thus, in case of Universal Ports there will be much higher degree of code reuse. This code reuse will result in a more consistent behavior of the ESB. Furthermore, the code will be easy to maintain and update since the code will exists in a single place.
Because of the huge simplification in process of configuring ports on an ESB, a large number of ports can be configured easily and quickly. This will allow a large number and types of applications to connect to the ESB, thus yielding high level of scalability in terms of types and number of applications that can be integrated. The use of Universal Ports, will also allow runtime scalability in terms of number of calls to the ESB. This type of scalability can be achieved because each protocol processor will be part of the body of the ESB, we can have multiple instances of each protocol processor, and each of these protocol processors can be reused by multiple Universal Ports.
Benefits on the Application Side
The most important benefits (on the connecting applications side) of the use of Universal Ports are the following:
The introduction of Universal ports will not require any major, if any, modifications for applications which currently are connected to the ESB. This is a great benefit because the transition from a conventional ESB to the new ESB type with Universal Ports can be made without the applications being aware of the change.
Typically the runtime environment of the application allows the application only one way/protocol to connect to the ESB and this protocol must match the protocol that is available on a given port on the ESB. For example for an application to be able to use MQ as the transport, some version of MQ must have been installed on the machine on which the application is running. Use of Universal Ports will allow an application to use any protocol which the runtime environment allows and the problem of matching the application protocol with the protocol on the ESB side will be eliminated. This may also reduce some of the runtime requirements on the application side.
Convenience of Switching Protocol
In the IT world, requirements can change frequently. In addition, new requirements can appear. In particular, the changed requirements may require the change of the communication protocol being used by an application to connect to the ESB. Examples of such new or changed requirements are: new requirements as regards transactions, security, reliability, and persistence. The use of the Universal ports would make it very easy for the application to switch protocol any time since it will not require any change (or will need minimal change) on the ESB side.
Use of Multiple Protocols by an Application
It is not uncommon for different components/[parts of an application to use different protocols to communicate with ESB and other applications. For example, it is fairly common for the different parts of a Legacy (COBOL) application running on mainframe to use different protocols such as Web Services, MQ, or Gateway. The use of Universal Ports will allow different parts of the application to connect to the ESB using the same computer port. This will help simplify configuration for such a connection.
In this third installment, Part 3 of the series you learned that there are a large number of benefits that the new ESB with Universal Ports enjoys over the conventional ESBs with ports specific to a communication protocol and message format type. Some of these advantages are on the ESB side while the others on the connecting application side.
This concludes this series on the new ESB type with Universal Ports. In Part 1 of this series you learned that there a number of problems associated with the use of currently available ESBs with ports specific to communication protocol and message format type. In the Part 2 of this series you learned about the concept of Universal Ports and how to implement these Universal Ports. Lastly, in Part3 of this series you learned that there are a large number of benefits, both on the ESB side and the connection application side, of the use of the Universal Port type. It is important to note that IBM has pending patents in this area and more details of the ideas presented here can be found in these patent applications.
- A recent book :
"SOA-Based Enterprise Integration"
is an excellent 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.

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 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.




