Web services provide a standard means of communication among
different software applications, running on a variety of platforms and/or
frameworks. The architecture presented in this document is intended to promote
interoperability and extensibility among these various applications, platforms
and frameworks in a manner that remains consistent with the architecture of the
Web [7].
This document defines the Web services reference architecture, and where appropriate, identifies candidate technologies that have been determined to meet the functionality requirements defined within the architecture.
The Web services reference architecture identifies the functional components, defines the relationships among those components, and establishes a set of constraints upon each to effect the desired properties of the overall architecture.
[EN: Here's the start of the reworked core concepts section Frank and Katia put together. It still needs the simple intro, and to be reconciled with the glossary. Some of the text is new, and represents proposed changes for review. A final draft will document all changes and differences from the text being proposed by the breakout team. Comments are noted in the text using the prefix of the person's name. ]
The architecture is enumerated as a set of conceptsand their relationships.
The core concepts that form the architecture are laid out in
this section.
The ordering of the concepts in this section is
alphabetical; this should not be understood to
imply any relative importance.
Actor[ KATIA: Legal Entity replaces
“actor” ; reason actor was felt to be close to
“agent” thus confusing]
Summary
A legal entity such as a person or a corporation — may be
the owner of agents that provide or request Web services.
Relationships to other elements
an legal entity may be
an ownerof an agent
an legal entity has a
presence in the physical domain
an legal entity may have
a physical address
an legal entity may have
a telephone number
an legal entity may agree
to a legally binding contract
an legal entity has a
name
Description
Legal entities are represented by agents and Web services.
Legal entities are individuals (i.e., humans) and organizations.
Both are legal entities in that they have the right to enter into
contracts -- which is the critical property from the perspective of
this architecture.
From a architectural perspective, the key difference between an
individual and an organization is that the former has no owner or
shareholders, and that all actions are ultimately rooted in the
actions of humans.
[KATIA] some of us agreed last night to do away with the
“actor” concept and keep only the concept “legal
entity”. So, this draft reflects this.
Summary
An agentis a
program acting on behalf of another person, entity, or process [Web
Arch] .
Relationships to other elements
an agent has an
owner
an agent has an
identifer
Agents are programs that engage in some set of actions as
representatives of other entities. On the Web, for example, agents
can seek information.
Web service agent
Summary
A Web service agent is an agent that implements a service
a Web service agent
isa agent
a Web service agent
implements a service
a Web service agent may be a
service provider
a Web service agent may be a
service requestor
a Web service agent
may be a service provideror a service requestorin different contexts
Description
Web service agents are the computational representatives of
business entities and people in the context of Web services. This
architecture specifically eschews any attempt to govern the
implementation of agents; it is only concerned with ensuring
interopability between systems.
[KATIA]:to make the definitions clear, I created the Web
service agent concept that inherits from agent and has the
additional properties that it provides ro requests a service, and
also that it is the executable component of a service. In the
document, we can use “agent” for Web service agent, for
brevity, as long as we note this abbreviation.
[KATIA] To be consistent with the diagram, I suggest we
simply say an agent “provides” services an agent
“requests” services rather than saying and agent
“may adopt the role of a service provider” (or
requester or bot). We can then have rules that say: an agent that
provides a service isa service provider; an agent that requests a
service isa service requestor; being a service provider and a
service requestor are not mutually exclusive.
Summary
Choreographies define how multiple web services are used
together, specifying the linkages and usage patterns involved. The
linkages between Web Services consist of interactions between those
services implemented by sending messages between those Web
Services, for example by invoking operations as defined in
WSDL.
Relationships to other elements
a choreography is a
description of how one or more services
can be coordinated together to form a coherent whole
a choreography may be expressedin
a choreography
description language
[KATIA]: form the SOA point of view, we can say that a
choreography is a compositie service. In a choreography we also
want to have the notion of workflow, ie the control structures of
how the services that compose the choreography are coordinated
Description
A single web service is limited to accepting a request for
information or the execution of a process and providing the
information or process results in return. Richer functionality can
be provided when multiple web services are used together.
A choreography definition describes the sequence and conditions
which control how the interactions occur. Successful execution of a
choreography should result in the completion of some useful
function, for example: the placement of an order, information about
its delivery and eventual payment.
Summary
Correlation [n.] is the association of matching messages.
Correlation ensures that the agent requesting a service execution
can match the reply with the request, especially when multiple
replies may be possible.
A message identifier is a piece of information that is used to
establish a relationship between one or more messages. A
conversation identifier is used to establish a relationship between
one or more parties that may exchange multiple messages.
Relationships to other elements
correlation is a
feature
correlation is
the association of a specific message in a specific
conversational context.
correlation may be realized
by including message identifiers to enable messagesto be correlated.
Description
Various requirements and higher-level features identified in
this architecture lead to the need for correlation. For example,
asynchronous interactions often require higher-level correlation
between otherwise distinct messages. One implementation of this
concept makes use of message identifiers for correlation itself,
allowing a response to be correlated with the original request. The
message identifier is an identifier that allows the response to be
correlated with the originating request. The sender may also add an
identifier for a service, not necessarily the originating sender,
who will be the recipient of the message (see asynchronous
messaging).
Correlation may be realized by the underlying protocol; it may
be realized by an intermediary between the protocol and the
application, ie specification of a conversation ID header; or it
may be realized by the application. Application uses the identifier
directly and it must be passed thru and available to the
application. The need for the application to do that depends on how
much infrastructure intermediary software is present or not
present.
[KATIA] Correlation is not currently defined in the Glossary. To
me correlation seems very close to orchestration (see definition in
the glossary). Perhaps we should do away with correlation as a
concept. The glossary also defines “collaboration”. It
is a very vague definition, the only purpose of its being included
in the glossary seems to be to refer to WSCI and BPSS models that
apparently use this word.
Summary
A deployed resource is a resource that exists in the physical
world.
Relationships to other elements
a deployed resource is an
resource
a deployed resource has an
an owner
a deployed resource has
a physical location
a deployed resource may realize
a service
a deployed resource may realize
an agent
a deployed resource may realize
an service description
Description
Deployed resources are resources that exist physically and are
potentially manageable. They are the realization of other elements
of this architecture — the services, the agents and the
descriptions that form the logical aspect of this architecture.
Deployed resources have locations and a physical presence in the
real world — for example, as a set of files on a disk, or an
executing process on a computer.
Deployed resources are the unit of manageability; they have
owners and may have other properties that are subject to
management.
[KATIA]: This tries to capture the constrain the definition of a
resource so as to make it a manageable element. In view of the many
e-mails on the “definition of resource” thread, we
probably need to revisit both the definition of a resource,
deployable resource, and/or define additional concepts, such as
“protocol resource” etc as some people on the thread
are suggesting.
Discovery
Summary
Discovery is the act of locating a machine-processable
description of a Web service that may have been previously unknown
and that meets certain functional criteria. [wsa-glossary]
Relationships to other elements
discovery
is an abstract process
discovery
may
be initiatedby an end useror a Service
agent
discovery
may
be realizedas a discovery
service
discovery
may
be realizedas a direct
interactionbetween service requestorand service provider
discovery
has inputsa set of functional
criteria
discovery
has outputsa set of service
descriptions that match the inputs
Description
There are varius means by which discovery can be performed.
Various entities, e.g. human end users or agents may initiate
discovery. Service requestors may find services and obtain binding
information (in the service descriptions) during development for
static binding, or during execution for dynamic binding. For
statically bound service requestors, using service discovery is
optional, as a service provider can send the description directly
to service requestors. Likewise, service requestors can obtain a
service description from other sources besides a service registry,
such as a local file system, FTP site, URL, or WSIL document.
Discovery Service
Summary
A discovery service is a service that performs
discovery
Relationships to other elements
discovery service
isa service
discovery service
may
be realizedas a search of a set
of descriptions
discovery service
may utilizea service
desription registry
Description
A discovery service searches a set of descriptions that are
either in a registry or distributed throughout the Web.
Registry
Summary
A registry contains service descriptions that service
providers publish.
Relationships to other elements
registry
is a
repository of service descriptions
registry
may
be browsable
registry
may
be queriable
Description
A registry may allow service requestors to browse service
provider descriptions. It may also allow matching requests, i.e.
queries from requestors against stored descriptions from
providers.
[KATIA] I redefined Discovery as an abstract process that can be
realized in various ways, e.g. as a distributed Web search, as a
centralized search of a registry, or as a direct information
exchange between requester and provider. It can be initiated by a
human or an agent (to capture David Booth’s Use Cases). I use
the word “end user” as in the Glossary. We can
mention UDDI as an example of implementation technology for a
service description registry. The new definitions of Discovery,
Discovery Service and Registry allow us to do away with the
controversial concept of Discovery Agency.
Summary
A feature is a subset of the architecture that relates to
a particular requirement or larger scale property. A key aspect of
features is that they may have realizations, possibly within the
architecture itself.
Relationships to other elements
a feature is a
set of related concepts
a feature has a
realization
Description
A feature is a subset of the architecture that relates to a
particular requirement of the architecture. It may be realizedthrough a number of mechanisms, such as
bindings, message exchange
patternsor modules.
For example, asynchronous messaging is a potential
feature of the architecture. As a result of a message, a service
may respond to the requestor or a different party using a separate
message channel that the request. The service must know where to
send the response(s). This is specified in a service identifier The
service identifier can be passed in one of several ways:
- service identifier in message
- service identifier in service definition (a.k.a. WSDL)
- service identifier identified by a URI and retrieved from a 3rd
party
[KATIA] I do not see asynchronous messaging in the Requirements
Document. So, how can we say that a feature relates to
requirements, and give as an example something that is not a
requirement?
Summary
An identifier is a preferably opaque string of
bits that may be used to associate with a resource
Relationships to other elements
an identifier is a
opaque string of bits
an identifier
may be realizedas a URI
an identifier identifies
a resource that is relevant to the architecture
[KATIA] the word “opaque” is meant to capture the
notion/constraint that an identifier does not have a structure
visible to an outside observer
Description
Identifiers are used to identify resources. In the architecture
we use Uniform Resource Identifiersto identify
resources.
We have a strong preference that any concrete realization of
identifiers does not exhibit any structure. The reason is that an
identifier's primary role is to permit multiple references to a
resource to be viewed as equivalent.
[KATIA] Zulah proposed the wording “Manageable
Element” till the term “element” can be clarified
further (ie whether it is a deployable resource or some other
term.
Manageable Element
Summary
A manageable element is a deployed element that is
manageable.
Relationships to other elements
a manageable element
is adeployed element
a manageable element
has a life cycle
a manageable element
has a manageability interface
a manageable element
has descriptionof its manageability interface
Description
Manageable elements expose an interface that permits their state
— especially their life cycle state — to be monitored
and potentially modified. The simplest such modification being to
delete the element.
Manageability Interface
Summary
A manageability interface is a description of ports and their
bindings
Relationships to other elements
a manageability interface
hascontrols
a manageability interface
hasidentificationinformation
a manageability interface
haseventsthat coorespond to
lifecycle
a manageability interface
hasmetrics
a manageability interface
hasstatus
a manageability interface
hasconfiguration
Summary
A message is the basic unit of interaction with Web services.
The architecture defines an interaction between software agents as
an exchange of messages.
Relationships to other elements
a message is a
unit of interaction between agents
a message may be part of
a message exchange pattern
a message has
zero or more message headers
a message has an
message envelope
a message has a
message content
a message has
a message sender
a message may have
a message identifier
a message has
zero or more message
recipients
Description
A message is defined as a construct that can include zero or
more headers, an envelope, data within the envelope and data
external to the envelope. The header part of a message can include
information pertinent to extended Web services functionality, such
as security, transaction context, orchestration information, or
message routing information. The data part of a message contains
the message content or data.
A message represents the data structure passed to a service
during its request, and received from a service during its response
(if any). The structure of messages are defined in service descriptions.
[EN:] Note the recent discussion on XMLP about what constitutes
a message (I guess basically whether or not the header and
associated metadata are considered part of the message or not). We
can certainly base our definition on their once that's
resolved.
Summary
A message exchange pattern is a minimal set of messages,
together with their sender and receivers, that constitutes a single
use of a service.
Relationships to other elements
a message exchange pattern is
a
set of messagesbetween agentsthat corresponds to a single instantiationof a service
a message exchange pattern is
a
feature
a message exchange pattern has
a
unique identifier
a message exchange pattern represents
the life cycle of a messageexchange
a message exchange pattern describes
the temporal and causal relationships, if any, of multiple
messagesexchanged in conformance with the
pattern.
a message exchange pattern describes
the normal and abnormal termination of any message exchange
conforming to the pattern
a message exchange pattern may be expressed in
a choreography
description language
a message exchage pattern
may realizea correlation
a message exchange pattern
may
describe a service invocation
[EN:] I'm not sure an MEP is a core concept, maybe it's more of
a quality, capability, or constraint? Also not sure an MEP has an
identifier?
Description
A Message Exchange Pattern (MEP) is a template that establishes
a pattern for the exchange of messages between agents
Requesters and providers interact using one or more message
exchange patterns (MEPs) that define the sequence of one or more
messages exchanged between them. A service descriptionincludes a
description; such as the form of the message, data types of
elements of the message and message structure information.
The architecture describes Web services support for MEPs that
group basic messages into higher-level interactions.
Summary
A message header is the part of the message that is available to
any potential intermediaries and contains information about the
message, such as its structure and the identity of the service
provider.
Relationships to other elements
a message header is part of
a message
a message header may contain
message routinginformation
a message header may contain
message securityinformation
a message header may contain
message
orchestrationinformation
a message header may contain
a transaction context
Description
The header part of a message can include information pertinent
to extended Web services functionality, such as security,
transaction context, orchestration information, or message routing
information.
Message description language
Summary
A message description language allows the structure of messages
to be described.
Relationships to other elements
a message description language describes
the structure of a message
Description
Summary
A message identifier is an identifierthat uniquely identifies a message.
Relationships to other elements
a message identifier is
a unique identifier
Description
A message may have an identifier. In
the context of Web services we expect to use URIs to represent
message identifiers. Message identifiers allow messages to be
correlatedwithin an extended
transaction; for example, an event message may reference the
original subscription request message.
Message identifiers also support message reliabilityand management and accountabilityof services:
by providing the means to uniquely identify messages in an audit
trail.
Summary
A message recipient is the agent that is intended — by the
message's sender — to consume the message.
Relationships to other elements
a message recipient is a
agent
a message sender consumes
a message
Description
The message recipient is the agent that the sender intends the
message to be consumed by. The message recipient of an agent may be
represented as the agent's identifier in a message envelope;
however, in the case of anonymous or broadcast-style interactions,
the recipient of a message may not be available to the sender.
Summary
A message sender is the agent that originates a message.
Relationships to other elements
a message sender is a
agenta message sender originates
a message
Description
A message sender is the agent that originally caused a new
message to be created and sent to an agent. The message sender of
an agent may be represented as the agent's identifier in a message
envelope; however, in the case of anonymous interactions the
originator of a message may not be available.
Summary
A representationis
a data object that represents or describes a resource state, and is
the vehicle for conveying the meaning of a resource. A resource is
an abstraction for which there is a conceptual mapping to a
(possibly empty) set of representations.
Relationships to other elements
a representation is a
data object
Description
Representations are data objects that represent a resource. A
resource has a unique identifer, whereas a representation is a data
object that represents the resource itself. Note, that a
representation of a resource need not be the same as the resource
itself; for example the resource asociated with the booking state
of a restaurant will have different representations depending on
when the representation is retrieved.
Resources have identifiers but cannot be retrieved —
representations of resources may be retrieved but are typically not
themselves resources.
Summary
A resource is defined by [RFC2396] to be
anything that has an identifier.
Relationships to other elements
a resource is an
entity
a resource has an
an identifier
a resource may have a number
of
representations
Description
Resources form the heart of the Web architecture itself —
the Web is a universe of resources that have URIs as identifiers, as
defined in [RFC2396].
Summary
A service is a set of actions that form a coherent whole
from the point of view of a service
provider
Relationships to other elements
a service
performsa task
a service
may be
realizedby a set of actions
a service has
a service provider
a service has
a service description
a service has
an identifier
a service has
a service semantics
a service
hasan interface
a service
is implemented byan Web service
agent
a service may be invoked by
zero or more service
requestors
a service is invoked by
exchanging messages
a service
hasa service
execution model
Description
A service performs a task and can be realized as a collection of
actions; each action is typically accessed via messages sent from
the service requestor to the service provider. A service may have a
service description, which includes a description of the messages,
their types any implied ordering of messages and the intended
effects of those messages. A service has a service description that
describes the functionality of a service, the service semantics and
the interface of the service, i.e how to interact with the service.
In addition, a service has an execution model.
Summary
Relationships to other elements
a service description is
a description of a service
a service description contains
a description of the service's
interface
a service description may contain
a description of the service's
semantics
a service description may be published in
a registry
a service descriptionmay be retrieved from
a registry
a service description
may be
sent from service providerto
service requestor
a service description is expressedin
a service description
language
Description
A service description contains the details of the interface and
implementation of the service. This includes its data types,
operations, binding information, and network location. It could
also include categorization and other meta data to facilitate
discovery and utilization by requestors. The complete description
may be realized as a set of XML description documents. The service
description may be published to a requestor directly or to a
discovery agency.
Summary
Relationships to other elements
a service provider is
a Web serviceagent
a service provider provides
a set of services
a service provider has
a name
Description
From a business perspective, this is the owner of the service.
From an architectural perspective, this is the agent that provides
the service.
Its role in the client-server message exchange patterns is that
of a server.
Summary
A service requestor is the entity that is responsible for
requesting a service from a service
provider.
Relationships to other elements
a service requestor is
a Web serviceagent
a service requestor requests
a set of services
a service requestor may have
a name
Description
From a business perspective, this is the business that requires
certain function to be satisfied. From an architectural
perspective, this is the agentthat is looking
for and invoking or initiating an interaction with a service. The
requestor role can be played by a browser driven by a person or a
program without a user interface, e.g. another web service.
Its role in the client-server message exchange pattern is that
of a client.
Summary
The semantics of a service is the contract between the
service providerand the service requestorthat expresses the
effect of invoking the service. A service semantics may be
formally described in a machine readable form, identified but
not formally defined or informally defined via an `out of band'
agreement between the provider and the requestor.
Relationships to other elements
a service semantics is
the contract between the service providerand the service requestorconcerning the effects
and requirements pertaining to the use of a service
a service semantics may be identifiedin
a service description
a service semantics may be expressedin
a service description
language
a service semantics describes
the intended effects of using a service
a service semantics describes
the requirements for using a service
a service semantics describes
notable events involved in using a service
a service semantics describes
the relationship between the service
providerand the service
requestor
a service semantics may describe
the quality of service expectations of a service
a service semantics may describe
the message types in a service
Description
Knowing the type of a data structure is not enough to understand
the intent and meaning behind its use. For example, methods to
deposit and withdraw from an account typically have the same type
signature, but with a different effect. Semantics in web services
provide formal documentation of meaning. Contracts describing
semantics may be used in other web service features such as
choreography.
SOAP
Summary
SOAPis a simple
and lightweight XML-based mechanism for creating structured data
packages that can exchanged between network applications.
Relationships to other elements
SOAP is
An example of implementation technologyfor
expressingthe structure of messages
a SOAP package has
an envelope
a SOAP package has
a set of encoding rules for expressinginstances of application-defined data
types.
a SOAP package has
a convention for representing the exchange of messagesand responses.
SOAP has
a set of rules for using SOAP with HTTP.
SOAP may be used with
other message delivery protocols.
Description
SOAP consists of four fundamental components: an envelope that
defines a framework for describing message structure, a set of
encoding rules for expressing instances of application-defined data
types, a convention for representing remote procedure calls (RPC)
and responses, and a set of rules for using SOAP with HTTP. SOAP
can be used in combination with a variety of network protocols;
such as HTTP, SMTP, FTP, RMI/IIOP, or a proprietary messaging
protocol.
SOAP is currently the de facto standard for XML messaging for a
number of reasons. First, SOAP is relatively simple, defining a
thin layer that builds on top of existing network technologies such
as HTTP that are already broadly implemented. Second, SOAP is
flexible and extensible in that rather than trying to solve all of
the various issues developers may face when constructing Web
services, it provides an extensible, composable framework that
allows solutions to be incrementally applied as needed. Thirdly,
SOAP is based on XML. Finally, SOAP enjoys broad industry and
developer community support.
Summary
The fundamental characteristic of a transaction is the ability
to join multiple actions into the same unit of work, such that the
actions either succeed or fail as a unit. Transaction is a
featureof the architecture that supports
the coordination of results or operations on state in a
multi-step interaction.
Relationships to other elements
a transaction is
a feature
a transaction
is the
execution modelof a choreography
Description
Summary
Relationships to other elements
a Web service is
a service
a Web service has
an identifierwhich is in the
form of a URI identifier
a Web service has
a description
Description
A Web service is a software system identified by a URI, whose
public interfaces and bindings are defined and is described using
XML. Its definition can be discovered by other software systems.
These systems may then interact with the Web service in a manner
prescribed by its definition, using XML based messages conveyed by
internet protocols.
At its bare minimum, for a service to be considered a Web
service, a Web service must have a URI and must exchange messages
expressed in XML. It is not required that Web services
have explicit descriptions, or use related technologies such as
SOAP or WSDL; nor is it required that messages be transported using
HTTP as the data transfer protocol.
Of course, Web services that do not use SOAP as the message
packaging and processing framework, and that do not use WSDL to
describe the interfaces and bindings, risk a reduced
interoperability with Web services that DO use these
technologies.
Summary
Relationships to other elements
WSDL is a
exampleof implementation technologyfor service descriptions
WSDL describes
the abstract functionality of a service
WSDL describes
the concrete binding details for SOAP 1.2, HTTP and MIME
Description
WSDLis an XML
document format for describing Web services as a set of endpoints
operating on messages containing either document-oriented or
procedure-oriented (RPC) messages.
WSDL describes Web services starting with the messages that are
exchanged between the service provider and requestor. The messages
themselves are described abstractly and then bound to a concrete
network protocol and message format. A message consists of a
collection of typed data items. An exchange of messages between the
service provider and requestor are described as an operation. A
collection of operations is called a portType. Collections of
portTypes are grouped and called a serviceType. A service
represents an implementation of a serviceType and contains a
collection of ports, where each port is an implementation of a
portType, which includes all the concrete details needed to
interact with the service.
WSDL is sufficiently extensible to allow description of
endpoints and their messages regardless of what message formats or
network protocols are used to communicate. WSDL1.1 describes
bindings for SOAP1.1, HTTP POST, and MIME. WSDL1.2 will add binding
support for SOAP1.2.
Web service definitions can be mapped to any language, object
model, or messaging system. Simple extensions to existing Internet
infrastructure can implement web services for interaction via
browsers or directly within an application. The application could
be implemented using COM, JMS, CORBA, COBOL, or any number of
proprietary integration solutions.
The relationships between concepts in the architecture are laid
out in this section. These relationships represent the core
modeling concepts used in the architecture itself.
The is a relationship
Summary
The X is a Y relationship
denotes the relationship between concepts X and
Y, such that every X is also a Y.
Relationships to other elements
Assuming that X is a Y,
then:
true of
if P is true of Y then P is true of
X
contains
if Y has aP then
X has aQ such that
Qis a P.
transitive
if U is aX then U
is aY
Description
Essentially, when we say that concept Xis a
Y we mean that every feature of Y is also a
feature of X. Note, however, that since X is
presumably a more specific concept than Y, the features of
X may also be more specific variants of the features of
Y.
For example, in the serviceconcept, we
state that every service has an identifier. In the more specific
Web serviceconcept, we note that a Web
service has an identifier in the form of a URI identifier.
Summary
The concept X is described by Y
relationship denotes that Y is an expression of some
language L and that the value of Y is an
instances of X.
Relationships to other elements
Assuming that X is described by
Y, then:
valid
if Y a valid expression of L, then the value
of Y is an instance of concept X
Description
Essentially, when we say that concept Xis
described by Y we are saying that the expression
Y denotes instances of X.
For example, in the service
descriptionconcept, we state that service descriptions are
expressed in a service description language. That means that we can
expect legal expressions of the service description language to be
instances of the service description concept.
Summary
The concept X is expressed in L
relationship denotes that instances of X are values of the
language L.
Relationships to other elements
Assuming that X is expressed in
L, then:
valid
if E a valid expression in L then E
is an instance of concept X
Description
Essentially, when we say that concept Xis
expressed in L we use the language L to
express instances of X.
For example, in the service
descriptionconcept, we state that service descriptions are
expressed in a service description language. That means that we can
expect legal expressions of the service description language to be
instances of the service description concept.
The has a relationship
Summary
The concept X has a Y
relationship denotes that every instance of X is
associated with an instance of Y.
Relationships to other elements
Assuming that X has a Y,
then:
valid
if E is an instance of X then Y is
valid for E.
Description
Essentially, when we say that concept Xhas a
Y we mean that whenever we see an X we should
also see a Y.
For example, in the Web
serviceconcept, we state that Web services have URI
identifiers. So, whenever we the Web service concept is found, we
can assume that the Web service referenced has an identifer. This,
in turn, allows implementations to use identifiers to reliably
refer to Web services. If a given Web service does not have an
identifier associated with it, then the architecture has been
violated.
Summary
The concept X is realized as Y
relationship denotes that the concept X is an abstraction
of the concept Y. An equivalent view is that the concept
X is implemented using Y.
Relationships to other elements
Assuming that X is realized as
Y, then:
implemented
if Y is present, or true of a system, then the concept
X applies to the system
reified
Yis a reification of the concept X.
Description
Essentially, when we say that the concept or feature
X is realized as Y, we mean that
Y is an implementation or reification of the concept
X. I.e., if Y is a valid concept of a system then
we have also ensured that the concept X is valid of the
same system.
For example, in the correlationfeature, we state that message
correlation requires that we associate identifiers with messages.
This can be realized in a number of ways — including the
identifier in the message header, message body, in a service
binding and so on. The message identifier is a key to the
realization of message correlation.
Also need to:
- Validate the list of core concepts and add/remove a appropriate
- Ensure all information is moved into the new sections
- Start to think about diagrams
[EN: I included this by reference, at least for the moment, as the easiest way to do it.]
In this section we examine how the architecturemeets the Web
services requirements. We present this as a series of
stakeholders' viewpoints; the objective being that, for
example, security represents a major stakeholder's viewpoint of the
architecture itself.
|
Editorial note |
|
|
When developing a particular stakeholder's viewpoint, one should
make sure that the concepts discussed are properly documented in
the architecture. |
Goal AG003 of the requirementsidentifies
Web services must be consistent with the current and evolving
nature of the World Wide Web.
This goal can be divided into two sub-goals — relating to
the architectural
principles of the Weband, more pragmatically, relating the
architecture to the various technologies in use.
Critical Success Factor AC011notes that the
architecture should be consistent with the architectural principles
and design goals of the Web. For our purposes we use the
Architecture of the
World Wide Webas our reference for the architecture of the
Web.
Thisidentifies the
architecture of the Web to be founded on a few basic concepts:
agents that are programs that represent people, identification of
resources using URIs representations of resources as data objects
and interaction via standard protocols — most notably of
course HTTP.
Unlike the World Wide
Webin general, it is of the essence that Web services, like
service oriented architectures in general, are essentially
about the provision of action. I.e., whereas the
World Wide Webis a
networked information system, the Web service World Wide Web is
a networked service system: information is exchanged between
Web service agentsfor the purpose
of requesting and provisioning service,
not simply information.
This is a key specialization of the World Wide Webin general; and
it drives a number of the specific features of this architecture.
However, it is also the case that requests for action and the
various possible responses are also information and have
representations.
The key representational requirement of this architecture is
that messages exchanged between Web service agents is encoded in
XML. This is consistent with the general principles of the
World Wide Web.
This architecture also uses the concept of an agentto identify the computational resource actually
involved with Web services. The key properties of agents required
to model Web services are that:
- It is a computational activity
- It has an owner
- It engages in message exchanges with other Web service agents,
those messages counting as equivalent messages between the agents'
owners.
- It uses standard protocols to:
-
- describe the form and semantics of messages
- describe the legal sequences of messages
- The distinction between a service requestor and service
provider is one of the agent's roles; i.e., it is not intrinsic to
the concept of agent that it is bound to be solely a provider or
requestor of services.
However, it is clear that there is a strong correspondence
between a Web service agent and a Web agent. Both are computational
resources that represent people; our definition requires sufficient
detail to be able to account for the greater degree of indirection
expected between Web service agents and Web agents.
A third major distinction between this architecture and the
World Wide Webis that,
for computer programs to be able to interact with other in a
meaningful way, it is necessary to model the semanticsof the information exchanged.
So long as the primary purpose of an agent is to render
information in a way that is immediately meaningful to human eyes,
the semantics of the interactions between agents is essentially
straightforward — as is ably captured in the generic HTTP
protocol.
However, if an agent is expected to be able to act on
information it receives, it becomes necessary to be much more
precise as to the intended semantics of the
information.
The semantics of the information exchanged between Web service
agents is derived from the structure of the messages, the message
exchange patterns and conversational patterns between agents. In
addition, it is necessary to be precise about
- the real-world entities referenced by terms in messages
- the expected actions to be undertaken by service providers
- the relationship between the owners of the agents acting as
service provider and service requestor
This architecture enables this precision by ensuring that the
various aspects of the semantics of the information exchanged
between agents can be properly identified. Where appropriate, and
possible, it also identifies a number of description languages
which can be used to describe different semantic aspects of this
exchanged information.
In summary, Web services can be considered to be a
specialization of World
Wide Webin general; a specialization that reflects the intended
purpose of the exchanged information — to be about
services. Similarly, this architecture can be viewed as an
elaboration of the general WWW architecture; albeit with a
significant number of additional concepts.
According to the Web
services Architecture requirements, it is a major goal of the
architecture that any implementations are inherently scalable and
extensible.
This goal is broken down into five critical success factors:
modularity,
extensibility,
simplicity,
migration from
EDIand peer to
peer.
The critical success factor AC002focuses on the
modularity of the architecture; with appropriate
granularity. This is reduced to an overall conceptual integrity
with appropriate decomposition and easy comprehension.
Our architecture is laid out using the simple style of
conceptsand relationships. This modeling technique is
simple, and yet allows us to expose the critical properties of
Web services. A major design goal of the architecture has been
the appropriate separation of concerns. In general,
this is achieved by rigorous minimalism associated with each
concept: only associating those properties of a concept that are
truly necessary to meet the requirements.
The overall themes in this architecture can be summarized
as:
- Web services are used and presented by agentsinteracting on behalf of real-world actors.
- Message structures,
service interfaces, conversationsare first of all explicitly
identifiedand potentially describedusing using a variety of description
languages. This has the effect of documenting the various aspects
involved in two or more interacting Web services.
- Minimal assumptions about required components. For example,
although Web services may be documented, it is not required.
Similarly, although descriptions may be published, that is also not
required.
To support Web services interacting in a peer to peer style, the
architecture must support peer to peer message exchange patterns,
must permit Web services to have persistent identity, must permit
descriptions of the capabilities of peers and must support
flexibility in the discovery of peers by each other.
In the message exchange
patternconcept we allow for Web services to communicate with
each other using a very general concept of message exchange.
Furthermore, we allow for the fact that a message exchange pattern
can itself be identified -- this permits interacting Web service
agents to explicitly reference a particular message pattern in
their interactions.
A Web service wishing to use a peer-to-peer style interaction
may use, for example, a publish-subscribe form of message exchange
pattern. This kind of message exchange is just one of the possible
message exchange patterns possible when the pattern is explicitly
identifiable.
In the agentconcept we note that agents
have identifiers. The primary role of an
agent identifier is to permit long running interactions spanning
multiple messages. Much like correlation, an agent's identifier can
be used to link messages together. For example, in a publish and
subscribe scenario, a publishing Web service may include references
to the Web service that requested the subscription, separately from
and additionaly to, the actual recipient of the service.
The agentconcept also clarifies that a
given agent may adopt the role of a service providerand/or a service requestor. I.e., these are
roles of an agent, not necessarily intrinsic to the agent
itself. Such flexibility is a key part of the peer to peer mode of
interaction between Web services.
In the serviceconcept we state that
services havea semanticsthat may be identified in a
service descriptionand that may
be expressedin a service description language.
This identification of the semantics of a service, and for more
advanced agents the description of the service contract itself,
permits agents implementing Web services to determine the
capabilities of other peer agents. This is turn, is a critical
success factor in the architecture supporting peer-to-peer
interaction of Web services.
Finally, the fact that serviceshave
descriptionsmeans that these
descriptions may be published in discovery agenciesand also retrieved from
such agencies. In effect, the availability of explicit descriptions
enables Web services and agents to discover each other
automatically as well as having these hard-coded.
In CSF
AC017are identified two requirements that support applications
in a similar manner to traditional EDI systems: reliable messaging
and support for long-running stateful choreographed interactions.
This architecture supports transactions by allowing messages to be
part of message exchanges and extended choreographies. It also
permits support for message reliability.
Conversations
Conversations are supported in this architecture at two levels:
the single use of a Web service and the combination of Web
services.
A message exchange
patternis defined to be the set of messages that makes a single
use of a service. Typical examples of message exchange pattern are
request-response, publish-subscribe and event notification.
The details of the message exchange pattern may be documented in
a service description—
expressed in a service
description languagesuch as WSDL.
In addition, the architecture supports the correlationof messages by permitting messages to
have identifiers.
Web services may be combined into larger scale conversations by
means of choreographies. A choreography
is the documentation of the combination of Web services, leaving
out the details of the actual messages involved in each service
invokation and focusing on the dependencies between the Web
services.
Of particular importance, both to individual message exchange
patterns and combined services, is the handling of
exceptions.
Message reliability
Web service manageability
Goal AG007 of the requirements
identifies that manageability of Web services is an important goal
of this architecture.
Management in this case is defined as a set of capabilities for
discovering the existence, availability, health, and usage, as well
the control and configuration of resources, where resources are
defined as Web services, agents of the Web services architecture,
and roles undertaken in the architecture.
Unlike other aspects of this architecture, management refers
almost exclusively to deployed resources. For example, an
executing Web services agent is a
resource that may require management, as is an actual deployed
Web service and the Web service's
service description.
Of course, systems that are deployed in order to help the
management of Web services are also potentially subject to
management; however, to the extent that such management services
are already modeled as Web services, their management will be
handled as any other Web service.
This architecture does not attempt to specify completely how Web
services are managed; that is be the role of a separate
specification. The architecture does, however, identify the key
concepts and relationships involved in modeling manageability.
Critical Success Factor AC018 states that
the architecture must enable the management and provisioning of Web
services.
The central concept around which manageability is modeled here
is the concept of physically deployed
resource. A deployed resource is a resource that physically
exists; and a manageable
resource is one whose configuration and/or life cycle state is
available to a management system.
The key relationship that ensures that the architecture models
management appropriately is the realizes
relationship. The objects under management — the deployed
resources — have a realizes
relationship with other elements of the architecture. For example,
a Web service is provided by an
agent. Both the Web service itself and the
agent are realized in some fashion; as
are any descriptions of the service; as physically deployed
resources, and those deployed resources are themselves
potentially manageable.
If a deployed resource `exposes' a management interface —
in the sense that the resource can be configured and its life cycle
managed — then an automatic management system may be used to
assist in managing the life cycle of the resource.
Of course, the specifics of the configuration of a
deployed resource will vary depending on many factors; such as the
kind of resource it is and the requirements of the application and
the environment.
In order to facilitate automatic support for the management of a
resource, it is helpful if the manageability of the resource is
explicitly described. This architecture permits a deployed resource
to identify the manageability semantics of the resource — of
course such a description may itself be a manageable resource!
Additional Topics
[EN: This section was not changed but includes a lot of work items for future editing]
The Web services architecture consists of:
A single specification of the way in which artifacts of the
system are identified: the Uniform Resource Identifier (URI) [1] (see section 5.1 Identifiers.).
A non-exclusive set of data formats designed for interchange between agents in the system (see section 5.2 Formats.).
A small and non-exclusive set of protocols for interchanging information between agents (see section 5.3 Protocols.).
A small and non-exclusive set of ... (see section 6 Processing Model).
Issue (procmod):
Is Process Model a foundational architectural aspect?
Resolution:
None recorded.
Each of these is discussed in detail in the following sections.
5.1 Identifiers
The Web services architecture builds directly upon the Web
Architecture [7]. As such, the Web services architecture directly leverages the definition of, and architectural constraints placed on,
identifiers from the
Architecture Principles of the Web[7].
Issue (qnames):
What about QNames as identifiers as used by WSDL? TAG Finding.
Resolution:
None recorded.
Issue (uuids):
What about UUIDs as identifiers as used by UDDI? Don't believe that
there is a formally registered URI scheme for UUIDs.
Resolution:
None recorded.
5.2 Formats
As with identifiers (see section 5.1 Identifiers), the
Web services architecture builds upon the definition of, and architectural
constraints placed on, formats from Architecture Principles of the Web[7].
...
5.2.1 XML Infoset
Specifications for data formats used in the context of Web services SHOULD be based on XML Infoset [2]. XML Infoset is not a data format per se, but a formal set of information items and their associated properties that comprise an abstract description
of an XML document [3]. The XML Infoset specification provides for a consistent and rigorous set of definitions for use in other specifications that need to refer to the information in a well-formed XML document.
Serialization of the XML Infoset definitions of information MAY be
expressed using XML1.0 [3]. However, this is not a requirement. The flexibility in choice of serialization format(s) allows for broader interoperability between agents in the system.
CBF: cite examples of possible alternate serializations such as compressed or binary XML.
5.2.2 XML Schema
Specification of message formats, structures and datatypes SHOULD be based on the W3C XML Schema: Structures[4] and XML Schema: Datatypes [5] specifications.
Issue (otherschema):
What about other schema languages such as RELAX NG, Schematron, DTD?
Resolution:
None recorded.
5.2.3 SOAP
One of the key specifications used in the context of Web services is SOAP [8]. The format of a SOAP message is formally defined in the SOAP1.2 Part 1: Messaging Framework specification. However, SOAP is much more than simply a message format.
| Editorial note | |
| refer to (and develop!) other sections describing
extensibility, binding framework, and process model. |
5.2.3.1 SOAP Extensibility
SOAP provides a simple messaging framework whose core functionality is concerned with providing extensibility. Extensions to the base
messaging framework defined by SOAP are modeled and specified as abstract features.
Example features include "reliability", "security", "correlation", and
"routing". The Web services architecture describes a number of these features (see section 3.2.1 Features), their inter-relationships with one
another, and their purpose within the overall architecture.
A SOAP feature MUST clearly and completely specify the content and semantics of the properties used to implement the desired behavior, including
any modifications to the SOAP Processing Model (see section 5.2.3.3 Process Model).
Constraint: URIs as identifiers
All SOAP Features MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 5.2.4 WSDL).
Expression of a SOAP Feature is accomplished through one of the
two mechanisms provided for by SOAP:
One special type of SOAP Feature is the Message Exchange
Pattern (MEP). A MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. Examples of MEPs include: request/response, oneway, peer-to-peer conversation, etc. A MEP MAY be supported by one or more underlying protocol binding instances either directly,
or indirectly with support from software that implements the required
processing to support the SOAP Feature as expressed as a SOAP Module.
Constraint: URIs as identifiers
All MEPs MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 5.2.4 WSDL).
Issue (wsdlmep):
WSDL identifies MEPs using QNames, not URIs.
Resolution:
None recorded.
5.2.3.1.1 SOAP Module
A SOAP Module is a formally specified expression of a SOAP Feature as one or more SOAP header blocks. Refer to the SOAP specification for the detailed requirements of a SOAP
Module. A SOAP Module is typically used to express a feature that is not provided for either directly or indirectly through mechanisms of the bound transport, or transfer, protocol. They are also used for the expression of end-to-end SOAP Features that might span multiple, disparate transport, or transfer, protocols as the message is conveyed from original sender to ultimate receiver.
5.2.3.2 SOAP Protocol Binding Framework
SOAP provides for the exchange of messages between software agents known as SOAP nodes using a variety of underlying transport, or transfer, protocols. The formal set of rules for exchanging a SOAP message via an
underlying protocol is called a binding. The SOAP
Protocol Binding Framework provides general rules for the specification of bindings to an underlying protocol. The framework also
describes the formal relationship between bindings and the SOAP nodes that
implement those bindings.
Constraint: URIs as identifiers
All SOAP Protocol Bindings MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 5.2.4 WSDL).
Issue (soapbinduri):
SOAP1.2 does not REQUIRE that a binding specification be identified with a URI.
Resolution:
None recorded.
5.2.3.3 Process Model
...
| Editorial note | |
| CBF: think that this might really belong under the Protocols section rather than the Formats section... |
5.2.4 WSDL
Both the sender and receiver of a Web services message must have access to the same service description. The sender needs the service description to know how to format the message correctly and the receiver needs the service description to understand how to receive the message correctly.
As long as both the sender and receiver have the same service description, (e.g. WSDL file), the implementations behind the Web services can be anything. Web services typically are implemented using programming languages designed for interaction with the web, such as Java Servlets or Application Server Pages (ASPs) that call a back-end program or object. These Web service implementations are also typically represented using a Web services description language.
The Web services description language contains the message data type and structure definition, the message exchange pattern definition, and the endpoint address the receiver listens on. When a sender wishes to send a message to a receiver, the sender obtains the service description and generates a message corresponding to the data type and structure information contained within the service description, and sends the message to the endpoint address identified in the service description. The receiver listens at the defined address for messages. When the receiver receives a message, the receiver validates the message using the data type and structure information in the service description, and uses information in the service description and associated with the service description to transform or map the message contents onto an executable program. Similarly, the sender's executable program generates the message using information in the service description and information associated with the service description.
Web service definitions can be mapped to any language, object model, or messaging system.
Simple extensions to existing Internet infrastructure can implement web services for interaction via browsers or directly within an application. The application could be implemented using COM, JMS, CORBA, COBOL, or any number of proprietary integration solutions.
5.2.4.1 WSDL harvesting material
Overview
WSDL plays a descriptor role in the overall Web Services
architecture. WSDL is static as it does not define dynamic interactions
between
Web Services.
http://www.w3.org/TR/2002/WD-wsdl12-20020709/#intro
WSDL defines
1. abstract functionality of a service
2. concrete binding details for SOAP 1.2, HTTP, and MIME
Namespaces
wsdl "http://www.w3.org/2002/07/wsdl" A normative XML Schema [XML Schema:
Structures], [XML Schema: Datatypes] document for the
"http://www.w3.org/2002/07/wsdl" namespace can be found at
http://www.w3.org/2002/07/wsdl.
soap12 "http://www.w3.org/2002/07/wsdl/soap12" Defined by WSDL 1.2: Bindings
[WSDL 1.2 Bindings].
http "http://www.w3.org/2002/07/wsdl/http" Defined by WSDL 1.2: Bindings
[WSDL 1.2 Bindings]. mime "http://www.w3.org/2002/07/wsdl/mime" Defined by
WSDL 1.2: Bindings [WSDL 1.2 Bindings].
WSDL has dependencies on XML schema.
Web Services model by WSDL
Summary: http://www.w3.org/TR/2002/WD-wsdl12-20020709/#intro
"WSDL describes Web services starting with the messages that are exchanged
between the service provider and requestor. The messages themselves are
described abstractly and then bound to a concrete network protocol and
message
format. A message consists of a collection of typed data items. An exchange
of
messages between the service provider and requestor are described as an
operation. A collection of operations is called a portType. Collections of
portTypes are grouped and called a serviceType. A service represents an
implementation of a serviceType and contains a collection of ports, where
each
port is an implementation of a portType, which includes all the concrete
details needed to interact with the service."
Components: requestor and provider
Connector: ports.
Data element: typed data item, messages
Architectural concept:
1. Messages are abstract and then bound to a concrete network protocol and
message format;
2. Operation is an exchange of message and there are only four types of
operations (Input-Output,Output-Input, Input only, and Output only)
Architectural decisions:
1. Data types are described by XML schema.
2. Both interface and implementation is defined in one WSDL.
WSDL bindings
http://www.w3.org/TR/2002/WD-wsdl12-20020709/#eii-binding
"A binding defines message format and protocol details for operations and
messages defined by a particular portType. There may be any number of
bindings
for a given portType."
WSDL SOAP 1.1 bindings
http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709/#_soap-b
"1. An indication that a binding is bound to the SOAP 1.2 protocol.
2. A way of specifying an address for a SOAP endpoint.
3. The URI for the SOAPAction HTTP header for the HTTP binding of SOAP.
4. A list of definitions for Headers that are transmitted as part of the
SOAP Envelope"
WSDL HTTP bindings
http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709/#_http
"1. An indication that a binding uses HTTP GET or POST
2. An address for the port
3. A relative address for each operation (relative to the base address
defined by the port) "
WSDL MIME bindings
http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709/#_mime
"1. 'multipart/related', defined in [IETF RFC 2387].
2. 'text/xml', defined in [IETF RFC 3023].
3. 'application/x-www-form-urlencoded', defined in Form content types
([HTML 4.01], section 17.13.4).
4. Others (by specifying the MIME type string) "
WSDL extensibility
http://www.w3.org/TR/2002/WD-wsdl12-20020709/#language-extensibility
"WSDL has an open content model: every element in the
'http://www.w3.org/2002/07/wsdl' namespace allows arbitrary extension
attributes and extension elements as long as their names are fully qualified
and they are defined in a namespace other than
'http://www.w3.org/2002/07/wsdl'"
WSDL issues:
1. Link handling
http://mail.python.org/pipermail/xml-sig/2002-February/007184.html
2. Does not support description of dynamic interactions.
| Editorial note | |
| CBF: WSDL harvested material above needs to be turned into appropriate prose. |
5.3 Protocols
Now provide description of Web service protocols
SOAP protocol binding framework
-------------------------------
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#transpbindframew
The SOAP Protocol Binding Framework provides general rules for the
specification of protocol bindings; the framework also describes the
relationship between bindings and SOAP nodes that implement those
bindings.
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#bindfw
The creation, transmission, and processing of a SOAP message,
possibly through one or more intermediaries, is specified in terms
of a distributed state machine.
... each SOAP message is modeled as an XML Infoset ...
... the XML Infoset of a SOAP message MUST NOT include a DTD ...
Bindings MAY provide for streaming when processing messages.
Bindings MAY depend on state that is modeled as being outside
of the SOAP XML Infoset.
| Editorial note | |
| CBF: This is harvested material that needs to be turned into prose. |
| Editorial note | |
| talk about modules and layering ... interoperability is
possible without all "web services" using the same set of features and modules,
but there has to be a conceptual agreement on what the features are, how they
are packaged, and how they are layered ... |
5.3.1 HTTP
something about HTTP, possibly as normative binding described for
SOAP.
HTTP has a special status in the W3C Web Services Architecture for a number of both practical and theoretical reasons. For one, early versions of
SOAP (and XML-RPC, which is still widely used in existing web services) were
explicitly tied to HTTP. SOAP 1.1 implied a certain amount of protocol-independence, and SOAP 1.2 makes this explicit, but HTTP is still the
dominant means of communicating between web services agents. Also, HTTP is
5.3.2 Other Protocols
Many believe that HTTP is the "native" protocol of the Web because it was designed to work with the URIs that identify Web resources. While HTTP has become almost ubiquitous, and many of the issues surrounding its earlier
incarnations have been resolved in subsequent versions of the standard and by "industrial strength" implementations, it is not the only protocol upon which
Web services can be built. For example
