Presentation on theme: "WSO2 Enterprise Service Bus"— Presentation transcript:
1WSO2 Enterprise Service Bus Prabath SiriwardenaDirector, Security Architecture
2Service 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 BusinessComponentsBusiness Components provide their functionality to its consumers as a ‘Service’ with the well-defined service interfaces.
3Why 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 combinationIntegrationOrganizations move away from monolithic systems Multiple Systems connected via SOA as the blue print
5What 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.
6What ESB does ? Message Routing. ESB performs message routing either based on predefined/derived paths or based on the content of the incoming message.
7What ESB does ? Protocol Switching. This could be from HTTP/ HTTPS to FTP or SMTP or any other protocol.
8What 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.
9What 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.
10What 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.
11What 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.
12What 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.
13What 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).
14What 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.
15What 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.
16WSO2 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.
17WSO2 Carbon An OSGi based components framework for SOA Extensive modularity and reusabilityEasily add, remove and customize features – Similar to Eclipse plug-insEasily deploy third party libraries and custom code into the server runtimeWeb based management console
24Mediator 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.
26Mediator – Hints & TipsAlthough 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.
27SequenceA sequence is a logical grouping of set of mediators. In a way it organizes mediators to form Pipes and Filters pattern.
28EndpointAn 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.
29Endpoint – Hints & TipsLoad-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.
30Endpoint – Hints & TipsFail-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.
31Proxy ServiceA 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.
32Sequence – 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.
33Sequence – Hints & TipsA 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.
35Tasks 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.
38Transport Listeners and Senders <transportSender name=”idoc” class="org.wso2.carbon.transports.sap.SAPTransportSender"/><transportReceiver name=”idoc” class="org.wso2.carbon.transports.sap.SAPTransportListener"/>
39Transport 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"/>
40Transport Listeners and Senders FIX<transportReceiver name="fix" class="org.apache.synapse.transport.fix.FIXTransportListener"/><transportSender name="fix" class="org.apache.synapse.transport.fix.FIXTransportSender"/>
41Transport 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"/>
42Message 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)
43Message 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"/>
45NHTTP 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.
46NHTTP TransportThe 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
47Pass-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
48Binary RelayA 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.BinaryRelayBuilderFormatter :org.wso2.carbon.relay.ExpandingMessageFormatterThe Builder Mediator can be used to build the actual SOAP message from a message coming in to ESB through the Message Relay.
49Modes of Mediation Message Mediation Service Mediation Priority Mediation
51Service MediationIn 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.
52Priority 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.
53Priority ExecutorsPriority 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
54Content Based RouterContent-Based Router, Enterprise Integration Pattern explains how to handle a scenario where a single logical function being implemented across multiple different systems.
55Dynamic RouterThe 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.
56SplitterSplitter, 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
57AggregatorAggregator EIP talks about combining the results of individual but related messages, so the result can be processed as a whole.
58Scatter and GatherScatter 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.
59Service ChainingService 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.
60Publish and SubscribePublish & 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.
61Message StoreThe 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.
62TransactionsIn 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.