Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
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.
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/.
Web services provide a standard means of interoperability among different software applications, running on a variety of platforms and/or frameworks. The architecture presented in this document promotes interoperability through the definition of compatible protocols and extensions, but does not define any application programming interfaces (APIs) for those protocols and extensions. The architecture is neutral with respect to implementation mechanism, operating system, programming language, platform, and framework in a manner 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 Web Services Architecture (WSA) is an instance of a Service Oriented Architecture (SOA). In a SOA, services are published using service descriptions and are accessed 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 or feature 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
This document introduces the Service Oriented Architecture (SOA) style in addition to the architectural styles described in Chapter 4 of Dr. Fielding's thesis [title], and the REST style introduced in Chapter 5. SOAs are described regularly in literature [see refs]. This section 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 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.
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. The document first presents the core concepts and their relationships, then the constraints, qualities, and capabilities 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 provide a common definition of a Web service, and define its place within a larger Web services framework to guide Web services product implementers, Web services specification authors, Web services application developers, and Web services students.
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.
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.
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.
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.
Core concepts include nouns, verbs, and adjectives. Some descriptions have sub-descriptions [this all probably needs a diagram]. For example, one of the core concepts is an agent, which has a description and provides the execution environment for a Web service. Agents are manageable. A legal entity is the owner of an agent, either a human or an enterprise.
Major concepts include:
A concept has a relationship to other concepts. For example, a service has a relationship to a:
A concept may also exhibit certain qualities. For example, a service exhibits the following qualities:
A relationship diagram illustrates the relationships among the core concepts.
[EN: Some concepts are not include in the illustration, and vice versa.]
The architecture is enumerated as a set of conceptsand their relationships.
The core concepts that form the architecture are laid out in this section.
The ordering of the concepts in this section is alphabetical; this should not be understood to imply any relative importance.
An agent is a program acting on behalf of another person, entity, or process [Web Arch].
an agent has an
an agent has an
Agents are programs that engage in some set of actions as representatives of other entities. On the Web, for example, agents can seek information. Agents implement services.
Agents are the computational representatives of legal entities. This architecture specifically eschews any attempt to govern the implementation of agents; it is only concerned with ensuring interopability between systems.
[KATIA] To be consistent with the diagram, I suggest we simply say an agent “provides” services or an agent “requests” services rather than saying an agent “may adopt the role of a service provider” (or requester or both). We can then have rules that say: an agent that provides a service is a service provider; an agent that requests a service is a service requestor; being a service provider and a service requestor are not mutually exclusive.
[Not on diagram]
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.
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
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.
[not on the diagram and not in the glossary]
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.
correlation is a
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.
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: Where does this fit? I thought it was agent? Need to resolve agent -> resource -> service. Later on it says "Deployed resources are the unit of manageability" but agents have to be manageable, don't they? This is confusing.]
A deployed resource is a resource that exists in the physical world.
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
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.
{EN: The diagram does not include this concept, maybe point to David Booth's text, instead of defining it here? Do we really need to define the act of discovery as a core concept, when we are defining registry and description as core concepts?]
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
EN: If this is a type of service, are there others? Is this a case of a sub-definition?]
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.
[EN: Ok, but let's think about including more services, such as a security service, transaction service, orchestration/choreography service, etc.]
[EN: This is a very high level concept and belongs in the glossary, IMHO.]
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.
a feature is a
set of related concepts
a feature has a
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?
An identifier is a preferably opaque string of bits that may be used to associate with a resource
an identifier is a
opaque string of bits
an identifier
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
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.
A legal entity such as a person or a corporation — may be the owner of agents that provide or request Web services.
an legal entity may be
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
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.
[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
[EN: Aren't resources by definition manageable?]
A manageable element is a deployed element that is manageable.
Relationships to other elements
a manageable 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.
A manageability interface is a description of ports and their bindings
a manageability interface
a manageability interface
hasidentificationinformation
a manageability interface
haseventsthat coorespond to lifecycle
a manageability interface
a manageability interface
a manageability interface
[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].
[EN: I think agents are manageable by definition (meaning they have management APIs) and agents are also secure, etc.]
A message is the basic unit of interaction with Web services. The architecture defines an interaction between software agents as an exchange of messages.
a message is a
unit of interaction between agents
a message may be part of
a message has
zero or more message headers
a message has an
a message has a
a message has
a message may have
a message has
zero or more message recipients
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.
A message exchange pattern is a minimal set of messages, together with their sender and receivers, that constitutes a single use of a service.
a message exchange pattern is a
set of messagesbetween agentsthat corresponds to a single instantiationof a service
a message exchange pattern is a
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?
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.
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:] It's also where the architecture is extended. Is this a sub-definition of message?
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
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.
A message description language allows the structure of messages to be described.
a message description language describes
the structure of a message
[EN:] This seems to me more like a "has a" as in a "message has an identifier"
A message identifier is an identifierthat uniquely identifies a message.
a message identifier is
a unique identifier
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.
A message recipient is the agent that is intended — by the message's sender — to consume the message.
a message recipient is a
a message sender consumes
a message
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.
A message sender is the agent that originates a message.
a message sender is a
agenta message sender originates
a message
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.
[EN: The description is self-referencing, it says a representation represents something... ]
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.
a representation is a
data object
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.
A resource is defined by [RFC2396] to be anything that has an identifier.
a resource is an
entity
a resource has an
an identifier
a resource may have a number of
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].
[EN: moved to the concepts/definitions section from the SOA section]
The minimum definition of a service is a software agent with the following properties:
A service is executed on request, is described, and runs in an agent that is manageable and secure...
A service is a set of actions that form a coherent whole from the point of view of a service provider
a service
a service
may be realizedby a set of actions
a service has
a service has
a service has
an identifier
a service has
a service
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
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.
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
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.
a service provider is
a service provider provides
a set of services
a service provider has
a name
From a business perspective, this is the owner of the service. From an architectural perspective, this is the agent that provides the service.
[EN: I thought the legal entity was the owner]
Its role in the client-server message exchange patterns is that of a server.
[EN: but it may also be a client.]
A service requestor is the entity that is responsible for requesting a service from a service provider.
a service requestor is
a service requestor requests
a set of services
a service requestor may have
a name
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.
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.
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 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
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.
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.
a transaction is
a feature
a transaction
is the execution modelof a choreography
Also need to:
[EN: I included this by reference, at least for the moment, as the easiest way to do it.]
In this section we examine how the architecturemeets the Web services requirements. We present this as a series of stakeholders' viewpoints; the objective being that, for example, security represents a major stakeholder's viewpoint of the architecture itself.
|
Editorial note |
|
|
When developing a particular stakeholder's viewpoint, one should make sure that the concepts discussed are properly documented in the architecture. | |
Goal AG003 of the requirementsidentifies Web services must be consistent with the current and evolving nature of the World Wide Web.
This goal can be divided into two sub-goals — relating to the architectural principles of the Weband, more pragmatically, relating the architecture to the various technologies in use.
Critical Success Factor AC011notes that the architecture should be consistent with the architectural principles and design goals of the Web. For our purposes we use the Architecture of the World Wide Webas our reference for the architecture of the Web.
Thisidentifies the architecture of the Web to be founded on a few basic concepts: agents that are programs that represent people, identification of resources using URIs representations of resources as data objects and interaction via standard protocols — most notably of course HTTP.
Unlike the World Wide Webin general, it is of the essence that Web services, like service oriented architectures in general, are essentially about the provision of action. I.e., whereas the World Wide Webis a networked information system, the Web service World Wide Web is a networked service system: information is exchanged between Web service agentsfor the purpose of requesting and provisioning service, not simply information.
This is a key specialization of the World Wide Webin general; and it drives a number of the specific features of this architecture. However, it is also the case that requests for action and the various possible responses are also information and have representations.
The key representational requirement of this architecture is that messages exchanged between Web service agents is encoded in XML. This is consistent with the general principles of the World Wide Web.
This architecture also uses the concept of an agentto identify the computational resource actually involved with Web services. The key properties of agents required to model Web services are that:
However, it is clear that there is a strong correspondence between a Web service agent and a Web agent. Both are computational resources that represent people; our definition requires sufficient detail to be able to account for the greater degree of indirection expected between Web service agents and Web agents.
A third major distinction between this architecture and the World Wide Webis that, for computer programs to be able to interact with other in a meaningful way, it is necessary to model the semanticsof the information exchanged.
So long as the primary purpose of an agent is to render information in a way that is immediately meaningful to human eyes, the semantics of the interactions between agents is essentially straightforward — as is ably captured in the generic HTTP protocol.
However, if an agent is expected to be able to act on information it receives, it becomes necessary to be much more precise as to the intended semantics of the information.
The semantics of the information exchanged between Web service agents is derived from the structure of the messages, the message exchange patterns and conversational patterns between agents. In addition, it is necessary to be precise about
This architecture enables this precision by ensuring that the various aspects of the semantics of the information exchanged between agents can be properly identified. Where appropriate, and possible, it also identifies a number of description languages which can be used to describe different semantic aspects of this exchanged information.
In summary, Web services can be considered to be a specialization of World Wide Webin general; a specialization that reflects the intended purpose of the exchanged information — to be about services. Similarly, this architecture can be viewed as an elaboration of the general WWW architecture; albeit with a significant number of additional concepts.
According to the Web services Architecture requirements, it is a major goal of the architecture that any implementations are inherently scalable and extensible.
This goal is broken down into five critical success factors: modularity, extensibility, simplicity, migration from EDIand peer to peer.
The critical success factor AC002focuses on the modularity of the architecture; with appropriate granularity. This is reduced to an overall conceptual integrity with appropriate decomposition and easy comprehension.
Our architecture is laid out using the simple style of conceptsand relationships. This modeling technique is simple, and yet allows us to expose the critical properties of Web services. A major design goal of the architecture has been the appropriate separation of concerns. In general, this is achieved by rigorous minimalism associated with each concept: only associating those properties of a concept that are truly necessary to meet the requirements.
The overall themes in this architecture can be summarized as:
To support Web services interacting in a peer to peer style, the architecture must support peer to peer message exchange patterns, must permit Web services to have persistent identity, must permit descriptions of the capabilities of peers and must support flexibility in the discovery of peers by each other.
In the message exchange patternconcept we allow for Web services to communicate with each other using a very general concept of message exchange. Furthermore, we allow for the fact that a message exchange pattern can itself be identified -- this permits interacting Web service agents to explicitly reference a particular message pattern in their interactions.
A Web service wishing to use a peer-to-peer style interaction may use, for example, a publish-subscribe form of message exchange pattern. This kind of message exchange is just one of the possible message exchange patterns possible when the pattern is explicitly identifiable.
In the agentconcept we note that agents have identifiers. The primary role of an agent identifier is to permit long running interactions spanning multiple messages. Much like correlation, an agent's identifier can be used to link messages together. For example, in a publish and subscribe scenario, a publishing Web service may include references to the Web service that requested the subscription, separately from and additionaly to, the actual recipient of the service.
The agentconcept also clarifies that a given agent may adopt the role of a service providerand/or a service requestor. I.e., these are roles of an agent, not necessarily intrinsic to the agent itself. Such flexibility is a key part of the peer to peer mode of interaction between Web services.
In the serviceconcept we state that services havea semanticsthat may be identified in a service descriptionand that may be expressedin a service description language. This identification of the semantics of a service, and for more advanced agents the description of the service contract itself, permits agents implementing Web services to determine the capabilities of other peer agents. This is turn, is a critical success factor in the architecture supporting peer-to-peer interaction of Web services.
Finally, the fact that serviceshave descriptionsmeans that these descriptions may be published in discovery agenciesand also retrieved from such agencies. In effect, the availability of explicit descriptions enables Web services and agents to discover each other automatically as well as having these hard-coded.
In CSF AC017are identified two requirements that support applications in a similar manner to traditional EDI systems: reliable messaging and support for long-running stateful choreographed interactions. This architecture supports transactions by allowing messages to be part of message exchanges and extended choreographies. It also permits support for message reliability.
Conversations 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.
Goal AG007 of the requirements identifies that manageability of Web services is an important goal of this architecture.
Management in this case is defined as a set of capabilities for discovering the existence, availability, health, and usage, as well the control and configuration of resources, where resources are defined as Web services, agents of the Web services architecture, and roles undertaken in the architecture.
Unlike other aspects of this architecture, management refers almost exclusively to deployed resources. For example, an executing Web services agent is a resource that may require management, as is an actual deployed Web service and the Web service's service description.
Of course, systems that are deployed in order to help the management of Web services are also potentially subject to management; however, to the extent that such management services are already modeled as Web services, their management will be handled as any other Web service.
This architecture does not attempt to specify completely how Web services are managed; that is be the role of a separate specification. The architecture does, however, identify the key concepts and relationships involved in modeling manageability.
Critical Success Factor AC018 states that the architecture must enable the management and provisioning of Web services.
The central concept around which manageability is modeled here is the concept of physically deployed resource. A deployed resource is a resource that physically exists; and a manageable resource is one whose configuration and/or life cycle state is available to a management system.
The key relationship that ensures that the architecture models management appropriately is the realizes relationship. The objects under management — the deployed resources — have a realizes relationship with other elements of the architecture. For example, a Web service is provided by an agent. Both the Web service itself and the agent are realized in some fashion; as are any descriptions of the service; as physically deployed resources, and those deployed resources are themselves potentially manageable.
If a deployed resource `exposes' a management interface — in the sense that the resource can be configured and its life cycle managed — then an automatic management system may be used to assist in managing the life cycle of the resource.
Of course, the specifics of the configuration of a deployed resource will vary depending on many factors; such as the kind of resource it is and the requirements of the application and the environment.
In order to facilitate automatic support for the management of a resource, it is helpful if the manageability of the resource is explicitly described. This architecture permits a deployed resource to identify the manageability semantics of the resource — of course such a description may itself be a manageable resource!
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
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].
What about UUIDs as identifiers as used by UDDI? Don't believe that there is a formally registered URI scheme for UUIDs.
Resolution:
None recorded.
Constraint: URIs as identifiers
URIs MUST be used to identify all conceptual elements of the system (see Web Services Architecture Requirements: AR009.3).
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.
[EN: Cut and pasted from the core concepts section]
SOAPis a simple and lightweight XML-based mechanism for creating structured data packages that can exchanged between network applications.
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.
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.
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 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 7.3.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 7.3.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 7.3.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.
Constraint: URIs as identifiers
All SOAP Protocol Bindings MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 7.3.4 Description Should Use WSDL).
[EN: Moved from the core concepts section]
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
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.
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.
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. | |
Now provide description of Web service protocols
SOAP protocol binding framework
-------------------------------
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#transpbindframew
The SOAP Protocol Binding Framework provides general rules for the
specification of protocol bindings; the framework also describes the
relationship between bindings and SOAP nodes that implement those
bindings.
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#bindfw
The creation, transmission, and processing of a SOAP message,
possibly through one or more intermediaries, is specified in terms
of a distributed state machine.
... each SOAP message is modeled as an XML Infoset ...
... the XML Infoset of a SOAP message MUST NOT include a DTD ...
Bindings MAY provide for streaming when processing messages.
Bindings MAY depend on state that is modeled as being outside
of the SOAP XML Infoset.
| Editorial note | |
| CBF: This is harvested material that needs to be turned into prose. | |
| Editorial note | |
| talk about modules and layering ... interoperability is possible without all "web services" using the same set of features and modules, but there has to be a conceptual agreement on what the features are, how they are packaged, and how they are layered ... | |
something about HTTP, possibly as normative binding described for SOAP.
HTTP has a special status in the W3C Web Services Architecture for a number of both practical and theoretical reasons. For one, early versions of SOAP (and XML-RPC, which is still widely used in existing web services) were explicitly tied to HTTP. SOAP 1.1 implied a certain amount of protocol-independence, and SOAP 1.2 makes this explicit, but HTTP is still the dominant means of communicating between web services agents. Also, HTTP is
Many believe that HTTP is the "native" protocol of the Web because it was designed to work with the URIs that identify Web resources. While HTTP has become almost ubiquitous, and many of the issues surrounding its earlier incarnations have been resolved in subsequent versions of the standard and by "industrial strength" implementations, it is not the only protocol upon which Web services can be built. For example
TCP
UDP
BEEP
JMS Service Provider's protocol
proprietary messaging systems
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. | |
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.).
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:
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
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 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.
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
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 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:
valid
if E a valid expression in L then E is an instance of concept X
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 concept X has a Y relationship denotes that every instance of X is associated with an instance of Y.
Assuming that X has a Y, then:
valid
if E is an instance of X then Y is valid for E.
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 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.
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.
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.
[EN: Here's where we should describe the recommended technologies, such as SOAP/WSDL/UDDI for implementing the architecture.]
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:
Integration with the Web - SOAP 1.1 web services use the HTTP infrastructure to move messages around, and allow standardization of the format of the payload of a POST command, but conventional Web applications are not able to directly access most web services. In particular, it is not possible to hyperlink to SOAP 1.1 web service via HTML links, XSLT document() functions, etc. As many critics have noted, hyperlinks are the very essence of the World Wide Web, and this limitation is quite severe. SOAP 1.2 addresses this issue at a technical level, but there is little architectural guidance available as to when and how to use the various HTTP-friendly and protocol-neutral aspects of the SOAP protocol.
Extension mechanism - SOAP 1.2 provides an extension mechanism via headers, but the implications, --such as when to use XML markup in the body of a message, when to use headers -- are not spelled out. Likewise, it is not clear how SOAP-based protocol extensibility would interoperate with or complement traditional Web applications.
Overall understanding of modules and layering - SOAP 1.2 provides a framework within which additional features can be added via headers, but there is little agreement on the specific categories of functionality that these headers will specify nor on specific format standards.
Detailed objectives are laid out in the accompanying Requirements document [WSAREQ], but at a high level the W3C Web Services Architecture is intended to:
Integrate different conceptions of web services under a common "reference architecture". There isn't a simple one to one correspondence between the architecture of the web and the architecture of existing SOAP-based web-services, but there is a substantial overlap, and the Web Services Architecture needs to identify what they have in common and how they differ.
Describe the "best practice" for the set of rules that existing Web service agents typically follow, and to rationalize the best practices from the different communities. The objective is not to say "this practice is good" or "that practice is bad", but rather to say "this specific approach is brittle in the following ways." or "That common practice works better if X occurs as well as Y."
Prescribe a framework for the future evolution of web services standards that will promote a healthy mix of interoperability and innovation. That framework must accommodate the edge cases of pure SOAP-RPC at one side and HTTP manipulation of business document resources at the other side, but focus on the area in the middle where the different architectural styles are both taken into consideration.
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.
| Editorial note | |
| CBF: placeholder. this material needs to be considered and folded in as necessary. | |
Since REST is so well defined, listing the architectural elements is pretty easy. They're already listed here; http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm Data elements are; resources, resource identifiers, representation, representation metadata, resource metadata, control data Components are; origin server, gateway, proxy, user agent Connectors are; client, server, cache, resolver, tunnel "features", as I understand what it is that we're mining, are difficult to extract from an architecture. But looking at the Web through REST eyes, I'd say that the following could be considered features, even though some are also listed above; - generic interface - intermediaries - stateless interaction - visibility of messages too all components - caching - data streams as arguments
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.
| 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 |