Cleaning Up Internet Access with SOAP
HTTP is a very useful protocol. Every day it moves vast numbers of bytes between Web servers and Web browsers. But HTTP was originally designed to do one simple thing: transfer files. Today, though, it has been pressed into service as a way to access applications as well. The fact that HTTP works at all for this is a testament to its good design, but using a screwdriver as a hammer still doesn’t make it a hammer. If what a client needs to do is access the services an application provides, why not use a protocol designed expressly for this purpose?
Today, distributed applications tend to provide their services as methods grouped into interfaces. Clients can call those methods over a network using some kind of distributed object protocol, such as the one defined by Microsoft’s Distributed COM (DCOM) or the Object Management Group’s Internet InterORB Protocol (IIOP). Plenty of applications running on internal networks today use this approach -- and one of these protocols -- to make requests across a network.
On the Internet, though, protocols such as DCOM and IIOP run into trouble. The primary source of problems is the firewall that most organizations place between the internal network and the scary public Internet. Those firewalls are commonly configured to block most protocols, including DCOM, IIOP, and their distributed object brethren. They are not, however, typically configured to block HTTP. Accordingly, although using a distributed object protocol to access a remote application’s services arguably makes more sense then force-fitting HTTP into this role, it’s just not feasible. The people who administer those firewalls are reluctant to open them up any more than is absolutely necessary.
Enter Microsoft’s Simple Object Access Protocol (SOAP). The key idea of SOAP is to define a distributed object access protocol that’s built on HTTP. Client requests, complete with parameters, can be sent to a server as part of a standard HTTP POST operation, with results returned as normal HTTP responses. Requests and results are represented using XML, so they’re relatively simple text strings. And because pretty much all firewalls happily pass HTTP, requests to distributed objects made via SOAP don’t face the same problems as those made with DCOM or IIOP. Even better, SOAP isn’t tied to a particular distributed object technology. Theoretically, this protocol -- or some future version of it -- could replace both DCOM and IIOP.
SOAP has plenty of potential. Like most new technologies, though, it also has its drawbacks. One is that packaging requests and results as XML-defined data takes time and leads to large messages, both of which mean that SOAP can be slower than more conventional distributed object protocols. Also, although the notion of silently slipping through firewalls appeals to application developers, it’s less thrilling to the administrators of those firewalls. After all, there are reasons why firewalls are configured to block distributed object protocols. Circumventing an administrator’s choices is unlikely to make him or her happy. Finally, although SOAP could potentially be used with COM, CORBA, or other object technologies, it’s very difficult to imagine the OMG or other vendors endorsing a Microsoft-defined protocol. Whatever the technical merits, business and political concerns are likely to get in the way.
SOAP’s performance will matter less, however, as networks and machines continue to get faster. Also, administrators can still set firewalls to block SOAP requests if desired by filtering any traffic with the content type text/XML-SOAP. And who knows? Maybe the object wars really can end in a SOAP-led truce. I think the chances of this happening are about the same as the odds of Warren Beatty being elected president, but unlikely things do sometimes happen.
Microsoft has posted the SOAP spec on its Web site at msdn.microsoft.com/xml/general/soap_v09.asp, but they’ve not said much about how they plan to use it. One possibility would be to replace the current DCOM protocol with SOAP, at least in cases where getting through firewalls is required. Whatever happens, though, SOAP is an interesting technology, one that will be worth watching. --David Chappell is principal of Chappell & Associates (Minneapolis), an education and consulting firm. Contact him at david@chappellassoc.com.