Myths and misunderstandings surrounding SOAP

Debunked, explained and clarified

Being the new kid on the block, SOAP has to do some explaining in order to gain acceptance. SOAP moves into a neighborhood brimming with other server-to-server communication technologies, including CORBA, RMI, and DCOM. Camps have formed around these existing technologies. And now myths, rumors, and innuendo are flying. In this article, Frank Cohen details and debunks many of the myths and misunderstandings surrounding SOAP.

Frank Cohen (fcohen@pushtotest.com), CEO, PushToTest

Frank Cohen is a software entrepreneur who has contributed to the worldwide success of personal computers since 1975. He began by writing operating systems for microcomputers, helping establish video games as an industry, helping establish the Norton Utilities franchise, leading Apple's efforts into middleware and Internet technologies, and most recently serving as principle architect for the Sun Community Server, Inclusion.net, and TuneUp.com. Frank maintains the open-source Load project and is CEO for PushToTest, a scalability and performance testing solutions company. More information is available at www.PushToTest.com. You can reach Frank at fcohen@pushtotest.com.



01 September 2001

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.


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. See Listing 1 to see how to get the root of the response XML document with JDOM.

Listing 1: Using 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.


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

  • 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.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=11610
ArticleTitle=Myths and misunderstandings surrounding SOAP
publish-date=09012001