Web standards: Are we on overload?

Summary:In Web services, interoperability is everything, says guest columnist Brent Sleeper. But let’s not risk that by over-specifying the solution.

COMMENTARY--The ubiquity of today's Internet-based computing infrastructure has taught us that standards are good. But, as you may recall from childhood sugar hangovers the day after Halloween, too much of a good thing is very often not a very good thing at all.

Software marketers rarely know when to say "when"--perhaps a sugar high explains a few of the recent press releases announcing one Web services "standard" or another. It's enough to make us raise our eyebrows and wonder, isn't this going a bit too far? How much standardization is really necessary for the Web services model to succeed--and will too much doom the architecture's appeal and interoperability?

By intent, Web services are not implemented in a monolithic way, but rather represent a collection of several specific, complementary standards (chiefly, SOAP, WSDL, and UDDI). From a technology perspective, quick agreement on these technologies has been a critical catalyst for accelerating acceptance of the basic Web services model. It seems reasonable to suppose that without agreement by IBM, Microsoft, Sun, and others on basic protocols like SOAP, Web services would remain just another nifty idea developed in a lab that grows stale before making it out to the real world.

Enlightened self interest
That being said, let's talk about why software companies and customers alike tend to support standards: it's simply enlightened self-interest. For platform vendors, standards help establish infrastructure that serves as the lowest common denominator upon which additional, high-value, and presumably innovative products can be built and sold. For customers, the kind souls who pay for all of this innovation, competitive products implemented on top of open standards help ensure that they won't be locked into one vendor's approach.

Unlike halloween candy, standards come in just two flavors: de facto and formal. De facto standards are usually the result of a single vendor gaining enough market share that its approach is "just the way things are done." Microsoft's Windows operating system and Office software are good examples of this model.

While de facto standards can ensure consistent operating environments, they also lock customers into a particular technology that lacks competitive alternatives.

Formal standards are the work of industry consortia or other independent bodies like the W3C. Consortia accept proposals, develop specifications, and publish standards through a committee process that ensures consensus and competitive access to the result.

However, as anyone who's worked on a committee knows, too much "consensus" can stall the development process or burden it with too many details, as it tries to be all things to all people.

Standards make a lot of sense when issues like basic connectivity are at hand. Witness the success of the Internet's TCP/IP and HTTP as just the most visible examples; for the same reason, SOAP and WSDL are a very appropriate step in solving basic problems of connection and semantics for Web services. These core layers that define basic Web services communication have been widely accepted and likely will be implemented quite uniformly. [Note: Here's a link to a primer on these basic standards in the Web services technology stack.]

Higher-level layers that define strategic aspects of business processes remain an open question, however, and it is likely that divergent approaches will emerge--in fact, we'd go so far as to say standards *should* diverge at these layers. After all, neither vendors nor customers of software benefit from software that is not compatible at the connection layer; however, both can realize significant competitive advantage when it comes to deciding how to orchestrate a business process (as WSFL would do) or how to best manage the user experience (which WSUI would help address).

Ultimately, will these attempts to create standard ways of describing business rules for Web services succeed? Perhaps, but partisans in battles over a particular standard very often lose sight of the forest for the trees. Although the authors of each of these proposals may be very earnest in their vision for Web services, standards that emerge ex nihilo risk racing far ahead of the current market need.

Vendors and customers alike are just barely beginning to wrestle with basic questions of SOAP interoperability and their approach to adopting service-based architectures like Web services. Until these early adopters face the challenges of real-world problems, they will not benefit from abstracted solutions like "proposed standards."

The larger risk
The basic model must solidify before software firms begin stuffing customers' treats bags full of standards and other sweets.

In our mind, a larger risk is the possibility that the Web services concept will become over-engineered as too many vendors try to push "standardization" of some aspect of services design and management to their own advantage.

If a consortium like the UDDI group tries to specify feature after feature of the services stack, one of Web services' basic appeals-simplicity-will vanish. If laden with an odious list of requirements and extra baggage, Web services risk becoming just an Internet-era version of CORBA: a complex idea that few businesses have a particular need or wherewithal to implement in an interoperable way.

In Web services, interoperability is everything. Let's not risk that by over-specifying the solution.

What do you think about some of the recently proposed Web services standards? I'd like to hear your thoughts in the TalkBack below.

Brent Sleeper is a partner in The Stencil Group. He is a leading expert on the emerging Web services market.

Topics: Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.