(January 28, 2002) - The chairman of the Internet Press Guild has gone on public record as claiming that there is an "evil little secret" about Web services: "they're fat...and therefore slow."

"Most vendors don't talk about" the problem, says Steven Vaughan-Nichols, but "Web services' protocols are very fat." And that, he maintains, "means that Web services interactions over the network will be slow and eat up a large chunk of bandwidth."

In a broadside at SOAP, which Vaughan-Nichols - previously a programmer and network administrator for NASA and the Department of Defense - calls "the problem child" of Web services - he argues that because SOAP includes both text-based XML tags for every data field and that all that data is also in text, the protocol is hopelessly bloated. Or, as the IPG chairman puts it: "That, my friends, is a lot of bytes," adding that fat protocols are a blight in particular to network administrators, who end up with more network traffic to deal with as a result.

But not everyone agrees with NASA's former network administrator. In particular, Derek Ferguson, author of a recent series of articles in Web Services Journal on mobile Web services and a well-known writer and commentator on Internet technologies, disagrees with Vaughan-Nichols that far faster network performance would be possible by sending the same information is much smaller binary messages using, say, DCOM (Microsoft's Distributed Component Object Model) or CORBA's IIOP (Internet Inter-ORB Protocol).

"On the Internet," explains Ferguson, "Web services are a replacement for Web applications. Therefore, the real comparison in bandwidth should be between XML and HTML (including images) - not with DCOM and CORBA. Doing your presentation on the device (the Web services approach) will always use less bandwidth than sending images across the ether (HTML approach)."

Ferguson points out too that, so far as he is aware, SOAP Extensions have been passed by the W3C and will be implemented by various vendors shortly. "This specifies a compressed, encrypted,binary format standard for SOAP messages traveling over slow connections," he tells WSJ Industry Newsletter, adding: "You will then be able to have your cake, and eat it too!"

Although no one seems to have any specific metrics yet on Web service traffic vs DCOM/CORBA/etc traffic, Ferguson points out that he has invoked Web services from Pocket PCs and J2ME devices, "and perceived them to be much more responsive than Web applications."

So the widespread claims that Web services are so "fat" that users can't even count on being able to utilize them over a dial-up, let alone a wireless connection, aren't - Ferguson says - true. But Vaughan-Nichols is insistent: "Dial-up customers will hate Web service performance," he asserts. Instead, he says, they should deploy Web services on corporate intranets "or with partners on company extranets where you have T1 connections at a minimum."

Bandwidth aside, the security concerns surrounding Web services continue to exercise everyone in the industry, including Vaughan-Nichols. "Because SOAP sends everything in cleartext ASCII, that's a true security headache." Advances in encryption threaten to increase the time that a secure Web services transaction takes, and even using a VPN (virtual private network) will also slow down the network.

Some industry commentators though say that SOAP itself is very lightweight since it only entails the outermost wrapper of the communication, without defining the datatypes within, making the real problem not SOAP but what goes into the SOAP wrapper, namely WSDL (Web Services Descriptor Language) and the W3C XML Schema itself.

"Using any schema that requires you to 'tag' every field is indeed wasteful and in most applications the network weight of the 'tags' will be greater than the data itself," says developer Richard Hansen.

"Yes, Web services will be slow until the WSDL and XML schemas mature in response to some real-world 'snicker tests,'" Hansen adds. "I would suggest to all companies that, for now, they just do their business data modeling using XML Schema and process modeling using WSDL schema. That will take a year or so, don't write any custom code or complex apps until this thing is proven next year. At least you'll be ready with your datatypes, object models, etc. when the faster listeners arrive to apply them."

"People seem to miss the entire point about SOAP." ObjectWatch CEO Roger Sessions tells WSJ Industry Newsletter. "Nobody believes it is as good as DCOM or RMI/IIOP, or any other way of transmitting information requests," he continues, "The one (and ONLY) thing that makes SOAP good is that everybody agrees on it. This makes up for all of the other SOAP shortcomings by a huge margin."

"Up until now," Sessions continues, warming to his theme, " the industry has attempted to accomplish interoperability through dictating a single, universal platform that everybody would use."

At this point he waxes controversial, making Steve Vaughan-Nichols' jibe that SOAP is fat look positively mild, compared anyway to the Sessions view on CORBA and Java: "This has resulted in spectacular interoperability disasters," Sessions says, "like CORBA and Java. Any attempt to achieve interoperability through common platforms is doomed from the start."

"What is significant about SOAP," Sessions finishes, hardly pausing for breath, "is that, for once, people have agreed to put aside their platform differences and focus exclusively on the information flow between systems. So is SOAP slow? The question is ludicrous! Compared to what? There is no other platform neutral way to transmit information requests!"

WSJ Industry Newsletter welcomes further discussion of the "fat future" of Web services...true or false?