Usage Scenario:
e-Service Composition in a
Behavior based Framework
Name:
Authors:
- Rick Hull, Bell Labs, Murray Hill (NJ)
- Daniela Berardi, Università di Roma "La Sapienza (visiting
PhD student at Bell Labs)
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.
- An e-Service can be:
- atomic (i.e., discrete, single interaction):
each e-Service presents an input/output behavior. In other words,
an e-Service is an operation with input and output parameters,
and possibly preconditions and effects
- interactive: each e-Service shows
a "long-running" behavior, which can be:
- message based: behavior as the set of all possible messages
that the e-Service may send or receive
- activity based: the behavior is the set of all possible
sequences of atomic actions that the e-Service may perform
- The result of composition can be:
- one-shot: it realizes a particular request
of a particular end-user,
Therefore, the result of composition cannot be used for other requests
of other end-users.
- reusable: it realizes a generic request of
a generic end-user. In this case the result of composition can
be used for other requests of other end-users
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
- Input:
- a set of available e-Services and
- the specification of the desired behavior of the e-Service
- Output:
- a new e-Service (called composite e-Service)
- obtained by composing ("pieces" of ) the available e-Services,
- that realizes the request of the end-user.
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
- There are three available e-Services:
- for registering to an event (either conference,
or business meeting, or tourist event)
- for arranging travel
- for arranging accommodation
- An end-user can participate according to one of the following three roles:
- researcher: all researchers 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 accommodation.
- 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 accommodation.
- tourist: all tourists want to attend to a
tourist event. A tourist first would like to arrange for the accommodation
for himself and his family. Therefore, after this information is available,
the travel is arranged. Finally, the tourist registers for the tourist
event.
Note that the same end-user can take on different roles in different times,
e.g., one day s/he plays as a researcher, the next day as a tourist.
- A Composition Agent: it is the software entity
that, after receiving the specification of the desired behavior of the composite
e-Service, first synthesizes a composite e-Service and then executes
it.
- e-Service designer: the designer specifies the
behavior of a desired composite e-Service. We assume that both the
available e-Services and the designer share a common set of actions.
In other words, the operation of the available e-Services belong
to such common alphabet and also the designer specifies the operations of
his e-Service in terms of such a set. The e-Service designer wants
to use (semi-)automatic tools as as support for building composite
e-Services.
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
- Available e-Services: atomic
- Result of composition: one-shot (desired
behavior of composite e-Service specified by the end-user)
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
- Available e-Services:
- register_event:
- Input: event_name, start_registr_date, end_registr_date
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: registered_event
- book_plane:
- Input: depature_place, date_leave, arrive_place, date_back
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: plane_booked
- book_hotel:
- Input: name_hotel, place_hotel, date_leave, date_back
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: hotel_booked
- End-users and their roles:
- Daniela plays role of researcher
- Rick plays role of business manager
- Maria plays role of tourist
- Composition Agent
- e-Service designer:
the designer specifies the behavior of a desired composite e-Service.
We assume that the designer does not know which e-Services can be
composed in order to obtained the requested e-Service; we assume
that both the available e-Services and the designer share a common
set of actions. In other words, the operation of the available e-Services
belong to such common alphabet and also the designer specifies the operations
of his e-Service in terms of such a set.
Goals/Context
The Composition Agent synthesizes a composite e-Service
that realizes a particular request of particular end-user:
- 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".
- 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"
- 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
- Preconditions and effects of operations are propositional formulas
- We represent the composite e-Service as a Finite State Machine (FSM).
Scenario/Steps
- Input for the composition:
- available e-Services: register_event,
book_plane, book_hotel
- end-user request (as specified above):
- For Daniela (role: researcher):
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
- For Rick (role: business manager):
book_plane (Newark, 01 June 2004, Atlanta, 02 June 2004)
register_event (Data Grid, 01 June 2004, 02 June 2004)
book_hotel (Marriott, Atlanta, 01 June 2004, 02 June 2004)
- For Maria (role: tourist):
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
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
- If the Composition Agent cannot satisfy the end-user request, it should
ask the client how to relax the constraints.
- 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.
- 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.
- 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
- Available e-Services: atomic
- Result of composition : reusable (desired
behavior of composite e-Service specified by e-Service designer)
Requirements
No specific requirements.
Actors/Roles
- Available e-Services (same as before):
- register_event:
- Input: event_name, start_registr_date, end_registr_date
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: registered_event
- book_plane:
- Input: depature_place, date_leave, arrive_place, date_back
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: plane_booked
- book_hotel:
- Input: name_hotel, place_hotel, date_leave, date_back
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: hotel_booked
- End-users and their roles:
- Daniela plays role of researcher
- Rick plays role of business manager
- Maria plays role of tourist
- Composition Agent: in the previous situation the synthesis phase
of composite e-Services was blurred within the composition. Here, we can precisely
identify the phases of synthesis and of execution of a composite e-Service:
- synthesis phase: an e-Service designer specifies to the Composition
Agent a specification of a desired composite e-Service; the Composition
Agent, starting from the specification of the available e-Services
and from the designer specification produces a specification of the composite
e-Service in terms of how to coordinate the available e-Services
to realize the designer specification.
- execution phase: the Composition Agent executes the specification
of the composite e-Service obtained in the previous phase, by
interacting with the end-user that chooses the next action to perform
according to the role s/he is playing.
- e-Service designer
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
- We assume that designer specifies the desired composite e-Service
as a FSM. In fact, any finite state based formalism can be used.
- We assume that the composite e-Service can be represented as a
FSM, for coherency with the previous point. Additionally, for sake of clarity,
we just mention the name of activities, i.e., omitting Input/Output parameters,
Preconditions and Effects (IOPE)
Scenario/Steps
- Input for the composition (design phase):
- Output of the composition:
- A new e-Service (a FSM) that
allows for the execution by any end-user, belonging to any class (those
mentioned above, or even others).
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
- Available e-Services: interactive (message
based, or activity based)
- Result of composition: reusable
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)
- Available e-Services:
- register_event: (it is as before, an atomic,
i.e., uninterruptible, e-Service)
- Input: event_name, start_registr_date, end_registr_date
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: registered_event
- book_airtravel: (this e-Service has
associated a "interactive" behavior)
- book_plane:
- Input: depature_airport, date_leave, arrive_airport, date_back
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: plane_booked
- book_limo:
- Input: depature_address, date_leave, arrive_address, date_back
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: limo_booked
- book_tracktravel: (this e-Service
has associated a "interactive" behavior )
- book_train:
- Input: depature_station, date_leave, arrive_station, date_back
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: train_booked
- book_limo:
- Input: depature_address, date_leave, arrive_address, date_back
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: limo_booked
- book_accommodation: (this e-Service
has associated a "interactive" behavior )
- book_hotel:
- Input: name_hotel, hotel_city, date_arrive, date_back
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: hotel_booked
- book_hotel_shuttle:
- Input: date, from/to_city
- Output: notification of success or failure of operation
- Preconditions: true
- Effects: hotel_shuttle_booked
- Composition Agent
- e-Service designer
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
- We assume that designer specifies the desired composite e-Service
as a FSM. In fact, any finite state based formalism can be used.
- We assume that the composite e-Service can be represented as a
FSM, for coherency with the previous point. Additionally, for sake of clarity,
we just mention the name of activities (omitting IOPE)
- For simplicity, we assume that the execution of an action is always successful.
Scenario/Steps
- Input to the composition:
- Output of the composition:
- A new e-Service that
has the same behavior specified by the designer, whose actions are associated
with the information about (the identifier of) the e-Service
that executes that action.
Extensions
-
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:
- 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
- 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.
- In the case of interactive e-Services, the discovery phase has to incorporate/tackle
aspects regarding:
- (global) precondition and effects and the signature of the e-Service
- the behavior of the e-Services, e.g., sequencing, or, more generally,
properties on awareness of the full behavioral signature.
- possible incomplete specification on the available e-Services, as discussed
in point 1 above.
Reasoning Techniques Required
- DL based composition techniques in message based model and action based
model, if actions/messages have no input/output parameters, no preconditions
and no effects, and the FSM are deterministic:
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).
- DL based composition techniques in message based model and action based
model, if actions/messages have no input/output parameters, no preconditions
and no effects, and the FSM present don't care non determinism on the transitions:
D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini and M. Mecella, Synthesis
of Composite e-Services based on Automated Reasoning. In Proc. of ICAPS
Workshop on Planning and Scheduling for Web and Grid Services 2004. To appear.
- T. Bultan, X. Fu, R. Hull, and J. Su. Conversation Specification: A
New Approach to Design and Analysis of e-Service Composition. In Proc.
of Intl. World Wide Web Conference (WWW2003).
- R. Hull, M. Benedikt, V. Christophides, and J. Su. e-Services: A Look
Behind the Curtain. In Proc. of ACM Symp. on Principles of Database Systems
(PODS 2003).
If actions have parameters it is an open problem, and it is also not clear
how to deal with data flow constraints.