1 / 63

WSO2 Enterprise Service Bus

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.

vin
Télécharger la présentation

WSO2 Enterprise Service Bus

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Servicesbuilt 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 systemsMultiple 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 • Templates • Tasks • Local Entries • Priority Executors • Transport Receivers/Senders • Message Builders/Formatters • Mediator • Sequence • Endpoint • Proxy Service • REST API • Topics • Message Stores/Processors

  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. • - Logmediator can be used to log any incoming/outgoing messages. • - The DBLookup mediator can be used to retrieve information from a database. • - Headermediator 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 Socket open Thread1 Request processing Outgoing req Socket open Incoming resp Thread2 Response processing Outgoing resp

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

  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

More Related