Tuesday, June 23, 2015

What is WSO2 Enterprise Service Bus (ESB)

An enterprise service bus (ESB) is a software architecture construct that enables communication among various applications. Instead of having to make each of your applications communicate directly with each other in all their various formats, each application simply communicates with the ESB, which handles transforming and routing the messages to their appropriate destinations.

This is the Formal Definition of ESB by WSO2 So Let's see the Word ESB and how its doing the Works.

Enterprise :  ­ the concept has been originally invented to reduce complexity of enterprise application integration (EAI) within an enterprise; the restriction has become obsolete since modern Internet communication is not limited to a corporate entity only.

Service​ :denotes non­iterative and autonomously executing programs that communicate with other services through message exchange

Bus​ : ­ is used in analogy to a computer hardware bus

Why ESB?

  • Individual software applications cannot achieve much 
  • Systems should be integrated to work together 
  • Enables free data flow across the organization, data sharing and unified data
  • Improves production and management efficiency through re­use of existing
  • Application users can make better decisions using universal information rather
    than isolated fragmentary information   
  • Proper feedback loop to enhance business operations, with integrated activity

How ESB Works

  1. An application sends a message to the ESB.
  2. The message is picked up by a transport.
  3. The transport sends the message through a message pipe, which handles quality of service aspects such as security. Internally, this pipe is the in-flow and out-flow of Axis2. The ESB can operate in two modes:
  4. Both message transformation and routing can be considered as a single unit. As the diagram specifies, there is no clear separation between message transformation components and routing components. In WSO2 ESB, this is known as the mediation framework. Some transformations take place before the routing decision has been made while others take place after the routing decision. This is part of the Synapse implementation.
  5. The message is injected to the separate pipes depending on the destinations. Here again, quality of service aspects of the messages are determined.
  6. The transport layer takes care of the transport protocol transformations required by the ESB.
The diagram shows how a request propagates to its actual endpoint through the ESB using its architecture. Response handling is the reverse of this operation. There are other areas like Working with Tasks and Events that are not shown in the diagram. All these components can be managed and monitored through the WSO2 ESB management console.

WSO2 ESB Architecture


A transport is responsible for carrying messages that are in a specific format. WSO2 ESB supports all the widely used transports including HTTP/s, JMS, and VFS, and domain-specific transports like FIX. You can easily add a new transport using the Axis2 transport framework and plug it into the ESB.
Transports include the following components:
  • Message builders - Identify the message using the content type and convert it to common XML. There is a message builder associated with each content type. WSO2 ESB includes message builders for text-based and binary content.
  • Message formatters - The opposite partners of the message builders. The formatter converts the message back to its original format by referencing the content type just before the message handover to the transports.
You can implement new message builders and formatters using the Axis2 framework.
See Working with Transports.


An endpoint defines an external destination (such as a service) for a message. An endpoint can be specified as an address endpoint, WSDL endpoint, a load balancing endpoint , and more. An endpoint is defined independently of transports, allowing you to use the same endpoint with multiple transports. When you configure a message mediation sequence or a proxy service to handle the incoming message, you specify the transport to use and the endpoint where the message will be sent.
See Working with Endpoints.

Proxy Services

Proxy services are virtual services that receive messages and optionally process them before forwarding them to a service at a given endpoint. This approach allows you to perform necessary transformations and introduce additional functionality without changing your existing service. Any available transport can be used to receive and send messages from the proxy services.
See Working with Proxy Services.


An API in WSO2 ESB is analogous to a web application deployed in the ESB runtime. Each API is anchored at a user-defined URL context, much like how a web application deployed in a servlet container is anchored at a fixed URL context. An API will only process requests that fall under its URL context. The API defines one or more resources, which is a logical component of an API that can be accessed by making a particular type of HTTP call. This approach allows you to send messages directly into the ESB using REST.
See Creating APIs.


A topic allows services to receive messages when a specific type of event occurs by subscribing to messages that have been published to a specific topic.
See Working with Topics and Events.


Mediators are individual processing units that perform a specific function, such as sending or filtering messages. WSO2 ESB includes a comprehensive mediator library that provides functionality for implementing widely used enterprise integration patterns (EIPs). You can also easily write a custom mediator to provide additional functionality using various technologies such as Java, scripting, and Spring.
See Mediators.


Sequences are the configuration component for mediators. Sequences allow you to organize mediators to implement pipes and filter patterns.
See Mediation Sequences.

Tasks and Commands

Tasks allow you to configure scheduled jobs in the ESB and execute internal and external commands for mediation.
See Working with Tasks.

QoS Components

Quality of Service (QoS) components implement security for the proxy services, including the Apache implementations of Rampart and Sandesha, which are provided as modules.


WSO2 ESB provides a registry with a built-in repository that stores the configuration and configuration metadata that define your messaging architecture. You can also use a remote repository.

Management and Configuration GUI

The Management Console provides a graphical user interface (GUI) that allows you to easily configure the components mentioned above as well as manage and monitor the ESB.

Flexible Deployment

You can deploy WSO2 ESB in a clustered environment with a load balancer to achieve failover and high availability.

in A Business View