The Standard Struggle, More So

Look at the number of Web services standards that are making the rounds today — between 50 and 60 by most experts' counts. Then think about the number of standards bodies that are working on standardizing those standards. That old saw, about standards being great because there are so many to choose from, has never been truer.

The value of Web services comes from implementing them as components in widely distributed, loosely coupled applications. And on a small scale, or when kept completely internal, the need to occasionally hard code or use a nonstandard schema doesn't cause many problems. In more complex situations, such as the extraprise level, when trying to implement Web services across multiple enterprises, then standards become an extremely important issue.

New or Tried and True?

"There is a basic set of Web services standards that have been well-established and are being used by customers to solve real business problems today," says Karla Norsworthy, vice president of software standards for IBM. Those standards — SOAP, WSDL, even UDDI — are at the core of and are ingrained in the fabric of Web services, she says. So, why does the number of standards being proposed and tested continue to increase?

Dan Foody, CTO for Actional, says it's a fundamental shift in the way that standards are formed. In the past, the standards process was long and onerous, and usually resulted in standards that were complicated and didn't address customer needs. "What has happened more recently," he says, "is that people have started to shift the way they do things. So instead of 'boil-the-ocean' standards, people are designing them for composability. Which means you can take a bunch of smaller standards and use them together to work with one another." Isn't that, after all, the purpose of Web services?

Still, the standards that are in place today are lacking in some areas. For instance, security is an issue that has enterprises doing backflips. How do you get disparate Web services to work together in a secure manner, without rearchitecting your entire organization?

In some cases, it's not an issue at all. "You can have a lot of levels of secure communications using [existing standards]," says Foody. "But," he warns, "that's only applicable to some subset of problems." However, he points out that it's not necessary for every application to have military-level security. And with proposed standards such as WS-Security, you run the risk of outstripping the performance of the hardware with the standards. "If you were to take up some of the new security standards, you would overload all of your applications with processing," Foody says.

It's About Evolution

"People have been wrestling with security transactions in their enterprise infrastructures for years," says Mike Champion, senior technologist for Software AG. "They deal with it by doing all the Web services stuff internally, behind their firewalls and not having to worry about it, or by negotiating, one-to-one, with their business partners." It comes down to a lack of interoperability, he says. And that's what the industry is trying to correct.

Champion's suggestion for ensuring the security of Web services is to start small. "Do what everybody is supporting, which is basically XML, and to slightly less of an extent SOAP and WSDL. But stick with the core specifications that are not controversial." He also points out that Web services standards are not about how to implement applications, including their security. "All this Web services stuff is about how these things talk together, not how they're actually implemented in the background. I don't think Web services standards will really come into their own until there's an evolution toward rebuilding, incrementally, enterprises to work as services." And that's not likely to happen tomorrow.

In the mean time, everyone has one common piece of advice to offer: Step back from the hype cycle and be pragmatic about implementing Web services within the context of your specific business needs.

Jerri L. Ledford is a freelance business and technology writer.