[EN stands for Eric Newcomer and I preface my comments in this text using my initials, EN. The following text collects the reworked sections of the architecture document that effectively constitutes the breakout team's proposal for a new approach to the document. The same text also appears within the existing document to show the proposal for where it would be placed.]
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.
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.
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.