WebLogic Workshop presents a compelling set of visual tools to enhance developer productivity to turn out SOAP-based Web services quickly. Workshop's designers have figured out a clean way to present the myriad of options found in the SOAP and WSDL specifications. Each option you choose impacts the scalability and reliability of your finished application. For example, a recent study of SOAP encoding styles showed a 30-fold performance improvement by choosing one SOAP encoding-style over the others. This article presents a way to understand the performance impact of SOAP encoding styles and shows how to build and test a Web service in Workshop for scalability and performance.
SOAP encoding styles
SOAP uses XML to marshal data that is transported to a software application. Most of the time, SOAP moves data between software objects, but the SOAP specification was intended to be useful for old legacy systems as well as modern object-oriented systems. Consequently, SOAP defines more than one data encoding method to convert data from a software program into XML format and back again. The SOAP-encoded data is packaged into the body of a message and sent to a host. The host then decodes the XML-formatted data back into a software object.
Since SOAP's introduction, three SOAP encoding styles have become popular and are reliably implemented across software vendors and technology providers:
- SOAP Remote Procedure Call (RPC) encoding, also known as Section 5 encoding, defined by the SOAP 1.1 specification.
- SOAP Remote Procedure Call Literal encoding (SOAP RPC-literal), uses RPC methods to make the call but uses an XML do-it-yourself method for marshalling the data.
- SOAP document-style encoding, also known as message-style or document-literal encoding.
There are other encoding styles, but software developers have not widely adopted them, mostly because their promoters have not come to agreement on a standard. For example, Microsoft is promoting Direct Internet Message Exchange (DIME) to encode binary file data while the rest of the world is promoting SOAP with Attachments. SOAP RPC encoding, RPC-literal and document-style encoding have emerged as the encoding styles that a software developer can count on.
WebLogic Workshop provides a fast and efficient implementation of the Java Web Service (JWS) interface. JWS implements a set of application programming interfaces (API) and a standard description of the files the JWS engine needs to automatically deploy the Web service on the server. JWS builds the deployment descriptors for you automatically. So you need to only define the public Java methods and JWS publishes the SOAP proxy to access the methods. Workshop makes this even easier by integrated JWS functions into its visual editors. This makes development appear very easy, but there is a lot of work going on under the covers, so to speak.
Before I discuss SOAP encoding style's impact on performance in the Workshop/JWS environment, you should understand the differences between these styles of SOAP encoding. SOAP RPC is the encoding style that offers the most simplicity for developers. The developer makes a call to a remote object, passing along any necessary parameters. The SOAP stack serializes the parameters into XML, moves the data to the destination using transports such as HTTP and SMTP, receives the response, deserializes the response back into objects, and returns the results to the calling method. Whew! SOAP RPC handles all the encoding and decoding, even for very complex data types, and binds to the remote object automatically.
Now, imagine you are a developer with some data already in XML format. SOAP RPC also allows literal encoding of the XML data as a single field that is serialized and sent to the Web service host. Since there is only a single parameter -- the XML tree -- the SOAP stack only needs to serialize one value. The SOAP stack still deals with the transport issues to get the request to the remote object. The stack binds the request to the remote object and handles the response.
Lastly, in a SOAP document-style call, the SOAP stack sends an entire XML document to a server without even requiring a return value. The message can contain any sort of XML data that is appropriate to the remote service. In SOAP document-style encoding, the developer handles everything, including determining the transport (for example, HTTP, MQ, SMTP) marshalling and unmarshalling the body of the SOAP envelope, and parsing the XML in the request and response to find the needed data.
The three encoding systems are compared in Figure 1.
Figure 1. Which encoding system is right for you?
SOAP RPC encoding is easiest for the software developer; however, all that ease comes with a scalability and performance penalty. SOAP RPC-literal encoding is more involved for the software developer to handle XML parsing, but requires less overhead from the SOAP stack. SOAP document-literal encoding is most difficult for the software developer, but consequently requires little SOAP overhead.
Why is SOAP RPC easier for the developer? With this encoding style, you only need to define the public object method in your code once; the SOAP stack unmarshals the request parameters into objects and passes them directly into the method call of your object. Otherwise, you are stuck with the task of parsing through the XML tree to find the data elements you need, and then you get to make the call to the public method.
There is an argument for parsing the XML data yourself: since you know the data in the XML tree best, your code will parse that data more efficiently than generalized SOAP stack code. As we will see when we measure scalability and performance in SOAP encoding styles, we will find this to be the case.
But before we go further into that, we look at how WebLogic Workshop facilitates building Web services in a variety of SOAP encoding styles. (For more details on the different encoding styles, see Resources below.)
WebLogic Workshop makes SOAP encoding choices very easy
Workshop's designers have figured out a clean way to present the myriad of options found in the SOAP and WSDL specifications. To see this in action look at Figure 2.
Figure 2. Workshop makes the many SOAP options visually easy to adjust, including setting SOAP encoding styles between document-style and SOAP RPC-style.
Public methods in a Java class are turned into SOAP-based Web services automatically. For example, Illustration 1 shows the responder_rpc class's single public method named
respond. The right-most Properties pane shows the SOAP options for respond. Illustration 1 shows how easy it is to change SOAP encoding styles for the respond method. The choices are document, rpc, and default. In a SOAP context, default really means SOAP document-style encoding.Choosing a SOAP encoding style in the Design View changes the JWS header in the Java code that is viewable in the Source View. JWS does the work for you. For example the respond method in the Source View is declared by default as:
import weblogic.jws.control.JwsContext;
/**
* @jws:protocol form-get="false" soap-style="document"
*/
public String respond(int wordcount, int delay) { ...
|
This is enough for Workshop to package the deployment descriptors to tell the JWS engine to deploy a Web service that has a respond method that uses SOAP document-style encoding.
When we change the encoding style in the Design View to rpc the Java code changes to:
import weblogic.jws.control.JwsContext;
/**
* @jws:protocol form-get="false" soap-style="rpc"
*/
public String respond(int wordcount, int delay) { ...
|
This does not appear to make much difference in the code; however, behind the scenes a lot is happening. And much of it impacts the scalability of the respond method. But before we go further into that, we look at how enterprise information systems managers are coming to grips with SOAP encoding styles and scalability.
Simple object access needs simple performance testing
The company Elsevier is a research content publisher for the science, technology, and medical industries. Elsevier's next-generation content publishing platform uses SOAP to build application-programming interfaces. Elsevier's information managers need to know if their choices of SOAP encoding style will scale and perform to handle millions of transactions every day. Their decisions affect how Elsevier will invest capital in new infrastructure. Over time, they need to know how new releases of their own software; new releases of application server software, and platform changes will affect scalability and performance.
Elsevier asked me to build a new test environment based on my free, open-source TestMaker utility (see Resources below for a link) to answer these scalability and performance questions. The Elsevier test environment that I delivered, illustrated in Figure 3, includes a Test Web Service (TWS) that handles RPC, RPC-literal, and document-style SOAP messages and installs on a variety of application servers. The environment is completed with a set of intelligent test agents to check TWS for scalability and performance.
Figure 3. The Elsevier test environment
TestMaker checks Web services for scalability, performance, and reliability. Software developers, QA analysts, and IT managers use TestMaker to build intelligent test agents that implement archetypal user behavior. The agents drive a Web service using native protocols (HTTP, HTTPS, SOAP, XML-RPC, SMTP, POP3, IMAP) just as a real user would. Running multiple intelligent test agents concurrently creates near production-level loads to check the system for scalability and performance.
In addition to checking SOAP encoding scalability, the Elsevier test environment provides a benchmark specific to Elsevier's systems to show a performance comparison for a variety of application servers and platforms. For example, TWS is currently implemented to run on BEA WebLogic, IBM WebSphere, and the SunONE Application Server. I am confident that ports to ElectricMinds Glue, Apache Axis, Systinet WASP, and other application servers is straightforward.
I built the Elsevier test environment by customizing TestMaker to support SOAP RPC, SOAP RPC-literal and SOAP document-style requests, and by implementing TWS to respond to requests in these encoding styles. The request to TWS contains two parameters: the first defines the size of the response and the second defines a delay value before responding. TWS responds by creating a response document containing random gibberish words that appeared in five response elements; each element has one child element. A TestMaker test agent uses the Apache SOAP library to make requests to TWS. The test agent varied the number of concurrent requests to TWS and the payload size of the response. The test agent logged the results to a delimited log file, which was subsequently summarized by a tally script. The tally script determined the number of transactions per second (TPS) performed by the test by counting the duration of successful transactions. We defined success as the absence of transport or SOAP faults.
This test environment has the added advantage of being able to view the scalability and performance impact of different SOAP implementations. For example, WebLogic provides BEA's implementation that uses the JAX-RPC APIs, WebSphere provides Apache SOAP, and the SunONE Application Server uses the Java 1.4 JAX-RPC library. On the client side TestMaker uses the Apache SOAP library.
I assembled a small test laboratory that includes a server running WebLogic Workshop 7.0.1 on a dual-processor 1.8 GHz AMD MP processor system running Windows 2000 with 512 MB of RAM and an Ultra-133 IDE 80 Gbyte drive. TestMaker runs on a 1.7 GHz AMD system running Java 1.4.1, Windows 2000 with 640 MB of RAM and an Ultra-133 IDE 40 Gbyte drive.
I found that a developer's choice of encoding style determines to a large extent the scalability and performance of a Web service. The SOAP implementations universally showed scalability problems when using SOAP RPC encoding, especially as payload sizes increased, as illustrated in Figure 4.
Figure 4. SOAP RPC encoding: Scalability problems become apparent with increased payload sizes
As Figure 4 shows, the test agent recorded 19.8 transactions per second when making requests where the response SOAP envelope measured 2500 bytes of SOAP RPC-encoded data. As the test agent increased the response size, the transactions per second plummeted. When making requests of 7,500 bytes of SOAP RPC-encoded data, the agent measured only 5.3 transactions per second.
When the test environment uses SOAP document-style encoding the performance fared much better, as you can see in Figure 5.
Figure 5. Document-style encoding: Performance stays relatively stable with increased payload sizes
With 2,500 bytes of document-encoded data, the test agent measured 24.1 TPS. Recall that the SOAP RPC-encoded requests gave us 19.81 TPS for requests of the same size. Additionally, when the test agent increased the response size, the TPS values did not degrade significantly when we used document-style encoded responses.
When the test environment uses SOAP RPC-literal encoding I found an efficient middleground, as you can see in Figure 6.
Figure 6. SOAP RPC-literal provides the performance benefits of SOAP document-style encoding with a little more work required to parse through the XML data.
With 2,500 bytes of literal-encoded data, the test agent measured 22.2 TPS. That is nearly the performance recorded for SOAP document-style requests. SOAP RPC-literal encoding did not show the plummeting TPS function of SOAP RPC encoding performance.
You may be wondering how the various application servers compare in scalability and performance. In my experience every production environment is unique. So, rather than show you a comparison here, I urge you to download the test environment yourself and try it in your own production environment. I have made a generalized version of the Elsevier test environment available for free download for your immediate use at:
http://www.pushtotest.com/ptt/kits/wlwencodingkit.html
Should you let the tools do the driving?
While the SOAP encoding styles provide a good range of power and flexibility, they also introduce interoperability problems. Many of the SOAP tools on the Java platform default to SOAP RPC encoding styles. For example, when using IBM WebSphere Application Developer, the default encoding style is set to SOAP RPC. On the other side of the divide, .NET development tools implement document-style SOAP calls by default. This is akin to watching two boats pass in the night. Both can be made to interoperate, but developers need to be wise to the different encoding styles to avoid problems.
In their attempt to make software developers' lives easier, these tools may be making decisions for you that affect scalability. This was highlighted when Microsoft and Sun debated the relative virtues of J2EE and .NET at an event hosted in Silicon Valley by the Software Development Forum recently. Microsoft made the argument that it serves developers best by being the sole supplier of a complete solution. On the other end of the spectrum, Sun posited that developers should have a choice of tools that they can assemble into a solution. This top-down versus bottom-up argument permeates both companies' development tools. For example, representatives from Sun and Microsoft were asked to explain why developers would choose SOAP RPC encoding over SOAP document-style encoding. Microsoft's reps gave a somewhat technical answer, but conceded that they thought the issue was moot, since developers should rely on their development tools to make decisions of encoding styles.
Software developers serve themselves best by making informed decisions of how helpful their development tools and environments should be. Understanding each tools' handling of SOAP encoding styles is an important factor to delivering well performing and reliable software projects.
Application server impact
Another place where developers should watch for scalability impact is in SOAP stacks in application servers. While building the Elsevier test environment, I noticed that each Web service platform had its own implementation of a SOAP stack – and that some even shipped with more than one stack. For example, BEA WebLogic Server comes with one SOAP stack that implements the JAX-RPC API and one that implements the Java Web Services APIs. IBM WebSphere 4 comes with the DOM-based Apache SOAP library, but WebSphere 5 has the SAX-based Apache AXIS library. I would love the opportunity to test the differences between all of these in some future project.
I also noticed that, while WSDL did a fair job at describing the interface to a SOAP service, often the WSDL was not complete. I found that a network monitor was necessary to see actually what values were moved over the HTTP transport.
One thing that struck me while building the test environment for Elsevier was the nature of SOAP implementations. In 2002, BEA and IBM announced major new versions of their Web service application servers. Consequently, reliability and performance of SOAP application servers is a moving target. This further reinforced the chief lesson learned here: that you should use a dynamic test environment to check reliability and performance now – and keep it handy to test new implementations as they become available.
Resources
To help you understand your Web Service system scalability I have built a special kit of utilities, test agents, and documentation. The Web Services SOAP Encoding Performance kit is available for free download and contains all you will need to test your software in your environment.
Download the Performance Kit at:
http://www.pushtotest.com/ptt/kits/wlwencodingkit.html
More dev2dev articles on SOAP encoding:
- Dear John: Building a Java Client for a WebLogic Workshop Web Service:
http://dev2dev.bea.com/products/wlworkshop/articles/DJ_001.html - WebLogic & .NET: Making Web Services That Work:
http://dev2dev.bea.com/products/wlserver61/articles/544.html