Getting your integration project off the ground with WSO2 ESB is simple.
WSO2 ESB Component Architecture
WSO2 ESB supports many application layer protocols and messaging standards (collectively known
as transports), including HTTP/S, E-mail, Java Message Service (JMS) and Virtual File System
(VFS). It also supports a range of domain specific protocols such as Financial Information
eXchange (FIX), Advanced Message Queueing Protocol (AMQP) and Health Layer 7 (HL7). New
transports can be easily plugged into the server thanks to the seamless extensibility offered
by the Axis2 transports framework.
ESB uses message builder components to parse the messages
arriving via different transports. A message builder is usually associated with a content type.
Depending on the actual content type of an incoming message, the ESB will select a suitable
message builder, which will then parse the message content and convert it into the Apache AXIOM
based XML infoset. WSO2 ESB ships with message builders for handling text messages (plain text,
SOAP, POX etc) as well as binary messages. Message formatters are the opposite partners of the
builders. A formatter converts the message back to its original format by referring the content
type just before the message is handed over to the transports again for routing. Similar to the
transports, user can implement new message builders and formatters by using the Axis2 API.
Endpoints stay as a logical component with the transports. There are three types of top level
endpoints, namely Address endpoints, WSDL endpoints and Default endpoints. In addition to these
there are secondary endpoint types such as load balanced endpoints and fail over endpoints which
are composed of one or more top level endpoints. An endpoint can use any available transport
to dispatch the messages and they can even enforce various QoS constraints (security, RM etc)
on outgoing messages.
Proxy services are virtual services hosted in WSO2 ESB. These are implemented using Axis2 message
receivers and hence can be opened up to accept incoming messages. A proxy service can be accessed
using a URL similar to a regular web service address. Proxy services allow publishing a WSDL as
well so that a client can connect to a proxy service just like connecting to an actual Web Service.
Any available transport can be use to receive and send messages through the proxy services. Proxy
services are a great way for exposing existing services over different transports, schemas and QoS
configurations.
The power of WSO2 ESB lies in the comprehensive mediator library that provides various message
processing and inter-mediation capabilities. Using the mediator library we can implement all widely
used Message Exchange Patterns (MEP) and Enterprise Integration Patterns (EIP). There are simple
mediators which provide fundamental message processing capabilities such as logging and content
transformation as well as advanced mediators which can be used to access databases, add security to
message flows and so on. In situations where the built-in mediators are not sufficient to implement
a given scenario one can write a custom mediator on top of the simple but powerful API provided
by WSO2 ESB. Mediators can be implemented using various technologies including Java, scripting and
Spring, all of which are considered as extension points to the WSO2 ESB.
Sequences are special mediators that act as the configuration component for the mediators. Sequences
allow organizing the mediators to implement ordered pipes and filters pattern to achieve actual
message processing and mediation.
Tasks provide the ability to configure scheduled jobs in WSO2 ESB and they allow executing
internal and external commands for mediation. QoS components that implement reliable messaging
and security for the proxy services and for mediation come with the Apache implementations of
those two modules for Axis2, namely Rampart and Sandesha.
WSO2 ESB has an in-built registry/repository to store the configuration and configuration
metadata and it provides the facility to use a remote repository as well. Components like
clustering, load balancing and high availability makes WSO2 ESB a production ready server.
Finally the GUI components provide comprehensive management, configuration
and monitoring capabilities to the ESB. GUI is built on a layered architecture by separating the
backend and frontend concerns. This allow the user to connect to multiple servers using a single
GUI console. The component based architecture of the WSO2 ESB has enhanced its loosely coupled
nature with the usage of OSGi. All the components are built as OSGi bundles.
