Usage Scenario: Composition of eServices in behavior based model

Authors: 
Rick Hull, Bell Labs, Murray Hill (NJ)
Daniela Berardi, Universita' di Roma "La Sapienza"

Domain: travel planning eService

Description:
A client wants to arrange its travel in order to attend to an event ( either a conference, or a business meeting, or a tourist event): he registers to the event, and arranges for the accomodation and the transportation using the available eServices. There are several classes of clients and the clients belonging to different classes present different needs. The difference in the needs is rendered as difference in the order in which the various operations are executed. 

Issue:

Input:
- a set of available eServices and 
- a client request, (a client is either a human or another eService, however in what follows we consider it to be a human)
Output:
-a new eService
-- obtained by composing ("pieces" of ) the available eServices, 
-- that realizes the client request.

Several use cases can be identified, depending on how the eServices and the client request are represented. Additionally, requests of some clients may show common features, e.g. in terms of constraints. Therefore clients can be grouped in classes so that clients of the same class share similar constraints on their request.

In particular:
-an eService can be:
-- atomic (i.e., discrete, single interaction): each eService presents an input/output behavior, possibly with preconditions and effects
-- interactive: each eService shows a "long-running" behavior, which can be:
    ---message based: behavior as the set of all possible messages that the eService may send or receive
    ---activity based: the behavior is the set of all possible sequences of atomic actions that the eService may perform

-a client request can be:
-- one-shot: it specifies a (particular) request of a particular client belonging to a particular class. Therefore, the result of composition cannot be used for other requests of other clients.
--reusable:  it specifies a generic request of a particular class of clients. Therefore,  the result of composition can be used for the requests of clients belonging to that class, but not for requests of other class of clients.
--generic: it specifies a generic request of a generic class of clients. In this case the result of composition can be used for the requests of clients belonging to any class (possibly, within a certain group of classes) 



Actors & Goals

There are three available eServices:
- for registering to an event (either conference, or business meeting, or tourist event)
- for arranging travel
- for arranging accomodation


There are three classes of clients, with the following characteristics: 
-researcher: all reseachers want to attend to a conference event. Since the registration fees depend on the date the registration is done, usually the researcher registers to the conference quite early. Then, the researcher arrange for the plane travel, since usually also plane fares depend on how much in advance the plane ticket is booked. Finally, the researcher arrange for the accomodation. 

-business manager: all business managers want to attend to a business event. A manager usually has strict timing, therefore, he first wants to arrange the travel so that he stays at the business meeting for the minimum needed time. Then, he registers for the business meeting and finally he arranges for the accomodation.

-tourist: all tourists want to attend to a tourist event. A tourist first would like to arrange for the accomodation for himself and his family. Therefore, after this information is available, the travel is arranged. Finally, the tourist registers for the tourist event.


Stakeholders & Interests
Automatic composition of eServices is a challenging and important research areas within the Semantic Web Services. Nowadays, when a client request is not satisfied by a single eService, but by combining a set of eServices, it is client's responsibility to manually compose (by sequencing or interleaving) a set of eServices. Instead, it would be reasonable to have the client simply specify his request and have some software agent synthesize it for him.


URL(s) or Other References
eService Behavior models:
-Message Based Model: http://www-db.research.bell-labs.com/user/hull/
-Action Based Model: http://www.dis.uniroma1.it/~berardi/


Modification History:
Created by Daniela Berardi and Rick Hull 


Use Case: One shot planning event scenario

Issues: 
-available eServices: atomic (operation with input and output parameters, and possibly preconditions and effects)
- client request: it specifies the particular, contingent need of a particular client, in terms of constraints on the invocation order of the eServices, in terms of particular value of input parameters and possibly in terms of propositional goal that must hold at the end of computation
- the composite eService realizes that particular client request (and no others). In this situation the composition is done at the client level. 

Note that the clients belonging to the same class present requests which differ in the value of eService parameters, but are equal in the order constraints of eService executions. It is the membership to a certain class that denotes the order constraints on eService executions. 

Note also that this problem addresses a particular kind of composition, that can be called "batch" composition: the client decides the value of the input parameters, once and for all, before starting the eService execution. During the eService execution, s/he has no control over the execution and cannot change the value of parameters.


Requirements:
No specific requirements.


Actors: 
available eServices:
1) register_event: 
--Input: event_name, start_registr_date, end_registr_date
--Output: notification of success or failure of operation
--Preconditions: none
--effects: registered_event 

2) book_plane:
--Input: depature_place, date_leave, arrive_place, date_back
--Output: notification of success or failure of operation
--Preconditions: none
--effects: plane_booked

3) book_hotel
--Input: name_hotel, place_hotel, date_leave, date_back
--Output: notification of success or failure of operation
--Preconditions: none
--effects: hotel_booked


particular clients: 

1) particular researcher: Daniela, 
2) particular business manager: Rick, 
3) particular tourist: Maria



Goal: 
particular request of particular client:

1) for the researcher Daniela: attend event "conference" "WWW04", which takes place from "17 May 2004" to day "22 May 2004", at "New York"; Daniela departs from "Rome"; the accomodation is in a hotel in "New York". 

2) for the business manager Rick: attend business meeting "Data Grid", from day "01 June 2004" to "02 June 2004", which takes place at "Atlanta"; the accomodation can be at hotel "Marriot"; Rick departs from "Newark"


3) for the tourist Maria: attend tourist event "Venice Carnival", which takes place at "Venice"; the accomodation is at hotel "Danieli" from "10 February 2004" to "25 February 2004"; Maria departs from "Madrid" 

Assumptions:
For sake of simplicity, the output of operations are simply messages.
Preconditions and effects of operations are propositional formulas
We represent the composite eService as a Finite State Machine.

Scenario/Steps:
-Input for the composition:
--Available eServices (register_event, book_plane, book_hotel)
-- client requests (those presented specified above). Note that not all input paramaters of operations are specified: the unspecified parameters represent don't care conditions, on which possibly additional constraints may be added. For example, the precise specification of client request may be as follows:

1) For researcher Daniela: 

register_event (WWW04, 17 May 2004, 22 May 2004)
book_plane (Rome, date_leave, New York, date_back) 
book_hotel (hotel_name, New York, date_leave, date_back)

Additional constraints on the unspecified parameters:
date_leave is between 14 May 2004 and 16 May 2004 
date_back is between 23 May 2004 and 25 May 2004 

2) For researcher Rick: 

book_plane (Newark, 01 June 2004, Atlanta, 02 June 2004)
register_event (Data Grid, 01 June 2004, 02 June 2004) 
book_hotel (Marriot, Atlanta, 01 June 2004, 02 June 2004)


3) For tourist Maria:

book_hotel (hotel_name, Venice, 10 February 2004, 25 February 2004) 
book_plane (Madrid, 10 February 2004, 25 February 2004)
register_event (Venice Carnival, start_registr_date, end_registr_date) 

Additional constraints on the unspecified parameters:
start_registr_date is either 11 February 2004 or 12 February 2004 
end_registr_date is either 23 February 2004 or 24 February 2004 


Output of the composition:  (see file in use_Case\oneSHOT)
1) for Daniela
2) for Rick 
3) for Maria

Note that if it is not possible to satisfy the client request, the composition fails. Also note that, the composite eService is different in the three cases, since the three actions are executed in different orders. Therefore, this example shows that an intrinsic feature of eServices is their behavior.

Extensions:
If it is not possible to satisfy the client request, it should be possible to ask the client how to relax the constraints.


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


Use case: Reusable composite eServices scenario

Issues: 
-available eServices: atomic (operation with input and output parameters, and possibly preconditions and effects)
- client request: it specifies a general-purpose request (not specific to any situation, and therefore reusable in several situations), which expresses only the constraints on the invocation order of the eServices (and not those on parameters of actions)
- the composite eService realizes that reusable client needs. Note that in this situation the composition is done at the client class level.


Requirements:
No specific requirements.


Actors/Roles:

Actors: 
Available eServices (same as before):
1) register_event: 
--Input: event_name, start_registr_date, end_registr_date
--Output: notification of success or failure of operation
--Preconditions: none
--effects: registered_event 

2) book_plane:
--Input: depature_place, date_leave, arrive_place, date_back
--Output: notification of success or failure of operation
--Preconditions: none
--effects: plane_booked

3) book_hotel
--Input: name_hotel, place_hotel, date_leave, date_back
--Output: notification of success or failure of operation
--Preconditions: none
--effects: hotel_booked


1) generic researcher: researcher (representative of all the researchers in the researcher class),
2) generic business manager: business manager (representative of all the business managers in the business manager class),
3) generic tourist: tourist (representative of all the tourists in the tourist class),


Goals/Context:

1) for a researcher: participate to a conference

2) for a business manager: participate to a business meeting

3) for a tourist: attend to a tourist event 

Assumptions:
We assume that the composite eService is represented as Finite State Machine.


Scenario/Steps:

-Input for the composition:
available eServices

-client requests: 
Each client wants to achieve his/her goal, specified above, with the following constraints on the order of invocation of operation, which are characteristic to each client class. Note that no input parameter is instantiated.

1) A researcher invokes the available eServices in the following order:

register_event (event_name, start_registr_date, end_registr_date)
book_plane (depature_place, date_leave, arrive_place, date_back) 
book_hotel (name_hotel, place_hotel, date_leave, date_back)


2) A business manager wants to invoke the available eServices in the following order:

book_plane (depature_place, date_leave, arrive_place, date_back)
register_event (event_name, start_registr_date, end_registr_date) 
book_hotel (name_hotel, place_hotel, date_leave, date_back)


3) A tourist wants to invoke the available eServices in the following order:

book_hotel (name_hotel, place_hotel, date_leave, date_back) 
book_plane (depature_place, date_leave, arrive_place, date_back)
register_event (event_name, start_registr_date, end_registr_date) 



Output of the composition:  (see file in use_Case\reusable)
1) for researcher 
2) for business manager
3) for tourist

Note that in this example the client makes a choice over the value of input parameters of eServices. 

Extensions:

see next use case

Use Case: General case eService scenario

Issues: 
-available eServices: atomic (operation with input and output parameters, and possibly preconditions and effects)
- client request: it specifies a general-purpose request (not specific to any class of client), which expresses the requests of all classes of clients. 
- the composite eService realizes that general-purpose request

Actors/Roles:
- Available eServices (as before) 
- client. It represents a generic client that can belong to any class.

Goals/Context:
attend a generic event that can be either a conference, or a business meeting or a tourist event.

Assumptions:
We assume that the composite eService can be represented as a Finite State Machine. Additionally, for sake of clarity, we just mention the name of activity (omitting IOPE)

Scenario/Steps:
-Input to the composition
--Available eServices: The same as above

--client request: attend a generic event that can be either a conference, or a business meeting or a tourist event.


Output of the composition:  (see file in use_Case\generic)

A web service that allows for the execution by any client, belonging to any class (those mentioned above, or even others).

Note that at each step of the eService execution, the client (and only him) makes a choice over the next action to perform. 


Reasoning Techniques Required:
The same presented in:
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 eService scenario

Issues: 
-eService: interactive: message based, or activity based
- client request:  general-purpose, it expresses a general request of a clients; 
- the composite eService realizes that general-purpose client requests. 


Actors/Roles: (see slides in file use_Case\behavioral) 

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


1) register_event: it is as before, an atomic, i.e., uninterruptible, eService. 

--Input: event_name, start_registr_date, end_registr_date
--Output: notification of success or failure of operation
--Preconditions: none
--effects: registered_event 


2) book_airtravel: this eService has associated a "interactive" behavior

a) book_plane:
--Input: depature_place, date_leave, arrive_place, date_back
--Output: notification of success or failure of operation
--Preconditions: none
--effects: plane_booked

b) book_limo_airport:
--Input: depature_place, date_leave, arrive_place, date_back
--Output: notification of success or failure of operation
--Preconditions: none
--effects: limo_airport_booked

3) book_tracktravel: this eService has associated a "interactive" behavior

a) book_train:
--Input: depature_place, date_leave, arrive_place, date_back
--Output: notification of success or failure of operation
--Preconditions: none
--effects: train_booked


b) book_limo_airport:
--Input: depature_place, date_leave, arrive_place, date_back
--Output: notification of success or failure of operation
--Preconditions: none
--effects: limo_airport_booked


3) book_accomodation: this eService has associated a "interactive" behavior


a) book_hotel:
--Input: name_hotel, place_hotel, date_arrive, date_back
--Output: notification of success or failure of operation
--Preconditions: none
--effects: hotel_booked

b) book_hotel_shuttle:
--Input: date, from/to_place
--Output: notification of success or failure of operation
--Preconditions: none
--effects: hotel_shuttle_booked

Designer: the designer specifies the behavior of the eService he would like to interact with. We assume that the designer does not know which eServices can be composed in order to obtained the requested eService; we assume that both the available eService and the designer share a common set of actions. In other words, the operation of the available eServices belong to such common alphabet and also the designer specifies the operations of his eSErvice in terms of such a set.


Goals/Context:

Obtain an eService that behaves as specified by the designer.

Assumptions:
for sake of readability, we assume that the execution of an action is always successful. This allows us to drop some transitions in the FSM. However, it is simple to consider the situation where such an assumption does not hold. it suffices to add a transition labeled by an operation and the corresponding "failure message" output. This assumption allows us not to consider the output of an action (since it is always a success message) and to consider successful an action if the client is prompted with the next one.


Scenario/Steps: 
-Input to the composition
--Available eServices

--Designer specification

Output: A new eService that has the same behavior specified by the designer, whose actions are associated with the information about (the identifier of) the eService that executes that action.


Reasoning Techniques Required:

DL based composition techniques in message based model and action based model, if actions/messages have no parameters:
D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini and M. Mecella 
Automatic Composition of e-Services that Export their Behavior  
In Proc. of First Int. Conference on Service Oriented Computing (ICSOC-03).  

If actions have parameters it is an open problem.