The elements of Web services
What technologies support Web services and what is ready
for prime time? The answers can be confusing. Like any new technology, most of
the current action surrounding Web services is just talk and experimentation.
The basic building blocks have been laid, but questions abound about what
additional pieces need to fall into place.
Nonetheless, some companies are not waiting for all the ''i's'' to be dotted
and the ''t's'' to be crossed. Galileo International, a travel service subsidiary
of Cendant Corp. headquartered in Parsippany, N.J., has been looking for ways to
broaden its corporate travel services, providing corporate clients greater
leeway to plan trips, book reservations and gain flexible reporting capabilities
without having to ''dumb'' the application down using conventional HTML Web pages.
It wanted to provide capabilities, like wizards, that are taken for granted in
desktop apps. But the initial version of its app, which required Microsoft-based
clients, would have had limited usefulness in the real world. Web services
proved the only viable deployment alternative.
''Web services are effective at two levels,'' said Glen Zwart, principal
engineer at Galileo. ''First you expose the host system, then you add pieces of
logic that make the host system useful.'' But, he conceded, Web services as an
emerging technology provides some speed bumps. ''We need a real security model,''
said Zwart, noting that for now, his development team has to use homegrown logic
for essential functions such as authenticating users and authorizing access.
According to Steven VanRoekel, director of Web services technical marketing at
Microsoft, Web services promise to restore some of the functionality taken away
when the Web dumbed down classic GUI clients. ''The GUI introduced ideas like
polymorphism, where every app understood commands like copy, paste and print.
Web services could give much of that back,'' he said.
Web services could also provide the technology building blocks for
deconstructing apps into a series of functions or services that can be accessed
using RPC-like transactions or loosely coupled, asynchronous transactions
completed with intermediary brokers. Using brokers, Web service requests do not
have to know how or where services are deployed -- a significant change from
conventional client/server or distributed computing architectures.
What does it take to make this happen? What are the building blocks, and what
technologies are ready for production today? At first glance, the answers seem
simple. An introductory demo by XMethods Inc. at the XML and Web services One
conferences brought a half-dozen vendors together to stage a rudimentary
procurement app using the basic building blocks of Web services: SOAP messages,
WSDL service definitions and UDDI services directories. In the demo, the
mechanics of passing service requests, lookups and responses was the easy part,
said Tony Hong, president of XMethods, San Jose, Calif., who directed the
''In the real world,'' said Hong, ''the heavy lifting will happen where trading
partners agree on business ground rules.''
If only it were that easy. With Web services, however, much of the
transaction services that are taken for granted with conventional software and
OS environments have to be reinvented and implemented in an environment where
the parties, apps and underlying systems involved in processing an application
might not be known until runtime -- if they are known at all. Suddenly, concepts
like two-phase commit sound quaint, because the transaction might require more
intermediaries than a conventional transaction processing application. And if
the service request travels outside the firewall, security requirements for
authentication, authorization and confidentiality will snowball. Furthermore,
the challenge of figuring out how to manage, test and maintain service levels in
loosely coupled environments -- where almost anything goes -- could prove
challenging, to say the least.
The original premise behind Web services is
deceptively simple. It starts with XML, a text-based, Unicode language that
accomplishes for structured data what ASCII did for plain text: It provides a
neutral format that has become practically ubiquitous. Web services add standard
interfaces for communicating structured messages over standard protocols like
HTTP, defining business services and providing rudimentary directories of
Web services are also designed to be flexible. They can be structured as
conventional, synchronous RPC-style transactions where data types and
request/response methods are strictly defined. Or they can be deployed as
asynchronous, complex transactions that involve multiple parties, loosely
structured document exchanges or just about anything in between.
Web services start with SOAP, the predominant Web services messaging format.
Used for sending XML-based messages over protocols like HTTP, SOAP's popularity
is due to its simplicity and flexibility. Its headers provide an envelope that
describes the type of content in the message, directions on how to process the
message and the sender's identity. Content may be structured or unstructured, in
whatever manner the sender chooses.
The brass ring of Web services is the Web Services Definition Language
(WSDL), the mechanism for specifying how a service operates. WSDL consists of a
structured XML document that specifies endpoints (the operations that are
performed) and the messages that define the subject of the data. More
importantly, WSDL specifies the bindings (where the services are to be deployed
on the network) and provides the flexibility for deploying services in RPC or
loosely coupled forms. Better yet, by making binding a separate header, WSDL
definitions are extremely portable and reusable.
In effect, WSDL furnishes the ground rules for conducting business using Web
services. Some observers say getting WSDL straight could be half the battle in
setting up business interactions using Web services.
''The fact that the WSDL documents were defined in advance meant that 80% of
our effort was defining things like what the physical interfaces would look like
and how to handle faults,'' recalled Sam Ruby, a specialist for IBM, who
participated in the XMethods demo.
Then there is Universal Description, Discovery and Integration (UDDI), a
mechanism by which Web services can be registered and have their interfaces
discovered. Providing a rudimentary registry of Web services, WSDL names the
service provider, categorizes the service, and includes technical descriptions
of the service being made available. Currently viewed as an optional function
for Web services, UDDI is required when the interfaces and specifics of the
service provider and the actual service to be performed are not known in
advance. Ultimately, the real value of UDDI may be its ability to provide an
intermediary layer that eliminates the need for Web service requests to know
anything about the services they are requesting -- a capability that could be
especially useful if the identity of the provider or the physical location of
the service on the network changes.
UDDI is not the only registry proposal out there. E-business XML (ebXML), a
broad framework for defining e-business collaborations, includes proposals for
registries, messaging and other functions. ''It's more than a UDDI registry, and
not a rival to SOAP,'' noted Patrick Gannon, president of the standards group
OASIS. Although it is endorsed by special interest groups like Covisint (an
automotive industry B2B exchange), ACORD (an insurance industry organization)
and HR-XML (focused on human resources transactions), questions remain about the
level of ebXML's market acceptance.
''While ebXML started with enormous customer feedback, it has not progressed
as well as UDDI, where real products have come out,'' claimed Siva Darivemula,
market manager, WebSphere strategic business initiatives at IBM, and the former
president of UDDI.org.
Order in the court
In the real world, transactions need to be
secure, manageable and reliable. And to make Web services useful for businesses,
there needs to be a way to codify business rules to build the Web services
equivalent of applications. These requirements are far from unique to Web
But they are likely to be far more complex. ''One of our biggest challenges
for Web services today is how to authenticate the cardholder seamlessly, which
requires directories to talk to directories,'' said Simon Pugh, vice president of
infrastructure, standards and alliances for credit-card network MasterCard.
With Web services, the security and business logic management functions
traditionally performed at the operating system, application or database levels
must now be managed in the free space environment of the Internet. The challenge
is analogous to state management in the Web's early days, where responsibility
was assumed by application server middleware based on Java, Microsoft or other
The difference this time is that the standards cannot be driven by the Java
Community Process or Microsoft alone, because Web services are supposed to be
multivendor. Compounding the challenge is the possibility that, with Web
services, the application logic processing and data access authorizations might
be handled on a chain of servers across different organizations and platforms.
While some transactions might be conventional RPCs, others may require
longer-lived processes that cannot be managed by simple concepts of state
Not surprisingly, the Web services standards land rush is currently centered
in the gray areas of transaction management, process flow, coordination and
security. Of these functions, security standards are the furthest along because
consensus is gathering around two key standards: Security Assertion Markup
Language (SAML) and WS-Security.
Battening down the hatches
SAML provides the authorization and
authentication functions required for many Web services security functions, and
it enables capabilities like single sign-on. With Version 1.0 finalized last
spring, SAML provides digitally signed tokens to the recipient of a Web services
request. These tokens can be restricted in a variety of ways. For example, they
can carry firm expiration times and selective authorizations for different
portions of the message -- features that may be useful given the Web's latency
and the fact that responses to a Web services request may require participation
from more than one party.
Complementing SAML is WS-Security, a framework that does not actually enforce
security policies per se, but specifies what security technologies (such as
Kerberos or PKI) are to be employed to perform those functions. OASIS is just
beginning to tackle this specification, a job that could prove challenging.
''We will probably limit ourselves to the basics, not on the semantics of how
to perform security,'' noted Hal Lockhart, a member of the OASIS joint security
committee and W3C liaison. ''This technical committee won't be the end-all for
Web services security; it's a first step.''
Like any work in progress, Web services security has plenty of rough edges.
Proposals in many areas, like encryption and authorization, still have critical
gaps. Current XML Encryption and XML Signature proposals continue to lack specs
that prevent corruption of encrypted data and signatures as they pass through
the various parsers used by each party in a multi-party transaction.
Then there are issues like what levels of security standards should cover.
For example, there is an ongoing debate regarding whether security policy
headers, like those spelled out in the proposed XACML standard, are necessary,
and whether the concept must also cover content ownership and access -- a key
concern for publishers who routinely deal with intellectual property rights
issues in their businesses.
''We need a clear distinction because overlapping standards could mean chaos,''
said Chet Ensign, a spokesperson for the online publisher Lexis/Nexis, who
mentioned the need to clarify intellectual property rights at a recent Web
services security forum organized by OASIS and the W3C.
According to OASIS' Lockhart, questions of security policy and digital rights
management might be too hot to handle for now. ''We are unsure what will become
part of the long-term agenda,'' he said. ''The current thinking is that digital
rights management might be too specific for the types of documents exchanged via
Where's the beef?
The heart of any business application is the
business logic -- the business rules, interactions and workflows that
represent how users work with the system and how business processes are
automated. If applications require the processing of transactions, it is
necessary to take protective measures that ensure that completed transactions
are acknowledged and interrupted transactions are rolled back. In scenarios
where several business processes are integrated, a traffic cop or broker is
necessary to ensure that the interactions follow existing business rules and
In conventional applications, all of these services are typically managed
within the application, database, or a third-party integration broker or
messaging system that performs these tasks using its own proprietary
technologies. However, the open-air nature of Web services rules out the use of
proprietary technologies, especially when multiple players, organizations and
platforms are involved.
The flexibility of Web services makes business process integration and
coordination more complex than typical inside-the-firewall EAI scenarios. While
Web services could include conventional RPCs against known systems, it could
also involve more complex, longer-duration, asynchronous transactions that must
factor in the latencies of the Internet as well as scenarios involving multiple
parties whose identities might not be known until runtime or later. In these
scenarios, conventional RPC mechanisms, such as two-phase commits, are no longer
Furthermore, measures such as ensuring authenticity, acknowledgement,
rollbacks and completion grow more critical when they are conducted outside the
protective cocoons of conventional transaction systems.
For example, a procurement request might involve not only a buyer and seller,
but third parties like credit and transportation providers. Additionally, the
transaction may or may not be instantaneous. And even if the original service
request sounds simple, providing assurance that the service request was
answered, in an environment where multiple organizations inside and outside the
firewall are involved, might trigger a series of transactions that could be
interrupted if one link in the chain -- such as the ability to get financing,
delivery on the requested date or even the transmission of an acknowledgement --
Among the questions to be answered: Can the identities of all parties be
verified, and are they authorized to make or process the service requests? If
any link in the chain is broken, are there business rules specifying alternate
options and do transactions have to be rolled back? If they have to be rolled
back, to what point? And is there any way to perform all these assurances in a
non-proprietary way so that everyone involved can decipher the service
requests and responses?
A number of organizations whose memberships overlap, have jumped into the
fray, proposing a wide array of complementary and competing standards proposals.
It starts with tags for defining services supporting conventional RPC
synchronous transactions and longer-duration asynchronous transactions. That is
complemented with an array of proposals addressing business processes, including
process modeling that offers tags for defining business processes; workflow
languages that chain related activities into business processes; and
choreography, a function that addresses the integration brokering role
traditionally performed by EAI tools and messaging middleware inside the
There are numerous competing proposals for process definition languages,
including BPML, developed by BPMI.org, and XML Process Definition Language
(XPDL), sponsored by the Workflow Management Coalition. Then there are languages
specifying business collaboration, such as the Business Transaction Protocol
(BTP), directed by OASIS, and ebXML BPSS, managed by UN/Cefact. And there are
proposals for choreographing all these processes, such as Web services
Choreography Interface (WSCI), which the W3C has agreed to consider.
Amid all the chatter, IBM, Microsoft and BEA unilaterally trumped their own
''better'' solution, the awkwardly named Business Process Execution Language For
Web Services (BPEL4WS). This framework contains three proposed specs, including
Business Process Execution Language (BPEL), a workflow language that converges
earlier proposals from IBM and Microsoft; WS-Transaction, which defines services
for conventional RPC and long-running transactions; and WS-Coordination, which
provides the choreography.
''With Microsoft and IBM, we saw partners that could broaden the appeal and
technical input of the work we had been doing,'' said John Kiger, director of Web
services marketing at BEA, which co-developed BTP, BPML and WSCI.
Many groups with rival proposals have ramped up the spin control, claiming
the IBM/Microsoft/BEA proposal validates their original bright ideas.
''BPEL is very close to BPML,'' said Ismael Ghalimi, chairman of BPMI.org and
cofounder of workflow software vendor Intalio Inc., San Mateo, Calif., who
claims that while the syntaxes are different, the underlying technology and
structures are the same. ''Future extensions of BPEL are already covered by
BPML,'' he added.
Countered BEA's Kiger, ''We did not publish any blueprints of where to go with
Who's on first?
The question to be answered is whether the
standards process is open and democratic, or being hijacked by back-room deals
that drive the public agenda. MasterCard's Pugh voiced concern that while the
WS-Security proposals are a small step forward, he still perceives it 'as too
much of an IBM/Microsoft initiative.'
Responded OASIS' Gannon:''SAML [a complementary proposal] emerged as a result
of 32 vendors who submitted their own ideas and converged them.''
And given the necessity for standards groups rather than vendor consortia to
drive the technology framework, figuring out who is responsible for what is
almost as challenging as deciphering all the competing and complementary
standards proposals themselves.
While the W3C might seem the logical place for standards-making, in reality,
a growing array of technology organizations are laying claim to approving
standards, defining testbeds or functioning as moral intermediaries. A sampling
of the groups entering the fray besides the W3C include OASIS, a group first
formed to promote SGML (the grandfather of HTML and XML); the Object Management
Group (OMG), which seeks to ensure that proposed standards are compatible with
its Model-Driven Architecture initiative; the Open Applications Group, which
focuses on application integration and B2B collaboration; and the Distributed
Management Task Force, which is lobbying for Web services standards covering
remote systems administration.
The lure of Web services is the promise of interoperability and the
flexibility of the services-oriented architecture. Given that technology
development is still in its infancy, the wish lists for standards remain
diverse, ranging from digital access rights for intellectual property to
vertical industry-specific tags and meta-directory standards. Nonetheless,
reality may start seeping in.
''We don't expect the W3C or other standards organizations to solve 100% of
our requirements,'' admitted Stephen Whitlock, security architect for The Boeing
Company, Chicago, at a recent OASIS/W3C security forum.
So much of the standards debate pinpoints functionality that may be ahead of
current user demand. ''The workflow and choreography proposals aren't relevant to
us today,'' noted Galileo's Zwart. ''Maybe, when we go down the road and push
'travel-related' products such as golf packages, it would be very nice to have a
transaction model to coordinate booking among multiple suppliers,'' he said.
Not that Galileo's business is not complicated today. For example, the
permutations of booking a single round-trip ticket between two cities can number
up to 10 to the 30th power. But, conceded Zwart, do not confuse convoluted fare
structures with the actual booking process itself.
''Today, the travel industry uses relatively simple, straightforward
transactions,'' he said.