Enterprise Software

Web services' fat protocols could wreck your network

While your company may soon be negotiating a contract for an ASP to bring in Web services, you better realize that Web services also bring a significant protocol load. If you're not prepared, network performance could suffer severely.

By Steven Vaughan-Nichols

Recently, 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.

SOAP clogs the pipes
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 eXtensible 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 Internet Inter-ORB Protocol (IIOP) can send the same information in much smaller binary messages, giving you much 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 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 admitted 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 said. 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 as well. SOAP is the problem child, not the application server engine.

Security adds more network overhead
To add to this problem, Web services have no built-in security because SOAP sends everything in ASCII clear text, which is a true security headache. That means your choices are:
  • Insist on server- and client-side encryption, which will eat up time on both ends of the Web services transaction.
  • Use Secure Sockets 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."
  • Use a virtual private network (VPN), as DesAutels suggests.

I like the VPN option myself because it's the least costly in terms of 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.

What's the solution?
So how do you avoid this potential network traffic jam? Within your enterprise network, take a long hard look at avoiding 802.11b wireless networking. I already don't like 802.11b performance for anything but the smallest networks; however, 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 10-Mbps 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 an already overburdened Ethernet network.

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 connectivity (ODBC), Java Database Connectivity (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.

Steven Vaughan-Nichols has written about technology for more than 15 years. He was previously a programmer and network administrator for NASA and the Department of Defense. Steven is also currently chairman of the Internet Press Guild.

What do you think about the performance of Web services?
We look forward to getting your input and hearing about your experiences regarding this topic. Post a comment or a question about this article.


Editor's Picks

Free Newsletters, In your Inbox