Fat protocols slow Web services

Last time around, I told you that if you wanted to support Web services you could look forward to upgrading your old servers and adding new ones. And, indeed, that will go a long way to making Web services fast enough to keep your users happy. But that's only part of the story.

You see, there's an evil little secret about Web services that most vendors don't talk about. Web services' protocols are very fat, and that means that Web services interactions over the network will be slow and eat up a large chunk of bandwidth. That's because Simple Object Access Protocol (SOAP) is an Extended Markup Language (XML)-based messaging format that provides the middleware glue that binds Web Services together. In turn, that means SOAP includes both text-based XML tags for every data field and that all that data is also in text. That, my friends, is a lot of bytes. By comparison, both Microsoft's Distributed Component Object Model (DCOM) and CORBA's IIOP (Internet Inter-ORB Protocol) can send the same information in much smaller binary messages, giving you far faster network performance.

So why didn't DCOM, IIOP, or one of the similar remote procedure call (RPC) protocols take over the networking application world? Because they're much more complex to program; DCOM works only with Microsoft products, and IIOP works only with software that has adopted the CORBA programming model. SOAP's big selling point has always been that it's open, making it easy to add existing application servers and programs. And, frankly, it's simply easier to write programs with SOAP than it is with the other protocols.

That's great for developers. But it's a pain for network administrators, because they end up with more network traffic to deal with.

How much more? At this point, it's hard to say, since Web services are still in their infancy. But Microsoft XML Web services project manager Philips DesAutels admits that "there's a cost to everything," and I believe the cost is performance with SOAP-based Web services. "The best (in terms of network speed) protocol is the one I write for myself," he says. Still when all is said and done, with Web services, "you trade performance for highly flexible protocols."

In no way is this just a .NET problem. It's true of any J2EE Web services application server too. SOAP's the problem child, not the application server engine.

Add to this that Web services have no built-in security. Because SOAP sends everything in cleartext ASCII, that's a true security headache. Your choices are:

1. Insist on server- and client-side encryption, which will eat up time on both ends of the Web services transaction
2. Use Security Socket Layer (SSL), which, as DesAutels says, can also be network and server/client side time-intensive, since for each transaction "you're taking SSL up and down"
3. Use a virtual private network (VPN), as DesAutels suggests.

I like the VPN option myself, because it's the least costly in overall performance, but VPNs aren't security solutions in and of themselves. Of course, the common factor in each of these is that they all slow down the network.

So how do you avoid yet another network traffic jam? Within your enterprise network, take a long hard look at 802.11b. I already don't like 802.11b performance for anything but the smallest networks; adding Web services to its load is asking for the help desk to be swamped by calls from users who are sure that the Web services aren't working.

If you're still using good-old 10Mbps Ethernet and those connections are already running at a high rate of utilization, you might as well seize the opportunity to upgrade them to Fast Ethernet. Web services are likely to be the straw that breaks the camel's back on already overburdened Ethernet networks.

Also, it may be time to tell--oh all right, suggest that the CIO and CTO stop plans to deliver Web services over the Web if many of your users use dial-up. Trust me, dial-up customers will hate Web service performance. Instead, deploy Web services on corporate intranets or with partners on company extranets where you have T1 connections at a minimum.

Finally, for your servers, it's time to say hello to Gigabit Ethernet. While your database servers will still be talking to your application server in relatively speedy Open Database Connect (ODBC), Java Database Connect (JDBC) or the like, communications among the application servers and the Web server will be in SOAP. And since those links will be the central bus for all Web services, they'll need every byte of data transfer power you've got.