Usage Scenario:

e-Service Composition in a Behavior based Framework

 

Name:

Authors: Domain: travel planning e-Service

Description

In this use case scenario we discuss several approaches to composition, that depend on (i) how the available e-Services are described and (ii) on the degree of reusability of composite e-Service.

The purpose of this usage scenario is to illustrate the different forms of composition depending on such features, and show that they require different reasoning support and have various degrees of complexity. Of course, a one-shot composition involving only atomic e-Services represent the simplest variant of the composition problem, the most difficult being a reusable composition involving interactive e-Services. Note also that the result of composition is a long running e-Service.

The situation tackled by the use cases is the following. An end-user wants to arrange his/her travel in order to attend to an event (either a conference, or a business meeting, or a tourist event): s/he registers to the event, and arranges for the accommodation and the transportation using the available e-Services. An end-user may participate according to different roles. Each role characterizes different needs of the end-user, in terms of the order in which the various e-Services are executed.

Issues

The problem of composition can be generally stated as follows

Several use cases can be identified, depending on how the (available and composite) e-Services and the specification of the desired behavior of the composite e-Service are represented. Note that, in particular, it is the specification of the desired behavior of the composite e-Service that characterizes the degree of reusability of composition. As it will be clear later, the behavior of the composite e-Service is specified by the end-user in the case of the one-shot composition; it is specified by an e-Service designer in the case of reusable composition.


Actors & Goals

 

Stakeholders & Interests

Automatic composition of e-Services is a challenging and important research areas within the Semantic Web Services. Nowadays, when an end-user request is not satisfied by a single e-Service, but by combining a set of e-Services, it is the end-user's responsibility to manually compose (by sequencing or interleaving) a set of e-Services. Instead, it would be reasonable to have the end-user simply specify his request and have some Composition Agent synthesize it for him.

URL(s) or Other References

e-Service Behavior models:

Modification History

Created by Daniela Berardi and Rick Hull


Use Case: Atomic e-Services, One-Shot Result Scenario

Issues

Note that the clients playing the same role present requests which differ in the value of e-Service parameters, but are equal in the order constraints of e-Service executions.

Note also that the composition addressed in this situation can be called batch composition: the end-user decides the value of the input parameters, once and for all, before starting the e-Service execution. During the e-Service execution, s/he has no control over the execution and cannot change the value of parameters.

Requirements

No specific requirements.

Actors/Roles

Goals/Context

The Composition Agent synthesizes a composite e-Service that realizes a particular request of particular end-user:
  1. Daniela (role: researcher): attend event "conference" "WWW04", which takes place from "17 May 2004" to day "22 May 2004", at "New York"; Daniela departs from "Rome"; the accommodation is in a hotel in "New York".
  2. Rick (role: business manager): attend business meeting "Data Grid", from day "01 June 2004" to "02 June 2004", which takes place at "Atlanta"; the accommodation can be at hotel "Marriott"; Rick departs from "Newark"
  3. Maria (role: tourist): attend tourist event "Venice Carnival", which takes place at "Venice"; the accommodation is at hotel "Danieli" from "10 February 2004" to "25 February 2004"; Maria departs from "Madrid"

Assumptions

Scenario/Steps

Note that not all input parameters of operations are specified: the unspecified parameters represent don't care conditions, on which possibly additional constraints may be added.

In this case, the end-user submits his/her request to the Composition Agent. The Composition Agent synthesizes and executes a composite e-Service by coordinating the available e-Services, then it executes the composite e-Service.

Note that in this case, if the Composition Agent cannot find a composite e-Service that realizes the client request, the composition fails. Also note that, the composite e-Service is different in the three cases, since the three actions are executed in different orders. Therefore, this example shows that an intrinsic feature of e-Services is their behavior.

Extensions

  1. If the Composition Agent cannot satisfy the end-user request, it should ask the client how to relax the constraints.
  2. The case where the available e-Services are interactive and the result of composition is one-shot is an extension of this problem. In particular, advanced form of planning where the actions have a duration (so that each action is associated with an e-Service) can be applied.
  3. Discovery issues about how to discover the available e-Services starting from the desired behavior of composite e-Service. In the case of atomic e-Services discovery essentially focuses on preconditions and effects and signature of the atomic e-Service. In the case of interactive e-Services, see discussion below.
  4. In this example the order in which e-Services are executed depend on the client request, indeed our purpose is to show that e-Services are intrinsically characterized by their behavior. However, it is possible to think to other examples of one-shot composition where invocation order of the atomic e-Services depend on data flow constraints, in such a way that output parameters of some e-Services are the input parameters of other e-Services. Data flow poses interesting challenges, that of course are orthogonal to the grid on which this usage scenario is based.

Reasoning Techniques Required

In general (possibly advanced form of) planning techniques can be used to achieve composition. For informative e-Services, i.e., e-Services that provide information without affecting the world, also data integration technique can be used.


Use Case: Atomic e-Services, Reusable Result Scenario

Issues

Requirements

No specific requirements.

Actors/Roles

Goals/Context

The Composition Agent synthesizes a generic composite e-Service that allows an end-user to attend a generic event (it can be either a conference, or a business meeting or a tourist event), starting from a finite set of atomic e-Services and a specification of the desired behavior of composite e-Service.


Assumptions

Scenario/Steps

Note that at each step of the e-Service execution, the end-user (and only him/her) makes a choice over the next action to perform.

Reasoning Techniques Required

The following reference addresses essentially the same problem and uses a different formalism to achieve an output (of composition) that has essentially the same "effect":
McIlraith, S., Son, T.C. and Zeng, H. ``Semantic Web Services" , IEEE Intelligent Systems. Special Issue on the Semantic Web. 16(2):46--53, March/April, 2001. Copyright IEEE, 2001.


Use Case: General case behavioral e-Service scenario

Issues

Requirements

No specific requirements.

Actors/Roles

(Note that in this example we assume an activity based model, however, it is straightforward to modify the example to cope with a message based model)

Goals/Context

The Composition Agent produces a composite e-Service that behaves as specified by the designer, starting from a finite set of interactive e-Services and a specification of the desired behavior of composite e-Service.

Assumptions

Scenario/Steps

Extensions

  1. In this setting we assumed to have complete information on the specifications of both the e-Service designer and of the available e-Services. From a theoretical point of view it would be interesting to tackle the cases where:

    1. the e-Service designer specification is loosely specified, for example, it contains don't care conditions on the operations to be performed at certain points of the e-Service execution
    2. the behavior of the available e-Services is only partially known (by the software module that creates composition), therefore the (completely specified) composite e-Service has to behave coherently with all the possible complete specifications of a partially known e-Service specification.
  2. In the case of interactive e-Services, the discovery phase has to incorporate/tackle aspects regarding:


Reasoning Techniques Required

If actions have parameters it is an open problem, and it is also not clear how to deal with data flow constraints.