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 per cent 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 on 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 (msdn.microsoft.com/xml), and IBM has produced its SOAP for Java Project (www.alphaworks.ibm.com).
Microsoft's initial attempt at SOAP is rather unstable, and it has quirks that make it best suited 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.
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.