Whenever I think about soap, my mind inevitably travels back to my youth. One of my siblings was always adept at placing just the right amount of the sudsy stuff into park water fountains around town. The results were almost always effective and a joy to watch, but surely a mess to clean up.
These days, soap is taking on a new meaning: Simple Object Access Protocol. This new form of SOAP may not produce bubbles or leave park maintenance personnel peeved.
It is a promising solution that lets business applications communicate via the Internet regardless of the development architecture that was used to create the software.
I predict SOAP will play a key role in helping to eliminate interoperability problems, particularly those you might experience when integrating applications with business partners.
Earlier this year, Gartner estimated that by 2003 more than 70% of the services executed via the Internet will use SOAP.
So what exactly is SOAP? Simple Object Access Protocol is a connectivity specification based on XML. SOAP was developed by IBM, Lotus Development, Microsoft, and others; Version 1.1 was recently submitted to the World Wide Web Consortium (W3C) for approval.
You may have already implemented applications that are based upon the CORBA object standard or Microsoft's DCOM (Distributed Component Object Model). The SOAP specification is not meant to replace these.
Instead, SOAP greases the wheel, so to speak, to smoothly link applications written using DCOM, CORBA, or other architectures. SOAP is an XML-based messaging/RPC (Remote Procedure Call) protocol.
SOAP will be crucial to companies because it will enable easier integration of dissimilar architectures. This is extremely important given the trend toward more dynamic business partner integration.
For example, suppose your applications conform to CORBA. Your business partner may be heavily invested in Microsoft technologies with a large DCOM-based framework. SOAP would be an easy mechanism to let your applications "speak" with those of your partner without having to make huge technology changes on either side.
Thus far, Microsoft and IBM have been working on initial implementations of SOAP. Microsoft has put forth its SOAP Toolkit for Visual Studio, and IBM has produced its SOAP for Java Project.
Microsoft's initial attempt at SOAP is rather unstable, and it has quirks that make it suited best to communication among Windows platforms at the moment. (Why am I not surprised at that?)
With Microsoft's new focus on supporting interoperability in high-end mixed enterprises and the company's recent announcements concerning future availability of its applications as services, I am hopeful that subsequent versions of the Microsoft SOAP Toolkit will show greater support for cross-platform application communication.
IBM's SOAP Project for Java is more stable, and the company claims that it is the first production-ready SOAP implementation. IBM's implementation is a bit trickier to install than Microsoft's, but the former more closely follows the specification.
Neither IBM nor Microsoft has completely implemented the SOAP specification. Both companies expect to release updates, and I expect you'll see others such as Sun Microsystems implement SOAP as part of its platform and application solutions.
Quite recently, IBM donated its SOAP implementation to the Apache Software Foundation's new XML Project. The Apache XML Project brings together technologies from IBM, Sun, and others into a single open-source XML product. SOAP is one of five project components.
IBM's bold move to "open source" its SOAP implementation will prove fruitful. Open-source developers are already pushing ahead and adding to IBM's implementation.
The result will be good for the open-source community and businesses as a whole, as the specification can be implemented rapidly and in an unfettered manner.
The only real issue is that SOAP is still a "specification" (and not yet a standard). The current version is before W3C for standards approval.
Like WAP (Wireless Application Protocol), SOAP is being implemented quickly, without waiting for committees, as the business need for SOAP technology is pressing.
Implementing a technology prior to standards approval may or may not have implications. I'm hoping for the latter. But perhaps the rapid implementation of WAP and SOAP point to the need to streamline the standards process for fast-track technologies.
This is an ideal time for your development staff to examine SOAP in test environments.
Understanding how to implement SOAP now will shorten development cycles once the specification is ready for production use. Look at details on the current version of the specification.
Well, my sibling is no longer placing soap in park water fountains. These days he develops software; my guess says he'll soon have gone from soap to SOAP. What will you do with SOAP?
Send email to Maggie Biggs. Biggs is director of the InfoWorld Test Center.