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.

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.

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.

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.

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.