Getting Web Services Off The Ground

The reality: Web services hold much promise, and if you're not already on board, you will be eventually. But security fears are valid and must be addressed from the get-go. Competing standards implementations are also a concern.

In "Be Nimble, But Be Safe," we examine the key drivers of Web services adoption and tell you how to deal with standards and security worries. Easier application integration and smoother customer and partner interactions are strong incentives, but the ultimate reward is that SOAP can make your business processes as flexible as an Olympic gymnast.

In "Serving Up SOAP," we tested application servers and platforms from BEA Systems, Cape Clear Software, Iona Technologies, Novell, Sun Microsystems and Systinet that support enterprise, SOAP-based Web services. We looked for price, performance, standards--especially security standards--and interoperability (we tested each Web service against a .Net client, a Java client and a generic SOAP client using WSDL to access the service). Novell's Extend earned our Editor's Choice, thanks to its strong feature set and golden IDE. We also liked BEA's WebLogic, but its price and lack of support for security standards kept it in the silver-medal spot.

How'd We Bet Here? Evolution, Baby
In The Hitchhiker's Guide to the Galaxy, Douglas Adams says: "The Babel Fish is small, yellow, and simultaneously translates from one spoken language to another. When inserted into the ear, its nutrition processes convert sound waves into brain waves, neatly crossing the language divide between any species you should happen to meet whilst traveling in space."

Like the Babel Fish, Web services bridge the gap between development languages and disparate species ... er, platforms. Insert Web services into the "ear" of your application infrastructure, between the consumer of the service and the back-end system--the brain, if you will--that will ultimately process the request, in its own language of course, and you're in business.

The evolution of the Babel Fish--and Web services--are no accident. The past two decades have seen many attempts to provide a mechanism through which business and applications can talk to one another without regard to platform or language, and without the distasteful side effect of requiring modifications to existing business processes.

CORBA and COM arose out of a need to provide enterprises with a way to exchange data between systems and with business partners that did not require a massive investment. EDI standards have been the traditional, and somewhat successful, mechanism through which businesses have exchanged data for everything from purchase orders to scheduling shipments to invoices.

And yet EDI isn't the solution we had hoped for. Standard formats across industries were a start, but the data formats weren't flexible enough to support every business, which resulted in additional code to translate from EDI to an internal representation and then back to EDI. And the expense of using value-added networks to transport and ensure message delivery pushed the price of entry too high for many small and midsize enterprises.

XML and the Internet were big evolutionary jumps. A self-defining format with an accepted, standard description language exchanged over an easily accessible, standardized network suddenly offered a better way to integrate businesses and applications. But even as XML became the de facto standard for exchanging data, the manner in which that data was sent and received varied greatly from business to business. Distribution channels could not count on being able to send an order to Business A in the same manner as Business B. As a result, the time and cost to implement such connectivity remained high.

Enter SOAP. Taking advantage of the flexibility and widespread acceptance of XML, SOAP provides a standardized transport mechanism for messages, and when combined with WSDL (Web Services Definition Language), offers a standard method of describing supported business services. (For more on how all this works, see "SOAPing Up Web Services," at www.nwc.com/ 1321/1321ws1.html.)

Fatter Payloads, Bigger Bulge
SOAP requests (and responses) comprise much bigger payloads, primarily because they are XML. They contain not only the data, but a plethora of additional information, all necessary for the Web service receiving the request to process that request.

As you can see, even in this simple scenario, the payload for a SOAP request is much fatter than more conventional means of data submission. It isn't just the addition of the SOAP headers; it's the wrapper around each piece of data being submitted that makes the payload larger. For each parameter included in the submission, the payload grows. The size gets even larger if you specify the type of each parameter (for example, 2). At a minimum, you'll need to double the number of bytes being sent to account for the parameter wrapping. If an HTML form submission is 1 KB, you'll have at least 2 KB with SOAP, because every parameter name shows up twice--wrapping the actual data being submitted.

Network administrators need to be aware that live requests and responses will likely be much larger and consume more resources.

By the Numbers
In a recent Peerstone survey asking about Web services:
102 of 191 respondents said Web services would be of "fundamental importance" in the way software applications are built and deployed at their organizations
74 of 172 respondents now use Web services to make functions or data contained in major packaged applications--for example, ERP, CRM, supply chain--available on their e-commerce sites or portals for suppliers/customers/partners
102 are thinking about or actively experimenting with using Web services in this way

Defining Web Services Performance
To evaluate the performance of Web services platforms, we considered three things:

• Number of messages per second successfully processed
• Consistent processing of messages under increased load
• Differences in performance between processing of the DOC/LIT and RPC/ENC encoding models

The number of messages per second a product can process is dependent on the XML parser employed. The SOAP request must be decoded by the parser and then handed off to the appropriate Java method. An inefficient XML parser will degrade performance significantly as the size of the request increases, because there is more XML to decode.

Also entering the equation is the way in which a platform marshals and unmarshals arguments--in English, the way a platform transforms an XML element into a Java argument and vice versa. The way in which this is handled varies according to implementation. For example, Cape Clear's implementation handles DOC/LIT differently from the way it does RPC/ENC. In the DOC/LIT model, every argument--even primitive data types, such as an integer--is encoded into a corresponding Java class. That class may be simple, consisting of a single piece of data, or complex, a complete object that may comprise individual objects within it. In the RPC/ENC model, the arguments are often passed to the Web service as a primitive, which can increase performance.

Some platforms, such as those from Novell or Systinet, use the DOC/LIT model of processing even for RPC/ENC, which can degrade performance because of the additional instantiation of objects which are, in some regard, spurious. BEA provides an extra level of abstraction that allows elements within a SOAP request to be mapped to Java methods or arguments that do not necessarily share the same name. This is a definite value-add, making BEA's implementation more flexible, but it does add additional time to the process of marshaling and unmarshaling arguments.

Because Web services are in their infancy, it is not expected that the implementation of a Web service will result in it being inundated with thousands of messages per second. If that happens, we suggest taking advantage of clustering and load balancing, either via the products where available or through an external solution. Because of the real-world use of Web services, we were more concerned with the products' ability to maintain consistent performance as the number of concurrent users increased. In other words, we were examining the ability of each product to scale and were less concerned with the raw message throughput capability of the products under test.

For example, we were impressed with both BEA's and Iona's ability to remain consistent under load, even though the number of messages each processed per second appeared to be low as tested under an out-of-the-box configuration. Sun's product showed a high processing capability while maintaining consistency, while the other products decreased in their processing capabilities as the load increased.

Take advantage of the tuning suggestions made by your vendor of choice. Changes to the Java Virtual Machine parameters, such as memory or threads, and modifications of activation policies, log levels and connection-level settings can drastically increase the performance of an application server, so consider tuning part of the deployment process.

How We Tested Web Services
We set up a Hewlett-Packard Compaq ProLiant DL750, rolling in beefiness with its eight Xeon processors and 2 GB of RAM. Then we imaged eight SCSI 18-GB drives with a copy of Microsoft Windows 2000 Advanced Server, hooked up the Gigabit Ethernet NIC and prepared to test.

We installed each product on one of the prepared drives, then evaluated it in terms of management capabilities, monitoring and configuration options. We then built two Web services with the same functionality, one using DOC/Literal and one RPC/Encoded, and deployed them to the platform using the vendor's development environment. On each platform, we built two Web services, each based on a simple case within the WS-I's interoperability tests. We called both services echoInt. Both services took a single integer argument and returned that argument, plus one. The only difference between the two services was the encoding model. We also implemented a service that connected to our NWC Inc. customer database. This "getName" service took the user name of a customer and returned the first and last name of that customer. Each product was tested on the same version of Sun Microsystems' Java Virtual Machine, version 1.3.1.

Performance testing was accomplished by harnessing five Dell Optiplex machines, all running Red Hat Linux 8.0, and sending SOAP requests via ApacheBench to the product under test. Each test was configured to run for one minute or 50,000 requests (reaching either threshold completed the test) with a concurrency level of 10 on each machine, and was run three times against each Web service. Additional tests were run from a single client machine with concurrency levels of 10, 20 and 30, under the same time- and request-limit constraints.

Each client machine was time-synchronized to a public NTP (Network Time Protocol) server, and a script scheduled via at kicked off the tests to coordinate the five load-generating clients.

We tested interoperability by building MindElectric GLUE (Java) and Microsoft .Net (C#) clients from the WSDL (Web Services Definition Language) served up by each product and then running the respective clients against the service. ApacheBench, though used for our performance tests, was also indicative of the interoperability of each product, as the service was required to interact with the tool in order to perform our tests. We encountered some problems, specifically when trying to access the Web services from a .Net client. Minor tweaks to the WSDL provided the solution, but proved that concerns over interoperability are not completely unfounded.