Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document is an editors' copy that has no official standing.
This is the second public Working Draft of a document of the Web Services Architecture specification for review by W3C members and other interested parties. It has been produced by 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.
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
1.1 The Need for an Architecture
1.2 Document Overview
1.3 Notational Conventions
2 What is a Web service?
3 Architecture Overview
3.1 Basic Architecture
3.1.1 agents
3.1.2 Roles
3.1.3 Operations
3.2 Extended Web Services Architecture
3.2.1 Features
3.2.1.1 Packaging
3.2.1.2 Transactions
3.2.1.3 Publish/Subscribe
3.2.1.4 Choreography
3.2.1.5 Semantics
3.2.2 Infrastructure Services
3.2.3 Diagrammatic representation of features
3.2.4 Flows
4 Web Services Stacks
4.1 Wire "Stack"
4.1.1 Transport
4.1.2 Packaging
4.1.3 Extensions
4.2 XML Messaging with SOAP
4.2.1 Interactions
4.3 Description "Stack"
4.3.1 Descriptions Applying to a Particular Web Service
4.3.1.1 Interface
4.3.1.2 Implementation
4.3.1.3 Policy
4.3.1.4 Presentation
4.3.2 Description for Relationships between Web Services
4.3.2.1 Composition
4.3.2.2 Orchestration
4.3.2.3 Service Level Agreements
4.3.2.4 Business Level Agreements
4.4 Discovery Agencies "Stack"
4.4.1 Service Publication
4.4.1.1 Producing Service Descriptions
4.4.1.2 Publishing Service Descriptions
4.4.2 Service Discovery
4.4.2.1 Acquiring Service Descriptions
4.4.2.2 Consuming Service Descriptions
4.4.2.3 Inspection
4.5 Overarching Concerns
4.5.1 Security Concern
4.5.2 Quality of Service Concern
4.5.3 Management Concern
4.5.3.1 Managed Resources
4.5.3.2 Management
4.5.3.3 Manageability
4.5.3.4 Manager Role
4.5.3.5 Manageable agents
4.5.3.6 Manageability Information
4.5.3.7 Access to Manageability Information
4.5.3.8 Manageability Discovery
4.5.3.9 Realization in Web Services Architecture
4.6 The Complete Web Services "Stack"
5 Web Service Architecture
5.1 Identifiers
5.2 Formats
5.2.1 XML Infoset
5.2.2 XML Schema
5.2.3 SOAP
5.2.3.1 SOAP Extensibility
5.2.3.1.1 SOAP Module
5.2.3.2 SOAP Protocol Binding Framework
5.2.3.3 Process Model
5.2.4 WSDL
5.2.4.1 WSDL harvesting material
5.3 Protocols
5.3.1 HTTP
5.3.2 Other Protocols
6 Processing Model
A Acknowledgments (Non-Normative)
B References (Non-Normative)
B.1 Normative References
B.2 Informative References
C The Bottom Up View of the Architecture (Non-Normative)
D Architectural Use of Technologies (Non-Normative)
E Other harvested material (Non-Normative)
E.1 REST
E.2 ebXML
F Web Services Architecture Change Log (Non-Normative)
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.
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).
The Web Services Architecture (WSA) is an instance of a Service Oriented Architecture (SOA) in which services have descriptions and access each other via a transport. A service is executed by an agent when it receives a request to do so, and returns a response if one is defined. The service execution conforms to the interface and semantics (if any) expresssed within its description. A combination of services and requesters comprises a Web services application.
Artifacts of the WSA are modeled either as properties of the transport or of a service. Services are modeled and described as endpoints on a transport that provides access to them. Properties such as security, transactions, discovery, and choreography can be both services and qualities of the architecture. For example, a security service generates and manages security context, but security context propagation is also an attribute of the transport.
Attributes of the transport include such things as reliability, transactions, and security. To the extent that a quality such as reliability in invisible to the Web services application, it is not modeled as a service, but only as an attribute of the transport. However, reliability is a quality that pertains to multiple levels of the system, including the application level. Reliability mechanisms available at the application level are therefore modeled as services.
Services are logical entities, and some of them might be realized as physical instantiations and therefore executable. The architecture does not impose any such requirement on them, and imposes no restriction on how services might be combined.
[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:
Services are implemented using agents that support Web technologies, minimally including XML and URIs, but optionally including HTTP and RDF. For example:
The Web Services Architecture (WSA) is an instance of a service-oriented architecture (SOA). The WSA is comprised of a service transport, various services accessible via the transport, descriptions of the services, and qualities and constraints of the transport and services.
[EN: I've got a diagram to propose here, will send separately]
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.
[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 put together, with my annotations]
The architecture is enumerated as a set of concepts and their relationships.
The core concepts that form the architecture are laid out in this section.
The ordering of the concepts in this section is alphabetical; this should not be understood to imply any relative importance.
[EN:] Not sure this is correct, but maybe necessary. It would be difficult to decide on an order of importance, and especially if we could only figure out a partial order of importance. The first few would be: service, transport, requester, provider, description... Then what? Context? Security? Choreography?
[EN: slight change to wording] An agent is a computational process or execution environment that implements a service.
Agents are the computational representatives of business entities and people in the context of Web services.
[EN: Added from Roger's email] An actor is a legal entity - such as a person or a corporation - that may be the owner of agents that either seek to use Web services or provide Web services.
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
[EN:] A choreography is an instance of a service, executed on request.
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.
[EN for consistency with SOA unifying concept:] Choreographies exist as services accessible via the transport and described to the transport as services, thereby representing aggregates or composites of other services.
Correlation is an activity that uses an identifier for matching messages. 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.
[EN:] Correlation ensures that the agent requesting a service execution can match the reply with the request, when multiple replies may be possible.
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.
[EN:] Correlation can be a feature of the transport or the application.
This is a searchable set of service descriptions where service providers publish their service descriptions. The service discovery agency can be centralized or distributed. A discovery agency can support both the pattern where it has descriptions sent to it and where the agency actively inspects public providers for descriptions. 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, the service discovery agent is in fact an optional role in the architecture, 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 filesystem, FTP site, URL, or WSIL document.
[EN:] A discovery agency is a service accessible via the transport for the purpose of finding a service description when an agent requesting a service execution doesn't have one.
A feature is a subset of the architecture that relates to a particular requirement or larger scale property.
A feature is a subset of the architecture that relates to a particular requirement of the architecture. It may be realized through a number of mechanisms, such as bindings, message exchange patterns or 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:
[EN:] I'm not sure a feature is a really concept of WSA...?
An identifier is a preferably opaque string of bits that may be used to associate with a resource
Identifiers are used to identify resources. In the architecture we use Uniform Resource Identifiers to identify resources.
[EN:] Every service has a unique identifier>
[EN:] Aren't we saying identifiers are URIs? And if so, is this the same as a service name? Or does a service name have both a "human" readable name and a URI?
A message is the basic unit of interaction with Web services. The architecture defines an interaction between software agents as an exchange of messages.
[EN:] Not sure about this wording, since a message is more like the data passed to a service...? Also 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.
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.
[EN:] Within WSA, a message represents the data structure passed to a service during its request, and received from a service during its response (if any). Messages are defined in service descriptions.
A message exchange pattern is a minimal set of messages, together with their sender and receivers, that constitutes a single use of a service.
[EN:] If we define message as the data passed into and received out of a service, then an MEP would be confined to a set of messages, and would not require further definition, would it?
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 description includes 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.
[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?
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.
[EN:] Not just intermediaries, but also the ultimate receiver.
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.
[EN:] Good question as to whether messages have headers, or whether messages include headers...are headers also maybe an attribute of the transport?
A service is a set of actions that form a coherent whole from the point of view of a service provider
A service is a collection of actions, each action is typically accessed via messages sent from the service requestor to the service provider. A service [does] may have a service description, which includes a description of the messages, their types [the rest optional part of description] any implied ordering of messages and the intended effects of those messages.
[EN:] To me, the basic abstraction of a service is that it includes a service name, the description of the data to be sent to (and optionally received from) the service, and the network location of the service. I am not sure a service includes multiple interfaces, for simplicity I think we have to model them as unique interfaces -- multiple interfaces = multiple services.
From a business perspective, this is the owner of the service. From an architectural perspective, this is the platform [EN: agent?] that hosts access to the service. It has also been referred to as a service execution environment or a service container. Its role in the client-server message exchange patterns [EN: are these MEPs defined or part of the architecture?] is that of a server.
[EN:] I think it would definitely simplify things to describe them in terms of SOA, so a service provider is the instance of a service, or the agent that hosts the instance of the service that can be invoked by the requester? more like that...
A service requestor is the entity that is responsible for requesting a service from a service provider.
From a business perspective, this is the business that requires certain function to be satisfied. From an architectural perspective, this is the application that 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 patters is that of a client.
[EN:] Also not sure it makes sense to talk about the business perspective here.
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.
[EN:] I don't see the difference between description and service description, especially if we move to SOA. Let's combine them.
The semantics of a service is the contract between the service provider and the service requestor that 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.
Types are not enough to understand the intent and meaning of data. For example, 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.
[EN:] Not sure this is part of the architecture, at least not the core concepts, this seems to be the next level up. I think the core concepts do not include interpreting the content of the message.
A Service Description language is a language which is used to describe a service.
[EN:] Not sure this is part of the core concepts, other than as an instance of a service description, or as an example implementation of a service description. We could say that service descriptions have a language, but we could also constrain it to a Web language, and that could be an implicit constraint within the Web architecture constraint.
SOAP is a simple and lightweight XML-based mechanism for creating structured data packages that can exchanged between network applications.
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.
[EN:] Let's not define SOAP but reference it as an example of a technology that implements messaging.
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 feature of the architecture that supports the coordination of results or operations on state in a multi-step interaction.
[EN:] Transactions may be a core concept but they also need a service to manage them.
[EN: the following are not really core concepts I don't think -- the first is a key definition, perhaps for the glossary or introduction, and the WSDL definition is again something for use as an example technology not a core part of the architecture.]
A Web service is [EN: instantiated or provided via a software agent] a software system identified by a URI, whose public interfaces [EN- delete this: 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. [EN: need to include service accessed via transport upon request, returning any results]
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. [EN: not really sure about this either since these are more along the lines of example technologies.]
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 X is a Y relationship denotes the relationship between concepts X and Y, such that every X is also a Y.
Assuming that X is a Y, then:
Essentially, when we say that concept X is 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 service concept, we state that every service has an identifier. In the more specific Web service concept, we note that a Web service has an identifier in the form of a URI identifier.
The concept X is expressed in L relationship denotes that instances of X are values of the language L.
Assuming that X is expressed in L, then:
Essentially, when we say that concept X is expressed in L we use the language L to express instances of X.
For example, in the service description concept, 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 concept X is realized as Y relationship denotes that the concept X is an abstraction of, or view of the concept Y. An equivalent view is that the concept X is implemented using Y.
Assuming that X is realized as Y, then:
Essentially, when we say that the concept or feature X is realized as Y we mean that one of implementing concept X is to ensure that the concepts Y are valid.
For example, in the correlation feature, 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.
[EN: Not sure "relationship" has to be formally defined, might be better to document the rubric as manuals do instead of defining "relationship" as if it were a core architectural concept on a par with service, choreography, and transport.Also need to:
This section is divided into two parts. In section 3.1 Basic Architecture, we describe the basic Web services architecture, the essence of the overall architecture. In section 3.2 Extended Web Services Architecture, we explore the extended Web services architecture, which explains how extended features and functionality can be layered over the basic functionality represented in the basic architecture.
The basic architecture includes Web services technologies capable of:
Software agents in the basic architecture can take on one or all of the following roles:
The figure above illustrates the basic Web services architecture, in which a service requestor and service provider interact based on the service's description information published by the provider and discovered by the requester through some form of discovery agency. Service requesters and providers interact by exchanging messages, which may be aggregated to form MEPs.
In the diagram above, the nodes of the triangle represent roles, as further defined in section 3.1.2 Roles and the edges represent operations, which are further defined in section 3.1.3 Operations
Basic Web services architecture components are typically defined using applications of XML, use XML infoset definitions for message data typing and structuring, and use HTTP for transport. Extended Web services architecture components are typically defined using extensions to the core XML applications and transports, including alternatives to HTTP.
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 web service is described using a standard, formal XML notion, called its service description, that provides all of the details necessary to interact with the service, including message formats (that detail the operations), transport protocols, and location. The nature of the interface hides the implementation details of the service so that it can be used independently of the hardware or software platform on which it is implemented and independently of the programming language in which it is written.
Web services can be used alone or in conjunction with other web services to carry out a complex aggregation or a business transaction.
The previous figure also illustrates the relationships between requesters, providers, services, descriptions, and discovery services in the case where agents take on both requester and provider roles. For example, XML messages compliant with the SOAP specification are exchanged between the requester and provider. The provider publishes a WSDL file that contains a description of the message and endpoint information to allow the requester to generate the SOAP message and send it to the correct destination.
To support the common MEP of request/response, for example, a Web services implementation provides software agents that function as both requesters and providers, as shown in Figure 2. The service requester sends a message in the form of a request for information, or to perform an operation, and receives a message from the service provider that contains the result of the request or operation. The service provider receives the request, processes the message and sends a response. The technologies typically used for this type of Web services interaction include SOAP, WSDL, and HTTP.
Note:
The 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 response messages is typically application-defined.
The following sections provide more formal definitions of the agents, roles, and operations in Web services architecture.
Here is a partial list of Features:
Two major cases of context management need to be addressed:
Where communication sessions (or conversations) are available to maintain shared state
Where communication sessions (or conversations) are not available to maintain shared state
Editorial note | |
EN: Improve definition of long-running transaction. Link the concepts to specific architecture elements, such as SOAP and WSDL. Incorporate the section better into the overall context of transactionality. |
Example uses of choreography definitions include:
A standard choreography definition language provides significant benefits:
Editorial note | |
DO: I don't know if we've modelled infrastructure services very well. Take something like WS-Coordination. It has defined services exchanged for startup and takedown of coordination. And then contexts are transferred during regular service invocation. So it defines a few features (startup and takedown) with their MEPs and it also defines a feature and a particular binding (soap headers for contexts). I think we need to have a way of expressing this notion. |
The following views represent...
As we see above, a Web service instance can serve multiple roles simultaneously. In the peer to peer scenario, each peer Web service instance serves in both the Service Requester and Service Provider roles.
In the graphic above, we see that the Service Requester and Discovery Agency role are fulfilled by the client.
One or more intermediaries may exist in a message path between requester and provider. Intermediaries, where present, cannot interfere with the MEP. Intermediaries may perform certain functions associated with the message such as routing, security, management, or other operations. Examples of MEPs include one-way, request/response, publish/subscribe, and broadcast.
discuss oneway
To ensure interoperability when performing the publish, find and bind operations expressed in the Service Oriented Architecture (SOA) diagram; conceptual and technical standards must be defined for each role and type of interaction. This section will explore each of roles and interactions in order identify each relevant stack of technologies.
There are over arching concerns involving security, management and quality of services that must be addressed at each layer in the conceptual and technical stacks. The various solutions at each layer may or may not be independent of one other. More of these overarching concerns will emerge as the web services paradigm is adopted and evolved. What is most important is building a framework through which all such concerns may be applied to each of the layers in the stack so that as new concerns emerge they may be dealt with flexibly and consistently.
At the end of this section we assemble the independent stacks into a single stack where each additional layer builds upon the capabilities provided by those below it. The vertical towers represent the variety of over arching concerns that must be addressed at every level of each of the stacks.
An important point is that, towards the bottom layers of the stack, the technologies and concepts are relatively more mature and achieve a higher level of standardization than many of the upper layers. The maturation and adoption of Web services will drive the continued development and standardization of the higher levels of the stack and the overarching concerns.
The basic requirements for a network node to play the role of requestor or provider in XML Messaging based distributed computing are the ability to build and/or parse a SOAP message and the ability to communicate over a network (receive and/or send messages).
Typically, a SOAP Server running in a web application server performs these functions. Alternatively, a programming language-specific runtime library can be used that encapsulates these functions within an API. Application integration with SOAP can be achieved by using four basic steps:
In the Figure 1 above at (1), a service requestor’s application creates a SOAP message. This SOAP message is the request that invokes the web service operation provided by the service provider. The XML document in the body of the message can be a SOAP RPC request or a document-centric message as indicated in the service description. The service requestor presents this message together with the network address of the service provider to the SOAP infrastructure (e.g. a SOAP client runtime). The SOAP client runtime interacts with an underlying network protocol (e.g. HTTP) to send the SOAP message out over the network.
The network infrastructure delivers the message to the service provider’s SOAP runtime (e.g. a SOAP server) (2). The SOAP server routes the request message to the service provider's web service. The SOAP runtime is responsible for converting the XML Message into programming language specific objects if required by the application. This conversion is governed by the encoding schemes found within the message.
The web service is responsible for processing the request message and formulating a response. The response is also a SOAP message. The response SOAP message is presented to the SOAP runtime with the service requestor as the destination (3). In the case of synchronous request/response over HTTP, the underlying request/response nature of the networking protocol is used to implement the request/response nature of the messaging. The SOAP runtime sends the SOAP message response to the service requestor over the network.
The response message is received by the networking infrastructure on the service requestor’s node. The message is routed through the SOAP infrastructure; potentially converting the XML message into objects in a target programming language (4). The response message is then presented to the application.
This example uses the request/response transmission primitive that is quite common in most distributed computing environments. The request/response exchange may be synchronous or asynchronous. Other transmission primitives such as one-way messaging (no response), notification (push style response), publish/subscribe are possible using SOAP.
The service description layer is actually a stack of description documents defined using XML Schema.
It is through the service description that the service provider communicates all the specifications for invoking the Web service to the service requestor. The service description is a key contributor to making the Web services architecture loosely coupled and to reducing the amount of required shared understanding, custom programming and integration between the service provider and the service requestor. For example, neither the requestor nor the provider must be aware of the other's underlying platform, programming language, or distributed object model (if any). The service description combined with the underlying XML Message infrastructure defined in the Wire stack sufficiently encapsulates this detail away from the service requestor's application and the service provider’s Web service.
We describe the constituent parts of the service description used in the Web services architecture in two groups, those used to fully describe one Web service and those used to describe interactions or relationships between sets of Web services.
The Web services architecture uses WSDL (Web Services Definition Language)[WSDL 01] for base-level service description. WSDL has been submitted to the W3C and is being actively developed by the W3C Web Services Description WG. WSDL is 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. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints may be combined into services. 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.
The policy description layer is where the additional description necessary to specify the business context, qualities of service, security requirements and offerings, and management requirements. The WSDL document can be complimented by other service description documents to describe these higher-level aspects of the Web service. For example, business context can be described using Universal Data Description Interface (UDDI) [UDDI] data structures in addition to the WSDL document.
The presentation layer describes how to render the input and output messages on a screen for a user to interact with. This is particularly useful for rendering Web services to users on many different types of devices.
Any action that makes a WSDL document available to a requestor, at any stage of the service requestor’s lifecycle, qualifies as service publication.
Since a web service cannot be discovered if it has not been published, service discovery depends upon service publication. The variety of discovery mechanisms parallels the set of publication mechanisms. Any mechanism that allows the service requestor to gain access to the service description and make it available to the application at runtime qualifies as service discovery. The simplest, most static example of discovery is static discovery wherein the service requestor retrieves a WSDL document from a local file. This is usually the WSDL document obtained through a direct publish or the results of a previous find operation. Alternatively, the service may be discovered at design time or run time using a local WSDL registry, or a public or private registry such as UDDI. The variety of service discovery mechanisms is discussed in more detail in the section titled Service Discovery.
Discovery agents populated by crawlers looking for WSIL documents.
Management topologies of available services (but its not a discovery source).
Editorial note | |
CBF: this section needs more, we can get some help the WSIL folks |
Editorial note | |
CBF: To be further developed... |
Editorial note | |
(@@@ need list to be made more open: non-repudiation, etc.) |
Web Services Security Core Specification[23] : message level integrity and confidentiality
XKMS[20] : obtaining security information (values, certificates, management or trust data) from a Web service
XML Signature[21] : document signing
XML Encryption[22] : document encryption
As a result of these definitions it is useful to introduce the role of the Manager which uses the manageability information provided by the manageable resources. Since, the manager needs to be able to manage all of the agents of the Web services architecture, it needs to be able to ‘discover’ manageable resources and access management information of the resource, as well as utilise the control and configuration mechanisms exposed. The Web service Architecture will define the basic set of management information, and control mechanisms supported by each resource identified in the architecture The definition of the ‘Manager’ role, beyond the information model offered to it and how it interacts with the existing roles of the Web services architecture, is outside the scope of this architecture document, which will neither define how the Manager is implemented or how an implementaion is to use the manageability information.
The management concern is satisfied by defining the architecture necessary to make a Web service architecture implementation and a Web service implementation manageable. This architecture must define the minimum, basic information, metrics, configuration, operations, events, and behaviors that a Web services agent must implement in order to be called a ‘manageable Web services agent’. Not all agents must be manageable. Not all Web services architecture implementations must be manageable. Support of this manageable Web services architecture by implementations of the Web services architeture is higly recommended, but not required.
To summarize, the Web Services Architecture does not specify how management concept should to be implemented and does not prescribe any specific management systems. It defines:
Extensible Management Information Schema that directly correlates with the WS Architecture roles
Base set of Management Operations/Events (Manageability) that WS Architecture roles need to provide
Access to Management Information/Operations/Events (Manageability)
Discovery of Access to Management Information
Essentially, it defines an extensible information set and information flow that enable various interested parties to realize management of implementations of Web Services and Web Services Architectures.
The following management information categories must be defined for each manageable agent:
Since the Web services architecture defines how to define information, operations, and notifications through WSDL portTypes, access through bindings, and locateability through ports, it is consistent to use the Web services architecture to describe as well as provide access to and discoverability of the manageable agents of the Web services architecture itself.
A Web service can define its manageability information in a portType and service that is available to the manager or environment. A manageability service WSDL document can be defined that a web service implements to provide access to a web service’s management information by management systems. This interface would include the ability to get configuration and metric data, update configurations, and receive events from manageable web service that the manageability service represents. Other agents of the Web services architecture can provide their own manageability portTypes and ports as well.
The management interface, or service port, of a Web Service, Execution Environment, or Discovery Agency is identified by a URI. This URI will be bound directly to a port type described by WSDL. The WSDL document may contain multiple bindings, including a SOAP over HTTP and an HTTP binding, which allows direct HTTP Get of manageability data items via a URL. The manageability WSDL should be published or advertised to a discovery agency. This provides for the following variation of the Web services oriented architecture triangle:
Editorial note | |
This probably should be added to Usage Scenarios doc |
In this scenario we take the Web services architectural triangle, we can decorate it with the artifacts and roles for management activities. In this example we add the following artifacts
A service environment that the service runs in. The service environment is part of the service provider
A management portType for the execution environment which it advertises (grey oval).
Management portTypes for the Discovery Agencies which they advertise (yellow oval).
A management portType for the service which the service provider advertises (green oval)
A business portType and for the service which the service provider advertises
A discovery agency for management portTypes. The management portType is advertised with a different discovery agency than the busines portType. This is for illustration purposes only and certainly the both portTypes could be available from the same discovery agency.
A business service requester (i.e. stockquote requester) which has access to the business operations.
A separate management service requester which has access to the management operations. Certainly, these requesters could be one and the same.
In this scenario, a manageable service is advertised by the service provider in a management discovery agency. The management service requester discovers the existence and interface of a manageable Web service. It then interacts with the management portType to access the management data of the service.
This same scenario works for management requesters who want to interact with the management PortTypes of the discovery agencies and execution environment. The management service requester can discover the managability portType for the discovery agencies, service environment, and service and interace with any of these agent just like the example of their interaction with a service.
This scenario is not meant to be exclusive of all other ways to advertise and pass manageability information to managers.
The figure above illustrates the complete stack of functions contained in the extended Web services architecture. The extended functionality includes additional technologies in the following areas: discovery agencies, description, and wire. The extended architecture also includes overarching concerns such as security, management, and qualites of service that apply to all agents in the Web services architecture.
Editorial note | |
CBF: what about privacy? where should this be reflected in the stack? |
Editorial note | |
EN: As with the basic architecture, a next step after completing the description of the diagrams will be to fill in the diagrams with reference technologies and specifications. |
In this section we examine how the architecture meets 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. |
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 EDI and peer to peer.
The critical success factor AC002 focuses 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 concepts and 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:
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 pattern concept 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 agent concept 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 agent concept also clarifies that a given agent may adopt the role of a service provider and/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 service concept we state that services have a semantics that may be identified in a service description and that may be expressed in 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 services have descriptions means that these descriptions may be published in discovery agencies and also retrieved from such agencies. In effect, the availability of explicit descriptions enables Web services and agents to discover each other automatically as well as having these hard-coded.
In CSF AC017 are 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 are supported in this architecture at two levels: the single use of a Web service and the combination of Web services.
A message exchange pattern is 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 language such as WSDL.
In addition, the architecture supports the correlation of 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.
The Web services architecture consists of:
A single specification of the way in which artifacts of the system are identified: the Uniform Resource Identifier (URI) [1] (see section 5.1 Identifiers.).
A non-exclusive set of data formats designed for interchange between agents in the system (see section 5.2 Formats.).
A small and non-exclusive set of protocols for interchanging information between agents (see section 5.3 Protocols.).
A small and non-exclusive set of ... (see section 6 Processing Model).
Each of these is discussed in detail in the following sections.
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].
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].
...
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 | |
Specification of message formats, structures and datatypes SHOULD be based on the W3C XML Schema: Structures[4] and XML Schema: Datatypes [5] specifications.
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. |
SOAP provides a simple messaging framework whose core functionality is concerned with providing extensibility. Extensions to the base messaging framework defined by SOAP are modeled and specified as abstract features. Example features include "reliability", "security", "correlation", and "routing". The Web services architecture describes a number of these features (see section 3.2.1 Features), their inter-relationships with one another, and their purpose within the overall architecture.
A SOAP feature MUST clearly and completely specify the content and semantics of the properties used to implement the desired behavior, including any modifications to the SOAP Processing Model (see section 5.2.3.3 Process Model).
Constraint: URIs as identifiers
All SOAP Features MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 5.2.4 WSDL).
Expression of a SOAP Feature is accomplished through one of the two mechanisms provided for by SOAP:
the SOAP Binding Framework, or
as a SOAP Module
One special type of SOAP Feature is the Message Exchange Pattern (MEP). A MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. Examples of MEPs include: request/response, oneway, peer-to-peer conversation, etc. A MEP MAY be supported by one or more underlying protocol binding instances either directly, or indirectly with support from software that implements the required processing to support the SOAP Feature as expressed as a SOAP Module.
Constraint: URIs as identifiers
All MEPs MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 5.2.4 WSDL).
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.
SOAP provides for the exchange of messages between software agents known as SOAP nodes using a variety of underlying transport, or transfer, protocols. The formal set of rules for exchanging a SOAP message via an underlying protocol is called a binding. The SOAP Protocol Binding Framework provides general rules for the specification of bindings to an underlying protocol. The framework also describes the formal relationship between bindings and the SOAP nodes that implement those bindings.
Editorial note | |
CBF: think that this might really belong under the Protocols section rather than the Formats section... |
Editorial note | |
CBF: WSDL harvested material above needs to be turned into appropriate prose. |
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 ... |
Now provide description of SOAP and WSDL Processing models
Editorial note | |
CBF: This is harvested material that needs to be turned into prose. |
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.).
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. |
Sender -- generates or forwards XML data in the form of a Web services message
Receiver -- accepts and processes XML data received as a Web services message
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. |
Editorial note | |
CBF: placeholder. this material needs to be considered and folded in as necessary. |
20021202 | DBO | Incorporated f2f changes from the first morning - use of agents, duplicate diagrams, document overview - and the correlation/reliability feature summary |
20021114 | CBF | incorporate MTF overview proposal. merged with daveo's changes based on 11/13/2002 f2f session. |
20021029 | CBF | tweaked intro per Hugo's suggestion/comment. |
20021028 | CBF | incorporated Jean-Jacques' and Hugo's comments on description. amended status and abstract. some restructuring of the references and appendicies. |
20021025 | CBF | incorporated Heather's description prose. Incorporated Hugo's comments |
20021024 | CBF | incorporated feedback from Joel Munter and some from Jean-Jacques Moreau. |
20021022 | CBF | incorporated revised graphics |
20021020 | CBF | incorporated Eric's section 1.2 updates. Converted to xmlspec-v2.2. |
20020720 | CBF | incorporated SOAP harvest, weaved into the revised flow. added normative biblio. |
20020604 | DBO | Initial Rev |