Web Service Architectural Roles

David Booth <dbooth@w3.org>

$Revision: 1.24 $ of $Date: 2003/08/06 18:42:52 $ by $Author: dbooth $

This document: http://www.w3.org/2002/ws/arch/2/10/roles_clean.htm

This document attempts to precisely identify the architectural roles that are relevant in various general-purpose Web service scenarios. 

Status of This Document

This document represents the views of the author only.  It has no official status.  Comments are welcome.

Table of Contents

 

Scenario 0: Web Interaction Without Web Services

Web services seek to automate interactions that might otherwise be performed manually, by a human through a browser interacting with a Web server that was previously programmed to host a particular application, as depicted in Figure 0 below.

[image: roles_figure_0]

./roles_files/image001.gif
 


Since the Web browser merely acts as a means for the Requester Human to interact with the Web server, this is essentially a human-to-machine interaction.  Although any given application may require a particular pattern of interaction from the user, in most cases each step will provide some human-readable clue about what step is expected next, and humans are flexible enough to respond accordingly.  Thus, there isn't much need to describe the pattern of interaction in a formalized, machine processable format.  However, if we wish to automate these interactions, it is very helpful to have formal descriptions of the interaction.  The following sections explicitly identify what actors, actions and artifacts are required to make it the process work in various scenarios.

Scenario 1: Parties Known in Advance

In this simple scenario, two organizations that are already known to each other wish to automate their interactions using Web services.  Semantics are specified manually, by humans.  The FredCo/Widgets-R-Us scenario, the Jane/Sue bridge scenario, and the BobCo/SallyCo scenario are variations of this general scenario, which is illustrated and described in Figure 1 below.

Actors

There are four actors in this scenario:

  1. Requester Human, which may be played by one or more humans;
  2. Provider Human, which may be played by one or more humans;
  3. Requester Agent, which is the Client software application that will be communicating with the Provider Agent; and
  4. Provider Agent, which is the Web Server software application.

The Requester Human and Requester Agent are grouped under "Requester Entity" to indicate that they are assumed to operate on behalf of the same organization.  Similarly for the "Provider Entity".

Artifacts/Documents

The Web Service Description ("WSD") in the diagram represents some kind of machine-processable description of the desired interaction.  It is assumed to include syntactic-level descriptions of the messages, datatypes, operations, etc., to be used in the interaction, but does NOT completely define the semantics of the interaction.  

The Semantics includes ALL other relevant information about the desired interaction that is NOT defined in the WSD.  This includes any and all business agreements and other real world ramifications that are relevant to the interaction, whether they are communicated explicitly or not. In the illustration below, the Semantics is depicted as a document, even though it isn't necessarily in any written form.  The Semantics may be communicated verbally or in any combination of written documents, and may be represented in any format that is mutually agreeable.

The WSD and the Semantics, taken together, represent a complete description of the desired interaction.  The WSD represents whatever part of that description is written in a machine processable form; the Semantics represents the rest.  Modeled this way, it is easy to see how the scenario changes as choreography and other semantically rich languages are adopted for use in describing Web services: more of the description moves from the Semantics to the WSD (from yellow to blue in Figure 1).

[image: roles_figure_1]

./roles_files/image002.gif
 


Sequence of Operation

From an architectural point of view, the following sequence occurs.  (Refer to Figure 1 above.)

  1. The Requester Human and the Provider Human somehow agree on the Web Service Description (labeled "WSD") and the Semantics (labeled "Sem") that describe the interaction that they want the Requester Agent and Provider Agent to have. This agreement could be accomplished in any number of ways, and how it is achieved is irrelevant.  Some possibilities:
    1. The Provider Human sends both the WSD and Semantics, in their entirety, to the Requester Human, and the Requester Human accepts them.  For example, the Provider Human might send the information by email.  (This corresponds to the FredCo/Widgets-R-Us scenario or the Jane/Sue Bridge analogy.)
    2. The Requester Human sends both the WSD and Semantics, in their entirety, to the Provider Human, and the Provider Human accepts them.  (This corresponds to the BobCo/SallyCo scenario.)
    3. The Requester Human and the Provider Human work collaboratively to create both the WSD and Semantics.
    4. A third party (not modeled) provides the WSD and the Semantics, and the Requester Human and Provider Human both decide to adopt them.  For example, the Requester Human and the Provider Human might both decide to implement a particular standard.  In this case, the Requester Human and the Provider Human might never communicate directly with each other.
  1. The Requester Human inputs both the WSD and the Semantics to the Requester Agent.  This may be done by any combination of hard coding the information or reading the information dynamically.  The Provider Human completes a similar process for inputting the WSD and Semantics into the Provider Agent. 

In practice, the WSD and Semantics that are input to the Requester Agent should be exactly the same as the WSD and Semantics that are input to the Provider Agent, with the following exceptions:

  1. The role of "Requester" or "Provider" must somehow be specified, so that the Requester Agent and the Provider Agent each know which role they are supposed to play.  (This may be hard coded in the Agents or their environments, but it must be indicated somehow.  Otherwise there would be no difference between the Requester Agent and the Provider Agent!)
  2. Information in the WSD or Semantics that is not relevant to that Agent may be omitted.
  1. The Requester Agent and the Provider Agent interact using whatever means they have agreed upon, as illustrated by the "Interact" arrow in the diagram above.

Scenario 2: Parties Known, Dynamically Getting WSD

Figure 2 shows a variation of Scenario 1, in which the Provider Entity supplies the WSD, and the Requester Agent dynamically obtains the WSD, in order to be sure that it always uses the latest available version.  This allows the WSD to be periodically updated without requiring the Requester Human and Provider Human to renegotiate the semantics (provided that the WSD changes do not affect the semantics).

Actors and Artifacts

The actors and artifacts/documents are the same as in Scenario 1.   

[image: roles_figure_2]

./roles_files/image003.gif
 


Sequence of Operation

The following sequence occurs.  (Refer to Figure 2 above.)

  1. Agree on Semantics.  The Requester Human and the Provider Human agree on the Semantics, as before.  The Semantics somehow indicate what kinds of WSD documents would be compatible with the Semantics. 
  2. Input Semantics.  The Requester Human and the Provider Human input the Semantics to the Requester Agent and the Provider Agent (respectively), as before.
  3. Get WSD.  The Requester Agent gets the current WSD from the Provider Agent.  This may be as simple as an HTTP GET on a URL, or it could involve a third party intermediary.  The WSD must be compatible with the previously agreed Semantics, or an error occurs.
  4. Interact.  The Requester Agent and the Provider Agent interact, as before.

Scenario 3: Multiple Providers, Manual Discovery

In Figure 3, we assume that the Requester Human does not already know what Web service he/she wishes to engage.  He/she uses a Discovery Tool to searches for a Web service that is semantically compatible with what he/she wants to achieve, and then makes a trust decision to use that service.  Semantics are still assumed to be specified manually, by humans. 

Actors

There are five actors in this scenario:

Artifacts/Documents

[image: roles_figure_3]

./roles_files/image004.gif
 


Sequence of Operation

The ordering of these steps can vary somewhat, but all steps must be performed.

  1. Agree on Semantics. The Requester Human and the Provider Human agree on the Semantics that describe the interaction that they want the Requester Agent and Provider Agent to have, as before.  (Remember that the Requester Human and Provider Human do not necessarily have to communicate directly with each other in order to agree on the Semantics.  For example, they both might just decide to use the same Semantics that someone else has defined, without ever talking to each other directly.)
  2. Input Semantics and WSD to Provider Agent.  The Provider Human somehow creates the WSD, and inputs the WSD and the Semantics into the Provider Agent, as before.
  3. Discovery Tool gets WSD and FuncID.  The Discovery Tool somehow gets the WSD and the FuncID from the Provider Human.  How this occurs is irrelevant.  For example, the Provider Human might publish them directly to the Discovery Tool, or Discovery Tool might obtain them indirectly by crawling the Web or through any number of intermediaries, without the Provider Entity having any knowledge of, or direct interaction with, the Discovery Tool.
  4. Requester Human gets WSD.  The Requester Human uses the Semantics to query the Discovery Tool for an acceptable WSD document that corresponds to the desired Semantics.
  5. Input Semantics and WSD to Requester Agent.  The Requester Human inputs the Semantics and WSD to the Requester Agent.
  6. Interact.  The Requester Agent and the Provider Agent interact using whatever means they have agreed upon.

Scenario 4: Multiple Providers, Manual Discovery, WSD from Provider

Figure 4 is a variation of Scenario 3.  The Requestor Human still finds a suitable Web service based on the desired semantics, but the WSD is obtained directly from the Provider Agent.  Semantics are still assumed to be specified manually, by humans, and are fixed in advance. 

Actors

There are five actors in this scenario:

Artifacts/Documents

[image: roles_figure_4]

./roles_files/image005.gif
 


Sequence of Operation

The ordering of these steps can vary somewhat, but all steps must be performed.

  1. Agree on Semantics. As before.
  2. Input Semantics to Provider Agent.  The Provider Human inputs the Semantics to the Provider Agent.
  3. Discovery Tool gets FuncID and WSD URL.  The Discovery Tool somehow gets the WSD URL and the FuncID from the Provider Human.  
  4. Requester Human gets WSD URL.  The Requester Human uses the Semantics to query the Discovery Tool for an acceptable WSD document that corresponds to the desired Semantics. 
  5. Input Semantics and WSD URL to Requester Agent.  The Requester Human inputs the Semantics and WSD URL to the Requester Agent.
  6. Get WSD.  The Requester Agent gets the WSD from the Provider Agent, either directly or indirectly.
  7. Interact.  The Requester Agent and the Provider Agent interact using whatever means they have agreed upon.

Scenario 5: Multiple Providers, Automatic Selection

In Figure 5, the Requester Agent dynamically selects one of several potential Provider Entities that all implement semantically compatible Web service.  (Presumably, the Provider Entities have been pre-screened in advance, so that the Requester Entity can trust the Requester Agent to perform this selection automatically.)  Semantics are still assumed to be specified manually, by humans, and are fixed in advance. 

Actors

There are five actors in this scenario:

Artifacts/Documents

The ordering of these steps can vary somewhat, but all steps must be performed.

[image: roles_figure_5]

./roles_files/image006.gif
 


Sequence of Operation

  1. Agree on Semantics.  As before. 
  2. Input Semantics and WSD to Provider Agent.  The Provider Human somehow creates the WSD, and inputs the WSD and the Semantics into the Provider Agent.
  3. Selection Agent gets WSD and FuncID.  The Selection Agent somehow obtains the WSD and FuncID from the Provider Human. 
  4. Input Semantics to Requester Agent. The Requester Human inputs the desired Semantics to the Requester Agent. 
  5. Select WSD.  The Requester Agent uses the Semantics to query the Selection Agent for an acceptable WSD document that corresponds to the desired Semantics.
  6. Interact.  The Requester Agent and the Provider Agent interact using whatever means they have agreed upon.

Scenario T: Triangle Diagram

This scenario describes the correspondence between the "triangle diagram" and scenarios 4 and 5.  Essentially, the triangle diagram is a higher level abstraction of scenarios 4 and 5.  It merges the Discovery Tools and the Selection Agent into a single "Discovery Agent"; it omits the semantics; and it abstracts away the details of what is inside the Requester Entity and Provider Entity. 

Actors

There are three actors in this scenario:

Artifacts/Documents

[image: roles_figure_t]

./roles_files/image007.gif
 


Sequence of Operation

  1. (Agree on Semantics)
  2. (Input Semantics to Requester Agent and Provider Agent)
  3. Provider Entity publishes WSD.  The Provider Entity publishes the WSD and the Discovery Agent somehow obtains it, either directly or indirectly.  This could involve the Provider Entity actively informing the Discovery Agent (like a registry), or the Discovery Agent might obtain the WSD autonomously (like a search engine).
  4. Requester Entity finds the WSD.  The Requester Entity somehow uses the Discovery Tool to obtain the WSD. 
  5. Interact.  The Requester Agent and the Provider Agent interact using whatever means they have agreed upon.

To Do:

Reduce the number of scenarios?

Variation of 5: Get WSD dynamically

Discuss Choreography: 2 party; multi party.

Add Peer-to-peer scenario

Multiple requesters/ Multiple providers?

Scenario: Setting up a multi-party chat session, or multi-party meeting

Call scenario 5 a "Broker" pattern?