Level: Introductory Frank Cohen (fcohen@pushtotest.com), CEO, PushToTest
01 Sep 2001 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. 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.
About the author  | | |
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. |
Rate this page
| 
