ESB 1

Apache Synapse Enterprise

Service Bus (ESB) and WSO2

Index

1. Introduction
2. What is an ESB?
3. ESB de Synapse
4. WSO2 ESB’s architecture (Synapse ESB integrated into the WSO2 Carbon Platform)
5. Conclusion

1. Introduction

This is a series of posts dedicated to WSO2 ESB. It is based on the ESB developed by

Apache Synapse. In this instalment, I explain the basic workings of the BUS and will continue with all

examples, which will be explained in detail in each blog. You will be able to find the original

documentation on Synapse’s website, and Synapse’s examples can also be found on WSO2’s website.

The upside is that in this blog we will analyse each example, adding more comments and more

high-level graphs, which you hardly see in Synapse and WSO2’s documentation. Furthermore,

you will be able to leave your questions or issues in case any example does not work for you.

I also like adding the information provided by some Sniffer such as WSO2’s TCPMON in order to better

understand the messages traveling between components.

*Which are the advantages?

First, only WSO2 support is paid for a single component.

Secondly there, WSO2 support is paid for the independently installed components.

That is, it is more profitable to install the Integrator if you want to use more than one WSO2 component.

But this note is at the business level, for example, to pay support for the production environment,

of course, you can download it for free on the laptop.

In this chapter, we are going to make use of version 5.0.0 of the ESB! Now it’s time to start.

*Note: At WSO2’s website you can download the ESB in two ways:Standalone, by selecting the ESB version that you wish
to download. Or by downloading Enterprise Integrator. This component includes: the ESB, Message Broker, Application Server,
Business Process Server, and Data Services Server.

2. What is an ESB?

An ESB (Enterprise Service Bus) is basically a middleware that acts as a bridge between several
applications to perform processing. For example, reading from queues and sending messages to an
endpoint or service in the backend. Later we will comment on the different patterns of integration using
this technology through examples. Apache Synapse has support for plain text and binary messages,
Hessian (web service protocol), XML as SOAP, JSON, Web services and REST. Other protocols
it uses are: HTTP/S, Mail (POP3, IMAP, SMTP), JMS, TCP, UDP, VFS, SMS, XMPP, and FIX.

3. Synapse ESB

The bus can process a large volume of messages with a minimal delay and use of resources. It uses
Axis 2 as a Web Services engine. I can be configured using a series of XML files. It can be clustered and
uses a wide range of mediators. They can be used to process the messages within the ESB.
Furthermore, custom mediators can be extended or created. Log files can be used to log the ESB’s
execution. Statistical data is collected, such as the number of requests per second, errors when
processing messages, etc. Using JMX technology the behavior of the tool can be monitored.

4. WSO2 ESB’s architecture (Synapse ESB integrated into the WSO2 Carbon Platform)

In this chart, you can see a set of well-defined elements that explain the ESB’s internal functioning.

– The transport layer is in charge of sending and reporting messages in several formats. New types of
transports may be added as plugins. Each transport uses a service to listen to incoming messages and
another one to send responses.

– In the next layer, the transport that received the message chooses the ‘Message Builder’ based on
the ‘content type’ value contained in the message header. This transforms the payload into the XML
format, which the mediator engine understands.

In the response, again, based on the ‘content type’ value, the ‘Message Formatter’ is chosen to
transform the payload into the original format. These two components can be customised.

– The QoS (Quality of Service) layer adds security to the proxy service. This is accomplished by applying
an XML security policy file to the web service. There are several predefined security scenarios; the
default scenario is called ‘UsernameToken’. This token travels as part of the message and is used for
authentication. Using other security scenarios, one can specify which roles may have access to the proxy
service.

– Next three is the Synapse ESB engine. It has the following components:

Proxy: It is a virtual service in the ESB that receives messages and processes them. It then
delivers them to an endpoint outside the ESB, where the actual Web Service is located.

API: Rest API is an endpoint in the ESB that has a URL. This address specifies the context and
resources that need to be accessed through an HTTP method or call such as GET, PUT, POST, DELETE.

Requests arrive at the input sequence, the ESB processes the message using mediators and forwards the

message to the Backend. The output sequence receives the backend’s response, processes it and

forwards the message to the client.

Inbound endpoints: They can be configured dynamically without restarting the server. Messages
move from the transport layer to the mediation layer without going through the Axis2 engine.

Main: This is the ESB’s main sequence used to forward the requests that do not match any defined

service.

Sequences: Sequences are used in the proxy service and the REST APIs. Each sequence is a set of

mediators where messages are processed.

Mediator: It is the processing unit or action that is performed on a message. For example, when

enriching a message, filtering it, sending it to an endpoint, deleting it, etc. Mediators can be customised.

Scheduled Tasks: This is a code that is to be executed at a specific moment. Tasks can also be

customised.

Endpoints: They are destinations, for example, external to the ESB, for a message; it may be a service

represented by a URL, mailbox, JMS queue, TCP socket. The same endpoint can be used with several

transport protocols.

Message Store/Message Processors: This design pattern is used in integration when dealing with

messages asynchronously. Which is to say, when the client does not wait for the response. The message

is stored in the memory or drive; this is done by the Message Store. The message processor extracts a

queue, memory or database from it and sends it to an endpoint. By using this pattern, the delivery of a

message to the endpoint can be guaranteed, since it is only deleted from the Store when an endpoint

receives the message correctly.

– Registry: The registry is a metadata container where resources are stored, such as WSDL, message
schemes for validation, scripts, XSLT files, Xquery transformations, etc. This information may be used by
referencing it in the mediators. It is a way to better organise the information within the ESB.

– Management UI: it is a Graphical User Interface where all components can be configured through
menus and options.

– Carbon Platform: It is an open-source middleware on top of which all other WSO2 components are built. 

5. Conclusion

This is the first introductory tutorial-guide of the ESB, in the rest we will start with the first examples of the
ESB, from the basic level to the most complex ones! In summary, with a tool like WSO2 ESB easy to use
and download, it does not require a lot of work to configure it internally through XML files. The most
interesting thing is that being open source in Java facilitates the customisation of the tool through
interfaces.