USB-Like Universal Ports Type for Enterprise Service Bus: Part 2: Concept, process, and implementation

Learn about concept and implementation of Universal Ports for an ESB

In the first installment, part 1 of this series, you learned about the basic functionalities of the currently available Enterprise Service Buses (ESBs). In part 1, you also learned about some of the difficulties in the use of the currently available ESBs. In this installment, Part 2 of this series, you will learn about the new concept of the Universal Ports type for ESB and how to implement Universal Ports. 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 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. In the installment, part 3 of this series you will learn about the many benefits of Universal Ports.

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.



08 November 2011

Also available in Chinese Russian Japanese Vietnamese

Introduction

Enterprise Service Bus (ESB) is a critical part of the Service-Oriented Architecture (SOA) infrastructure. An ESB provides efficient means to connect applications among themselves. 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.

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

In the first installment, part 1 of this series, you learned about the basic functionalities offered by the currently available ESBs, which include content and context based routing, protocol transformation, and data/message format transformation. In the first installment you also learned about some of the common problems in the use of currently available ESBs. 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.

In this installment, part 2 of this series you will be introduced to a new type of ESB, which employ Universal Port type. In the next section you learn about the basic concept of Universal Ports. The general process of implementing USB will be described in the section 3 of this installment. In section 4 you will learn two methods for detection of communication protocol being used by a connecting application. The last section of this installment will include some concluding remarks.

Universal Ports Concept

To overcome the short comings of the present day ESBs as outlined in the last installment, Part1 of this series, a new ESB type is proposed here. 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.

Applications connecting to an ESB using a single port type (Universal Port)
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.

Process

A general process for working of an ESB with Universal ports is shown in Figure 3. The process consists of the following steps:

  1. The process starts when an application connects to the ESB through a USB-like port and sends a message. This message could be in any format and sent using any protocol
  2. The message is intercepted by a protocol detector software component, which determines the communication protocol being used by the application.
  3. Once the communication protocol is determined, the message is sent to an appropriate protocol processor component. Note that the system will have one protocol processor component each for a given protocol. Thus we will have separate protocol processors for HTTP, SMTP, IIOP, etc protocols. The purpose of these protocol processors is to extract the body of the message, which should be independent of the protocol being used by the application.
  4. The extracted message is then sent to another software component, called format detector. This software component is responsible for determining the message format. Examples of message formats include SOAP, (raw) XML, copybook, etc.
  5. After determining the message format, format detector component forwards the message to an appropriate component for conversion to a canonical (common) format.
  6. Next the canonical format is converted to a target format by a conversion software component. This target format is dependent on the application type of the target application.
  7. The conversion software component then sends the message to a target protocol generator component. After receiving the message the target protocol generator component, generates the target protocol with the message in the target format.
  8. Finally, the target protocol generator component sends the message to the target application.
Process of implementing ESB with Universal Ports type
Process of implementing an ESB with Universal Ports type

Click to see larger image

Process of implementing ESB with Universal Ports type

Process of implementing an ESB with Universal Ports type

Note that most of the steps (3 -8), can be performed outside the port component and inside the body of the ESB. Moving steps 3 -8 to the inside the body will result in much code reuse. The only thing left for the Universal Port is to determine the communication protocol used by the connecting application. This is shown schematically in Figure 4. Thus the Universal port is a very light weight component. In the next section we describe two methods for determining the communication protocol.

Universal Port as a light weight component with most processing occuring inside the body of the ESB
Universal Port as a light weight component

Detecting Communication Protocol

We now describe two new methods which will allow implementation of a Universal port as a light weight software component.

Super Protocol Method

The first method introduces a super-protocol or a Meta Protocol, which will be used as an envelope for each high level protocol. The envelope of the super-protocol will include a header which will have information on the type of high level protocol (e.g. HTTP or IIOP or JRMP, or JMS/MQ) being used by an application. This header will be included in the message by the connecting application as the first line of the message. The rest of the message will contain the higher level protocol headers and the actual message content. If this super-protocol is used, then the Universal Port will only have to parse the first line of the message received to determine which high level protocol is being used by the connecting application. After determining the high level protocol the software component constituting the Universal Port, will simply forward the message to the appropriate protocol listener in the body of the ESB for processing. Thus, the Universal Port will be a very light weight software component having only to parse the first line of the message. In addition, high level protocol listener code will be greatly reused because each high level protocol listener will be part of the body of ESB and can be used by any number of Universal port components. A minor disadvantage of this method is that the applications code will need to be modified slightly in order to enable the use of this super protocol.

An example of the use of Super-protocol as an envelope for a high level protocol (HTTP) is provided below:

Listing 1. Example code for the use of a super protocol as an envelope for the high level protocols such as HTTP
Protocol: HTTP   Format: SOAP
GET /intro.html HTTP/1.1
User-Agent: Mozilla/5.0 (Windows;en-GB;...
Accept: text/*,image/jpeg, */*
Accept-Language: en-gb
...
...

Since the first line contains the required information, the code in the Universal Port will need only parse the first line in order to determine which high level protocol is being used. After this detection, the Universal Port code simply invokes the appropriate protocol processor in the body of the ESB, as shown in Figure 4.

Socket Level Detection

The second method of dealing with the problems mentioned in the first section is to realize that all the high level protocols such as HTTP, IIOP, JRMP, JMS/MQ, etc are built on the top of TCP/IP. In other words all these protocols employ TCP/IP sockets in the background for enabling communications between the applications and the ESB. Furthermore, all these protocols include headers and the information in these headers could be used to detect which high level protocol is being used by the connecting application. These headers are visible / readable if the incoming message is read at the socket level. Thus, this method of detecting the protocol will rely on listening to the incoming message at the socket level. This will make the Universal Port a very light weight component since it will only have to read the first header/line of the message and then forward the message to the appropriate protocol listener in the body of the ESB. As in the first method this will also result in much code reuse since the each protocol listener will be part of the body of the ESB and the same protocol listener can be used by any number of Universal ports.

To illustrate the use of this method, we now provide an example of the use of this method. For this example we consider an HTTP incoming request. If you read the request at the socket level, the headers of incoming HTTP request would look like the following.

Listing 2. Socket level detection
GET /intro.html HTTP/1.1
User-Agent: Mozilla/5.0 (Windows;en-GB;...
Accept: text/*,image/jpeg, */*
Accept-Language: en-gb
...
...

The most important item to note from these headers is the first header on line 1. This header is mandatory for this protocol. In this header the occurrence of the string HTTP is also mandatory. Thus by just looking at the first line, we can identify this protocol to be HTTP. In addition, this particular protocol starts from a word from a short, specific list of words. This list contains specific words including GET, PUT, DELETE, etc. Thus one may also look at the first word of the fist line of the incoming request, and if this word matches any word in the short list, one can conclude that the incoming request is using HTTP protocol.

It is quite easy to read the message at the socket level in most common programming languages such as Java and C++. As an example code we provide a snippet of Java code that can be used for our purpose.

Listing 3. Code for reading message at socket level
import java.io.*;
import java.net.*;

public class testServer {

//declare a socket server and a socket //client
SocketServer myServer = null;
ClientServer myClient = null;

//declare an input stream and an output //stream
DataInputStream in;
PrintStream out;

//declare a variable to hold the first //line of the incoming message
String firstLine = null;

//open a socket for listening at the port //number 8080
myServer = new ServerSocket (8080);
//accept connection
myClient = myServer.accept();

//get the incoming message
in = new DataInputStream ( myClient.getInputStream());

//store the first line of the message in a //local variable
firstLine = in.getLine();


...
...

}

Note that the variable firstLine in the above code contains the header information we need to determine the high level protocol being used by the connecting application. With this simple and short code, the Universal Port becomes light weight, which then invokes the appropriate protocol listener/processor in the body of the ESB as shown in the Figure 4. This also results in a high degree of code reuse since each protocol listener/processor can be used by many different Universal Ports.

Conclusion

In this installment we have described the concept of Universal Ports for an ESB. A Universal Port can be used to connect almost any application to the ESB and, thereby, connect indirectly to any other application connected to the ESB. The application could use any communication protocol or message format type and still use this single type of Universal Port.

In this installment you have also learned about the process of implementing a Universal Port. It is important to remind yourself that in this process Universal Port is a light weight component, whose only function is to detect the communication protocol being used by a connecting application. In addition, in this installment you learned two different methods of detecting the communication protocol being used by a given application.

In the next installment you will learn about many advantages of the use of Universal Ports in an ESB.

Resources

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=772419
ArticleTitle=USB-Like Universal Ports Type for Enterprise Service Bus: Part 2: Concept, process, and implementation
publish-date=11082011