Nothing But Net/Mark McFadden: Is There Hope for SOAP?
- By Scott Bekker
Imagine you wanted to have your applications work across any platform or network boundary: you could be running an Active Server Page application that called on the services of a Oracle database running on Unix and a Linux-based message server. Our heterogeneous world today makes these kinds of connections very difficult, but where there’s SOAP, there’s hope. At least that’s what I thought until recently.
SOAP is the Simple Object Access Protocol. SOAP defines how to use XML and HTTP so that any service, object, or server can be accessed in a completely platform-neutral manner. You can think of SOAP as a kind of glue that binds services from multiple platforms together -- allowing a DB2 database to talk to an IIS server that builds ASP applications for Unix workstations. If developers and vendors can agree on SOAP, then we have a mechanism for bridging competing technologies in a standard way.
The good news is that SOAP is built on HTTP and XML: two standards that enjoy wide acceptance in the development community. HTTP and XML have another crucial advantage: transparency to firewalls. It isn't easy to get distributed applications across network boundaries to work. Internet firewalls typically block all but a few TCP ports and as a result, many distributed object protocols -- such as Microsoft’s DCOM -- fail because they use blocked ports. Forcing firewalls to reconfigure each time you deploy an application simply isn’t practical.
It looks like a fair amount of support is building for SOAP as an alternative: the original authors of the standard -- Microsoft, IBM, DevelopMentor and UserLand -- have been joined by six new companies. The current version of the SOAP specification, version 1.1, even seems acceptable to Sun Microsystems.
What remains to be done? While SOAP will provide a lightweight foundation for many applications, it’s also clear the proposed standard will not provide the complete infrastructure that industrial-strength e-business requires. For instance, SOAP will be the bedrock for Microsoft’s BizTalk systems, but may not be sophisticated enough for the ebXML initiative. The ebXML effort is likely to deliver a wide-ranging solution to meet the needs of electronic business -- but not for another 12 to 15 months.
During that time there’s the significant problem of successfully standardizing SOAP. The current protocol is an Internet draft in the Internet Engineering Task Force’s (IETF, www.ietf.org) standards process. The World Wide Web Consortium (W3C, www.w3.org) hasn’t decided if it should tackle the difficult task of standardizing XML-based protocols.
At a recent meeting I attended in The Netherlands neither the W3C nor the IETF stepped up to become the standards body for the vast array of XML-protocols emerging in the marketplace. I’m worried that SOAP -- as important as it is -- won’t find a home in one of the key standards organizations.
That would be bad because developers need a stable standard on which to build applications. For SOAP it would be better if it were done in the open light of an Internet standards group. --Mark McFadden is a consultant and is communications director for the Commercial Internet eXchange (Washington). Contact him at [email protected].
About the Author
Scott Bekker is editor in chief of Redmond Channel Partner magazine.