How the WSO2 ESB outperforms other major open source esb vendors


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How the WSO2 ESB outperforms other major open source esb vendors

  1. 1. How the WSO2 ESB outperforms other Major Open Source ESB vendorsKasun Indrasiri Dushan AbeyruwanAssociate Tech Lead Senior Software EngineerIntegration Technology Team Integration Technology TeamMember - Integration MC Member - Integration MCWSO2 Inc. WSO2 Inc.March 2013 March 2013
  2. 2. About WSO2• Providing the only complete open source componentized cloud platform – Dedicated to removing all the stumbling blocks to enterprise agility – Enabling you to focus on business logic and business value• Recognized by leading analyst firms as visionaries and leaders – Gartner cites WSO2 as visionaries in all 3 categories of application infrastructure – Forrester places WSO2 in top 2 for API Management• Global corporation with offices in USA, UK & Sri Lanka – 200+ employees and growing• Business model of selling comprehensive support & maintenance for our products
  3. 3. Outline for the todays webinar• Background - SOA & ESB• What is Pass Through Transport (PPT) and the main differences between PTT and NHTTP.• How PTT was enhanced to work as the default Transport layer.• High performance Stream Xpath.• FAST XSLT – High Performance Message Transformations .• ESB Performance round 6.5 – observations and test results .• Conclusion.
  4. 4. Background• Service Oriented Architecture (SOA) – 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.
  5. 5. Background• Enterprise Service Bus (ESB) – An ESB is a middleware solution that enables interoperability among heterogeneous environments using a service-oriented model. – Stateless and Seamless Integration – Standard Protocols – SOAP, REST, JSON etc. – Transports – HTTP/S, JMS, TCP, VFS etc. Source :
  6. 6. WSO2 ESB is…• A lightweight, high performance ESB• Feature rich and standards compliant – SOAP and WS-* standards – REST support – Domain specific protocol support (eg: FIX, HL7)• User friendly and highly extensible• 100% free and open source with commercial support
  7. 7. Under the Hood: Apache Synapse• A lightweight, open source ESB implementation from the ASF :• Makes up the mediation engine of WSO2 ESB• Multithreaded and asynchronous message processing core• Based on a number of well known open source projects (eg: Axis2, Http Core)
  8. 8. Under the Hood: 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
  9. 9. WSO2 Carbon
  10. 10. WSO2 Carbon
  11. 11. Why ESB Performance Matters?• Most organizations are adopting SOA as the enterprise architecture and ESB is essential in order to realization of SOA.• Similar or disparate systems are connected via an ESB• All communication and message passing occurs via ESB.• Diverse message transformations, message filtering and protocol switching occurs inside the ESB
  12. 12. High Level Architecture (NHTTP )
  13. 13. Axis2 In Runtime
  14. 14. Transport Transport Sender • Sends the message to given endpoint address/output stream Transport Receiver • Receives the transport specific message. • Builds the message context. • Invokes the AxisEngine.
  15. 15. Limitations with Default NHTTP• The default transport was very generic and it was designed to offer reasonable performance in all the integration scenarios the ESB could potentially participate in.• However HTTP load balancing, HTTP URL routing (URL rewriting) and HTTP header-based routing are some of the most widely used integration patterns in the industry and to support these use cases well, we needed a specialized transport.
  16. 16. NHTTP Inside Story Message Message InputStream builder Formatter OutputStream I/O Buffer1 I/O Buffer2 NHTTP Receiver NHTTP Sender Axis2 OS Buffer OS Buffer
  17. 17. NHTTP Inside Story Cont.• The old NHTTP transport was based on a dual buffer model.• Incoming message content was placed in a SharedInputBuffer.• 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.• This architecture is illustrated in the following diagram.
  18. 18. NHTTP Inside Story Cont.
  19. 19. NHTTP – The Limitation…• 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.
  20. 20. Why do we need a Specialized transport ?To achieve followings• Ultra-fast, low latency mediation of HTTP requests.• Supporting a very large number of inbound (client-ESB) and outbound (ESB-server) connections concurrently (we were looking at several thousand concurrent connections).• Automatic throttling and graceful performance degradation in the presence of slow or faulty clients and servers.
  21. 21. History behind Passthrough transport (PT Transport)• The HTTP pass-through transport was first released in June 2011 along with WSO2 ESB 4.0.• Back then it was disabled by default and the user had to enable it by un-commenting a few entries in the axis2.xml file.• The performance numbers we were seeing with the new transport were simply remarkable.• WSO2 also published some of these benchmarking results in a March 2012 article. [1][1] comparative-benchmarks
  22. 22. Why Passthrough so special?
  23. 23. Why passthrough transport so special Cont.• PTT can utilize a single shared buffer.• In similar circumstances, the NHTTP transport utilizes two buffers. This improvement is particularly useful for the performance of pass- through mediation.
  24. 24. Limitations with PT prior to ESB 4.6.0 releases• Configuration overhead (Users had to explicitly enable the transport depending on their target use cases)• Cannot support any integration scenario that requires HTTP content manipulation (because Axiom was bypassed, any mediator attempting to access the message payload would not get anything useful to work with)• Instance maintaining two separate HTTP transports was twice as work for the developers and testers.
  25. 25. Improvements in Passthrough Transport• Content-unaware mediators – Mediators that never access the message content in anyway (eg: drop mediator)• Content-aware mediators – Mediators that always access the message content (eg: xslt mediator)
  26. 26. Improvements in Passthrough Transport<proxy xmlns="" name="CBRProxy" Outbound transports="https http" startOnLoad="true" In Sequence contnetaware =true , since it trace="disable"> <description/> refers the content of the message in XPath <target> <inSequence> <filter xmlns:soapenv= source="//order[1]/symbol“ regex="IBM"> <then> </inSequence> <outSequence> <target> <filter xmlns:soapenv= source=“$trp:symbolHeader“ regex="IBM"> </target> <outSequence></proxy> Inbound outSequence contnetaware =false, since the inbound response the synapse language written only to evaluate based on transport headers.
  27. 27. Streaming XPathXPath is a special component in ESB Since most of the messages going through the SOA environment are SOAP messages. To manipulate these SOAP messages, we use XPath expressions. Uses XPath engines like Jaxen or AXIOM Xpath.PROBLEMS• Navigation through each and every node consumes time and memory• So the larger the XML file, the more parsing performance is reduced
  28. 28. Streaming XPath The XPath parsing happens on top of the AXIOM data model created by an input stream to the XML document. Returns the first match of the XPath expression. Complex XPath expressions that have predicates, logical combinations of results, etc. are not eligible for Streaming XPath
  29. 29. Streaming Xpath – How it works AXIOM data model for the XML document will be passed to the first component -> choose the first element that has the local name “data” Send the selected element to the next component. (And process continues. When a XPath is given it creates a component chain. Input XML stream is pass through the component chain and result is obtain at the last component.
  30. 30. Streaming Xpath – How it works Streaming XPath parser supports simple absolute and relative XPath expressions that dont have logical combinations, functions, predicates etc. When an XPath is given, the Streaming XPath parser will analyze that expression to mandate whether it belongs to the supported set of expressions. -> If so, it creates the component chain for the given Xpath Why Antlr?  For matching the given XPath and component chain creating process we used ‘Antlr’ language-analyzing tool.  Using Antlr we can check whether a given string matches a particular syntax, or set of rules, which is provided in a grammar file. (XPath1.g)  Grammar file is used to identify the XPath expressions that can be processed with Streaming XPath. Unsupported XPath expressions will be processed with traditional XPath processing
  31. 31. FAST XSLT An improved XSLT mediator which provides much faster streaming transformation when used with the PTT. Almost doubled the XSLT performance.
  32. 32. ESB Performance Round 6.5• Conducted performance study to compare the performance of WSO2 ESB 4.6.0, WSO2 ESB 4.5.1, Mule 3.3.0, Talend-SE-5.1.1, and UltraESB 1.7.1 - Enhanced.• We have chosen to called this test “Round 6.5” because we are comparing against the same versions and results of the ESBs used in the Round 6 performance benchmark published on the UltraESB- managed performance site
  33. 33. ESB Performance Round 6.5• All the load tests were carried out using Amazon AWS EC2 with the instance type "High-CPU Extra Large (c1.xlarge, 7GB).” The configuration used is described below. The back-end echo service used for testing was hosted in fully optimized Apache Tomcat 7.0.29.• Testing Scenarios • DirectProxy • CBRProxy • CBRSOAPHeaderProxy • XSLTProxy • XSLT Enhanced Proxy (Using FAST XSLT mediator written to handle with passthrough transport) SecureProxy
  34. 34. Observations• Number of messages per client n=1000 up to 320 concurrency and n=10 for higher concurrency (1280/2560)
  35. 35. Observations• Number of messages per client n=1000 up to 320 concurrency and n=10 for higher concurrency (1280/2560)
  36. 36. Observations• Number of messages per client n=1000 up to 320 concurrency and n=200 for higher concurrency (1280/2560)
  37. 37. Observations• Number of messages per client n=1000 up to 320 concurrency and n=200 for higher concurrency (1280/2560)
  38. 38. ESB is not just about performances• Enterprise Ready – WSO2 Customer Case Studies• Part of a complete middleware platform – WSO2 Middleware Platform• PaaS - ESB in the Cloud• 100% Open Source
  39. 39. Conclusion• Why ESB Performance• NHTTP and PTT• Performance Test Round 6.5• Observations
  40. 40. Time for questions
  41. 41. 150+ globally positioned support customers
  42. 42. Engage with WSO2• Helping you get the most out of your deployments• From project evaluation and inception to development and going into production, WSO2 is your partner in ensuring 100% project success