Prabath Siriwardena

Director, Security Architecture

 A design paradigm and discipline - used by IT to improve

its ability to quickly and eciently meet business
demands.
A style of software architecture that is modular,
distributed and loosely coupled.
Componentization The main driver of SOA Business
Functionalities are implemented in dierent Business
Components
Business Components provide their functionality to its
consumers as a Service with the well-dened service
interfaces.

Modern Enterprises

Comprised of so many Systems and Services built based on
open standards, custom-built, acquired from a third party,
part of a legacy system or any such combination

Integration

Organizations move away from monolithic systems
Multiple Systems connected via SOA as the blue print

An ESB is a middleware solution that enables interoperability among

heterogeneous environments using a service-oriented model. An ESB
models an application endpoint as a service. The ESB may host the service
agent locally, or the service may execute remotely. In both cases, the ESB
provides an abstraction layer that virtualizes the service and separates it
from infrastructure concerns. The ESB makes the service accessible to
other applications via one or more middleware protocols. As a general
rule, one of the protocols that an ESB supports is Simple Object Access
Protocol (SOAP), but it doesn't require all services to communicate via
SOAP. The ESB mediates interactions between service endpoints and
enables dissimilar systems to interoperate.

Message Routing.

ESB performs message routing either based on
predened/derived paths or based on the content of
the incoming message.

Protocol Switching.

This could be from HTTP/ HTTPS to FTP or SMTP or
any other protocol.

Message Transformations.

The backend SOAP services can be exposed to REST/
JSON clients and the ESB will take care of the
message transformation.

Expose legacy systems through a standard

interface.

We may need to develop adaptors and plug those
into the ESB while exposing legacy systems as
standard services to the outside. The adaptors will
take care of transforming the incoming messages to
the message formats expected by the legacy
systems.

Expose business functionalities through service

orchestration.

ESB should be able to expose proxy services to cater
some business functionalities by wrapping some
concrete backend services.

Handling Versioning.

By decoupling the service from the client and
exposing it through an ESB allows handling
versioning at the perimeter level. When a new version
of a service been added to the system, which could
possibly break the service contract with old clients,
the EBS can still transform the requests from old
clients into the new format.

Centralized policy enforcement point for

authentication, authorization and throttling.

Security can be enforced at the ESB while the
concrete backend services either could be secured or
non-secured.

Centralized auditing and monitoring.

As all the messages pass through the ESB, this is one
of the best places to do auditing and monitoring. In
case of WSO2 ESB, it can be easily integrated with
WSO2 BAM (Business Activity Monitor).

Message screening and schema validation.

Doing message screening and schema validation at
the perimeter level could help to drop invalid
messages as early as in the message processing ow.
Hence lowering the chances for a Denial of Service
attack.

Reliable message store.

In addition to all the above functionalities, the Service
Gateway also could act as a reliable message store. It
can persist messages and deliver those to backend
services when they are available. Also, the message
store can be used to match the rate limits expected
by backend services.

 A lightweight, high performance ESB

Feature rich and standards compliant
SOAP and WS-* standards
REST support
Domain specic protocol support (e.g.: FIX, HL7)
User friendly and highly extensible
100% free and open source with commercial support.
Built on top of WSO2 Carbon.

 An OSGi based components framework for SOA

Extensive modularity and reusability
Easily add, remove and customize features Similar to
Eclipse plug-ins
Easily deploy third party libraries and custom code into
the server runtime
Web based management console

Mediator
Sequence
Endpoint
Proxy Service
REST API
Topics
Message Stores/Processors

Templates
Tasks
Local Entries
Priority Executors
Transport Receivers/Senders
Message Builders/Formatters

 Mediator is the smallest functional unit in WSO2

ESB.
A mediator is granular enough to perform a given
specic task.
WSO2 ESB comes with a rich collection of
mediators addressing most of the common
integration problems.
- Log mediator can be used to log any incoming/outgoing messages.
- The DBLookup mediator can be used to retrieve information from a
database.
- Header mediator can be used to add or remove SOAP headers.

 Although WSO2 ESB comes with a rich

collection of mediators, it does not
limit the user to those.
If you want to extend the functionality
of WSO2 ESB you can simply do it by
writing your own mediator.
Using a Class mediator is one of the
easiest and the mostly used way of
extending the ESBs functionality.

A sequence is a logical grouping of set of

mediators. In a way it organizes mediators to
form Pipes and Filters pattern.

 An end point is a logical abstraction over an external

destination where WSO2 ESB has to deliver the
message.
The end point dened in WSO2 ESB can also take care
of quality of service aspects like security, reliability
corresponding to the external destination.

Load-balancing endpoint is an abstraction

over a set of endpoints that you want to
distribute the incoming load.
By default WSO2 ESB supports round-robin
load-balancing algorithm, but it does not
prevent you from having your own.
Having support for load-balancing endpoints
you can also use WSO2 ESB as a load
balancer.

 Fail-over endpoint is an abstraction over a set

of endpoints where you can dene the fail-
over behaviour.
If the primary endpoint fails then ESB will start
sending messages to the next available one.
The default fail over behaviour is dynamic fail-
over and it will fall back to the primary
endpoint as soon as it is available.
Whenever the ESB discovers a given endpoint
is down, it will mark it as inactive.

 A proxy service provides a well-dened SOAP endpoint

to the outside.
In most of the cases a proxy service as its name implies
proxies a real, concrete business service.
A proxy service may or may not have a one to one
mapping to a business service. It can simply provide a
level abstraction over one concrete service or many
other business services.
In WSO2 ESB, a proxy service is built with a collection
sequences.

 Main sequence is a pre-dened named

sequence.
Any message that is not directed to a
proxy service or an API will hit the
main sequence.
WSO2 ESB comes with a default main
sequence, which you can override.

A request message comes in to a given proxy

service will hit the In-Sequence dened for that
proxy service.
A response message comes from a concrete or a
business service will go through the Out-
Sequence dened for the corresponding proxy
service.
You can also associate a Fault-Sequence with a
proxy service and it will get executed when an
exception happens in a proxy operation. This
sequence wont get executed for the exceptions
thrown from the backend business services.
Those will still go through the Out-Sequence.

 A programmed activity congured to run periodically.

Frequency (time interval between two executions) and
the number of times to run the task is congurable.
Based on the Quartz job scheduler for Java.
Can be even congured using the CRONTAB Simple
API to develop custom tasks syntax.

<transportSender name=idoc
class="org.wso2.carbon.transports.sap.SAPTransportS
ender"/>

<transportReceiver name=idoc
class="org.wso2.carbon.transports.sap.SAPTransportLi
stener"/>

HL7
<transportReceiver name="hl7"
class="org.wso2.carbon.business.messaging.hl7.transp
ort.HL7TransportListener"/>

<transportSender name="hl7"
class="org.wso2.carbon.business.messaging.hl7.transp
ort.HL7TransportSender"/>

FIX
<transportReceiver name="x"
class="org.apache.synapse.transport.x.FIXTransportLi
stener"/>

<transportSender name="x"
class="org.apache.synapse.transport.x.FIXTransportS
ender"/>

JMS
<transportReceiver name="jms"
class="org.apache.axis2.transport.jms.JMSListener">
</transportReceiver>

<transportSender name="jms"
class="org.apache.axis2.transport.jms.JMSSender"/>

 Message Builder : When a message comes through a

given transport(HTTP) to the WSO2 ESB we need to
build a SOAP message out of that (e.g.. convert JSON
to SOAP/XML) based on the message's content type.
Message Formatter : When a message goes out from
ESB, again based on the output content type, the
message should be converted to the required format.
(e.g.: SOAP to JSON)

HL7

<messageFormatter contentType="application/edi-hl7"
class="org.wso2.carbon.business.messaging.hl7.messa
ge.HL7MessageFormatter"/>

<messageBuilder contentType="application/edi-hl7"
class="org.wso2.carbon.business.messaging.hl7.messa
ge.HL7MessageBuilder"/>

Synapse

Incoming req

Thread1

Request
processing

Socket open

Socket open
Thread2

Outgoing resp

Outgoing req

Response
processing

Incoming resp

 NHTTP transport was based on a dual buer model.

Incoming message content was placed in a
SharedInputBuer and the outgoing message content
was placed in a SharedOutputBuer.
Apache Axiom, Apache Axis2 and the Synapse
mediation engine sit between the two buers, reading
from the input buer and writing to the output buer.

 The key advantage of this architecture is that it enables

the ESB (mediators) to intercept all the messages and
manipulate them in any way necessary.
The main downside is every message happens to go
through the Axiom layer, which is not really necessary in
cases like HTTP load balancing and HTTP header-based
routing.
Also the overhead of moving data from one buer to
another was not always justiable in this model.
The default HTTP/HTTPS transport prior to ESB 4.6.0

 Based on a single buer model and completely bypassed

the Axiom layer.
On-demand message parsing in the mediation engine.
The default HTTP/HTTPS transport since ESB 4.6.0.

 A Message Builder, that takes the input stream and hides

it inside a fake SOAP message without reading it, and a
Message Formatter that takes the input stream and
writes it directly to a output stream.
Builder : org.wso2.carbon.relay.BinaryRelayBuilder
Formatter :org.wso2.carbon.relay.ExpandingMessageFor
matter
The Builder Mediator can be used to build the actual
SOAP message from a message coming in to ESB through
the Message Relay.

 Message Mediation
Service Mediation
Priority Mediation

 In service mediation, the ESB exposes a service endpoint

on the ESB, that accepts messages from clients.
Typically, these services act as proxies for existing
(external) services, and the role of the ESB would be to
"mediate" these messages before they are proxied to the
actual service.
In this mode, the WSO2 ESB could expose a service
already available in one transport, over a dierent
transport or expose a service that uses one schema or
WSDL as a service that uses a dierent schema or WSDL
etc.

 The priority based mediation is implemented in two

levels in WSO2 ESB:
HTTP transport level - If users would like to use the
ESB as a pure router.
Message mediation level - If users use ESB for heavy
processing like XSLT and XQuery.
Uses Enqueue mediator to priority based mediation at
the mediation level.

 Content-Based Router, Enterprise Integration Pattern

explains how to handle a scenario where a single logical
function being implemented across multiple dierent
systems.

The Dynamic Router, Enterprise Integration Pattern explains how to avoid

dependency of the router on all possible destinations / business services while
maintaining its eciency.
The Dynamic router can be self-congured based on special conguration
messages from participating destinations.
Each business service has to announce their capabilities and Dynamic Router will
maintain a list of them.

 Splitter, Enterprise Integration Pattern explains how to

handle a scenario where the incoming request brings
multiple elements in it and each element needs to be
handled in a separate manner

 Aggregator EIP talks about combining the results of

individual but related messages, so the result can be
processed as a whole.

 Scatter and Gather Enterprise Integration Pattern

explains how to handle a scenario where the incoming
request has to be handled by multiple recipients and each
recipient will reply back to form an aggregated response.

 Service Chaining Enterprise Integration Pattern explains

how to handle a scenario where the incoming request has
to be orchestrated through multiple business services in
an order.

 Publish & Subscribe, Enterprise Integration Pattern

explains how to handle a scenario where one needs to
publish events to all the interested parties without
maintaining any hard coupling between those.

 The Message Store Enterprise Integration Pattern

explains how to capture information about each message
in a central location. Also, the Message Store can be used
to match the rate limits expected by backend services.

 Supports JDBC/JMS local transactions.

Supports distributed transactions through XA.
It's required to have transaction manager to handle
distributed transactions.
WSO2 ESB has integrated the "Atomikos" transaction
manager which is a implementation of Java Transaction
API (JTA).
Transaction Mediator supports distributed transactions
using JTA.

http://dinushasblog.blogspot.com/2012/11/distributed-transactions-with-wso2-esb.html