Developing Trends: The Drag on Web Services

Reality Strikes

Fact is, for Web services to be useful, an organization needs more assurance than "everything will be OK ... as long as no more than 5 percent of your employees hit this application at the same time."

Not long ago, I wrote a Web-based operations application that works only with Internet Explorer, so I could test IE's JavaScript/Web services interface. I found that, though the interface works as advertised, IE leaks memory when calling Web services. And because the application I wrote is one that users tend to leave on 24/7, the Web service is called every 10 seconds, leading to massive memory consumption and torturously sluggish system performance. That just won't fly.

And I don't think this is one of those "it will get better with time" situations. Many vendors are committed to Java and .Net, and I believe the performance bottleneck is in the platform. No one considers Xerces and Xalan--the Java XML processing libraries--fast, nor do they appreciate the low speed with which MS-XML processes files. Yet when I suggested to one developer that portions of his company's architecture should be rebuilt using something faster, like C or C++, he responded matter-of-factly, "That's not how Java works." Duh.

Stuck in Our WaysOf course it's easier to develop and implement applications in Java and .Net than C or C++, but that won't solve the Web services problem.

Systinet, a Web services vendor, is one of very few companies with a C++ implementation of a Web services server, and based on what I hear from our tech editors, it buries most of its competition. But even Systinet's performance isn't enough to change the pervasive attitude that the status quo is the way to go, so low-speed Web services remain the norm.

The only way to convince vendors that poor performance is unacceptable is for you and me to spell it out for them: Yes, Web services promise to improve computing, but with the overhead of WS-Security, UDDI (Universal Description, Discovery and Integration) and other speed-eating "enhancements," current models won't do the trick, even for internal use at companies with just a few hundred employees, let alone for companies operating over the public Internet.

And we need to stick to our guns: If there's no market for a sluggish Web services application, there's no reason for the vendor to make and market that application. It comes down to the simple law of supply and demand.

Let's keep our Web services dollars in our pockets until the vendors get the message.Don Macvittie is a technology editor at NETWORK COMPUTING. He previously worked at WPS Resources as an application engineer. Write to him at [email protected].