1. WSO2 Enterprise Service Bus
Prabath Siriwardena
Director, Security Architecture

2. 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.

3. 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

4. Spaghetti Integration Dilemma

5. 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.

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

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

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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).

14. 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.

15. 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.

16. 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.

17. 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

18. WSO2 Carbon

19. WSO2 Carbon

20. WSO2 Carbon

21. WSO2 Carbon

22. WSO2 Carbon

23. 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

24. 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.

25. Mediator

26. 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.

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

28. 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.

29. 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.

30. 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.

31. 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.

32. 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.

33. 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.

34. Proxy Service

35. 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.

36. Tasks

37. Transport Listeners and Senders

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

39. 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"/>

40. 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"/>

41. 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"/>

42. 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)

43. 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"/>

44. 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

45. 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.

46. 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

47. 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

48. 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.

49. Modes of Mediation Message Mediation Service Mediation
Priority Mediation

50. Message Mediation

51. 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.

52. 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.

53. 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

54. 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.

55. 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.

56. 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

57. Aggregator
Aggregator EIP talks about combining the results of individual but related messages, so the result can be processed as a whole.

58. 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.

59. 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.

60. 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.

61. 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.

62. 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.

63.
Thank You…!!!