This is a series of blogs dedicated to WSO2 ESB. It is based on the ESB developed by Apache Synapse. In this installment 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 in Synapse’s website, and Synapse’s examples can also be found in WSO2’s website. The upside is that in this blog we will analyze 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 travelling between components.
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.
The advantages: in the first case you only pay support to WSO2 for a single component. In the second case, you pay support to WSO2 for independently installed components. That is to say, it is more cost-effective to install the Integrator if you intend to use more than one WSO2 component. But this note applies at a corporate level – for example, when paying support for your production environment –; of course, you can download it for free on your notebook.
Version 5.0.0 of the ESB will be used in this post.
What is an ESB?
An ESB (Enterprise Service Bus) is basically a middleware that acts as a bridge between several applications to perform a processing. For example, reading from queues and sending messages to an endpoint or service in the backend.
I will discuss further on the different integration patterns when using this technology by means of 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.
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. It 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 tool’s behavior can be monitored.
-You might be interested in: What is WSO2 ESB? The enterprise integration solution-
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 customized.
– 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 ant 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 customized.
- Scheduled Tasks: This is a code that is to be executed at a specific moment. Tasks can also be customized.
- 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 organize 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.
Conclusion
This is the first introductory chapter about the ESB. In the following ones we will begin with the first few ESB examples, from the most basic to the most complex. In summary, with a tool such as WSO2 ESB, which is easy to use and download, and without the need for a lot of work when configuring it internally by using XML files. What is most interesting is that, since it is open-sourced in Java, the customization of the tools is made easy through the use of interfaces.
Discover the next episode of ESB: ” WSO2 ESB Quick Start & Installation Guide”. Enjoy it!
