Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Serving Up SOAP

Taste Tests

We invited BEA, Cape Clear, IBM, Iona, Microsoft, MindElectric Co., Novell, Oracle, Systinet and Sun to our Green Bay, Wis., Real-World Labs® to see which of their secret sauces could withstand our rigorous testing. IBM passed, saying a forthcoming release would be a better fit, and Microsoft reluctantly declined as well, preferring to serve up Windows Server 2003 at a later date. MindElectric bowed out, citing resource issues, and though Oracle worked hard to meet our deadlines, resource issues also prevented its participation.

So we tossed, whipped, mixed and beat products from BEA, Cape Clear, Iona, Novell, Systinet and Sun with the frenetic energy of the Swedish Chef. All the products deserve a standing ovation for their interoperability--during our testing, a failure to interoperate with our clients, regardless of the operating system/ development language platform used to build each client was negligible, and total interoperability was achieved with minimal tweaks to product-generated WSDL (Web Services Definition Language).

Happy SOAPing

One of the beautiful things about Web services is the agnostic nature of the standards behind SOAP (Simple Object Access Protocol). Because every existing Web services standard--from SOAP to WSDL to UDDI (Universal Description, Discovery and Integration) to WS-Security--is based on XML, it really doesn't matter what underlying operating system the product resides on; to provide Web services functionality the Web service must process XML. That means that half of the Web services' secret sauce, regardless of whether it's served on a J2EE or Microsoft .Net plate, is the XML parser used by the product. The second half is the way in which a product handles marshaling and unmarshaling of arguments. Marshaling is the process of taking arguments from the submitted XML document, such as a purchase order or customer ID, and putting it in a format usable by the developer. Unmarshaling is the opposite process--taking a language-specific construct and turning it into XML. If either of these ingredients is substandard, it means poorer performance and a more difficult time for developers to create Web services of their own.

  • 1