1. How the WSO2 ESB outperforms other Major
Open Source ESB vendors
Kasun Indrasiri Dushan Abeyruwan
Associate Tech Lead Senior Software Engineer
Integration Technology Team Integration Technology Team
Member - Integration MC Member - Integration MC
WSO2 Inc. WSO2 Inc.
March 2013 March 2013

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. Outline for the today's 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. 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. 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 : http://graegert.com/programming/no-soa-criticism-somewhere

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. Under the Hood: Apache Synapse
• A lightweight, open source ESB implementation from the
ASF : http://synapse.apache.org
• 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. 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. WSO2 Carbon

10. WSO2 Carbon

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. High Level Architecture (NHTTP )

13. Axis2 In Runtime

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. 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. 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. 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. NHTTP Inside Story Cont.

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. 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. 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] http://wso2.org/library/articles/2012/03/wso2-esb-message-transfer-mechanisms-
comparative-benchmarks

22. Why Passthrough so special?

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. 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. 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. Improvements in Passthrough Transport
<proxy xmlns="http://ws.apache.org/ns/synapse"
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=http://schemas.xmlsoap.org/soap/envelope/ source="//order[1]/symbol“ regex="IBM">
<then>
</inSequence>
<outSequence>
<target>
<filter xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/ 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. Streaming XPath
XPath 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. 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. 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. Streaming Xpath – How it works
 Streaming XPath parser supports simple absolute and relative XPath
expressions that don't 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. FAST XSLT
 An improved XSLT mediator which provides much faster streaming
transformation when used with the PTT.
 Almost doubled the XSLT performance.

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 esbperformance.org.

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. Observations
• Number of messages per client n=1000 up to 320 concurrency and
n=10 for higher concurrency (1280/2560)

35. Observations
• Number of messages per client n=1000 up to 320 concurrency and
n=10 for higher concurrency (1280/2560)

36. Observations
• Number of messages per client n=1000 up to 320 concurrency and
n=200 for higher concurrency (1280/2560)

37. Observations
• Number of messages per client n=1000 up to 320 concurrency and
n=200 for higher concurrency (1280/2560)

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. Conclusion
• Why ESB Performance
• NHTTP and PTT
• Performance Test Round 6.5
• Observations

40. Time for questions

41. 150+ globally positioned support customers

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