1. Introduction
It might be a stock firm that aspires to improve its uptime and create a more reliable trading system across the globe, or a transnational corporation that aims to improve the data flow across their departments in Europe: all industries, companies and organizations are increasingly dependent on their business processes. CEOs want their information technology systems to measurably improve their data flow and uptime. But accomplishing this is a hard and painful task.
It turns out there has been an answer for these problems for many years, the Enterprise Service Bus (ESB). But what is it? A product ? An architecture ? Or is it a vacuous marketing term designed only to get one to buy even more software? For many years, the IT community has used different definitions of the ESB leading to a lot of confusion about its nature and the roll it can play in intercontinental corporations.
In this paper, we will attempt to clear up at least a bit of this confusion. We will not focus, however, on specific features, API’s, or products, but rather examine the general idea and architecture.
First we will look at definitions and opinions from different companies and see if we can get a clear picture out of these definitions. After giving an in-depth explanation of the philosophy behind the ESB and answering the most prominent questions (how does an ESB work and what are its main characteristics) in chapter 2, we will focus on the advantages and disadvantages of the ESB and what the impact is on extended enterprises. Finally, in chapter 4 we will try to give a conclusive definition of the ESB.
2. Contrasting definitions of the ESB
What is an Enterprise Service Bus (ESB) exactly ? If you were to ask three different IT managers this question, they would all give a different definition of the ESB. But are two of the three given definitions wrong or are there many different possible answers to the question what an ESB is? To find this out we will look at five different companies and research institutes whom all came up with a definition of the ESB.
Of course when we, as IT professionals, don’t know the definition of a specific subject, the first thing we look at is the Gartner Group to see “what do they have to say about it”:
“A Web-services-capable infrastructure that supports intelligently directed communication and mediated relationships among loosely coupled and decoupled biz components” - Gartner Group
Here are four other companies that gave a definition:
“An Enterprise Service Bus is a broker that supports synchronous and asynchronous service invocation. It also enables data transfer and event notification between applications. It helps consumers find providers and handles the details of communications between them.” - Bobby Woolf (WebSphere J2EE Consultant, IBM)
“The ESB label simply implies that a product is some type of integration middleware product that supports both MOM and Web services protocols” - Burton Group
“A standards-based integration backbone, combining messaging, Web services, transformation, and intelligent routing” - Sonic Software
“An enterprise platform that implements standardized interfaces for communication, connectivity, transformation, and security” - Fiorano Software
So the Gartner Group tells us that an Enterprise Service Bus is a “loosely coupled infrastructure” and the Burton Group tells us it is a product. Fiorano however is saying it is a platform which enables one to implement standardized interfaces. This probably sums op why the IT community has been confused for many years about this vacuous term.
The funny thing is, all these definitions are very good, but are all from a different point of view. Simply said, you can’t get a definitive definition in less then a few sentences. But you can however give the most crucial characteristics that all together make and define the ESB but still at the same time can be a pattern or a product.
3. The philosophy of the ESB
In international organizations, vital business applications often have to communicate with other applications around the globe. It is no secret that one imperative for achieving maximum enterprise productivity is to remove the people who serve as the glue between those business processes. In order to allow these applications to communicate with each other integration technology was introduced in order to replace the people, who where the cause of many flows in the system, to function between the different applications.
Though trying to achieve maximum productivity by optimizing communication between the many application services is easier said then done. For years this “integration technology” has been realized by hard wiring these applications together. Resulting often in a cavalcade of projects to update one end point of the system.
To get an understanding of key features of the Enterprise Service Bus we will now look at some problems it could solve. However because of its changing nature in functionality, trying to get an understanding of the ESB is not about trying to define the exact features, but more about what problems it can solve in big enterprises when implemented correctly.
The following examples are practices which we could consider to be bad, but are however widely used with a lot of success.
3.1 The nightmare of integration
Figure 1 is an example of a tightly coupled environment. In this situation we see that each client has a direct connection to each service provider. The approach of hard wiring client and service providers together has been, with great success, used for years. There are however some problems that can occur if the IT infrastructure keeps following this approach.
Figure 1 - Example of a tightly coupled environment
3.1.1 Problem
In a configuration where this kind of “point-to-point” connectivity exists, often there are not ‘just’ three clients and two service providers who have to be connected to each other. Our fairly simple example consisted already of six connections, a more realistic approach however could consist of thousands of clients and hundreds of service providers, who on their turn could also be a service provider for other applications, eventually resulting in a catastrophic amount of connections.
All those clients should know where all the service providers are located, what ports to connect to and what kind of interface they use. When updating one of those service providers (for example a trade system moved from one data centrum to another), thousands of clients should also have to be updated.
In most cases updating thousands of clients isn’t a real challenge anymore, big intercontinental enterprises have overcome these problems and gained a lot experience in this area by building update solutions in their products. This is however not the sort of client we are talking about. The clients in this situation are not the end-point of a system but are often very complicated applications whom are vital to big enterprises around the globe, this client could easily be a technical analysis stock system which tries to forecast the future direction of stock prices through the study of past market data for example.
Updating these kind of clients could become a catastrophic project, resulting in a cavalcade of projects to fix the problems caused by the initial update. The solution of these problems would be to change that tightly coupled fashion into a loosely coupled system, resulting in a more effective, reliable and maintainable infrastructure.
3.1.2 Intelligent Routing as a solution
To accomplish this “loosely coupled system” the clients should not have to know anything about the systems who provide the services. They should not have to know where they are located, on what ports they operate or what interface they use (SOAP, MQ, CICS). It should be a mediator between those systems who has knowledge of all the systems, interfaces and their responsibilities.
3.2 Mediate between the services
One of the many problems international enterprises face when connecting applications is the interfaces whom often do not match. Applications are written in al kinds of languages and environments, it all depends on the service they have to provide and environments they where created in, even the time they where created in is often dependent for example in what language they are programmed, it is just what techniques where mostly used in that time.
3.2.1 Problem
When designing a new service, companies want their service to be able to communicate with other service providers. These providers don’t have to be from the same company. It could be a partner organization who provides a regular service (delivering goods for example), these applications can not be adjusted to the needs, in terms of special interfaces, for each client. Therefore the application protocol layer of the company should be able to communicate with the protocol the partner company provides.
However useful applications rarely make use of just one service provider to accomplish their daily tasks. For that reason applications often need many different protocol layers for each service provider they have to connect to, resulting in a very unstable and messy solution.
3.2.2 Protocol transformation
Luckily the ESB can provide a solution for this problem. By providing an infrastructure which can contain many different interfaces, theoretically all systems can be connected to the ESB and thereby can connect to every service provider who is connected to the same ESB.
This solution provides a more stable, maintainable and useful environment. When the interface of an application is changed, only the ESB has to be updated in order to make it compatible with the infrastructure. This of course is preferred above the solution of updating all applications one by one.
This solution is however very complex, because it is not just transforming the incoming data, for example XML to JSON, it should also make it compliant for the service it is supposed to go to. This means the ESB should not only know the port, ip address and protocol about every application. But also about the structure of the data, amount of requests the application can handle and what kind of answers it sends back to the ESB. This way the ESB can on his term ensure the owner of the request that messages are delivered or not.
Only when all these features are implemented you could speak about reliable protocol transformation.
3.3 Queuing requests
Most of the communication between applications these days are done by invoking requests. The most common request is a synchronous request, with this method the client uses a single thread to get or send the information to or from a specific application. Using synchronous requests has however some drawbacks when used in high-end and vital business applications. These applications rarely live in isolation, and in order to accomplish their daily tasks they have to communicate with a lot of applications often with an enterprise. As a result communication between these systems can generate a horrific amount of traffic and when not dealt correctly with the type of requests it can cause a lot of problems. To give you a vague idea of the problems that emerge when applications only make use of synchronous request we will now look at two simple problems.
3.3.1 Problem
When dealing with different kind of requests in high end systems it often can result in a lot of problems when requests are not handled properly. In Figure 2 we see an example of two systems whom both are connected another system.
Figure 2- structure example of three applications
We could imagine that these applications do a lot of requests to the end application. Now lets imagine that we would send a synchronous request with all the payment information of the last week from AppOne to appThree, we are not talking about “just” thousand records but it would not be inappropriate to suggest tens of thousands of or even more! Of course when AppThree gets so much data at once it will take some time to accomplish the task of restructuring the data, doing something appropriate with new information and then send an appropriate message back to AppOne.
Of course because AppOne communicates with AppThree by sending synchronous requests AppOne would wait for a response from AppThree to make sure that all the data was handled properly and maybe he would even expect some valuable information back. As a result when appTwo would try to send a request it would not be able to. Due to the fact that appOne is blocking all other requests by still waiting for an answer.
Though even when AppTwo doesn’t need to send any requests at that time there is another problem that can arise. If for example appThree takes to long to handle the request and send back a response. AppOne would eventually break off the request and would have to repeat the whole process.
3.3.2 Asynchronous vs Synchronous requests
One of the ways to solve the problems mentioned above is to implement asynchronous queue in an ESB. This way applications won’t have to wait on a response but will just send the request to the ESB. The ESB will then store the request in a in a “request queue” and the response in a “response queue”. Of course this can’t be accomplished by every request and it shouldn’t be. The ESB or application will have to determine if the request should be synchronous (the client application uses a single thread to invoke the service and will block the thread waiting for a response) or asynchronous (a thread of the client application sends the request to the ESB queue and won’t wait for a response). Eventually, when implemented correctly, the whole enterprise will profit due to the fact that the applications will be more more reliable and efficient in their resources.
Figure 3 is an example of an ESB that will keep track of requests by setting it in a request or reply queue. In this communication could be established via SOAP requests but could of course be any type of communication.
Figure 3 - example of a synchronous request system
4. Key advantages and disadvantages
In chapter three we saw a few examples in what areas an ESB could be a useful solution. There are however no specific guidelines an environment should meet in order to be an ESB. When in 2002 the ESB was first introduced as a product by Sonic Software and as a result got a lot of attention, it resulted in a debate about the essence of functionality and the definition. There are however a few widely accepted characteristics that can help us to define our understanding of the ESB. the most important characteristics where already mentioned in chapter three:
- Intelligent routing
- Protocol transformation
- Synchronous and asynchronous queuing
Without making use of features mentioned above systems can’t be called an ESB. So far we saw a few problems the ESB could solve. But what are the real advantages and disadvantages that emerge when enterprises make use of an ESB.
4.1 Advantages
Of course we already saw a lot of problems that do often occur in point-to-point application infrastructures. We will now take a look at the three most important advantages before moving on to some disadvantages whom often are not easy to solve but have to be taken into consideration when deciding to move to an ESB.
4.1.1 Increased flexibility
As we have seen in chapter 3.1, hardwiring many applications together with point-to-point connections can cause a lot of problems. Not only does the loosely coupled idea of the ESB (see Figure 4) result in a more reliable system, but also increases flexibility.
This increased flexibility is accomplished by removing the need of applications to know what application is responsible for which data. This is all done by the ESB which knows with its intelligent routing where it has to send the request to in order to get the information the application has asked for.
This loosely coupled fashion enables a software developer to change the nature of an application and as a result only needs to update the ESB. This will result in less errors, decreased development time and a more robust and maintainable system.
Figure 4 - The ESB, and loosely coupled system
4.1.2 Standards based
Many enterprises overtime have developed their own standards in order to let their applications communicate. When enterprises eventually decide to transform their infrastructure to an ESB it will insure the enterprise that future applications who will be added are forced to meet those standards in order to let them communicate with other applications.
In order to let applications communicate with an ESB they have to meet some predefined standards. When developing or implementing an ESB, naturally at first it might seem like an awful and time consuming task to define all the standards and changing all applications to those standards but in time this will insure that the system will also function properly in the future and will keep doing that as long as new application keep meeting the standards.
4.1.3 Reduced complexity
Of course this is one of the most obvious advantages of the ESB, but also probably the most important one. It is no secret that the key to increasing reliability and maintainability is by introducing protocols and procedures but also by decreasing the complexity of systems. Figure 5 shows the decrease of complexity when moving point-to-point infrastructures to an ESB, mind you this is of course not a real world example.
Figure 5 - point-to-point connectivity versus an ESB
4.2 Disadvantages
As we have seen in the last few chapters there are a lot of advantages. But disregarding the many problems it solves their are some problems which also have to be taken into consideration. Many of these problems do not occur in point-to-point systems.
4.2.1 The ESB as single point of failure
Although enterprises who make use of an ESB will get much better and reliable systems when they make use of an Enterprise Service Bus, there are however a few drawbacks that have to be overcome. One of those drawbacks is the “single point of failure” whom is created by centralizing all network communication to one point. This could eventually result in a catastrophic event for many enterprises when this system would crash. To overcome this problem enterprises should not rely only on one Enterprise Service Bus, but should implement fail back procedures or “ghost systems” in case of such a catastrophic event.
4.2.2 Increase latency
By introducing an extra component in a information system it comes as no surprise that more overhead is introduced, resulting in a slower system. Requests have to make more “jumps” when they try to get to their final destination. Besides the obvious problem that more “jumps” means more time, often the ESB will have to transform the data to make it suitable for other applications which also increases the request time.
This is a serious problem and should be dealt with as soon as possible when enterprises try to integrate an ESB. When deciding to implement an ESB into their corporate infrastructure it should always be taken into consideration that the latency will increase and as a result will increase the time of requests. It will never be as fast as direct connect applications.
4.2.3 Costly implementation
Though there are of course some disadvantages mentioned above, but maybe the most challenging part is the actual implementation or creation of an ESB. It requires a significant amount of effort, knowledge and planning when enterprises trying to succeed in building or implementing such complex systems. If not designed with care it could result in a catastrophic project. Also many enterprises will not see the advantages due to the fact that they do not produce any commercial value, and thereby as a result will not give the proper funds to accomplish such a task.
5. Conclusion
After reading this research paper, you should have an understanding about the Enterprise Service Bus. One of the most import things to remember is the fact that the Enterprise Service Bus is a loosely coupled system that, when implemented correctly, will result in a more effective, reliable and maintainable infrastructure.
Due to the fact that the functionality of an Enterprise Service Bus is changing as the IT community evolves in it’s understanding of the ESB, it is almost impossible to give a definition without using vague terms. There are however a few characteristics that an ESB should have:
- Intelligent routing
- mediation between different application interfaces
- Reliable communication
With these key characteristics in mind you should be able to at least come up with your own definition of the ESB and know what the advantages and disadvantages of an Enterprise Service Bus are.
Although the ESB got a lot of attention over the last few years, it is almost certain to say that this is just the beginning and this trend will continue to grow in popularity. Not only will this result in more efficient systems in terms of development and stability but will also reduce overall cost in IT departments of enterprises.
Used Literature
Books
- Enterprise Service Bus (O’Reilly: June 2004, ISBN 0-596-00675-6)
- Open-Source ESBs in Action (2008 Manning, ISBN 1933988215)
Articles
- “Intergration Patterns” (msdn - microsoft library)
- “why do developers need an ESB” (Bobby Woolf, IBM, 2005)
- “Microsoft on the ESB” (msdn library, 2005)
- “the ESB, a ride you shouldn’t miss” (David Berlind, Zdnet, 2004)
- “Service-oriented architecture” (Wikipedia, 2009)
- “Choosing between Routing and Orchestration in an ESB” (Adrien Louis & Marc Dutoo, InfoQ, 2008)
- “Driving the Enterprise Service Bus” (Paul Krill, InfoWorld, 2003)
