As a newcomer, SOAP is being compared to its entrenched and mature predecessors, including CORBA, DCOM, RMI, and others. SOAP takes a lightweight "let's interoperate with everything" approach. Much myth and misunderstanding around SOAP needs to be debunked. As Ralph Waldo Emerson once said, to be truly great one needs to be first misunderstood.

Here are some of the more common myths and misunderstandings surrounding SOAP:

Misunderstanding: SOAP exists because CORBA is not friendly to firewalls

CORBA's reputation as being difficult to work with firewalls is unfair

SOAP and CORBA include mechanisms to marshal together data that is transported over an Internet connection to a remote service. While CORBA 1.0 successfully defined a language-independent way of communicating, it left it up to the vendors to implement a protocol for their Object Request Brokers (ORBs). Because the Internet was relatively new at the time it came out, most of the CORBA 1.0 ORBs did not interoperate. CORBA 2.0 introduced the Inter-ORB Protocol (IIOP) which runs over TCP/IP, among other network protocols.

Firewalls noticed the new protocol and sometimes stopped the ORBs from communicating. IIOP quickly gave CORBA an undeservedly bad reputation as being difficult to work with firewalls.

SOAP, however, deploys its protocol by tunneling through HTTP connections: SOAP requests marshal request parameters into an XML document, which is then sent in the body of an HTTP POST request to a SOAP-based Web service running on a Web host. Also, much work is being done now to expand SOAP to use other transport protocols, such as HTTPS and SMTP.

SOAP plugs into existing Web environments; CORBA extends itself to include the Web. Legacy systems -- including the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), online transaction processing (OLTP) software such as IBM CICS, and others that have their own protocols and language dependencies -- are expected to implement HTTP-style stateless protocols to support SOAP. IIOP, on the other hand, was designed to enable these legacy systems to be the communication protocol connecting ORBs across networks.

Since CORBA 2.0's launch back in 1995, many IIOP/HTTP gateways were launched to enable IIOP tunneling over HTTP.

Back to top

Myth: SOAP scales better, because SOAP is stateless

SOAP too will eventually become stateful

SOAP marshals request parameters into an XML document and uses HTTP to send the request to a Web service. Many people believe that SOAP's reliance on HTTP makes SOAP stateless. And SOAP 1.2 is indeed missing a definition of a session mechanism. However, SOAP will inevitably have a session mechanism to enable transactional requests. Imagine a database application where more than one SOAP request forms a transaction and that groups of SOAP requests may be rolled-back or committed at once. After all, even the supposedly stateless HTTP protocol has cookies to enable stateful transactions.

CORBA features a simple mechanism to use stateless ORB requests. The choice of stateless or stateful is a decision the system designer takes in CORBA environments. Many systems lose scalability when they try to implement complicated stateless systems.

Back to top

Myth: SOAP is open, .Net is closed

SOAP is open; with careful application, .Net is open too

Even though SOAP is an open standard governed by the W3C, Microsoft's .NET use of SOAP may give an unexpected Windows slant to your Web service. But careful use of SOAP in .NET applications will keep SOAP open.

SOAP defines several primitive data types (String, Int, and Double) through which parameters are sent and received. Each new data type introduces a serializer to convert from the XML value into the local programming language's value and back again. Microsoft .NET deploys additional proprietary data-types. For example, the Apache and Microsoft SOAP implementations both include a BigDecimal data type. However, they are not compatible.

Using the SOAP-defined primitive data types guarantees your SOAP-based Web service will interoperates with all Web services, including .NET services. If you do it the other way around, and use .NET or other proprietary extensions to SOAP -- your service will not interoperate with all others.

SOAP implementation differences give rise to a tools market for SOAP interoperability. The Mind Electric's Glue is a commercial product that maps between the platform differences of XML and SOAP.

Back to top

Misunderstanding: SOAP offers no advantages over well-designed, open and mature technology, which is CORBA today

SOAP is more about messaging than Corba is about remote procedure calls

The fight between the SOAP and CORBA camps shows the emerging generation gap in the computer industry. CORBA was developed a decade before the open source movement emerged. The Object Management Group (OMG) created CORBA in 1989 from the sponsorship of 3Com, American Airlines, Canon, Data General, HP, Philips, Sun, and Unisys. These are the technology dinosaurs of today compared to Apache Group, Red Hat, and Sendmail.

On the surface, SOAP and CORBA deliver solutions to inter-application communication. Beneath the surface, CORBA does a lot of work to enable object-oriented programs to seek out and use objects on a remote server. SOAP does a lot of work marshalling data into a format that can be universally shared and transformed between server application software. Here SOAP is leveraging XML's benefits: English-readable code, transformation language, description language, and platform-independence.

New technologies have recently appeared that leverage SOAP to provide data sharing and transformation. For example, IBM offers software to wrap legacy Cobol applications into SOAP-based Web services. And Cape Clear's Web Services Platform allows SOAP calls to be made to CORBA ORBs.

While CORBA can be much more powerful to build and deploy distributed systems, SOAP-based Web services will be able to communicate in data formats that will be readable into the distant future.

Back to top

Myth: SOAP requires you to be a DOM expert

JDOM eliminates the need to become a DOM expert when using SOAP

SOAP uses HTTP to send XML request and response data to a remotely running process. That sounds like you need to learn XML, HTTP, DOM, Web server operations, and more. In practice, though, most of the SOAP example code uses SOAP's bundled-in marshalling methods to set the outgoing parameters and values. So, unless you're sending a complicated request with many parameters, I have found it best to use the SOAP Call object and a Vector to set the parameters.

SOAP returns a Response object containing an XML document. Java developers have a new open-source project, JDOM, to make manipulating the response XML document easy. See Listing 1 to see how to get the root of the response XML document with JDOM.

SAXBuilder responseSAXTree = new SAXBuilder();
Document doc = responseSAXTree.build( response );
Root theroot = doc.getRoot();

Thus, JDOM eliminates the need to become a Document Object Model (DOM) expert when using SOAP.

JDOM will eventually be part of Java itself (JSR 104.) For now, you can download and use JDOM for free (see Resources for a link). To see SOAP and JDOM in action, look at the Load utility (also listed in Resources). Load is a free open-source utility for testing SOAP-based Web services for scalability and performance.

Back to top

Conclusion

Many myths and misunderstandings around SOAP come from SOAP's youth or the generation gap developing in the computer industry. SOAP, CORBA, RMI, DCOM, and others accomplish scalable interoperability. Over time, SOAP will join their ranks as a mature technology and add facilities for security, encryption, protocol compression, and time services. At the same time, a new set of tools will appear to provide XML-powered data transformation between server applications. Provided software developers stick with open-standard implementations and data types, I believe SOAP will become an effective interoperability technology with a new promise to unite the server world.

Resources

• JDOM, a free open-source utility for managing XML documents.
  
  
• Load, a free open-source utility for testing SOAP-based Web services for scalability and performance.
  
  
• Check out the SOAP protocol specification.
  
  
• Here is a list of publicly available Web services.
  
  
• Glue is a cross-platform XML framework.
  
  
• See the Microsoft SOAP resource.
  
  

• For another comparison between Web services and CORBA, take a look at a past issue of the the Web services architect column.
  
  
• This Lotus page on Web Services Architecture and Technology shows how SOAP fits in with other technologies to create the Web services landscape.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Misunderstanding: SOAP exists because CORBA is not friendly to firewalls
• Myth: SOAP scales better, because SOAP is stateless
• Myth: SOAP is open, .Net is closed
• Misunderstanding: SOAP offers no advantages over well-designed, open and mature technology, which is CORBA today
• Myth: SOAP requires you to be a DOM expert
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers