Page 1 of 3   next page »

Service Oriented Architecture (SOA) stands on the twin pillars of reusability and interoperability. Any business function that can be reused is an ideal candidate to be exposed as a service.

A reusable service, until and unless implemented in an interoperable manner, isn't much use. Web Services standards provide standards-based interfaces for service description, discovery, and message definitions to invoke such services. Web Service technology has come a long way to reach enterprise-grade adoption of the core standards. Nonetheless, the process has been facilitated by Web Service engine offerings from both the open source community and product vendors. One of the majors concerns of Web Services adoption is the performance overhead associated with transmitting and processing of XML. Today, Web Services engines and tools provide a means for data compression (XMill), data representation efficiency (fast infoset), and efficient processing of XML. In this article we'll be benchmarking the performance of a few leading open source Web Service runtimes, based on their capability to process XML using different binding frameworks in addition to native XML binding. We aim to bring out a comparative study highlighting the relative merits in using specific platforms for specific scenarios.

The Evolution of Web Service Platforms
Broadly speaking, Web Services engines can be segregated into three generations - the first generation of Web Services engines such as Apache SOAP came to market during the early stages of Web Services core standards definition/adoption. These platforms used the DOM API and had dismal performance.

The second generation of Web Services platforms such as Apache Axis 1.4 had native support for WSDL, JAX RPC, and SAAJ; however, these engines had limited support for integrating with external XML binding frameworks and solely depended on a native binding framework. Second-generation Web Services platforms boasted far better performance compared to first-generation Web Service platforms; however, the performance degraded significantly for large XML payloads. Third-generation Web Services platforms such as XFire and Axis2 use StAX for XML processing and have a pluggable architecture that allows for integrating with external binding frameworks. These platforms draw from the strength of individual binding frameworks, StAX parsing models, and overall a better and pluggable architecture. Third-generation Web Services platforms deliver better performance both in small XML payloads and large XML payloads and come with support for a number of WS* standards.

Web Service Performance
Web Service performance is a function of several factors, such as the communication protocol, the network latency, the compression mechanism used, the size of the document, and the representation format (encoding) of the information. It's beyond the scope of this article to cover the broad spectrum of factors affecting the overall performance of Web Service.

Here we're concerned with the performance analysis of a SOAP Engine combined with a binding framework, hence we'll limit our performance studies to key related areas such as binding performance, round-trip performance, scalability, speed, and throughput. These are directly affected by factors such as the binding framework used and the parsing model of the SOAP Engine. The study assumes that factors external to the situation of concern remain in a constant state and that reasonable steps were taken to ensure that.

Factors Affecting the Performance of a Web Service Engine
XML data sent over the wire is converted to native objects in a Web Service platform and vice versa; these native objects are passed to and from underlying business methods. The process of converting a native object to XML and vice versa is termed marshalling and un-marshalling, respectively. In J2EE, there are three APIs (SAX, DOM, and StAX) for parsing XML document; each of these APIs has relative strengths and shortcomings. Binding frameworks use one of these APIs to generate custom native objects from XML and vice versa with a little configuration. All Web Services platforms use either a parsing mechanism or binding frameworks for marshalling and un-marshalling data. As a result, the performance of a Web Service platform largely depends on the efficiency of binding frameworks used, the underlying parsing models, and the overall architecture.

The first generation of Web Services engines used the DOM API, which attributed to the degradation of performance for larger payloads and high load conditions.

The second generation of Web Service platforms used native code for marshalling and un-marshalling, which depended on the SAX API for XML parsing. Though SAX-based XML parsing is faster than DOM, it necessitates parsing the whole XML document, which may not be unnecessary at times, and moreover, Web Service platform-specific binding frameworks are often not as efficient as the best-of-breed binding frameworks available. Because of their dependence on custom platform-specific binding frameworks, the second generation of Web Services platforms can't benefit from improvements incorporated in the mainstream best-of-breed available binding frameworks.

The third generation of Web Services platforms come with a pluggable architecture that allows the use of best-of-breed binding frameworks with little configuration, moreover, these platforms use StAX, which combines the best features of both SAX and DOM to deliver consistently better performance for both large payloads and high load conditions.

Methodology for Web Service Engine Performance Evaluation
Overview of the Test Environment
All tests were carried out on a Dell Optiplex GX 260 desktop workstation, with a 1.8GHz Pentium 4 processor, 400MHz front-side bus, and 1GB of DDR SD-RAM, running Windows XP Professional (Service Pack 2).

Table 1 provides the version numbers of the various tools and APIs used in the course of this study.

JRE Configuration
Both Java Runtime Environments were used with their default configuration. No configuration changes were made to optimize the JVM.

Apache Tomcat Server Configuration
The Apache Tomcat Server was used with the default configuration. The maximum permitted heap size of the Tomcat server was 64MB and the maximum number of threads permitted was 150.

Overview of the Test Cases Under Consideration
The test cases were chosen to satisfy three primary goals:

• Compare the performance of second-generation SOAP Engines with their third-generation counterparts.
• Compare the performance of the major binding frameworks in wide use (ADB, JAXB2, and JibX).
• Comment on the level of support/integration offered by different SOAP Engines for the aforesaid binding frameworks.

  To achieve this, five test cases were chosen for analysis:
  

• Axis 1.4 with native data-binding
• Axis2 1.2 with Axis Data Binding (ADB)
• Axis2 1.2 with JibX Data Binding
• XFire 1.2.6 with JibX Data Binding
• XFire 1.2.6 with Sun's JaxB 2.0 Data Binding

Page 1 of 3   next page »