Web Services Framework

for W3C Workshop on Web Services
11-12 April 2001, San Jose, CA USA

Introduction

The beginning of the charter for the W3C XML Protocol
Activity states

“Today, the principal use of
the World Wide Web is for interactive access to documents and applications. In
almost all cases, such access is by human users, typically working through Web
browsers, audio players, or other interactive front-end systems. The Web can
grow significantly in power and scope if it is extended to support
communication between applications, from one program to another.”

The XML Protocol work is the foundation for a Web Service
framework within which automated, decentralized services can be defined, deployed,
manipulated and evolved in an automated fashion. The purpose of this document
is to outline a framework for evolving XML Protocol’s functions. This
framework provides a structure for integration and a foundation for protocols
that will support the needs of such service-oriented applications. The goal is
a scalable, layered architecture, one that can appropriately meet the needs of
both simple and extremely robust high-volume deployments. As with other Web
technologies, the focus is on enabling ubiquitous interconnectivity of entities
and organizations dispersed throughout the world.

While most descriptions of Web based solutions emphasize
their distributed characteristics, their decentralized nature –
they have distinct management and control environments and communicate
across trust domains – has much more impact on architecture of this framework
and the requirements of the underlying protocols. So, we focus our framework
first on supporting application-to-application integration between enterprises having
disjoint management, infrastructure and trust domains.

The focus of this document and the framework it defines is a
model for describing, discovering and exchanging information that is
independent of application implementations and the platforms on which
applications are developed and deployed.

We note that other organizations such as the IETF and
ebXML are tackling a related set of problems, and we are pleased there are already formal liaisons between the W3C XML Protocol Working group and its
counterparts in both ebXML and IETF. We hope and expect that the realization of
this framework will embody the best ideas from all of these sources, and yield
a common framework and supporting components. This integration and convergence
is essential for realizing the benefits of cross-enterprise, global application
integration.

Why Have a Framework?

A common framework identifies specific functions that need
to be addressed in order to achieve decentralized interoperability. It does not
determine the particular technologies used to fulfill the functions but rather
divides the problem space into sub-problems with specified relationships. This
functional decomposition allows differing solutions to sub-problems without
overlaps, conflicts or omitted functionality. This is not to say that all
applications must offer the same facilities, rather that when a feature is offered
it should fit into a common framework and preferably have a standard
expression.

Conversely, without a common framework and coordinated
development of each component, one almost certainly produces overlaps, which
are likely to make implementations more complex and decrease the probability of
achieving interoperability. Lacking a common framework also forces developers
to guess how various components work in concert. This guessing leads to poor
interoperability and fragility. The framework also allows the development and
adoption of the individual components to happen in parallel and asynchronously,
which has the added benefit of enabling critical pieces to be completed sooner
than others, thereby allowing implementations to proceed. As new components or
modules are completed, they can be applied later, as desired. It is crucial
that these mechanisms remain orthogonal so they can evolve without having to
change the whole system. Finally, a framework supports selections of subsets of
components to provide specific levels of service that scenarios require.

Second, our primary goal is to connect applications on a
worldwide basis. Such applications will necessarily be built in a variety of
programming languages, using a range of operating systems, database, and
middleware technologies. The interoperability we seek can only be achieved when
based on standard data formats and protocols, not APIs. By focusing "on
the wire", we define just the specifications needed for interconnection. We
believe this approach provides the greatest benefit in the shortest time, and
does not impinge of software vendors’ flexibility and enterprise autonomy.

Scenario: Buying Something

Alice wants to rent some linen for her restaurant. So, she
goes to an online catalog of a restaurant supplier. Its catalog
lists the products sold and rented.

Though the website looks like a single application, it is
actually composed of several distinct and interacting web services. One
application handles display of the catalog and form based selection of products.
When Alice selects an item, the catalog app communicates with a generic web
service that manages the catalog, shopper groups and handles the shopping
basket. In this scenario, the catalog display and browsing web front-end uses an
on-line commerce solution for its catalog and shopping functions.

Two different service providers may be supporting the
restaurant supplier’s web site. One hosts and develops the person facing
front-end. The second hosts the on-line commerce application, supporting many
different front-ends and enterprises. This service is not specific to restaurant
suppliers, but can manage online commerce, catalogs and shopping carts for many
different types of customers.

The commerce application accumulates a list of items with
their prices, shipping costs and other details, collects credit card
information, shipping addresses and supports checkout. This service charges a
small fee to its catalog based retail customers per transaction

Actually, this shopping cart service itself depends on yet
another web service, the credit card handling web service, which takes in
credit card information and purchase amounts and either denies the charge or
approves it and returns an approval code. Again, it charges a small fee to its
user, in this case the commerce service.

The credit card service, wanting to create an enforceable
legal record of the approval, does not send approval messages directly back to
the commerce service. Instead, it routes the message via an intermediary such
as the US Post Office, which adds a proof-of-transmission certification and
then forwards the message to the commerce service.

The commerce web service serves many different customers at
once, each with a distinct cart. So do the other services. Some of the messages
are encrypted. Many are digitally signed, in part to prove that the message
originates from an acceptable application and has not been tampered with.
Additionally, the messages contain reliability information and are used in a
protocol that allows either party to detect duplicate messages, retry in the
case of apparently lost messages and detect when communication has failed.

How did the developer of the catalog front-end application
know which messages to send to the shopping cart web service? He read the
documentation, of course, a large element of which was formalized as a WSDL
file. This listed all the messages sent and received by the catalog service. He
also read the process flow description file, learning the sequence of messages
(such as that one message creates a cart, after which a different message adds
items to it, after which a different message causes checkout, etc.).

Similarly, the developer of the shopping cart service read
the documentation, WSDL and process flow descriptions for the credit card
validation service and the proof-of-transmission services.

How did the developer of the catalog service discover the
shopping cart web service? He searched for it in a directory of useful
services. Similarly, Alice, wanting to find a restaurant supplier, found it in
the directory.

The Components

The purpose of the above scenario is to show how an
application can be built out of several communicating web services, allowing
large-granularity, implementation-independent building blocks for application
construction. These distinct web services could be co-located or widely distributed
over the web. Application construction is facilitated by standardized
mechanisms for signature, encryption, guaranteed delivery as well as
standardized forms of machine-readable definitions and contracts.

A key assumption of our framework is that application
integration and assembly occurs over services in different enterprises or
domains of control. We view the standard, defined mechanisms for guaranteed
delivery, security and other qualities of service as providing the glue that supports
applications spanning different domains and infrastructures. We believe that
interface aspects of the framework, like WSDL, will support a common
programming model for assembly applications within an infrastructure and over
different enterprises and domains. Within an infrastructure or domain, the
underlying service implementation may rely on other protocols and services that
plug into the framework. For example, within a domain of control, reliable
messaging may rely on the enterprises existing choice of products, and use a
gateway to map the internal service to remote web services. Similar models may
apply to transactions, security, etc.

In more detail, these functional components are:

Function:Message envelope and controlled extensibility

Specific technology: XML Protocol (under development)

Description: Messages need a facility to delimit the
message, drawing a boundary around the contents of the message and establishing
ground-rules for interpretation of the contents in the context of a message
exchange between parties. Controlled extensibility, of which versioning is a
specific application, must be in the base protocol. Messages suitable for
Internet scale need extensibility in two dimensions: First, because the sender
of a message may have dynamically composed the message from separate parts,
some of which might be unfamiliar to the receiver, the sender must be able to
tag the parts to distinguish those whose processing by the receiver is
mandatory versus optional. Second, because a sender may create a final message
by routing a starting message through one or more intermediate processors
(actors) that modify it, the sender must be able to distinguish those parts
that are intended for the final receiver from those parts intended for an
intermediate processor.

Used: Base for all XML messaging

Function:Binary Attachments

Specific Technology: TBD.

A message may have binary components that are expensive to
convert to and from valid XML forms such as Bin.Base64. A binary attachments
specification describes how to associate such or other resources with a
message, possibly in the same transmission unit. This model may also support passing binary attachments by
URL reference. This enables only the services of a multi-step flow that need to
attachment to receive it, using a service interface.

Used: Large binary objects (no example in the
scenario).

Function:Message ExchangeakaRouting

Specific Technology: TBD.

A message sent from party A to party B, possibly through
intermediary parties I1, I2, I3 etc., possibly
requiring a response, must have some means of designating the parties and
providing an identifier to the message to enable the sender to correlate the
reply to the sent message. The model for intermediaries may support direct
identification of the intermediaries, or a description of the type of service
that a selected intermediary may perform.

Used: All messages, potentially.

Function:Message Correlation

Specific Technology: TBD

Description: Messages may be related to each other by
being elements of a single application-level protocol instance and need a
mechanism for correlation. This requires identification beyond just the
individual message, but also the larger protocol instance and possibly the
protocol type.

Used: All shopping cart messages related to the same
cart instance are correlated. The approval or denial of a credit card charge is
correlated to the request.

Function: Guaranteed Message Exchange

Specific Technology: TBD

Description: In the exchange of messages,
individually or as part of a long-running process, the communicating parties
benefit from certain delivery guarantees. The receiver of a message would like
to detect duplicate copies of the same message, preferably allowing some bounds
on the storage that may be required for this function without compromising the
effectiveness of the detection. The sender would like to determine when a
message has definitely been received by the destination party. The combinatorics
of error handling, and hence, application complexity, are reduced to the degree
that (a) ambiguity over the receipt status of a message is eliminated and (b)
both parties to a message are guaranteed the same view of the status of the
communication.

There may be several levels of
message guarantees. For example, some of these might include 1) At-Least
Once for queries, 2 ) At Most Once, for some update modes, and 3) Exactly
Once.

Used: The catalog application uses guaranteed message
exchange when it communicates with the shopping cart web service, ensuring that
no items or steps are lost or duplicated. Similarly, the shopping cart web
service uses guaranteed communication to the credit card service.

Function:Digital Signature

Specific Technology: XML Dsig

Description: Digital signatures, applied to whole
messages or distinct parts, allow the receiver of a message to authenticate the
identity or other specific characteristics of the sender as well as to verify
that the message has not been altered after composition. The mechanism to apply
a digital signature should be independent of specific signature technology and
is separate from any protocols or techniques used to verify signatures, manage
keys or determine authorizations.

Used: Messages to the credit card service prove that
they originate from the shopping cart service and have not been tampered with.

Function:Encryption

Specific Technology: XML Encryption (in process)

Description: Encryption allows the sender of a
message to make whole messages or parts unreadable except by selected,
privileged parties. The mechanism to apply encryption should be
independent of specific encryption technology and is separate from any
protocols or techniques used to manage keys.

Used: Communication with the credit card service is
encrypted. Perhaps communication between the catalog application and the
shopping cart service is also.

Function:Transactions and Activities

Specific Technology: TBD

Description: Transactions allow parties to a
control the execution, completion and visibility of sequences of operations.
The “Two Phase” model of traditional transaction processing provides a useful
metaphor. We believe that the realization in multi-party web services may
support this metaphor, but the underlying implementation will be significantly
different due to the fact that web service transactions span transaction
infrastructure and models, domains of control and have duration far longer than
tradition models support. We also expect that more flexible process,
compensation and version based transaction schemes will be needed for web
services.

Used: Not used in the example scenario.

Function:Service Description

Specific Technology: WSDL

Description: A Service Description names and lists
the messages that may be sent and received by a web service, both abstractly
and by concrete syntax, identifies the protocols by which they may be
exchanged, lists one or more logical ports associated with the service and
binds those ports to one or more addresses. Preferably, the service description
notation is independent of any particular implementation technology, message
protocol and encoding. In addition, these parts should be separable, allowing
for incomplete service descriptions and for a more complete description to be
created by reference to a less complete one, plus specifying details.

Used: The shopping cart, credit card and
proof-of-transmission services are all formally described using this.

Function:Process Flow Contract Description

Specific Technology: TBD

Description: Enriching a Service Description, the
external contract of a web service may describe the valid sequences of
messages, that is, which messages initiate specific business processes, which
may follow which in each direction, and which are terminal. Preferably, a flow
orchestration language allows composition of a contract by reference to several
other contracts.

Used: The shopping cart, credit card and
proof-of-transmission services are all formally described using this.

Function:Inspection.

Specific Technology: TBD

Description: Inspection is a process or protocol
allowing one to, given an identifier of a resource such as a web service, to
obtain metadata about that resource, metadata such as its service description
and process flow orchestration contracts.

Used: Not used in the example scenario, but one could
inspect any of the services and locate their descriptions by this mechanism.
Additionally, a web crawler might assemble a directory of services by using
inspection.

Function:Discovery

Specific Technology: UDDI

Description: Discovery is a protocol by which one can
obtain identifiers (and perhaps other data) about web services based on
characteristics of the services.

Used: Finding the services, finding the restaurant
supplier.

Three Stacks

These components of course are not unrelated. In fact, they
can be organized into three stacks: wire format (or exchange format),
description and discovery. It is also the case that some stacks depend on
others. For example, the wire stack will provide the basis for the discovery
and description stacks. Thus, the “discovery” function may itself be a web
service accessed through the wire stack.

Wire – those pieces that represent what is sent during a
given exchange, the combination of the data, the envelope and all other
metadata necessary for the successful transmission of a message.

Message envelope and controlled extensibility

Message Exchange aka Routing

Guaranteed Message Exchange

Business (Long-Running) Transactions

Two-phased Transactions

Digital Signature

Encryption

Description – the collection of specifications that provide
the formal definition of the format, use, or application, of the specs in the
“Wire” stack.

XML Schemas

Service Description

Process Flow Orchestration

Note that the description framework is modular: the
offerings are both layered and ordered. Each technology is built on the ones
above, and simpler ones provide useful function by themselves. Therefore, we
anticipate that schemas and WSDL will be deployed first to provide descriptions
for individual messages and message pairs. Over time, tools will become
available to support the increasingly rich descriptions enabled by the other
standards.

Discovery – those specs that provide a means for manual or
automated searching and discovery of the components in the other two stacks.