Soapbox: Why I'm using SOAP

Soapbox: Why I'm using SOAP   
    
－－One developer tells why he's feeling sold on SOAP

Benoit Marchal

Software engineer

February 2001

In the XML zone's new opinion department, Beno?t Marchal steps up on the soapbox to tell why SOAP is winning him over. SOAP's selling point is its simplicity, Marchal says. Because the new protocol builds on familiar technologies, in particular the Web server and XML, it's relatively easy for developers to design and deploy SOAP servers.

SOAP, the Simple Object Access Protocol, is a new protocol engineered by IBM, Microsoft, Userland, and DevelopMentor to support remote procedure calls (and other sophisticated requests) over HTTP.

SOAP draws from two distinct environments. Built on HTTP and XML, SOAP aims to be as simple as the Web. Yet it targets object-oriented remote procedure calls borrowed from CORBA and DCOM.

I think that the major benefit of adopting SOAP is that it builds on a Web server. Therefore, to understand SOAP, one needs to start with Web servers. Modern Web servers -- and in particular application servers like WebSphere, WebLogic, or ColdFusion -- are powerful development platforms. They are optimized to process requests efficiently.

SOAP is an attempt to turn these Web servers into object servers. By object servers I mean the middle-tier servers in a three-tier architecture. SOAP supports object servers this way by adding a thin XML layer over HTTP.

Let me give an example. I once had to compile ranking information from search engines (for example, Alta Vista). My customer produced reports on site popularity. It is easy to simulate a browser request from an application, the problem is decoding the response. It came in HTML and my application would parse it to extract the links. Unfortunately, the application broke whenever the search engines changed their layouts. That is one of the limitation of the Web: It works well when a user queries a Web server, but it is very difficult to automate.

Now imagine the search engine would run an object server. An updated version of my application could query it. If the object server is built on SOAP, the request and the response are XML responses. Since XML contains no formatting instructions, the application would not break the next time the search engines change their layouts.

Should you consider SOAP?

I will confess to an initial skepticism towards SOAP. I was originally concerned that SOAP was too simple. The new protocol targets a crowded market: other object protocols include DCOM (Microsoft offering), RMI (Java networking by Sun), and CORBA (an open effort). When I compared CORBA and SOAP, I could not help but feel SOAP was too limited for real applications.

Then I started using SOAP and I realized that its major benefit is that it builds on the Web. Granted, SOAP is more limited than CORBA and DCOM. For example, it offers limited support for object-oriented concepts like inheritance, and it lacks transaction management (as offered by MTS with DCOM or OTS with CORBA).

However, what it lacks in power, SOAP more than compensates for in its simplicity. For example, since SOAP uses HTTP, SOAP servers are Web servers. Most businesses have significant experience in deploying Web servers or developing Web applications. With SOAP, they can leverage that experience for object servers.

When should you SOAP?

I can think of only two drawbacks to SOAP but, depending on the project, they can be significant. First, SOAP is not an official standard yet. The W3C has launched its own Protocol Activity, and there is no guarantee that the result will be compatible with SOAP.

Second, SOAP is new, and it lacks some of the tools common for CORBA or DCOM. In particular, there is no transaction management with SOAP. This is not an inherent limitation of SOAP; I'm sure transaction managers will eventually appear on the market, but they are not available yet.

Currently SOAP is ideal for distributed applications that need lightweight remote procedure calls. I realize that there is no hard definition for "lightweight," but essentially it means that the requests should not depend on object-oriented concepts like inheritance or transaction management.

I recently ran into a project that started as a textbook example for CORBA. But it ended up as a SOAP project. I'll share the main issues with you to help you evaluate SOAP.

The project is a classic three-tier application: there is an Oracle database server, business objects reside on a middle-tier server, and the user interface is written with Java servlets. The servlets use a combination of XML and XSLT, as I explained in Making teams work, via XML and XSL (see Resources).

The customer originally wanted to deploy CORBA between the business object server and the presentation servlets. However, we hit two problems: cost and lack of training. The ORB, the CORBA run-time, is expensive and will limit our ability to deploy the application. Also while the development team has lots of experience with Web development, they are new to CORBA.

As we refined our analyses, we realized that the communication between the presentation and middle tiers were simple remote procedure calls (for example, list of products or product details). Given that the presentation servlets depend on XML, we came to the conclusion that SOAP would be a more elegant solution than CORBA. The SOAP response (in XML) can be fed directly to the XSLT processor.

We have just completed a series of tests and the case for SOAP is compelling. Not only do we save on the CORBA licenses and training, but we deploy a Web server on both the middle and presentation tiers. That means we will draw from the same experience to fine-tune the servers.

Conclusion

The name SOAP always reminds me of another protocol that boasts simplicity as its primary virtue: SMTP, the Simple Mail Transport Protocol. Like SMTP, SOAP is underpowered but easy to understand and quick to deploy. There are more powerful e-mail protocols than SMTP, but none is as popular. Will SOAP achieve similar success?

Resources

• Apache SOAP is an open-source implementation of SOAP. It is available in Java and various scripting languages.
• IdooXoap is another open-source implementation of SOAP.
• Microsoft has released SOAP Developer Resources, including beta support for SOAP in Visual Studio.
• Jon Bosak commented on SOAP and ebXML at the latest XML 2000 conference.
• The W3C Protocol Activity may result in a standard that supercedes SOAP.
• Making teams work, via XML and XSL, a chapter from my book XML by Example, excerpted on dW, explains how presentation servlets can use XML and XSLT.
• Pose questions and get answers on the developerWorks soapbox forum.
• Do you have a different view? Or a strong opinion on another aspect of XML development? Take your turn on the Soapbox. Send a brief description of your idea to the XML zone editor at ndunn@us.ibm.com or, if you've already typed up your thoughts, use the Submit content form.