Prabath SiriwardenaDirector, Security 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. 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 . The ESB makes the service accessible to other applications via one or more middleware protocols. the ESB provides an abstraction layer that virtualizes the service and separates it from infrastructure concerns. An ESB models an application endpoint as a service. As a general rule. In both cases. The ESB may host the service agent locally. 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. .An ESB is a middleware solution that enables interoperability among heterogeneous environments using a service-‐oriented model. or the service may execute remotely. Message Routing. ESB performs message routing either based on predefined/derived paths or based on the content of the incoming message. . This could be from HTTP/ HTTPS to FTP or SMTP or any other protocol.Protocol Switching. . The backend SOAP services can be exposed to REST/ JSON clients and the ESB will take care of the message transformation.Message Transformations. . We may need to develop adaptors and plug those into the ESB while exposing legacy systems as standard services to the outside. .Expose legacy systems through a standard interface. The adaptors will take care of transforming the incoming messages to the message formats expected by the legacy systems. ESB should be able to expose proxy services to cater some business functionalities by wrapping some concrete backend services.Expose business functionalities through service orchestration. . which could possibly break the service contract with old clients. the EBS can still transform the requests from old clients into the new format. By decoupling the service from the client and exposing it through an ESB allows handling versioning at the perimeter level.Handling Versioning. When a new version of a service been added to the system. . . authorization and throttling.Centralized policy enforcement point for authentication. Security can be enforced at the ESB while the concrete backend services either could be secured or non-‐secured. In case of WSO2 ESB. . As all the messages pass through the ESB.Centralized auditing and monitoring. this is one of the best places to do auditing and monitoring. it can be easily integrated with WSO2 BAM (Business Activity Monitor). Hence lowering the chances for a Denial of Service attack.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. . . In addition to all the above functionalities. Also. the Service Gateway also could act as a reliable message store. the message store can be used to match the rate limits expected by backend services.Reliable message store. It can persist messages and deliver those to backend services when they are available. : FIX.g. . high performance ESB • Feature rich and standards compliant – SOAP and WS-‐* standards – REST support – Domain specific protocol support (e. HL7) • User friendly and highly extensible • 100% free and open source with commercial support.• A lightweight. • Built on top of WSO2 Carbon. 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 .• An OSGi based components framework for SOA • Extensive modularity and reusability • Easily add. . . . . • • • • • • • 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 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. . 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.• Although WSO2 ESB comes with a rich collection of mediators. . . In a way it organizes mediators to form Pipes and Filters pattern.A sequence is a logical grouping of set of mediators. • 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. Having support for load-‐balancing endpoints you can also use WSO2 ESB as a load balancer. . By default WSO2 ESB supports round-‐robin load-‐balancing algorithm.• • • Load-‐balancing endpoint is an abstraction over a set of endpoints that you want to distribute the incoming load. but it does not prevent you from having your own. The default fail over behaviour is dynamic fail-‐ over and it will fall back to the primary endpoint as soon as it is available. • If the primary endpoint fails then ESB will start sending messages to the next available one. . it will mark it as inactive.• Fail-‐over endpoint is an abstraction over a set of endpoints where you can define the fail-‐ over behaviour. • Whenever the ESB discovers a given endpoint is down. • In WSO2 ESB. • In most of the cases a proxy service as its name implies proxies a real. It can simply provide a level abstraction over one concrete service or many other business services.• A proxy service provides a well-‐defined SOAP endpoint to the outside. • A proxy service may or may not have a one to one mapping to a business service. concrete business service. . a proxy service is built with a collection sequences. . which you can override. • WSO2 ESB comes with a default main sequence. • Any message that is not directed to a proxy service or an API will hit the main sequence.• Main sequence is a pre-‐defined named sequence. This sequence won’t get executed for the exceptions thrown from the backend business services. Those will still go through the Out-‐Sequence. You can also associate a Fault-‐Sequence with a proxy service and it will get executed when an exception happens in a proxy operation. A response message comes from a concrete or a business service will go through the Out-‐ Sequence defined for the corresponding proxy service.• • • A request message comes in to a given proxy service will hit the In-‐Sequence defined for that proxy service. . . . • Can be even configured using the CRONTAB Simple API to develop custom tasks syntax. • Frequency (time interval between two executions) and the number of times to run the task is configurable.• A programmed activity configured to run periodically. • Based on the Quartz job scheduler for Java. . . SAPTransportLi stener"/> .sap.wso2.<transportSender name=”idoc” class="org.SAPTransportS ender"/> <transportReceiver name=”idoc” class="org.transports.transports.wso2.sap.carbon.carbon. messaging.carbon.hl7.HL7TransportSender"/> .transp ort.messaging.HL7 <transportReceiver name="hl7" class="org.business.HL7TransportListener"/> <transportSender name="hl7" class="org.carbon.wso2.wso2.transp ort.hl7.business. FIXTransportLi stener"/> <transportSender name="fix" class="org.FIXTransportS ender"/> .transport.transport.fix.fix.FIX <transportReceiver name="fix" class="org.synapse.apache.apache.synapse. jms.apache.jms.JMS <transportReceiver name="jms" class="org.transport.JMSListener"> </transportReceiver> <transportSender name="jms" class="org.apache.JMSSender"/> .axis2.axis2.transport. again based on the output content type.• 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.: SOAP to JSON) . the message should be converted to the required format. • Message Formatter : When a message goes out from ESB.g. (e.g. convert JSON to SOAP/XML) based on the message's content type.. hl7.messaging.business.carbon.messa ge.wso2.business.hl7.carbon.HL7 <messageFormatter contentType="application/edi-‐hl7" class="org.messaging.wso2.HL7MessageFormatter"/> <messageBuilder contentType="application/edi-‐hl7" class="org.HL7MessageBuilder"/> .messa ge. Synapse Incoming req Thread1 Request processing Socket open Socket open Thread2 Outgoing resp Outgoing req Response processing Incoming resp . • Incoming message content was placed in a SharedInputBuffer and the outgoing message content was placed in a SharedOutputBuffer. .• NHTTP transport was based on a dual buffer model. reading from the input buffer and writing to the output buffer. • Apache Axiom. Apache Axis2 and the Synapse mediation engine sit between the two buffers. • 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.• 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 default HTTP/HTTPS transport prior to ESB 4.6.0 . • Also the overhead of moving data from one buffer to another was not always justifiable in this model. 6.0.• Based on a single buffer model and completely bypassed the Axiom layer. • The default HTTP/HTTPS transport since ESB 4. • On-‐demand message parsing in the mediation engine. . • A Message Builder. and a Message Formatter that takes the input stream and writes it directly to a output stream.wso2.BinaryRelayBuilder • Formatter :org.relay. . • Builder : org.wso2.relay. that takes the input stream and hides it inside a fake SOAP message without reading it.carbon.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.carbon. • Message Mediation • Service Mediation • Priority Mediation . . • In service mediation. • In this mode. • Typically. that accepts messages from clients. the ESB exposes a service endpoint on the ESB. the WSO2 ESB could expose a service already available in one transport. and the role of the ESB would be to "mediate" these messages before they are proxied to the actual service. 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. . these services act as proxies for existing (external) services. 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. .• 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. . Enterprise Integration Pattern explains how to handle a scenario where a single logical function being implemented across multiple different systems.• Content-‐Based Router. • • • The Dynamic Router. 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. . Enterprise Integration Pattern explains how to avoid dependency of the router on all possible destinations / business services while maintaining its efficiency. 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 .• Splitter. so the result can be processed as a whole. .• Aggregator EIP talks about combining the results of individual but related messages. • 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. . 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. .• Publish & Subscribe. • 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. • It's required to have transaction manager to handle distributed transactions.blogspot.html . • Supports distributed transactions through XA.com/2012/11/distributed-‐transactions-‐with-‐wso2-‐esb. http://dinushasblog. • Transaction Mediator supports distributed transactions using JTA.• Supports JDBC/JMS local transactions. • WSO2 ESB has integrated the "Atomikos" transaction manager which is a implementation of Java Transaction API (JTA).