WSO2 Enterprise Service Bus Prabath Siriwardena Director, Security Architecture

Service Oriented Architecture A design paradigm and discipline - used by IT to improve its ability to quickly and efficiently 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 different Business Components Business Components provide their functionality to its consumers as a ‘Service’ with the well-defined service interfaces.

Why ESB ? 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

Spaghetti Integration Dilemma

What is ESB ? 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.

What ESB does ? Message Routing. ESB performs message routing either based on predefined/derived paths or based on the content of the incoming message.

What ESB does ? Protocol Switching. This could be from HTTP/ HTTPS to FTP or SMTP or any other protocol.

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

What ESB does ? 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.

What ESB does ? 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.

What ESB does ? 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.

What ESB does ? 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.

What ESB does ? 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).

What ESB does ? 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 flow. Hence lowering the chances for a Denial of Service attack.

What ESB does ? 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.

WSO2 ESB • A lightweight, high performance ESB • Feature rich and standards compliant – SOAP and WS-* standards – REST support – Domain specific 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.

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

WSO2 Carbon

WSO2 Carbon

WSO2 Carbon

WSO2 Carbon

WSO2 Carbon

Functional Components of WSO2 ESB Mediator Sequence Endpoint Proxy Service REST API Topics Message Stores/Processors Templates Tasks Local Entries Priority Executors Transport Receivers/Senders Message Builders/Formatters

Mediator Mediator is the smallest functional unit in WSO2 ESB. A mediator is granular enough to perform a given specific 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.

Mediator

Mediator – Hints & Tips 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 ESB’s functionality.

Sequence A sequence is a logical grouping of set of mediators. In a way it organizes mediators to form Pipes and Filters pattern.

Endpoint An end point is a logical abstraction over an external destination where WSO2 ESB has to deliver the message. The end point defined in WSO2 ESB can also take care of quality of service aspects like security, reliability corresponding to the external destination.

Endpoint – Hints & Tips 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.

Endpoint – Hints & Tips Fail-over endpoint is an abstraction over a set of endpoints where you can define 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.

Proxy Service A proxy service provides a well-defined 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.

Sequence – Hints & Tips Main sequence is a pre-defined 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.

Sequence – Hints & Tips A request message comes in to a given proxy service will hit the In-Sequence defined for that proxy service. A response message comes from a concrete or a business service will go through the Out-Sequence defined 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 won’t get executed for the exceptions thrown from the backend business services. Those will still go through the Out-Sequence.

Proxy Service

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

Tasks

Transport Listeners and Senders

Transport Listeners and Senders <transportSender name=”idoc” class="org.wso2.carbon.transports.sap.SAPTransportSender"/>   <transportReceiver name=”idoc” class="org.wso2.carbon.transports.sap.SAPTransportListener"/>

Transport Listeners and Senders HL7 <transportReceiver name="hl7" class="org.wso2.carbon.business.messaging.hl7.transport.HL7TransportListener"/>   <transportSender name="hl7" class="org.wso2.carbon.business.messaging.hl7.transport.HL7TransportSender"/>

Transport Listeners and Senders FIX <transportReceiver name="fix" class="org.apache.synapse.transport.fix.FIXTransportListener"/>   <transportSender name="fix" class="org.apache.synapse.transport.fix.FIXTransportSender"/>

Transport Listeners and Senders JMS <transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener"> </transportReceiver>   <transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender"/>

Message Builder and Formatters 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)

Message Builder and Formatters HL7 <messageFormatter contentType="application/edi-hl7" class="org.wso2.carbon.business.messaging.hl7.message.HL7MessageFormatter"/>   <messageBuilder contentType="application/edi-hl7" class="org.wso2.carbon.business.messaging.hl7.message.HL7MessageBuilder"/>

Non-Blocking Synapse Incoming req Outgoing req Socket open Thread2 Incoming req Socket open Thread1 Request processing Response Outgoing resp Outgoing req Incoming resp Synapse

NHTTP Transport NHTTP transport was based on a dual buffer model. Incoming message content was placed in a SharedInputBuffer and the outgoing message content was placed in a SharedOutputBuffer. Apache Axiom, Apache Axis2 and the Synapse mediation engine sit between the two buffers, reading from the input buffer and writing to the output buffer.

NHTTP Transport 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 buffer to another was not always justifiable in this model. The default HTTP/HTTPS transport prior to ESB 4.6.0

Pass-through Transport Based on a single buffer 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.

Binary Relay 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.ExpandingMessageFormatter The Builder Mediator can be used to build the actual SOAP message from a message coming in to ESB through the Message Relay.

Modes of Mediation Message Mediation Service Mediation Priority Mediation

Message Mediation

Service 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 different transport or expose a service that uses one schema or WSDL as a service that uses a different schema or WSDL etc.

Priority based Mediation 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.

Priority Executors Priority executors can be used to execute sequences with a given priority. Used in high load scenarios, where user wants to execute different sequences with different priorities. Allows user to control the resources allocated to executing sequences and prevent high priority messages from getting delayed and dropped. Sample 653 / Sample 653

Content Based Router Content-Based Router, Enterprise Integration Pattern explains how to handle a scenario where a single logical function being implemented across multiple different systems.

Dynamic Router The Dynamic Router, Enterprise Integration Pattern explains how to avoid dependency of the router on all possible destinations / business services while maintaining its efficiency. The Dynamic router can be self-configured based on special configuration messages from participating destinations. Each business service has to announce their capabilities and Dynamic Router will maintain a list of them.

Splitter 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 Aggregator EIP talks about combining the results of individual but related messages, so the result can be processed as a whole.

Scatter and Gather 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 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 and Subscribe 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.

Message Store 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.

Transactions In the ESB point of view we can think of two types of transactions. Distributed transaction. JMS transaction. 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

prabath@wso2.com Thank You…!!!