1 Introduction
1.1 Purpose of the Web Service Architecture
Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. This document (WSA) is intended to provide a common definition of a Web service, and define its place within a larger Web services framework to guide the community. The WSA provides a conceptual model and a context for understanding Web services and the relationships between the components of this model.
The architecture does not attempt to specify how Web services are implemented, and imposes no restriction on how Web services might be combined. The WSA describes both the minimal characteristics that are common to all Web services, and a number of characteristics that are needed by many, but not all, Web services.
The Web services architecture is an interoperability architecture: it identifies those global elements of the global Web services network that are required in order to ensure interoperability between Web services.
1.2 Intended Audience
This document is intended for a diverse audience. Expected readers include Web service specification authors, creators of Web service software, people making decisions about Web service technologies, and others.
1.3 Document Organization
This document has two main sections: a core concepts section and a stakeholder's perspectives section.
2 Concepts and Relationships provides the bulk of the conceptual model on which conformance constraints could be based. For example, the resource concept states that resources have identifiers (in fact they have URIs). Using this assertion as a basis, we can assess conformance to the architecture of a particular resource by looking for its identifier. If, in a given instance of this architecture, a resource has no identifier, then it is not a valid instance of the architecture.
While the concepts and relationships represent an enumeration of the architecture, the stakeholders' perspectives approaches from a different viewpoint: how the architecture meets the goals and requirements. In this section we elucidate the more global properties of the architecture and demonstrate how the concepts actually achieve important objectives.
A primary goal of the Stakeholder's Perspectives section is to provide a top-down view of the architecture from various perspectives. For example, in the 3.6 Web Services Security section we show how the security of Web services is addressed within the architecture. The aim here is to demonstrate that Web services can be made secure and indicate which key concepts and features of the architecture achieve that goal.
The key stakeholder's perspectives supported in this document reflect the major goals of the architecture itself: interopability, extensibility, security, Web integration, implementation and manageability.
1.4 What is a Web service?
For the purpose of this Working Group and this architecture, and without prejudice toward other definitions, we will use the following definition:
[Definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.]
1.4.1 Agents and Services
A Web service is an abstract notion that must be implemented by a concrete agent. (See Figure 1-1) The agent is the concrete piece of software or hardware that sends and receives messages, while the service is the resource characterized by the abstract set of functionality that is provided. To illustrate this distinction, you might implement a particular Web service using one agent one day (perhaps written in one programming language), and a different agent the next day (perhaps written in a different programming language) with the same functionality. Although the agent may have changed, the Web service remains the same.
1.4.2 Requesters and Providers
The purpose of a Web service is to provide some functionality on behalf of its owner -- a person or organization, such as a business or an individual. The provider entity is the person or organization that provides an appropriate agent to implement a particular service. (See Figure 1-1: Basic Architectural Roles.)
A requester entity is a person or organization that wishes to make use of a provider entity's Web service. It will use a requester agent to exchange messages with the provider entity's provider agent.
(In most cases, the requester agent is the one to initiate this message exchange, though not always. Nonetheless, for consistency we still use the term "requester agent" for the agent that interacts with the provider agent, even in cases when the provider agent actually initiates the exchange.)
Note:
A word on terminology: Many documents use the term service provider to refer to the provider entity and/or provider agent. Similarly, they may use the term service requester to refer to the requester entity and/or requester agent. However, since these terms are ambiguous -- sometimes referring to the agent and sometimes to the person or organization that owns the agent -- this document prefers the terms requester entity, provider entity, requester agent and provider agent.
In order for this message exchange to be successful, the requester entity and the provider entity must first agree on both the semantics and the mechanics of the message exchange. (This is a slight simplification that will be explained further in 3.3 Using Web Services.)
1.4.3 Service Description
The mechanics of the message exchange are documented in a Web service description (WSD). (See Figure 1-1) The WSD is a machine-processable specification of the Web service's interface, written in WSDL. It defines the message formats, datatypes, transport protocols, and transport serialization formats that should be used between the requester agent and the provider agent. It also specifies one or more network locations at which a provider agent can be invoked, and may provide some information about the message exchange pattern that is expected. In essence, the service description represents an agreement governing the mechanics of interacting with that service. (Again this is a slight simplification that will be explained further in 3.3 Using Web Services.)
1.4.4 Semantics
The semantics of a Web service is the shared expectation about the behavior of the service, in particular in response to messages that are sent to it. In effect, this is the "contract" between the requester entity and the provider entity regarding the purpose and consequences of the interaction. Although this contract represents the overall agreement between the requester entity and the provider entity on how and why their respective agents will interact, it is not necessarily written or explicitly negotiated. It may be explicit or implicit, oral or written, machine processable or human oriented, and it may be a legal agreement or an informal (non-legal) agreement. (Once again this is a slight simplification that will be explained further in 3.3 Using Web Services.)
While the service description represents a contract governing the mechanics of interacting with a particular service, the semantics represents a contract governing the meaning and purpose of that interaction. The dividing line between these two is not necessarily rigid. As more semantically rich languages are used to describe the mechanics of the interaction, more of the essential information may migrate from the informal semantics to the service description. As this migration occurs, more of the work required to achieve successful interaction can be automated.
1.4.5 Overview of Engaging a Web Service
There are many ways that a requester entity might engage and use a Web service. In general, the following broad steps are required, as illustrated in Figure 1-1: (1) the requester and provider entities become known to each other (or at least one becomes know to the other); (2) the requester and provider entities somehow agree on the service description and semantics that will govern the interaction between the requester and provider agents; (3) the service description and semantics are realized by the requester and provider agents; and (4) the requester and provider agents exchange messages, thus performing some task on behalf of the requester and provider entities. (I.e., the exchange of messages with the provider agent represents the concrete manifestation of interacting with the provider entity's Web service.) These steps are explained in more detail in 3.4 Web Service Discovery. Some of these steps may be automated, others may be performed manually.
2 Concepts and Relationships
2.1 Introduction
The formal core of the architecture is this enumeration of the concepts and relationships that are central to Web services' interoperability.
2.2 How to read this section
The architecture is described in terms of a few simple elements: concepts, relationships and models. Concepts are often noun-like in that they identify things or properties that we expect to see in realizations of the architecture, similarly relationships are normally linguistically verbs.
As with any large-scale effort, it is often necessary to structure the architecture itself. We do this with the larger-scale meta-concept of model. A model is a coherent portion of the architecture that focuses on a particular theme or aspect of the architecture.
2.2.1 Concepts
A concept is expected to have some correspondence with any realizations of the architecture. For example, the message concept identifies a class of object (not to be confused with Objects and Classes as are found in Object Oriented Programming languages) that we expect to be able to identify in any Web services context. The precise form of a message may be different in different realizations, but the message concept tells us what to look for in a given concrete system rather than prescribing its precise form.
Not all concepts will have a realization in terms of data objects or structures occurring in computers or communications devices; for example the person or organization refers to people and human organizations. Other concepts are more abstract still; for example, message reliability denotes a property of the message transport service — a property that cannot be touched but nonetheless is important to Web services.
Each concept is presented in a regular, stylized way consisting of a short definition, an enumeration of the relationships with other concepts, and a slightly longer explanatory description. For example, the concept of agent includes as relating concepts the fact that an agent is a computational resource, has an identifier and an owner. The description part of the agent explains in more detail why agents are important to the archicture.
2.2.2 Relationships
Relationships denote associations between concepts. Grammatically, relationships are verbs; or more accurately, predicates. A statement of a relationship typically takes the form: concept predicate concept. For example, in agent, we state that:
- An agent is
a computational resource
This statement makes an assertion, in this case about the nature of agents. Many such statements are descriptive, others are definitive:
- A message has
Such a statement makes an assertion about valid instances of the architecture: we expect to be able to identify the message sender in any realization of the architecture. Conversely, any system for which we cannot identify the sender of a message is not conformant to the architecture. Even if a service is used anonymously, the sender has an identifier but it is not possible to associate this identifier with an actual person or organization.
2.2.3 Concept Maps
Many of the concepts in the architecture are illustrated with concept maps. A concept map is an informal, graphical way to illustrate key concepts and relationships. For example the diagram:
Figure 2-1. Concept Map
shows three concepts which are related in various ways. Each box represents a concept, and each arrow (or labeled arc) represents a relationship.
The merit of a concept map is that it allows rapid navigation of the key concepts and illustrates how they relate to each other. It should be stressed however that these diagrams are primarily navigational aids; the written text is the definitive source.
2.2.4 Model
A model is a coherent subset of the architecture that typically revolves around a particular aspect of the overall architecture. Although different models share concepts, it is usually from different points of view; the major role of a model is to explain and encapsulate a significant theme within the overall Web services architecture.
For example, the Message Oriented Model focuses and explains Web services strictly from a message passing perspective. In particular, it does not attempt to relate messages to services provided. The Service Oriented Model, however, lays on top of and extends the Message Oriented Model in order to explain the fundamental concepts involved in service - in effect to explain the purpose of the messages in the Message Oriented Model.
Each model is described separately below, in terms of the concepts and relationships inherent to the model. The ordering of the concepts in each model section is alphabetical; this should not be understood to imply any relative importance. For a more focused viewpoint the reader is directed to the Stakeholder's perspectives section which examines the architecture from the perspective of key stakeholders of the architecture.
The reason for choosing an alphabetical ordering is that there is a large amount of cross-referencing between the concepts. As a result, it is very difficult, if not misleading, to choose a non-alphabetic ordering that reflects some sense of priority between the concepts. Furthermore, the optimal ordering depends very much on the point of view of the reader. Hence, we devote the Stakeholders perspectives section to a number of prioriterized readings of the architecture.
2.2.5 Conformance
Unlike language specifications, or protocol specifications, conformance to an architecture is necessarily a somewhat imprecise art. However, the presence of a concept in this enumeration is a strong hint that, in any realization of the architecture, there should be a corresponding feature in the implementation. Furthermore, if a relationship is identified here, then there should be corresponding relationships in any realized architecture. The consequence of non-conformance is likely to be reduced interoperability: The absence of such a concrete feature may not prevent interoperability, but it is likely to make such interoperability more difficult.
A primary function of the Architecture's enumeration in terms of models, concepts and relationships is to give guidance about conformance to the architecture. For example, the architecture notes that a message has a message sender; any realization of this architecture that does not permit a message to be associated with its sender is not in conformance with the architecture. For example, SMTP could be used to transmit messages. However, since SMTP (at present) allows forgery of the sender's identity, SMTP by itself is not sufficient to discharge this responsibility.
2.3 The Architectural Models
This architecture has four models, illustrated in Figure 2-2. Each model in Figure 2-2 is labeled with what may be viewed as the key concept of that model.
The four models are:
The Message Oriented Model focuses on messages, message structure, message transport and so on — without particular reference as to the reasons for the messages, nor to their significance.
Figure 2-3. Simplified Message Oriented Model
The essence of the message model revolves around a few key concepts illustrated above: the agent that sends and receives messages, the structure of the message in terms of message headers and bodies and the mechanisms used to deliver messages. Of course, there are additional details to consider: the role of policies and how they govern the message level model. The abridged diagram shows the key concepts; the detailed diagram expands on this to include many more concepts and relationships.
The Service Oriented Model focuses on aspects of service, action and so on. While clearly, in any distributed system, services cannot be adequately realized without some means of messaging, the converse is not the case: messages do not need to relate to services.
Figure 2-4. Simplified Service Oriented Model
The Service Oriented Model is the most complex of all the models in the architecture. However, it too revolves around a few key ideas. A service is realized by an agent and used by another agent. Services are mediated by means of the messages exchanged between requester agents and provider agents.
A very important aspect of services is their relationship to the real world: services are mostly deployed to offer functionality in the real world. We model this by elaborating on the concept of a service's owner — which, whether it is a person or an organization, has a real world responsibility for the service.
Finally, the Service Oriented Model makes use of meta-data, which, as described in 3.1 Service Oriented Architecture, is a key property of Service Oriented Architectures. This meta-data is used to document many aspects of services: from the details of the interface and transport binding to the semantics of the service and what policy restrictions there may be on the service. Providing rich descriptions is key to successful deployment and use of services across the Internet.
The Resource Oriented Model focuses on resources that exist and have owners.
Figure 2-5. Simplified Resource Oriented Model
The resource model is adopted from the Web Architecture concept of resource. We expand on this to incorporate the relationships between resources and owners.
The Policy Model focuses on constraints on the behavior of agents and services. We generalize this to resources since policies can apply equally to documents (such as descriptions of services) as well as active computational resources.
Figure 2-6. Simplified Policy Model
Policies are about resources. They are applied to agents that may attempt to access those resources, and are put in place, or established, by people who have responsibility for the resource.
Policies may be enacted to represent security concerns, quality of service concerns, management concerns and application concerns.
2.3.1 Message Oriented Model
The Message Oriented Model focuses on those aspects of the architecture that relate to messages and the processing of them. Specifically, in this model, we are not concerned with any semantic significance of the content of a message or its relationship to other messages. However, the MOM does focus on the structure of messages, on the relationship between message senders and receivers and how messages are transmitted.
The MOM is illustrated in the Figure 2-7:
2.3.1.1 Address
2.3.1.1.1 Definition
An address is that information required by a message transport mechanism in order to deliver a message appropriately.
2.3.1.1.2 Relationships to other elements
- An address is
information used to describe how and where to deliver messages.
- An address may be
a URI.
- An address is
typically transport mechanism specific.
- An address may be contained
in the message envelope.
2.3.1.1.3 Explanation
In order for message transport mechanisms to function, it is normally necessary to provide information that allows messages to be delivered. This is called the address of the message receiver.
Typically, the form of the address information will depend of the particular message transport. In the case of an HTTP message transport, the address information will take the form of a URL.
The precise method that a message sender uses to convey address information will also depend on the transport mechanism used. On occasion, the address information may be provided as additional arguments to the invoking procedure. Or the address information may be located within the message itself; typically in the message envelope.
2.3.1.2 Delivery Policy
2.3.1.2.1 Definition
A delivery policy is a policy that constrains the methods by which messages are delivered by the message transport.
2.3.1.2.2 Relationships to other elements
- Delivery policy is
a policy
- Delivery policy constrains
- Delivery policy may be expressed
in a policy description language
- Delivery policy may express
the quality of service associated with delivering a message by a message transport mechanism
2.3.1.2.3 Explanation
Delivery policies are those policies that relate to the delivery of messages.
Typically, a delivery policy applies to the combination of a particular message and a particular message transport mechanism. The policies that apply, however, may originate from descriptions in the message itself, or be intrinsic to the transport mechanism, or both.
Examples of delivery policies include quality of service assurances — such as reliable versus best effort message delivery — and security assurances — such as encrypted versus unencrypted message transport. Another kind of delivery policy could take the form of assertions about recording an audit of how the message was delivered.
2.3.1.3 Message
2.3.1.3.1 Definition
A message is the basic unit of data sent from one Web services agent to another in the context of Web services.
2.3.1.3.2 Relationships to other elements
- a message is
a unit of data sent from one agent to another
- a message may be part of
- a message may be described using
a service description language
- a message has
- a message has
one or more message recipients
- a message may have
an identifier
- a message has
a message body
- a message has
zero or more message headers
- a message has
- a message is delivered by
a message transport system
- a message may have
a delivery policy associated with it
2.3.1.3.3 Explanation
A message represents the data structure passed from its sender to its recipients. The structure of a message is defined in a service description.
The main parts of a message are its envelope, a set of zero or more headers, and the message body. The envelope serves to encapsulate the component parts of the message and it serves as a well-known location for message transport services to locate necessary addressing information. The header holds ancillary information about the message and facilitates modular processing. The body of the message contains the message content or URIs to the actual data resource.
A message can be as simple as an HTTP GET request, in which the HTTP headers are the headers and the parameters encoded in the URL are the content. Note that extended Web services functionality in this architecture is not supported in HTTP headers.
A message can also simply be a plain XML document. However, such messages do not support extended Web services functionality defined in this architecture.
A message can be a SOAP XML, in which the SOAP headers are the headers. Extended Web services functionality are supported in SOAP headers.
2.3.1.4 Message Body
2.3.1.4.1 Definition
A message body is the structure that represents the primary application-specific content that the message sender intends to deliver to the message recipient.
2.3.1.4.2 Relationships to other elements
- a message body is contained by
the message envelope.
- a message body is
the application-specific content intended for the message recipient.
2.3.1.4.3 Explanation
The message body provides a mechanism for transmitting information to the recipient of the message. The form of the message body, and other constraints on the body, may be expressed as part of the service description.
In many cases, the precise interpretation of the message body will depend on the message headers that are in the message.
2.3.1.5 Message Correlation
2.3.1.5.1 Definition
Message correlation is the association of a message with a context. Message correlation ensures that a requester agent can match the reply with the request, especially when multiple replies may be possible.
2.3.1.5.3 Explanation
Message correlation allows a message to be associated with a particular purpose or context. In a conversation, it is important to be able to determine that an actual message that has been received is the expected message. Often this is implicit when conversations are relayed over stream-oriented message transports; but not all transports allow correlation to be established so implicitly.
For situations where correlation must be handled explicitly, one technique is to associate a message identifier with messages. The message identifier is an identifier that allows a received message 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 also be realized by the underlying protocol. For example, HTTP/1.1 allows one to correlate a request with its response.
2.3.1.6 Message Envelope
2.3.1.6.1 Definition
A message envelope is the structure that encapsulates the component parts of a message: the message body and the message headers.
2.3.1.6.2 Relationships to other elements
- a message envelope may contain
address information about the intended recipients of its associated message
- a message envelope contains
the message body.
- a message envelope contains
the message headers.
2.3.1.6.3 Explanation
How is a message associated with its destination address?
There is an unresolved issue here. A message somehow must be associated with its destination address. This combination of the message with its destination address seems to be a significant architectural concept, yet SOAP does not require that the address be included in the message header.
Resolution:
None recorded.
The message envelope may contain information needed to actually deliver messages. If so, it must at least contain sufficient address information so that the message transport can deliver the message. Typically this information is part of the service binding information found in a WSDL document.
Other metadata that may be present in an envelope includes security information to allow the message to be authenticated and quality of service information.
A correctly design message transport mechanism should be able to deliver a message based purely on the information in the envelope. For example, an encrypted message that fully protects the identities of the sender, recipient as well as the message content, may still be delivered using only the address information (and the encrypted data stream itself).
2.3.1.7 Message Exchange Pattern (MEP)
2.3.1.7.1 Definition
A Message Exchanage Pattern (MEP) is a template, devoid of application semantics, that describes a generic pattern for the exchange of messages between agents. It describes relationships (e.g., temporal, causal, sequential, etc.) of multiple messages exchanged in conformance with the pattern, as well as the normal and abnormal termination of any message exchange conforming to the pattern.
2.3.1.7.2 Relationships to other elements
- a message exchange pattern describes
a generic pattern for the exchange of messages between agents.
- a message exchange pattern should have
a unique identifier
- a message exchange pattern may realize
- a message exchange pattern may describe
a service invocation
2.3.1.7.3 Explanation
Distributed applications in a Web services architecture communicate via message exchanges. These message exchanges are logically factored into patterns that may be composed at different levels to form larger patterns. A Message Exchange Pattern (MEP) is a template, devoid of application semantics, that describes a generic pattern for the exchange of (one-way) messages between agents. The patterns can be described by state machines that define the flow of the messages, including the handling of faults that may arise, and the correlation of messages.
What is the difference between an MEP and a Choreography?
The precise difference between an MEP and a choreography is unresolved. Some view MEPs as being atomic patterns, and a choreography as including composition of patterns. Also, a choreography generally describes patterns that include application semantics (choreography = MEPs + application semantics), whereas an MEP is devoid of application semantics. Finally, there is usually a difference in scale between an MEP and a choregraphy: A choreography often makes use of MEPs as building blocks.
Resolution:
None recorded.
Messages that are instances of an MEP are correlated, either explicitly or implicitly. The exchanges may be synchronous or asynchronous.
In order to promote interoperability, it is useful to define common MEPs that are broadly adopted and unambiguously identified. When a MEP is described for the purpose of interoperability, it should be associated with a URI that will identify that MEP.
Some protocols may natively support certain MEPs, e.g., HTTP natively supports request-response. In other cases there is may be additional glue needed to map MEPs onto a protocol.
Web service description languages at the level of WSDL view MEPs from the perspective of a particular service actor. A simple request-reponse MEP, for example, appears as an incoming message which invokes an operation and an associated outgoing message with a reply.
An MEP is not necessarily limited to capturing only the inputs and outputs of a single service. Consider the pattern:
agent A uses an instance of an MEP (possibly request-response) to communicate initially with B.
agent B then uses a separate, but related instance of an MEP to communicate with C.
agent A uses another instance of an MEP to communicate with C but gets a reply only after C has processed (2).
This example makes it clear that the overall pattern cannot be described in terms of the inputs and outputs of any single interaction. The pattern involves constraints and relationships among the messages in the various MEP instances. It also illuminates the fact that exchange (1) is in in-out MEP from the perspective of actor B, and mirrored by an out-in MEP from the perspective of actor A. Finally, an actual application instantiates this communication pattern and completes the picture by adding computation at A, B and C to carry out application-specific operations.
It is instructive to consider the kinds of fault reporting that occur in such a layering. Consider a fault at the transport protocol level. This transport level may itself be able to manage certain faults (e.g., re-tries), but it may also simply report the fault to the binding level. Similarly the binding level may manage the fault (e.g., by re-initiating the underlying protocol) or may report a SOAP fault. The choreography and application layers may be intertwined or separated depending on how they are architected. There is also no rigid distinction between the choreography and binding layers; binding-level MEPs are essentially simple choreographies. Conceptually, the choreographic level can enforce constraints on message order, maintain state consistency, communicate choreographic faults to the application, etc. in ways that transcend particular bindings and transports.
2.3.1.8 Message Header
2.3.1.8.1 Definition
A message header is the part of the message that contains information about a specific aspect of the message.
2.3.1.8.2 Relationships to other elements
- a message header is contained in
- a message header may be
a specific well known types
Editorial note The "is-a" relationship here is used in a different way than elsewhere in the document. - a message header may identify
a service role, which denotes the kind of processing expected for the header.
- a message header may be processed
independently of the message body
2.3.1.8.3 Explanation
Message headers represent information about messages that is independently standardized (such as WS-Security) — and may have separate semantics -- from the message body. For example, there may be standard forms of message header that describe authentication of messages. The form of such headers is defined for all messages; although, of course, a given authentication header will be specific to the particular message.
The primary function of headers is to facilitate the modular processing of the message, although they can also be used to support routing and related aspects of message processing. The header part of a message can include information pertinent to extended Web services functionality, such as security, transaction context, orchestration information, message routing information, or management information.
Message headers may be processed independently of the message body, each message header may have an identifying service role that indicates the kind of processing that should be performed on messages with that header. Each message may have several headers, each potentially identifying a different service role.
Although many headers will relate to infrastructure facilities, such as security, routing, load balancing and so on; it is also possible that headers will be application specific. For example, a purchase order processing Web service may be structured into layers; corresponding to different functions within the organization. These stakeholders may process headers of different messages in standardized ways: the customer information may be captured in one standardized header, the stock items by a different standardized header and so on.
2.3.1.9 Message Receiver
2.3.1.9.3 Explanation
The message receiver is an agent that is intended to receive a message from the message sender.
Messages may be passed through intermediaries that process aspects of the message, typically by examining the message headers. The message recipient may or may not be aware of processing by such intermediaries.
Often a specific message receiver, the ultimate recipient, is identified as the final recipient of a message. The ultimate recipient will be responsible for completing the processing of the message.
2.3.1.10 Message Reliability
2.3.1.10.1 Definition
Message reliability is the degree of certainty that a message will be delivered and that sender and receiver will both have the same understanding of the delivery status.
2.3.1.10.2 Relationships to other elements
- message reliability is
a property of message delivery.
- message reliability may be realized by
a combination of message acknowledgement and correlation.
- message reliability may be realized by
2.3.1.10.3 Explanation
The goal of reliable messaging is to both reduce the error frequency for messaging and to provide sufficient information about the status of a message delivery. Such information enables a participating agent to make a compensating decision when errors or less than desired results occur. High level correlation such as "two-phase commit" is needed if more than two agents are involved. Note that in a distributed system, it is theoretically not possible to guarantee correct notification of delivery; however, in practice, simple techniques can greatly increase the overall confidence in the message delivery.
It is important to note that a guarantee of the delivery of messages alone may not improve the overall reliability of a Web service due to the need for end-to-end reliability. (See "End-to-End Arguments in System Design".) It may, however, reduce the overall cost of a Web service.
Message reliability may be realized with a combination of message receipt acknowledgement and correlation. In the event that a message has not been properly received and acted upon, the sender may attempt a resend, or some other compensating action at the application level.
2.3.1.11 Message Sender
2.3.1.11.1 Definition
A message sender is the agent that transmits a message.
2.3.1.11.3 Explanation
A message sender is an agent that transmits a message to another agent. Although every message has a sender, the identity of the sender may not be available to others in the case of anonymous interactions.
Messages may also be passed through intermediaries that process aspects of the message; typically by examining the message headers. The sending agent may or may not be aware of such intermediaries.
2.3.1.12 Message Sequence
2.3.1.12.2 Relationships to other elements
- a message sequence is
a sequence of related messages
- a message sequence may realize
a documented message exchange pattern
2.3.1.12.3 Explanation
A requester agent and a provider agent exchange a number of messages during an interaction. The ordered set of messages exchanged is a message sequence.
This sequence may be realizing a well-defined MEP, usually identified by a URI.
2.3.1.13 Message Transport
2.3.1.13.1 Definition
A Message Transport is a mechanism that may be used by agents to deliver messages.
2.3.1.13.3 Explanation
The message transport is the actual mechanism used to deliver messages. Examples of message transport include HTTP over TCP, SMTP, message oriented middleware, and so on.
The responsibility of the message transport is to deliver a message from a sender to one or more recipient, i.e. transport a SOAP Infoset from one agent to another, possibly with some implied semantics (e.g. HTTP methods semantics).
Message transports may provide different features (e.g. message integrity, quality of service guaranties, etc.).
For a message transport to function, the sending agent must provide the address of the recipient.
2.3.2 The Service Oriented Model
The Service Oriented Model (SOM) focuses on those aspects of the architecture that relate to service and action.
The primary purpose of the SOM is to explicate the relationships between an agent and the services it provides and requests. The SOM builds on the MOM, but its focus is on action rather than message.
The concepts and relationships in the SOM are illustrated in Figure 2-8:
2.3.2.1 Action
2.3.2.1.1 Definition
An action, for the purposes of this architecture, is any action that may be performed by an agent, possibly as a result of receiving a message, or which results in sending a message or another observable state change.
2.3.2.1.3 Explanation
At the core of the concept of service is the notion of one party performing action(s) at the behest of another party. From the perspective of requester and provider agents, an action is typically performed by executing some fragment of a program.
In the WSA, the actions performed by requester and provider agents are largely out of scope, except in so far as they are the result of messages being sent or received. In effect, the programs that are executed by agents are not in scope of the architecture, however the resulting messages are in scope.
2.3.2.2 Agent
2.3.2.2.1 Definition
An agent is a program acting on behalf of person or organization. (This definition is a specialization of the definition in [Web Arch]. It corresponds to the notion of software agent in [Web Arch].)
2.3.2.2.3 Explanation
Agents are programs that engage in actions on behalf of someone or something else. For our purposes, agents realize and request Web services. In effect, software agents are the running programs that drive Web services — both to implement them and to access them.
Software agents are also proxies for the entities that own them. This is important as many services involve the use of resources which also have owners with a definite interest in their disposition. For example, services may involve the transfer of money and the incurring of legal obligations as a result.
We specifically avoid any attempt to govern the implementation of agents; we are only concerned with ensuring interopability between systems.
2.3.2.3 Choreography
2.3.2.3.1 Definition
A choreography defines the sequence and conditions under which multiple cooperating independent agents exchange messages in order to perform a task to achieve a goal state.
| Editorial note | |
| This is a different level of abstraction from the definition used by the W3C Web Services Choreography Working Group. | |
2.3.2.3.2 Relationships to other elements
- A choreography uses
one or more service interfaces .
- A choreography defines
the pattern of possible interactions between a set of agents .
- A choreography may be expressed in
a choreography description language
- A choreography pertains to
a given task
- A choreography defines
the relationship between exchanged messages and tasks of a service.
2.3.2.3.3 Explanation
A choreography is a model of the sequence of operations, states, and conditions that control the interactions involved in the participating services. The interaction prescribed by a choreography results in the completion of some useful function. Examples include the placement of an order, information about its delivery and eventual payment, or putting the system into a well-defined error state.
A choreography can be distinguished from an orchestration. An orchestration defines the sequence and conditions in which one Web service invokes other Web services in order to realize some useful function.
A choreography may be described using a choreography description language. A choreography description language permits the description of how Web services can be composed, how service roles and associations in Web services can be established, and how the state, if any, of composed services is to be managed.