1 Introduction
| Editorial note | |
| dbooth editing this section. The previous "Contract with the Reader" has been
merged into this section. |
1.1 Purpose of the Web Service Architecture
Web services provide a standard means of interoperating between different software
applications, running on a variety of platforms and/or frameworks. This document (WSA) is
intended to provide a common definition of a Web service, and define its place within a
larger Web services framework to guide the community.
The WSA provides a model and a context for understanding Web services and the
relationships between the various specifications and technologies that comprise the WSA.
The WSA promotes interoperability through the definition of compatible protocols. The
architecture does not attempt to specify how Web services are implemented, and imposes no
restriction on how services might be combined. The WSA describes both the minimal
characteristics that are common to all Web services, and a number of characteristics that
are needed by many, but not all, Web services.
The WSA integrates different conceptions of Web services under a common "reference
architecture". There isn't always a simple one to one correspondence between the
architecture of the Web and the architecture of existing SOAP-based Web services, but
there is a substantial overlap.
We offer a framework for the future evolution of Web services standards that will promote
a healthy mix of interoperability and innovation. That framework must accommodate the edge
cases of pure SOAP-RPC at one side and HTTP manipulation of business document resources at
the other side, but focus on the area in the middle where the different architectural
styles are both taken into consideration.
1.2 Intended Audience
This document is intended for a large and diverse audience. Expected readers include
users and creators of individual Web services, Web service specification authors, and others.
1.3 Document Organization
This document provides introductory overview material followed by normative material.
The body of the architecture is presented as a set of core concepts and key relationships
between them. A core concept is usually a noun, but does not have to be, and the
relationships between conncepts are usually predicates, i.e., verbs. Both noun-style and
verb-style concepts are present in the architecture, the latter playing a prominent role
in the relationships between concepts.
A primary goal of the concepts
section is to provide a basis for measuring conformance to the
architecture. For example, the resource concept states
that resources have identifiers (in fact they have URIs). Using this assertion as a basis,
we can measure conformance to the architecture of a particular resource by looking for its
identifier. If, in a given instance of this architecture, a resource has no identifier,
then it is not a valid instance of the architecture.
While the concepts and relationships
represent an enumeration of the architecture, the stakeholders'
viewpoints approaches from a different perspective: how the architecture meets
the goals and requirements. In this section we elucidate the more global properties of the
architecture and demonstrate how the concepts actually
achieve important objectives.
A primary goal of the Stakeholder's Perspectives
section is to relate the actual architecture with the requirements of the architecture,
especially as outlined in the Web services requirements [WSA Reqs] document.
For example, in the 3.14 Web service manageability section we show how the
management of Web services is modeled within the architecture. The aim here is to
demonstrate that Web services are manageable and which key concepts and features of the
architecture achieve that goal. In this case, manageability is realized by showing a link
between the concept of a physically deployed
resource and the abstract concept it realizes (such as a Web service).
Management of such deployed resources then leads to management of Web services
themselves.
The key stakeholder's viewpoints supported in this document reflect the major goals of
the architecture itself: interopability, extensibility, security, Web integration,
implementation and manageability.
Where appropriate, the WSA also identifies candidate technologies that have been
determined to meet the functionality requirements defined within the architecture.
1.4 Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in [RFC 2119].
1.5 What is a Web service?
There are many things that might be called "Web services" in the world at large. However, for the purpose of this Working Group and this architecture, and without prejudice toward other definitions, we will use the following definition:
[Definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.]
1.5.1 Agents and Services
A Web service is viewed as an abstract notion that must be implemented by
a concrete agent. (See Figure 1.) The agent is the concrete entity (a piece
of software) that sends and receives messages, while the service is the abstract set of
functionality that is provided. To illustrate this distinction, you might implement a
particular Web service using one agent one day (perhaps written in one programming
language), and a different agent the next day (perhaps written in a different
programming language). Although the agent may have changed, the Web service remains the same.
1.5.2 Requester and Provider
The purpose of a Web service is to provide some functionality on behalf of its owner --
a person or organization, such as a business or an individual. The provider
entity is the person or organization that provides an appropriate agent to implement a
particular service. (See Figure 1: Basic Architectural Roles.)
A requester entity is a person or organization that wishes to make use of a provider
entity's Web service. It will use a requester agent to exchange messages
with the provider entity's provider agent. In order for this message
exchange to be successful, the requester entity and the provider entity must first agree
on both the semantics and the mechanics of the message exchange.
1.5.3 Service Description
The mechanics of the message exchange are documented in a Web service
description (WSD). (See Figure 1.) The WSD is a machine-processable
specification of the Web service's interface. It defines the message formats, datatypes,
transport protocols, and transport serialization formats that should be used between the
requester agent and the provider agent. It also specifies one or more network locations
("endpoints") at which a provider agent can be invoked, and may provide some
information about the message exchange pattern that is expected.
1.5.4 Semantics
The semantics ("Sem" in Figure 1) of the message exchange
represents the "contract" between the requester entity and the provider entity
regarding the purpose and consequences of the interaction. It also includes any
additional details on the mechanics of the message exchange that are not specified in
the service description. Although this contract represents the overall
agreement between the requester entity and the provider entity on how and why their
respective agents will interact, it is not necessarily written or explicitly negotiated.
It may be explicit or implicit, oral or written, machine processable or human oriented.
While the service description represents a contract governing the mechanics
of interacting with a particular service, the semantics represents a
contract governing the meaning and purpose of that interaction.
1.5.5 The Role of Humans
Although one of the main purposes of Web services is to automate processes that might
otherwise be performed manually, humans still play a role in their architecture and use,
notably in two ways:
Humans need to agree on the semantics and the service description. Since a human
(or organization) ultimately is the legal owner of any Web service, people must
either implicitly or explicitly agree on the semantics and the service description
that will govern the interaction.
Often this agreement will be accomplished by the provider entitity publicizing and
offering both the semantics and the service description as take-it-or-leave-it
"contracts" that the requester entity must accept unmodified as conditions
of use. However, nothing in this architecture prevents them from reaching agreement
by other means. For example, in some situations, the service description (excepting
the network address of the service) may be defined by an industry organization, and
shared by many requester and provider entities. In other situations, it may
originate from the requester entity (even if it is written from provider entity's
perspective).
Humans create the requester and provider agents (either directly or indirectly).
Ultimately, humans must ensure that these agents implement the terms of the
agreed-upon service description and semantics. There are many ways this can be
achieved, and this architecture does not specify or care what means are used. For
example:
an agent could be hard coded to implement a particular, fixed service
description and semantics;
an agent could be coded in a more general way, and the desired service
description and/or semantics could be input dynamically; or
an agent could be created first, and the service description and/or semantics
could be produced from the agent code.
Regardless of the approach used, from an information perspective both the semantics
and the service description must be somehow be input to, or embodied in, both the
requester agent and the provider agent before the two agents can interact.
Figure 1: Basic Architectural Roles.
| Editorial note | |
| dbooth: Not sure how we should label the figures. Also, Figure 1 may need to be resized. |
1.6 Architectural Style
1.6.1 Interoperability Architecture
The Web services architecture is an interoperability architecture it
identifies those global elements of the global Web services network that are required in
order to ensure interoperability between Web services. It is not intended to be an
architecture for individual Web services; the structure and implementation of these is
inherently private and is left to the discretion of the developers of these. However, in
order to ensure interoperability, certain concepts, relationships and constraints are
important; and this architecture identifies those.
The major goals of the architecture are outlined in the Web Services Architecture
Requirements document [WSA Reqs]. These goals are to promote
interoperability between Web services,
integration with the World Wide Web,
reliability of Web services,
security of Web services,
scalability and extensibility of Web services, and
manageability of Web services.
The role of this architecture is to provide a global perspective on the networked
service architecture. Other specifications, such as [SOAP 1.2 Part 1] and
[WSDL 1.2 Part 1] give detailed recommendations for specific requirements. This
architecture is intended to show how these, and other related, technologies fit together
to deliver the benefits of Web services.
Some non-goals of the architecture include:
to prescribe a specific programming model or programming technology
to constrain the internal architecture and implementation of specific Web services
to demonstrate how Web services are constructed
to be specific about how messages or other descriptions are formatted
to determine specific technologies for messaging, discovery, choreography etc.
1.6.2 Service Oriented Architecture
The Web architecture and the Web Services Architecture (WSA) are instances of a Service
Oriented Architecture (SOA). To understand how they relate to each other and to closely
related technologies such as CORBA, it may be useful to look up yet another level and
note that SOA is in turn a type of distributed system. A distributed system, consists of
discrete software agents that must work together to implement some intended
functionality. Furthermore, the agents in a distibuted system do not operate in the same
processing environment, so they must communicate by hardware/software protocol stacks
that are intrinsically less reliable than direct code invocation and shared memory. This
has important architectural implications because distributed systems require that
developers (of infrastructure and applications) consider the unpredictable latency of
remote access, and take into account issues of concurrency and the possibility of
partial failure. [Samuel C. Kendall, Jim Waldo, Ann Wollrath and Geoff Wyant, "A Note On Distributed Computing"].
An SOA is a specific type of distributed system in which the agents are
"services". For the purposes of this document, a service is a software agent
that performs some well-defined operation (i.e., "provides a service") and can
be invoked outside of the context of a larger application. That is, while a service
might be implemented by exposing a feature of a larger application (e.g., the purchase
order processing capability of an enterprise resource planning system might be exposed
as a discrete service), the users of that server need be concerned only with the
interface description of the service. Furthermore, most definitions of SOA stress that
"services" have a network-addressable interface and communicate via standard
protocols and data formats.
Figure 2, Generic Service Oriented Architecture Diagram 
The description of a service in a SOA is essentially a description of the messages that
are exchanged. This architecture adds the constraint of stateless connections, that is
where the all the data for a given request must be in the request.
| Editorial note | |
| Put in a good word about the Semantic web and semantics in general here |
In essence, the key components of a Service Oriented Architecture are the messages that
are exchanged, agents that act as service requesters and service providers, and shared
transport mechanisms that allow the flow of messages. In addition, in public SOAs, we
include the public descriptions of these components: descriptions of the messages,
descriptions of the services and so on. These descriptions may be machine processable,
in which case they become potential messages themselves: for use in service discovery
systems and in service management systems.
1.6.3 SOA and REST archictures
The World Wide Web is a SOA that operates as a networked information system that
imposes some additional constraints: Agents identify objects in the system, called
"resources," with Uniform Resource Identifiers (URIs). Agents represent,
describe, and communicate resource state via "representations" of the resource
in a variety of widely-understood data formats (e.g. XML, HTML, CSS, JPEG, PNG). Agents
exchange representations via protocols that use URIs to identify and directly or
indirectly address the agents and resources. [Web Arch]
An even more constrained architectural style for reliable Web applications known as
"Representation State Transfer" or REST has been proposed by Roy Fielding and
has inspired both the TAG's Architecture document and many who see it as a model for how
to build Web services [Fielding]. The REST Web is the subset of the WWW in
which agents are constrained to, amongst other things, expose and use services via
uniform interface semantics, manipulate resources only by the exchange of
"representations", and thus use "hypermedia as the engine of application state."
The scope of "Web services" as that term is used by this Working Group is
somewhat different. It encompasses not only the Web and REST Web services whose purpose
is to create, retrieve, update, and delete information resources but extends the scope
to consider services that perform an arbitrarily complex set of operations on resources
that may not be "on the Web." Although the distrinctions here are murky and
controversial, a "Web service" invocation may lead to services being performed
by people, physical objects being moved around (e.g. books delivered).
We can identify two major classes of "Web services":
REST-compliant or
"direct resource manipulation" services in which in which the primary purpose
of the service is to manipulate XML representations of Web resources using the a
minimal, uniform set of operations operations,
"distributed object" or
"Web-mediated operation" services in which the primary purpose of the service
is to perform an arbitrarily complex set of operations on resources that may not be
"on the Web", and the XML messages contain the data needed to invoke those
operations.
In other words, "direct" services are implemented by Web servers
that manipulate data directly, and "mediated" services are external code
resources that are invoked via messages to Web servers.
| Editorial note | |
| Lots of open terminology issues here, such as what we call these two types of
services, and whether the "Web service" is the interface to the external
code or the external code itself. |
Both classes of "Web services" use URIs to identify resources and use Web
protocols and XML data formats for messaging. Where they fundamentally differ is that
"distributed object" (editors' note: or "mediated services") use
application specific vocabularies as the engine of application state, rather than
hypermedia. Also, they achieve some of their benefits in a somewhat different way. The
emphasis on messages, rather than on the actions that are caused by messages, means that
SOAs have good "visibility": trusted third parties may inspect the flow of
messages and have a good assurance as to the services being invoked and the roles of the
various parties. This, in turn, means that intermediaries, such as firewalls, are in a
better situation for performing their functions. A firewall can look at the message
traffic, and at the structure of the message, and make predictable and reasonable
decisions about security.
In REST-compliant SOAs, the visibility comes from the uniform interface semantics,
essentially those of the HTTP protocol: an intermediary can inspect the URI of the
resource being manipulated, the TCP/IP address of the requester, and the interface
operation requested (e.g. GET, PUT, DELETE) and determine whether the requested
operation should be performed. The TCP/IP and HTTP protocols have a widely supported set
of conventions (e.g. known ports) to support intermediaries, and firewalls, proxies,
caches, etc. are almost universal today. In non-REST [Ed. note: or "distributed
object" or "mediated" ] but XML-based services, the visibility comes from
the fact that XML is the universal meta-format for the data. Intermediaries can be
programmed or configured to use the specifics of the SOAP XML format, standardized SOAP
headers (e.g. for encryption, digital signature exchange, access control, etc.), or even
generic XPath expressions to make routing, filtering, and cacheing decisions. XML-aware
firewall and other "edge appliance" products are just coming to market as of
this writing.
1.7 Web Service Technologies
Web service architecture involves many layered and interrelated technologies. There are
many ways to visualize these technologies, just as there are many ways to build and use
Web services. Figure 3 provides one illustration of some of these technology families.
Figure 3: Stack Diagram.
Marketing documents from Web services vendors often contain a three-part diagram to show
how the different Web services "standards" relate to one another: WSDL describes
the format SOAP messages, and UDDI serves as a discovery service for the WSDL
descriptions. The problem with such diagrams is that they don't convey the multiple
dimensions of the Web services standards "space" and can't easily be extended to
handle new standards, e.g. for security, management, choreography, and so on. In order to
show the big picture of the Web services architecture as we envision it, the picture needs
to be somewhat more complex.
First and foremost, XML is the "backplane" of the WSA. One can imagine Web
services that don't depend on the SOAP envelope framework or processing model, or that
don't employ WSDL to describe the interaction between a service and its consumers, but XML
is much more fundamental. It provides the extensibility and vendor, platform, and language
neutrality that is the key to loosely-coupled, standards-based interoperability that are
the essence of the Web services value proposition. Furthermore, XML helps blur the
distinction between "payload" data and "protocol" data, allowing
easier mapping and bridging across different communications protocols, which is necessary
in many enterprise IT infrastructures that are built on industrial-strength but
proprietary components. Thus, the "base technology" of the WSA consists of some
key XML specifications, including XML 1.x, XML Schema Description Language and the
XML Base specification. Note that we do not rely on all XML technologies; for
example, we do not rely on XML DTDs, in the architecture.
This leads to the next key concept in the WSA: services are invoked and provide results
via messages that must be exchanged over some communications medium. The WSA encompasses a
wide, almost infinite variety of communications mechanisms: HTTP (the dominant protocol of
"the Web"), other Internet protocols such as SMTP and FTP, generic interface
APIs such as JMS, earlier distributed object protocols such as IIOP, and so on. In
principle, Web services invocation and result messages could be passed around by
"sneakernet", RFC 1149-compliant carrier pigeons, or mechanisms that have not
yet been invented. WSA says almost nothing about this communication layer other than it
exists -- it does not specificy that it be at any particular level of the OSI reference
architecture protocol stack, and allows Web services messages to be "tunnelled"
over protocols designed for another purpose.
WSA does have quite a bit to say about the messages themselves, if not about the
mechanism by which they are communicated. SOAP is the key messaging technology in the WSA:
while very simple information transfer services can be implemented without SOAP, secure,
reliable, multi-part, multi-party and/or multi-network applications are much easier to
build if there is a standard way of packaging the messaging information in a protocol
neutral way. This also allows the messaging infrastructure (which may be specialized
hardware, SOAP intermediaries, or code libraries called by the ultimate recipient of a
SOAP message) to provide authentication, encryption, access control, transaction
processing, routing, delivery confirmation, etc. services. SOAP's envelope (and
attachment) structure and header / processing model have proven to be a very robust and
powerful framework within which to do this.
Interoperability across heterogenous systems requires a mechanism to allow the precise
structure and data types of the messages to be commonly understood by Web services
producers and consumers. WSDL is an obvious choice today as the means by which the precise
description of Web services messages can be exchanged.
| Editorial note | |
| Obviously we have open issues with respect to whether description mechanisms such
as shared code "qualify" here. |
In the future, more sophisticated description languages that handle more of the
*semantic* content of the messages are likely to become technologically viable, and such
languages (perhaps based on RDF and OWL) will fit well in the WSA framework.
Beyond the description of individual messages such as WSDL provides, the WSA envisions a
variety process descriptions: the process of discovering service descriptions that meet
specified criteria, the process of describing multi-part and stateful sequences of
messages, the aggregation of processes into higher-level processes, and so on. This area
is much much clearly defined than other parts of the WSA, but there is much work going on
and the WSA incorporates them at an abstract level.
In addition to specific messaging and description technologies, the architecture also
provides for security and management. These are complex areas that touch on many of the
different levels and technologies deployed in the service of Web services.
