Nothing But Net/Mark McFadden: Is There Hope for SOAP?

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, standards process. The World Wide Web Consortium (W3C, 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

About the Author

Scott Bekker is editor in chief of Redmond Channel Partner magazine.


  • Old Stone Wall Graphic

    Microsoft Addressing 36 Vulnerabilities in December Security Patch Release

    Microsoft on Tuesday delivered its December bundle of security patches, which affect Windows, Internet Explorer, Office, Skype for Business, SQL Server and Visual Studio.

  • Microsoft Nudging Out Classic SharePoint Blogs

    So-called "classic" blogs used by SharePoint Online subscribers are on their way toward "retirement," according to Dec. 4 Microsoft Message Center post.

  • Datacenters in Space: OrbitsEdge Partners with HPE

    A Florida-based startup is partnering with Hewlett Packard Enterprise in a deal that gives new meaning to the "edge" in edge computing.

  • Windows 10 Hyper-V vs. Windows Server Hyper-V: Which Platform for Which Workloads?

    The differences between these two Hyper-V versions are pretty significant, depending on what you plan to use them for. Here's a quick rundown of each platform, from their features to licensing quirks to intended use cases.

comments powered by Disqus

Office 365 Watch

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.