Perhaps you have heard one of your colleagues mentioning ‘what we need is an ESB to tackle our integration issues’ or read in a magazine about the wonders of the Enterprise Service Bus. But what is it exactly?
In this article we explain in simple to understand terms what an ESB is (minimal ICT knowledge required), what you can expect from it and what benefits it will bring properly implemented. We will simplify terms so they become clear to a larger audience without sacrificing the truth.
“The Enterprise Service Bus acts like a traffic cop, directing communication between systems but also telling you to walk faster”
A bit about architecture
An ESB is foremost an architectural model. Core of the model is the fact that the ESB acts as a central place for message exchange. An ESB is a critical component of a Service Oriented Architecture (an architectural model where components offer services via messages to other components).
The fact that it is called enterprise service bus gives an indication where the ESB can play an important role: the Enterprise. Especially in these environments, where a large number of systems and applications are in use, ESB can help organizations to enable new products and services built on these disparate systems.
Monoliths, 3 tier and SOA
Originally computer systems were designed as so called monoliths. The system performed one or a couple of tasks and kept its data pretty much to itself. With the advent of client server architecture and the three-tier model: presentation – logic – data, monolithic systems became less popular. The separation of these tiers or layers was the beginning of the Service Oriented Architecture movement.
At first, connections between systems were so-called point-to-point communication. This means that a direct connection was made between the two communicating systems. When the number of systems that needed to be connected or exchange information grew, the number of connections that need to be maintained grew more rapidly. Because if you want to have five systems connected to each other you need to define 25 connections (5^2). This becomes quickly unmanageable; imagine an enterprise with 100 separate systems.
A better solution was needed and that led to the enterprise application integration (EAI) products. An advantage over a point-to-point connection but the hub and spoke architecture has now proven to become bottlenecks in the system. The enterprise service bus is the next logical step in connecting disparate IT systems and programs.
Architecture and complexity
We already talked about the application infrastructure that you will find in an enterprise. Given the fact that most enterprises have been using IT systems for the better part of 40 years it’s not uncommon to find systems written in almost any imaginable language (from PL/1 to Cobol to PowerDesigner) running on in some cases obscure hardware and operating systems. These systems often still have critical functions within organizations and therefore integration of these applications is vital to the enterprise. The enterprise by way is an ever-changing entity. Through mergers or acquisitions of systems are added to the ICT landscape. Developments in technology (e.g. the ESB) make it increasingly possible to connect clients, suppliers and partners to your network.
So how does the enterprise service bus work?
WSO2 Enterprise Service Bus
The diagram below (figure 1) you can see how a message from one application arrives at an application.
 |
|---|
| Figure 1 ESB transporting a message from end to end |
There are some basic steps that need to be taken. The first step of course is that an application sends a message that is picked up by the enterprise service bus. The message is picked up by something that is called a transport. The transport is nothing more than a message in a specific format. You can have an HTTP transport which of course uses HTTP protocol whereas a HL7 transport uses a specific Health Level 7 message format. WSO2 supports the most common transports. In addition to the aforementioned two transports also sending email messages (MailTo transport) is possible.
After the message is picked up by a transport it is sent through a message pipe that handles things like security and other quality of service aspects (QoS). With quality of service we mean the way the message should be handled in the ESB, should it be encrypted or should it get priority when sending a message through.
Two modes of operation
The enterprise service bus can work in two modes:
• message mediation services;
• proxy services
In the message mediation mode the ESB is able to take a message and to perform one or more transformations on the message. Depending on what’s needed a message can be cloned or aggregated, data formats can be changed or you can even write your own message mediation. This allows you to do virtually anything that you can imagine with a message.
You should see the message transformation and message routing as one single unit. In some cases the transformation will take place before the routing decision, in other cases after the routing decision.
When the ESB is used in proxy services mode it will create a virtual endpoint that acts as a façade for an internal service. Transformations and mediation can still take place within such proxied services.
The message is put into a message pipe where again the quality of services aspects are taken care of, for instance encryption or decryption or other aspects. The transport layer takes care of the transport and delivers it to the actual endpoint (the application that should receive it in the first place).
Apart from this you can also use tasks and events with the ESB. A task in WSO2 ESB allows you to run a specific piece of code by inserting it automatically into the timeline.
Events are notifications published to any system that is interested in this event. Even the ESB itself can listen to events and take action when they arise. An integration pattern facilitating this is the publish-subscribe pattern.
WSO2 ESB
After describing the functionality of the WSO2 Enterprise Service Bus in general terms, let’s look into very specific functionality that WSO2 ESB offers.
WSO2 claims that it can connect anything to anything by supporting a number of transports (the most commonly used e.g. HTTP, POP, TCP, FIX and SMS), multiple formats and protocols like JSON, XML, HTML and HL7. They also include adapters to commercial off-the-shelf systems like SAP BAPI (SAP’s basic application programming interface) & iDoc (SAP’s standard data structure for Electronic Data Interchange) and IBM WebSphere MQ. Lastly there are adapters to cloud services like Salesforce, PayPal and LinkedIn. You can also create your own adapters if you need one that is not yet available.
When you look at routing, mediation and transformation the possibilities are almost limitless. We already indicated that its possible to add custom mediation rules to the ESB. When routing messages you can choose to do that based on the message header, its content and several other rules that you combine yourself and in the right order.
All of this is of course done with complete control over security including authentication, authorization and entitlement. For this the enterprise service bus works together with a number of other WSO2 components like the Governance Registry, API Manager, Identity Server, Business Activity Monitor (now called WSO2 DAS) and so on.
In order to have a high performance and high availability solution the ESB supports thousands of concurrent nonblocking HTTP(s) connections per server that will allow even the most demanding organizations to utilize the ESB. One of the examples of high load implementations is eBay that has implemented WSO2 ESB and has over 1 billion transactions per day. Of course the ESB can also support organizations that have lower demands or requirements.
In order to make the ESB simple to use it uses declarative development rather than coding to configure it. You can deploy the WSO2 ESB on your own servers, in a public, private or hybrid cloud and you even have the choice to the WSO2 Enterprise Service Bus as a service offering running on top of Amazon and being fully configured.
There is much more to be said about the WSO2 ESB. If you want more information you can visit the official WSO2 ESB website, follow a training, attend a webinar or contact us if you have any specific questions.
