Web Services Architecture

Working Draft @@ @@@ 2002

This version:
wd-ws-arch.html
Latest version:
http://www.w3.org/TR/wd-ws-arch/
Previous version:
Editors:
David Booth, W3C <dbooth@w3.org>
Michael Champion, Software AG <Mike.Champion@SoftwareAG-USA.com>
Chris Ferris, IBM <chrisfer@us.ibm.com>
Eric Newcomer, IONA <ericn@iona.com>
David Orchard, BEA Systems <dorchard@bea.com>

Abstract

This document defines the Web Service Architecture. The 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.

Status of this Document

This document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is a public Working Draft of a refactored Web Services Architecture specification for review by W3C members and other interested parties. It has been produced by a task force within the W3C Web Services Architecture WG, which is part of the W3C Web Services Activity. This document is a work in progress and is still incomplete in many respects, and is being published for the sole purpose of reviewing and evaluating ideas and proposals for improving the structure of the document.

A list of open issues against this document  is maintained by the Working Group.

Comments on this document should be sent to www-wsa-comments@w3.org ( public archives ). It is inappropriate to send discussion emails to this address.

Discussion of this document takes place on the public www-ws-arch@w3.org mailing list ( public archives ) per the email communication rules in the Web Services Architecture Working Group Charter.

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the Web Services Architecture Working Group. A list of all technical reports can be found at http://www.w3.org/TR/.

1 Introduction

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.

1.1 The Need for an Architecture

The architecture document identifies the technologies necessary for Web services to be used, described, discovered, how Web services interact with each other (such as long-time conversations, routing, composition, ...), etc. The architecture document delimits the boundaries of each identified functional area, and models the interfaces between them, so that the scope of web services related specifications created to address each piece of functionality is unambiguously defined. The architecture provides a model of the Web services concepts used in various specifications in order to ensure that the specifications actually work together and use the same concepts and terminology. The architecture document provides additional material to the W3C Web Services Architecture Glossary.

The generalized term "Web services" does not currently describe a coherent or necessarily consistent set of technologies, architectures, or even visions. Several streams of thought and practice have converged to produce an amalgam of what we think of as "Web services", including:

The excitement over Web services is based largely on the potential for a combination of XML, the Web, the SOAP and WSDL specifications, and to-be-defined protocol stacks to address many of the problems these technologies have encountered. For example, distributed object systems such as Microsoft's COM family and the OMG CORBA standard did not interoperate, each presented numerous security and administration challenges when deployed over the internet, and neither quite meet the scalability expectations created by the Web. Various XML-based B2B systems have showed much potential, but created incompatible protocols on top of the internet standards which lead to interoperability problems. The Web has proven enormously popular, scalable, and interoperable, but it too presents many challenges -- reliability, security, database-level transactions, details of how to map platform-neutral data, URIs and HTTP operations to back-end application systems, and many others -- that must be handled by Web applications rather than some standardized infrastructure.

The popular Web services technologies SOAP 1.1 and WSDL 1.1 were originally developed outside the W3C; however, their successors are now being developed within the W3C Web Services Activity. These specifications are being used as the basis for creating an extensible messaging framework (SOAP 1.2) and an interface definition language (WSDL 1.2).


Service Oriented Architecture

Summary

The Web Services Architecture (WSA) is an instance of a Service Oriented Architecture (SOA). In a SOA, services have published descriptions and access each other via a transport. A service executes when it receives a request, and returns a response if one is defined. Web services applications therefore consist of one or more of described services accessed via a transport in response to a request.

Artifacts of the WSA are modeled as properties of and constraints to the transport or a service. For example, a security service may generate and manage security context, but security context propagation is a property of the transport. Other properties of the transport include such qualities as reliability, scalability, and transactions. To the extent that a quality is not visible to a Web services application, it cannot modeled as a service, but only as a property of the transport.

Services are logical entities that can be mapped to execution environments in multiple ways. The architecture does not impose any requirements the implementation of services, and imposes no restriction on how services might be combined.

Figure 1, Generic Service Oriented Architecture Diagram

Service definition

[EN: This seems like it belongs in the concepts/definitions section]
The minimum definition of a service is a software agent with the following properties:

Architectural Style

In addition to the styles described in Chapter 4 of Dr. Fielding's thesis [title], and the REST style introduced in Chapter 5, this document introduces the Service Oriented Architecture (SOA) style. SOAs are described regularly in literature [see refs]. This document describes SOA in relation to Dr. Fielding's thesis.

A SOA is a derivation of the Layered Client Server style (3.4.3). It adds the constraint of stateless connections, that is where the all the data for a given request must be in the request. This is different from stateless (as defined in REST) in that Session state can be kept in the servers. A typical example is a session ID that a server uses to connect the request to the appropriate session.

NOTE [DaveO]: I'm somewhat confused about whether session IDs are considered stateless or stateful. I've heard it claimed by Roy that session Ids are stateless, as the client holds the information necessary for the server to do it's work. As opposed to FTP, where the previous commands determine state. This needs a bit more research to determine whether SOA is Stateless Server or not, as defined in Roy's thesis.

REST provides a generic interface through the use of four particular constraints:

SOA uses the first three constraints; that is, it uses URIs to identify resources, it manipulates resources through messages containing representations, and its messages can be self-descriptive. SOA uses application specific vocabularies as the engine of application state, rather than hypermedia. SOA allows for resources to be modeled as Services. It is possible that a SOA service will not expose the service (aka resource that is a service) directly via a URI, but will use an intermediary resource with an identifier. This distinction is between direct manipulation of the resource and indirect manipulation of the resource. This set of constraints shall be called specific interface

SOA has two derivations: Direct SOA, where the service is modeled with the representations exchanged through direct manipulation of the resource identifier, and Mediated SOA, where the service is modeled with representations exchanged through an intermediary identified by the resource identifier. A classic example of indirect service is the "getStockQuote" in the HTTP POST body. There are other examples, as described in the SOAP 1.2 primer, that show better examples of mediated services than the infamous getStockQuote example.

SOA has an optional constraint, of described interface. The service is described in a description language of some kind. The description includes features such as the syntactic constraints on the service interface, the identifier for the service, and semantic information about the service. Meeting this constraint induces the properties of higher re-usability of the component.

The Direct SOA has the same advantages as REST, such as better visibility, as the firewall can simply examine the generic interface to determine the action being performed. Intermediaries, such as HTTP routers or caches, can simply look at the method. An example is that a cache can look at the GET and the identifier, and return a cached representation. This is much more difficult if the method is in arbitrary places in the POST. Re-usability can be higher as the service may be available on the Web as a URI may be transferable.

The Mediated SOA has the advantage of protocol independence. There are limitations to HTTP that can be ameliorated by the use of SOAP. In cases of Service-oriented applications, such as messaging systems, it is easier to build applications in an SOA style. There may be higher Network Performance as the representations could be for multiple services.

[NOTE: DaveO:] Need to say more about which styles are more effective.

The following paragraphs provide some discourse on the notions of direct and indirect manipulation. It is possible for a Web service to be non-REST or REST compliant. A Web services based SOA may not support GET, and even may embed the equivalent of a GET inside a POST request. However, it is fact that the Web carries messages that contain Representations. So how can a Web service both: 1) non-REST compliant and 2) exchange representations? These seem to be in contradiction.

The reconciliation is that a Web services based SOA may not be "on the web". Being "on the web" is about supporting a generic interface to a URI, particularly the HTTP GET method for http: schemed URIs. This is completely consistent with the web as it currently exists. An HTML page that is returned as a result of a POST method is a representation of the status of a Resource. But that resource is not identified with a URI (you can't do a GET on it). The URI that the form is POSTed to does NOT identify the resource that the web page represents. There are 2 resources in play. The first, identified with a URI, is a gateway resource. The second, not identified with a URI and not on the web, is hidden from the web by the first URI. There is a decoupling of the resource identifier from the resource that the form data is sent to. Typically the resource identified by the URI is a gateway of some kind. And this is completely acceptable to REST. Nobody in the world has suggested that the Web is broken because FORM POST URIs are not directly accessible via browsers. We still consider the form result to be a web page. Thus we can consider the result of a SOAP POST to be a Web service message with a representation, yet not "on the web".

Style Summary. The set of constraints is: Layered, Client-Server, Cacheable, Stateless Connection, Specific interface, Described interface. In the vernacular of the Feilding thesis -LC$SCSIDI.

References:
Developer.com, Michael Stevens
Enhance Re-use by embracing a Service Oriented Architecture, Tim Landgrave
The evolution of Web applications into service-oriented components with Web services, Steve Burbeck
Rational's Using Service Oriented Architecture and Component Based Development to Build Web Applications, Alan Brown et all
Vinci, A Service Oriented Architecture, Rakesh Agrawal, et al
Web Service Oriented Architecture, Annrai O'Toole


Contract with the reader

[EN: The following is the new contract section]

The WSA document presents the architecture as a set of core concepts within specific relationships that determine the core framework or foundation of the architecture. Examples of core concepts include service, transport, message, and description. Qualities, capabilities, and constraints are overlaid atop the core concepts to validate the architecture's suitability for supporting various complex applications of Web services technologies. Examples of qualities, capabilities, and constraints include security, reliability, and consistency with Web architecture.

The WSA is intended to guide Web services product implementers, Web services specification authors, Web services application developers, and Web services students by providing a common definition of a Web service, and defining its place within a larger Web services framework.

The WSA provides a model and a context for understanding Web services, and a context for placing Web services specifications and technologies into relationships with each other and with other technologies outside the WSA. The WSA document lists the major concepts behind Web services, their relationships to each other, and the constraints, qualities, and capabilities of the concepts within the overall WSA.


1.2 Document Overview

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. It is organized to introduce overview material, followed by normative material.


1.3 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.

2 What is a Web service?

Although there are a number of varied and often seemingly inconsistent motivations for, and uses of, the term "Web service", at its core, the following definition captures what we believe to be the shared essence of the term:

[Definition: A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and 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.]

This definition serves as the basis for the architetcure described in this document.

Note:

Our definition of the term "Web services" does not presuppose the use of SOAP as a packaging format or a processing model. Nor does it presuppose the use of WSDL as a service description language. There are, and will be in the future, plenty of Web services that use raw HTTP as a data transfer protocol and some mutually agreed-upon XML format as the message content. The Web Services *reference architecture* does, however, assume that the higher levels of the Web services protocol stack are built on the foundation of SOAP and WSDL.

This "blessing" of SOAP and WSDL is not logically necessary, since some other mechanism could be defined to gather XML message elements into a single package, and other description mechanisms such as DAML-S could be used instead of WSDL. Perhaps in the long run, other technologies will supplant SOAP and WSDL, and it is not the intent of the WSA to discourage research and experimentation in these areas. On the other hand, the WSA WG believes that a common foundation is a *practical* necessity for the industry to move forward with additional Web services functionality, including security, choreography, etc. Thus, the WSA reference architecture builds on SOAP and WSDL as the basis for messaging and description. Specifications that conform to the WSA reference architecture MUST use SOAP and WSDL when appropriate.


[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. ]

Concepts and relationships

The architecture is enumerated as a set of conceptsand their relationships.

Concepts

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.

Agent

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.

Choreography

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.

Correlation

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.

Deployed resource

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.

Feature

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:

[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?

Identifier

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

[KATIA]: The above definitions of Manageable Element and Manageable Interface supercede the  definition of Manageable Resource. So, for now, I have dropped  the definition of Manageable Resourcethat was present in yesterday’s draft].

Message

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.

Message Exchange pattern

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.

Message Header

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

Message identifier

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.

Message recipient

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.

Message 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.

Representation

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.

Resource

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].

Service

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.

Service description

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.

Service provider

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.

Service requestor

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.

Service semantics

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.

Transaction

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

Web service

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.

WSDL

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.

Relationships

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.

The describes relationship

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.

The is expressed in relationship

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.

The is realized as relationship

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:


Web Services Architectural Roles

[EN: I included this by reference, at least for the moment, as the easiest way to do it.]


Stakeholders' viewpoints

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.

Web integration

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.

Information and service

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.

Web service agents

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:

  1. It is a computational activity
  2. It has an owner
  3. It engages in message exchanges with other Web service agents, those messages counting as equivalent messages between the agents' owners.
  4. It uses standard protocols to:
    1. describe the form and semantics of messages
    2. describe the legal sequences of messages
  5. 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.

Web service semantics

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

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.

Scalability and extensibility

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.

Modularity

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:

Extensibility

Peer to peer interaction

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.

Long running transactions

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.

The Management and provisioning of Web services

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:

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].

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.

Editorial note 
CBF: cite examples of possible alternate serializations such as compressed or binary XML.

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).

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.

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.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

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 ...

6 Processing Model

Now provide description of SOAP and WSDL Processing models

				Processing model
----------------
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#msgexchngmdl
 SOAP provides a distributed processing model that assumes a
 SOAP message originates at an initial SOAP sender and is sent to
 an ultimate SOAP receiver via zero or more SOAP intermediaries.

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soapnodes
 A SOAP node can be the initial SOAP sender, an ultimate SOAP
 receiver, or a SOAP intermediary.  A SOAP node receiving a SOAP
 message MUST perform processing according to the SOAP processing
 model.

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soaproles
 In processing a SOAP message, a SOAP node is said to act in one or more
 SOAP roles, each of which is identified by a URI known as the SOAP
 role name.

 This specification defines the following SOAP roles:
  http://www.w3.org/2002/06/soap-envelope/role/next
  http://www.w3.org/2002/06/soap-envelope/role/none
  http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#targettingblocks
 A SOAP header block MAY carry a role attribute information item that
 is used to target the header block at SOAP nodes operating in the
 specified role.

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#muprocessing
 A SOAP header block is said to be understood by a SOAP node if the
 software at that SOAP node has been written to fully conform to and
 implement the semantics conveyed by the combination of local name and
 namespace name of the outer-most element information item of that
 header block.

 ... for every mandatory SOAP header block targeted to a node, that
 node MUST either process the header block or not process the SOAP
 message at all, and instead generate a fault

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#structinterpbodies
 An ultimate SOAP receiver MUST correctly process the immediate
 children of the SOAP body

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#procsoapmsgs
 Rules for SOAP processing and the kinds of faults that must be
 generated.

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#envvermodel
 A SOAP Version 1.2 message has a child element information item
 of the document information item with a local name of Envelope and a
 namespace name of "http://www.w3.org/2002/06/soap-envelope".

 If a SOAP node receives a message whose version is not supported it
 MUST generate a fault with a Value of Code set to
 "env:VersionMismatch". Any other malformation of the message
 construct MUST result in the generation of a fault with a
 Value of Code set to "env:Sender".

Editorial note 
CBF: This is harvested material that needs to be turned into prose.

A Acknowledgments (Non-Normative)

This document has been produced by the Web Services Architecture Working Group

The editors would like to thank Heather Kreger of IBM for her substantial contributions to this document.

Members of the Working Group are (at the time of writing, and by alphabetical order): Daniel Austin (W. W. Grainger, Inc.), Mukund Balasubramanian (Infravio, Inc.), Mike Ballantyne (EDS), Abbie Barbir (Nortel Networks), David Booth (W3C), Allen Brown (Microsoft Corporation), Mike Brumbelow (Apple), Doug Bunting (Sun Microsystems, Inc.), Greg Carpenter (Nokia), Dipto Chakravarty (Artesia Technologies), Jun Chen (MartSoft Corp.), Alex Cheng (Ipedo), Tom Carroll (W. W. Grainger, Inc.), Michael Champion (Software AG), Martin Chapman (Oracle Corporation), Ugo Corda (SeeBeyond Technology Corporation), Roger Cutler (ChevronTexaco), Jonathan Dale (Fujitsu), Suresh Damodaran (Sterling Commerce(SBC)), Glen Daniels (Macromedia), James Davenport (MITRE Corporation), Alan Davies (SeeBeyond Technology Corporation), Paul Denning (MITRE Corporation), Ayse Dilber (AT&T), Zulah Eckert (Hewlett-Packard Company), Gerald Edgar (The Boeing Company), Colleen Evans (Progress Software Corp.), Chris Ferris (IBM), Daniela Florescu (XQRL Inc.), Shishir Garg (France Telecom), Yaron Goland (BEA Systems), Hugo Haas (W3C), Mark Hapner (Sun Microsystems, Inc.), Hao He (The Thomson Corporation), Dave Hollander (Contivo), Yin-Leng Husband (Hewlett-Packard Company), Nigel Hutchison (Software AG), Mario Jeckle (DaimlerChrysler Research and Technology), Mark Jones (AT&T), Tom Jordahl (Macromedia), Heather Kreger (IBM), Sandeep Kumar (Cisco Systems Inc), Hal Lockhart (OASIS), Michael Mahan (Nokia), Francis McCabe (Fujitsu), Michael Mealling (VeriSign, Inc.), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft), Jeff Mischkinsky (Oracle Corporation), Nilo Mitra (Ericsson), Himagiri Mukkamala (Sybase, Inc.), Eric Newcomer (IONA), Henrik Nielsen (Microsoft Corporation), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Srinivas Pandrangi (Ipedo), Fabio Riccardi (XQRL Inc.), Don Robertson (Documentum), Waqar Sadiq (EDS), Krishna Sankar (Cisco Systems Inc), Igor Sedukhin (Computer Associates), Jim Shur (Rogue Wave Software), Hans-Peter Steiert (DaimlerChrysler Research and Technology), Katia Sycara (Carnegie Mellon University), Patrick Thompson (Rogue Wave Software), Steve Vinoski (IONA), Scott Vorthmann (TIBCO Software, Inc.), Prasad Yendluri (webMethods, Inc.), Jin Yu (MartSoft Corp.), Sinisa Zimek (SAP).

Previous members of the Working Group were: Mark Baker (Idokorro Mobile, Inc. / Planetfred, Inc.), Tom Bradford (XQRL, Inc.), Sharad Garg (Intel), Joseph Hui (Exodus/Digital Island), Marcel Jemio (DISA), Timothy Jones (CrossWeave, Inc.), Jim Knutson (IBM), Bob Lojek (Intalio, Inc.), Anne Thomas Manes (Systinet), Joel Munter (Intel), David Noor (Rogue Wave Software), Kevin Perkins (Compaq), Darran Rolls (Waveset Technologies, Inc.).

B References (Non-Normative)

B.2 Informative References

6
Web Services Architecture Charter (See http://www.w3.org/2002/01/ws-arch-charter.)
7
DRAFT: Architecture Principles of the World-Wide Web; Ian Jacobs, 30 August 2002 (See http://www.w3.org/TR/2002/WD-webarch-20020830/.)
8
SOAP Version 1.2 Part 1: Messaging Framework Working Draft, eds. M. Gudgin, M. Hadley, J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/soap12-part1/.)
9
SOAP Version 1.2 Part 2: Adjuncts Working Draft, eds. M. Gudgin, M. Hadley, J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/soap12-part2/.)
10
SOAP 1.2 Part 0 (See http://www.w3.org/TR/2002/WD-soap12-part0-20020626/.)
11
SOAP 1.2 Part 0 (See http://www.w3.org/TR/soap12-af.)
12
SOAP Messages with Attachments (See http://www.w3.org/TR/SOAP-attachments.)
13
XML Protocol (SOAP) Requirements (See http://www.w3.org/TR/2001/WD-SOAP-reqs-20010319/#N2082.)
14
XML Protocol Usage Scenarios (See http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/.)
15
Web Services Description Language (WSDL) Version 1.2 Working Draft, eds. R. Chinnici, M. Gudgin, J. Moreau, S. Weerawarana (See http://www.w3.org/TR/wsdl12/.)
16
Web Services Architecture Requirements Working Draft, eds. D. Austin, A. Barbir, C. Ferris, S. Garg (See http://www.w3.org/tr/wsa-reqs.)
17
Web Services Glossary Working Draft, eds. H. Haas (See http://www.w3.org/tr/ws-gloss.)
18
Web Services Architecture Usage Scenarios Working Draft, eds. H. Haas, D. Orchard (See http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/.)
18
Message Service Specification, ebXML Message Service Specification Version 2.0 (See http://www.ebxml.org/specs/ebMS.pdf.)
19
Web Services Routing Protocol (WS-Routing) (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsrvspev/html/ws-routing.asp.)
20
XML Key Management Specification (XKMS 2.0) W3C Working Draft 18 March 2002, eds. Phillip Hallam-Baker, VeriSign (See http://www.w3.org/TR/2002/WD-xkms2-20020318/.)
21
XML-Signature Syntax and Processing, W3C Recommendation 12 February 2002, eds. D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. (See http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.)
22
XML Encryption Syntax and Processing W3C Proposed Recommendation 03 October 2002, eds. D. Eastlake J. Reagle (See http://www.w3.org/TR/2002/PR-xmlenc-core-20021003/.)
23
Web Services Security Specification, Working Draft 03 November 2002 (See http://www.oasis-open.org/committees/wss/documents/WSS-Core-03-1103.pdf.)

C The Bottom Up View of the Architecture (Non-Normative)

Editorial note 
CBF: The material in this section has been largely reconstituted in section 3 above. It remains here so that the editors can further harvest the concepts covered here. It is the editor's intent that this section will be removed and subsumed in the next published draft.

This section describes the bottom-up view of Web services architecture. The bottom-up view presents Web services as fundamentally comprised of XML messages and the software agents that process them. The software agents can be any one or combination of the following:

The bottom-up Web services architecture describes a system comprised of related technologies that exchange messages between senders and receivers, potentially including intermediaries. The architecture extends the message exchange into "patterns" such as one-way, request/response, and pub/sub. Message exchange patterns are further extended with functionality to ensure privacy, coordinate transactions, orchestrate multiple message exchange patterns, among other things. Web services architecture components are defined using XML applications, and use XML infoset definitions for message data typing and structuring. The bottom-up view of Web services architecture defines the message exchange patterns and extended functionality by placing the fundamental aspects of Web services into relationship: the message, sender, receiver, intermediary, and extended functionality data or context.

Figure 1 illustrates the basic concept of the Web services architecture. An XML message is sent from a sender and received by a receiver. The sender typically generates the XML message but may also forward it. Messages include zero or more headers and data. The header part of a message includes information pertinent to functional aspects of the message, such as security, transaction context, orchestration information, or message routing information. The data part of a message includes the application-defined content. Messages typically have one or more XML schema content models associated with them: one for each header, and one for the data. Messages are associated with endpoints using URIs. The URI identifies the endpoint to which a sender sends an XML message, and at which a receiver is listening for a message. Compatible content models for the header and the data must be available at both the sender and receiver.

The level of abstraction at which Web services operates encompasses such interaction styles as RPC emulation, asynchronous messaging, one-way fire and forget style messaging, broadcast, and publish and subscribe. All message interaction styles, or patterns, are composed of one or more one-way asynchronous messages. Thus the fundamental building blocks of Web services architecture are the XML message, message sender, and message receiver. Each is described furture in this document. Basic Web services applications use this level of functionality. More complicated Web services applications add to this basic level of functionality. Figure 1: A Web services implementation sends and/or receives XML messages

Figure 2 illustrates a common message exchange pattern: request/response. To support the request/response message exchange pattern a Web services implementation provides software agents that function as both senders and receivers. The sender sends an XML message in the form of a request for information or to perform an operation and the receives an XML message that contains the result of the request or operation. The receiver receives the XML request message and sends a response. The request/response pattern is also often called the remote procedure call (RPC) oriented interaction style. Web services architecture does not include the concept of automatically correlating requests and responses, as some RPC oriented technologies do. The correletion of request and reply messages is application-defined. Figure 2: A Web services implementation can be both sender and receiver

Figure 3 illustrates the role of an intermediary in message exchange patterns. An intermediary is by definition both a sender and a receiver. However, an intermediare receievs a message from a sender and forwards it to another receiver. Multiple intermediaries are possible, each one receiving a message from a sender and forwarding it to another receiver, until the ultimate destination of the message is reached. Intermediaries are restricted in their capability to process an XML message, however. Intermediaries are allowed to process a message header information only. When processing a message, intermediaries must not disturb the data content, but may add or remove header content. Figure 3: Web services messaging can include intermediaries

Figure 4 illustrates the concept that a Web services message can include headers that provide associated semantic information for higher level functions such as security, transaction coordination, reliability, and orchestration. The headers carry contextual information such as a security token, transaction identifier, or message destination. Messages are associated with content models (i.e. XML Schemas) that define the meaning, or semantics, of the header information and context data. Figure 4: Web services messages can carry semantic information relevant to their processing

Figure 5 illustrates the concept that intermediaries can process semantic information, potentially removing one or more headers after processing the header or headers and forwarding the message to another receiver (which could also be an intermediary). Intermediaries may also add header information to a message, but cannot disturb message data. Figure 5: Web services intermediaries can process or add semantic information (in headers) relevant to message processing

Figure 6 illustrates the concept that a receiver can publish a service description that the sender can use to construct the message and send it to the receiver. The service description provides the message definition and the receiver's endpoint address. The description is a form of an XML content model describing the message data and header(s). Figure 6: A Web services implementation can provide a service description for a message to be exchanged

Figure 8 illustrates the major components of the Web services architecture in relationship to each other: XML messages, senders, receivers, intermediaries, and header information potentially processed by intermediaries. The illustration includes a representation of persistent data storage systems into and out of which messages are transformed or natively stored. Figure 8: Web services message patterns are constructed out of senders, receivers, intermediaries, and headers

Editorial note 
EN: The above diagram might be the only one really necessary here, the others might be moved to a tutorial if they seem to basic or numerous.

D Architectural Use of Technologies (Non-Normative)

As previously stated, a Web services interaction is two, or more, software agents exchanging information in the form of messages, using a variety of Message Exchange Patterns (MEP). A very common Message Exchange Pattern for Web services is the Request Response MEP. A sender sends a request to a receiver, and the receiver responds. The data that is exchanged in the request or the response is usually XML carried over an underlying transport or transfer protocol, such as HTTP. The XML can be XML Element/attribute syntax or it can be defined as an XML Infoset, or it can be information solely in the underlying protocol. An example of this is an HTTP GET request that does not contain an XML message, but the response may carry an XML message.

SOAP provides an extensible framework for the XML data that is interchanged. The format that SOAP defines has restrictions and places of extensibility. The Web Services Description Language (WSDL) provides a format for defining the allowable formats for messages to and from agents. These include SOAP, XML, MIME, and simple HTTP requests.

Many "real" products and projects are successfully using SOAP and WSDL, and it is clear that a critical mass of knowledge and technology are forming around them, and they will remain at the center of the web services architecture. Nevertheless, there are numerous architectural questions that remain unsolved, or at least whose solution is not widely agreed upon. These include:

Detailed objectives are laid out in the accompanying Requirements document [WSAREQ], but at a high level the W3C Web Services Architecture is intended to:

It is a non-objective to resolve all of the profound disagreements that Web services theorists and practitioners continue to have over the concepts and technology in the shared area. The W3C WSA will accomodate divergent opinions on whether various services should be implemented at the application or infrastructure level, whether it is appropriate to "tunnel" remote procedure calls over HTTP, etc. Similarly, it is unrealistic to expect the W3C Web Services Architecture to define a set of "Lego blocks" that can be snapped together to build real applications. That is a reasonable vision for the Web services industry, but it will require considerable research, experimentation, and standards-building to achieve. This reference architecture is intended to help clear the way for these activities by forming a consensus on what the basic types of components might be, the ways in which they relate to one another, and what to name them.

E Other harvested material (Non-Normative)

Editorial note 
CBF: placeholder. this material needs to be considered and folded in as necessary.

E.2 ebXML

In brief: The ebXML suite of specifications enables enterprises to conduct
business over the Internet using a service based architecture. ebXML
(http://www.ebxml.org/ and http://www.oasis-open.org) consists of 5
specifications currently, addressing different aspects of B2B e-commerce
over the Internet: ebXML Message Service (ebMS), ebXML Collaboration
Protocol Profile and Agreement (ebCPPA), ebXML Registry (ebR), ebXML
Business Process Specification Schema (ebBPSS), and ebXML Core Components
(ebCC). Each specification is designed to be implementable independent of
other specification, though appropriate mappings and hooks are provided to
support efficient integration of components built using other ebXML
specifications.

Components: Party, Role, Service, Actions, Collaboration Protocol Profile
(CPP), Collaboration Protocol Agreement (CPA), Registry, Attachment.

Connectors: Message Service Handler (MSH), Business Service Interface (BSI)

Data Elements: ebXML Message, Business Process Specification, Business
Document, Business Transaction, Binary Collaboration.

There are several name spaces used in all the specifications, and I haven't
pulled them out.

Architectural Concepts: 

	Concept of Operation:  An ebXML Message from a Party A invokes an
Action within a Service at Party B. The message is received and processed by
the MSH at Party B according to a prior agreement  (CPA) between Party A and
Party B. This agreement is a CPA. The agreement between Party A and Party B
may be arrived at by negotiation (ebXML does not specify the details how
this negotiation happens) between them based on the CPP of Party A and CPP
of Party B. The integration of the MSH and the business application
executing at a Party is carried out through a BSI (not fully specified by
ebXML). An ebXML Message may be in a conversation consisting of multiple
messages that implements a Business Transaction. A Business Transaction may
include at a request, and the corresponding response, and acknowledgements
for the request/response. A Binary Collaboration contains an aggregation of
related Business Transactions. A Binary Collaboration and/or CPP may be used
to identify and  implement the Services. Party A and Party B may retrieve a
specified Binary Collaboration and CPPs from Registry. 
	
	Message based service invocation - ebMS:
http://www.oasis-open.org/committees/ebxml-msg/
-	An MSH is implemented conforming to ebMS. ebMS specifies
peer-to-peer, asynchronous, synchronous, reliable interactions between Party
A and Party B. An ebXML Message extends SOAP 1.1
(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) for such specification. An
ebXML message can be signed. Signature processing  is specified in ebMS, and
extends  XML Signature (http://www.w3.org/TR/xmldsig-core/). An ebXML
Message may have attachments (per "SOAP with Attachments"
http://www.w3.org/TR/SOAP-attachments) that are Business Documents such as
Purchase Order. These Business Documents may be in EDI, XML, or any other
format. MIME is used to physically package the ebXML Message with the
Attachments. ebMS provides an XML Schema for a ebXML Message. ebMS uses a
CPAId to identify the CPA that governs the ebXML Message reception and
processing.

Implementation independent Service specification - ebCPPA:
http://www.oasis-open.org/committees/ebxml-cppa/
A CPPA specifies XML Schemas for CPP and CPA, and also guidelines to form a
CPA from two CPPs. The CPP contains elements that specify Roles (e.g.,
Seller, Buyer), Services, Actions, and message attributes  (e.g., number of
retries, time out interval, and so on for reliable messaging, certificates
for trust management). It is possible to derive WSDL from CPP
(http://www.oasis-open.org/committees/ebxml-cppa/documents/presentations/ind
ex.shtml - see 4th F2f Web Services Zip File).
	
	Registry : http://www.oasis-open.org/committees/regrep/
	Registry is a registry ("catalog") as well as a repository
("warehouse"). Interfaces to manage the lifecycle of Registry entries and to
support queries on Registry entries are provided. Primarily, a Registry is
intended as a repository of CPPs and public business processes, though
information in any format may be stored in the repository and registered in
the Registry.

ebBPSS: http://www.geocities.com/ebtwg_bp/
ebBPSS is used to specify the externally visible ("public") business process
between Party A and Party B. It provides an XML Schema to specify Binary
Collaboration between Party A and Party B. A Binary Collaboration may
consist of multiple Business Transactions. Each Business Transaction is
specified in terms of Business Envelopes, Business Documents, and Business
Signals that are communicated between Party A and Party B. 

ebCC:
http://www.ebtwg.org/projects/documentation/core/CoreComponentsTS1.80.pdf
ebCC specifies the semantic elements of a Business Document to eliminate
dependencies on syntax (e.g., EDI) of Business Documents.

Architectural Decisions:
-	Modular specifications: each specification can be independent of
another to facilitate easy adoption
-	The operations described in the "Concept of Operation" earlier are
divided into three phase: Implementation, Discovery, and Run-time. A CPA
formed during the discovery phase is not changed during the execution of
business transactions in run-time phase.
-	Mappings among specifications: Whenever an ebXML specification can
use a component built to another ebXML specification, the necessary mappings
between the specifications are specified.
-	Evolve the current state of the art instead of impose a new
infrastructure - In B2B world EDI is still used heavily, and the best
practices of such usage is used in the design of ebXML.
-	Never reinvent the wheel - use other specifications (use of SOAP 1.1
and XMLDSIG in ebMS, for example) whenever available and appropriate. 

F Web Services Architecture Change Log (Non-Normative)

20021202DBOIncorporated f2f changes from the first morning - use of agents, duplicate diagrams, document overview - and the correlation/reliability feature summary
20021114CBFincorporate MTF overview proposal. merged with daveo's changes based on 11/13/2002 f2f session.
20021029CBFtweaked intro per Hugo's suggestion/comment.
20021028CBFincorporated Jean-Jacques' and Hugo's comments on description. amended status and abstract. some restructuring of the references and appendicies.
20021025CBFincorporated Heather's description prose. Incorporated Hugo's comments
20021024CBFincorporated feedback from Joel Munter and some from Jean-Jacques Moreau.
20021022CBFincorporated revised graphics
20021020CBFincorporated Eric's section 1.2 updates. Converted to xmlspec-v2.2.
20020720CBFincorporated SOAP harvest, weaved into the revised flow. added normative biblio.
20020604DBOInitial Rev