1.5.6 The Process of Engaging a Web Service

There are many ways that a requester entity might engage and use a Web service, depending on how the service description and semantics are created and who creates them, how the requester and provider agents are created, how the parties make the decision to interact with each other, and many other factors. It would impossible to diagram or describe all the steps that might be required in all possible scenarios. Instead, to provide an overall birds-eye view of the process, we will look at what steps are common to (virtually) all scenarios, i.e., what steps must be somehow performed in every scenario encompassed by this architecture. Although these steps are necessary, they may not be sufficient: many scenarios will require additional steps, or significant refinements of these fundamental steps. Furthermore, the order in which the steps are performed may vary from situation to situation.

Figure 1: The General Process of Engaging a Web Service

Editorial note
dbooth: Figure 1 may need to be updated, once we get this text stable. Also, not sure how we should label the figures. Also, Figure 1 may need to be resized.

At the most fundamental level, the process for engaging a service involves the following four steps, illustrated in Figure 1: (1) the requester and provider entities "become known to each other"; (2) the requester and provider entities 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 embodied in the requester and provider agents; and (4) the requester and provider agents exchange messages. These steps are explained in more detail below.

1. Step 1. The requester and provider entities "become known to each other", in the sense that whichever party initiates the interaction must become "aware" of the other party. To be precise, this means that whichever agent initiates the message exchange must first obtain the address of the other agent. There are two cases.

   1. In a typical case, the requester agent will be the initiator. In this case, we would say that the requester entity must become "aware" of the provider entity, i.e., the requester agent must somehow obtain the address of the provider agent. There are two ways this may typically occur: (1) the requester entity may obtain the provider agent's address directly from the provider entity; or (2) the requester entity may use a "discovery service" to "discover" a suitable service description (which contains the provider agent's invocation address or "endpoint") via an associated functional description, either through "manual discovery" or "autonomous selection". These cases are described more fully in the section on Web Service Discovery.

      Editorial note
      dbooth: Step 1 is not yet illustrated in Figure 1. (The number in Figure 1 are off by 1.)

   2. In other cases, the provider agent may initiate the exchange of messages between the requester and provider agents. In this case, saying that the requester and provider entities "become known to each other" actually means that the provider entity becomes "aware" of the requester entity, i.e., the provider agent somehow obtains the address of the requester agent. How this occurs is application dependent and irrelevant to this architecture. Although this case is expected to be less common than when the requester is the initiator, it is important in some "push" or "subscription" scenarios.

2. Step 2. The requester entity and provider entity agree on the service description (a WSDL document) and semantics that will govern the interaction between the requester agent and the provider agent. This does not necessarily mean that the requester and provider entities must communicate or negotiate with each other. It simply means that both parties must have the same (or compatible) understandings of the service description and semantics, and intend to uphold them. There are many ways this can be achieved, such as:

   • The requester and provider entities may communicate directly with each other, to explicitly agree on the service description and semantics.

   • The provider entity may publish and offer both the service description and semantics as take-it-or-leave-it "contracts" that the requester entity must accept unmodified as conditions of use.

   • The service description and semantics (excepting the network address of the particular service) may be defined as a standard by an industry organization, and used by many requester and provider entities. In this case, the act of the requester and provider entities "reaching agreement" is accomplished by both parties independently conforming to the same standard.

   • The service description and semantics may be defined and published by the requester entity (even if they are written from provider entity's perspective), and offered to provider entities on a take-it-or-leave-it basis. This may occur, for example, if a large company requires its suppliers to provide Web services that conform to a particular service description and semantics. In this case, agreement is achieved by the provider entity adopting the service description and semantics that the requester entity has published.

   Depending on the scenario, Step 2 (or portions of Step 2) may be performed prior to Step 1.

3. Step 3. The service description and semantics are input to, or embodied in, both the requester agent and the provider agent as appropriate. In other words, the information in them must either be input to, or implemented in, the requester and provider agents. There are many ways this can be achieved, and this architecture does not specify or care what means are used. For example:

   • An agent could be hard coded to implement a particular, fixed service description and semantics.

   • An agent could be coded in a more general way, and the desired service description and/or semantics could be input dynamically.

   • An agent could be created first, and the service description and/or semantics could be generated or deduced from the agent code.

   Regardless of the approach used, from an information perspective both the semantics and the service description must somehow be input to, or embodied in, both the requester agent and the provider agent before the two agents can interact.

   In fact, it is a slight simplification to say that the requester and provider agents implement the same semantics and WSD, for two reasons: (1) the requester agent implements them from the perspective of the requester entity, while the provider agent implements them from the perspective of the provider entity (for example, one party's input is the other party's output); and (2) the requester and provider agents only need to implement those aspects of the WSD and semantics that are relevant to their respective roles.

4. Step 4. The requester agent and provider agent exchange SOAP messages on behalf of their owners.