Web Services: Standards Breed Like Crazy...

Talking Points

  • Web services is still an evolving discipline and so are the commonly accepted rules for making sure everything works well together.
  • Under the Web services governance model, every service definition is assumed to be volatile, so there must be a process for making changes without having to propagate them.
  • Experts recommend building WSDL, UDDI and SOAP, although SOAP and WSDL have a number of inconsistencies, and each vendor interprets them differently.

The IT industry must love standards, to paraphrase Abraham Lincoln, “otherwise it wouldn’t have made so many of them.” Nowhere is this love affair more obvious than in the emerging world of Web services. Industry consortia and standards bodies alike are pumping out a glut of specifications that define every element of a Web service’s look, feel, functionality and operating environment.

It’s enough to make even veteran software managers and developers lose hope. “We watch all of these emerging standards, and frankly they seem to be breeding like rabbits,” says Greg Carter, CTO at Metastorm, developer of the e-Work business process management platform. “Every time we meet internally to refine our strategy, there’s a new standard or something that’s subtly different in an existing one. It’s been very challenging for us to figure out the best way to take advantage of them all.”

Part of the problem is that Web services is still an evolving discipline, and as technologies and development techniques remain in flux, so do the commonly accepted rules for making sure everything works well together. In some cases, specifications exist to guide the low-level interactions of two services. Other times, the rules have loftier goals—to create an environment where far-flung services can track each other down and become part of a larger business process, all without their creators ever interacting or even anticipating that their services might one day have reason to work together. The ultimate goal for an increasing number of organizations today is a service-oriented architecture, an organizational framework for launching, locating and orchestrating Web services into flexible and reusable business activities.

There’s a core set of standards for the simple interaction of point-to-point Web services. However, the view of specifications is much fuzzier for more ambitious endeavors. What’s a software manager or developer to do? The standards thicket can be tricky to negotiate, but it’s not impossible. The key is to know what standards are essential, when to use them and when to wait for specifications that may not yet be ready for prime time.

Ball of confusion
According to research firm Evans Data, developers have a passing familiarity with only a handful of Web services standards, with many more not yet on most radar screens. The EDC survey, conducted at the end of last year, also reveals why Web services and standards may become the top priority for software managers and developers. The survey found 40 percent of developers believe Web services will diminish the need for enterprise application integration. Similarly, 60 percent of the developers expect Web services to lower costs to implement standard EAI implementations. The prime areas for Web services development include business process management, data management and e-commerce applications, according to EDC.

Standards matter in the Web services world because they provide a foundation for the larger goals of reusability and interoperability. “They make it easier for multiple people to share a service,” says Daniel Sholler, vice president of technology research services at Meta Group.

Industry-accepted specifications also make it possible for Web services to evolve without initiating an enterprise-wide revision effort to accommodate the alterations—one of the prime headaches of traditional software development. “It’s not that change in itself has been difficult. The problem traditionally has been that one change here means you have to make changes in 15 other places,” Sholler adds. “Part of the Web services governance model is the idea that every service definition is assumed to be volatile. A process has to be in place to make changes without having to propagate those changes all over the place. The SOA concept, if done well, minimizes dependencies by distinguishing between [a Web service’s] interface and its functions.”

Three’s the charm
The good news is that developers have a growing familiarity with the most important standards that underpin Web services projects. XML, dating back almost a decade, opened the door to today’s version of Web services. More recently, a specifications trifecta has emerged to provide a cornerstone for standards-based services. Jeff Schneider, CEO of the systems integrator Momentum SI, calls them “the anchor for Web services.”

The trio consists of the W3C’s SOAP, WSDL and UDDI. SOAP provides an XML-based specification for defining how Web services exchange messages. “All the agreements between services about what functions will be provided show up inside of the SOAP message,” Schneider says. “The messages are divided into the header, which covers security and reliability, and the body, which provides a description of the business function. The SOAP document represents an instance of a specific message going from point A to point B.”

WSDL, another W3C specification based on XML, provides a lexicon for describing the characteristics and functionality of a Web service. Because individual character descriptions are embedded in a WSDL service, applications can easily search and discover the capabilities they need to complete a task.

UDDI provides the central repository where Web services wait to be discovered and is analogous to the Yellow Pages. “Let’s say Mary creates a service using WSDL, and she wants Bob to be able to use the service. Mary can register it with UDDI, which provides the metadata for how to use the service. Later, Bob goes to the UDDI directory, finds Mary’s service,” Schneider explains.

As anyone who has been around IT knows, standards in themselves, even relatively mature core specifications like these three, don’t always guarantee interoperability. Even the best-written specifications may include wiggle room that allows for enough interpretation to keep compliant programs from collaborating effortlessly. “Our recommendation is to build on the Web services framework of WSDL, UDDI and SOAP, but SOAP and WSDL, in particular, have a number of errors and inconsistencies, and because of that each vendor interprets them differently,” says Anne Thomas Manes, vice president and research director for Burton Group.

In a world where interoperability is everything, vendors and developers have worked to find common ground. The WS-I group, which includes software heavyweights such as BEA Systems, IBM, Microsoft, Oracle and Sun Microsystems, circulates the WS-I Basic Profile, a broad interpretation of important Web services standards. “The Profile provides an important guideline tool for those people who are implementing or writing Web services applications,” Manes says.

Standards are distant from reality
Experts point out that while standards help bring about interoperability, other factors, such as faster performance or pushing a critical service out the door, sometimes take precedence. “One of the most sophisticated applications I’m familiar with is built on top of an EAI application. It’s not a standards-based technology, but it otherwise fits all the definitions of SOA,” Sholler says.

Metastorm’s Carter says he thinks of standards applying to broad categories that map to a range of finely to coarsely grained services. The low-level, technical services, the most finely grained of all, include functions including authentication and security key creation. High-level, coarsely grained services, the focus of Metastorm’s strategy, support various business functions, such as “create a customer profile” or “compile all the orders placed by customer A in the last 90 days.” While established Web services standards, including SOAP and WSDL, serve the needs of low-level activities, the implementation of standards for higher-level functions is still relatively academic, Carter believes. “Because we focus on the actual business process, we’re different from the people working at the low-level processes,” Carter says. “We don’t tend to interchange [services] as much.”

Carter says he’s interested in standards that will eventually be helpful for interchanging process models and describing interactions among Web services. “Those kinds of standards will allow us to interoperate with applications that are exposing business functions.” But for now, that’s something for the long term. “The standards being discussed are still a long way from that ultimate business function, and that’s what keeps us from getting overly excited about them. We want more than what’s out there now,” Carter says.

Experts warn that software managers shouldn’t get bogged down by the proliferation of immature standards that may or may not become as significant in the future as SOAP or WSDL. “The key to keep in mind is what standards are for in the first place—providing interoperability across vendor implementations,” says Jason Bloomberg, senior analyst with ZapThink, a consulting firm that specializes in Web services, XML and SOA.

For some forward-thinking companies, interoperability is becoming a long-term strategic goal, not a means for solving the short-term tactical problem of getting two specific services to work together. “If Web services are just a better way to do point-to-point integration, then who cares? That’s what adapters are for,” says Ron Schmelzer, also a ZapThink senior analyst. “The real story is Web services as a movement toward SOA, which is an entirely different architecture. It’s about how do you take these individual [services] and put them together to build business applications.”

That’s where Web services standards may eventually show their true value. Standards will become essential if they can provide a mechanism for the interaction of loosely coupled services, where the services provider and the services consumer do not need plan their development projects together or even work in the same organization. “Loose coupling works only if there are some common ground rules that everybody can agree on,” Schmelzer says. “If we didn’t have standards, we couldn’t build SOA environments. You’d have to figure out what protocols to use ahead of time, and everybody would have to use your protocol.”

Welcomed relief
The good news is that today’s integrated programming environments, whether tailored for Java or .Net Web services, are starting to shield software managers and developers from the prospect of becoming specifications geeks. “Standards [adherence] is now getting generated by whatever development gizmos people are using,” Sholler says. Which may be the only way to herd something as plentiful as rabbits.


Sidebar: Relief from an OASIS

More on
Web services orchestration waits for standards harmony
By Alan R. Earls
Standards issues can't stop Web services spread
By John K. Waters
Web services standards near critical point, says Gartner
By Rich Seeley