In-Depth
Web Services: Standards Breed Like Crazy...
Talking Points
SETTLING ON STANDARDS
- 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.
ILLUSTRATION BY PETER FERGUSON
Sidebar: Relief
from an OASIS
More on ADTmag.com:
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