Web-service descriptions and behaviors

The following use case is due to Daniela Berardi (quoted with
permission).  It's lengthy but interesting.  My thoughts appear after
it. 


SOME THOUGHTs ABOUT WHY DESCRIPTION OF E-SERVICE SHOULD (NECESSARILY)
INCLUDE THE BEHAVIOR OF ESERVICES


In this use case we want to show the importance of behavior as part of
the description of an eService, and in particular of a composite
eService. Here, by "behavior of an eService", we consider the set of
ALL possible sequences of actions that the eService can
perform. Therefore, we claim that from a functional perspective (i.e.,
where the focus is on what the eService does) an eService should be
conceptually represented in terms of both its static interface (i.e.,
WSDL-like, as set of operations) and its dynamic behavior. Indeed, the
various users of an eService may have different 
constraints on the order in which the operations are executed. In
particular, depending on the typology of the user (and therefore on
his different needs), the interactions between the user and the
eService may be driven each time by the output produced by a different
operation. (Note that for sake of simplicity, the inputs and outputs
of operations are implicitly represented in the name of the
operation.) In what follows, we consider an eService as made by a set
of operations (with constraints on their invocation order)
and assume that a user invokes such an eService and executes the
operations it provides. In other words, the operations here are part
of (i.e., embedded in) the eService, therefore an operation cannot be
executed without invoking the eService. 

Consider the following eService for planning a trip (in the following,
referred to as S4TP). It is constituted by the following set of
operations (i.e., in this particular case, there are no constraints on their invocation order) 
- op1: book the plane ticket
- op2: register for event (where "event" can be either conference, 
  or business meeting, or tourist event)
- op3: book a hotel room

Now, consider the following three different variants for S4TP, namely
S4TP_researcher, S4TP_manager, S4TP_tourist, which are invoked by
different typology of users, having different needs. Note that all of
them are made by exactly the same operations as S4TP. 


1st variant) S4TP_researcher. S4TP is executed by a Lucent researcher
who wants to go to Crete (Greece) for the next EDBT Conference. The
researcher executes the operations in the following order:

- op2: register for the event (where the researcher chooses the
  "event" to be "conference") - IT DRIVES THE EXECUTION OF THE ESERVICE
- op1: book the plane ticket
- op3: book a hotel room

Since the registration fees depend on the date the registration is
done, usually the researcher registers to the conference quite
early. Then, the researcher books the plane ticket, since usually also
plane fares depend on how much in advance the plane ticket is
booked. Finally, the researcher books the hotel.


2nd variant) S4TP_manager. S4TP is executed by a Lucent manager who
wants to go to Paris for a business meeting. The manager executes the
operations in the following order:

- op1: book the plane ticket - IT DRIVES THE EXECUTION OF THE ESERVICE
- op2: register for the event (where the manager chooses the "event"
 to be "business meeting")  
- op3: book a hotel room

A manager is supposed to have strict timing, therefore, he has to
first book the plane ticket so that he stays at the business meeting
for the minimum needed time. Then, he registers for the business
meeting and finally he books for the hotel room.



3rd variant) S4TP_tourist. S4TP is executed by a Lucent employees who wants to go on
holiday with his family to Rome. The employee may execute the
operations in the following order

- op3: book a hotel room  - IT DRIVES THE EXECUTION OF THE ESERVICE
- op1: book the plane ticket
- op2: register for event (the tourist chooses the "event" to be "tourist event")

In this case the information that drives the execution of S4TP is the
dates when a hotel room is available for the employee and his
family. Therefore, after this information is available, the plane
ticket is booked.  Finally, the employee registers for the tourist
event (they may be one or more).

First of all, note that op2 is always the same operation (it
corresponds to the same piece of code), that can be invoked each time
with a different parameter. 

Note that without modeling behavior, all these services (S4TP,
S4TP_researcher, S4TP_manager, S4TP_tourist) would be modeled the
same, but when invoked, they would behave differently. In other words,
a reseacher looking for an eService for registering to a conference,
may be returned with the eService S4TP_manager, or S4TP_tourist, which do
not completely satisfy the user needs. Or, consider the 
case when, as an additional constraint, S4TP_tourist allows for mandatorily book a hotel room (which can
be a reasonable  constraint for a tourist) and then performing the
other actions. If a manager wants to register to a business event lasting
one day, he has no need for a hotel room. However, after the
service discovery phase, the manager is returned with
S4TP_tourist. What does he do? 


OBSERVATION: In real world applications, it is always possible to quit
an eService and abort all ongoing transactions. Here abortion
mechanism is orthogonal to our approach, since we focus on eServices
from a conceptual point of view. 



This example also shows another (advanced) issue that can/should be
studied, which can be referred to as customization: depending on the
typology of the user, an operation may execute differently, i.e., it
may export different functionalities. For example, usually, conference
registrations (or sometimes also business meeting registrations, if,
for example, business meetings last more than one day) perform also
hotel reservation, therefore in this case the S4TP_tourist
(S4TP_manager, resp.) user does not explicitly invoke the
corresponding operation, in this case op3. Therefore, if we are trying
to automatically build an instance of S4TP_researcher, S4TP_manager,
S4TP_tourist using a UDDI full of op1's, op2's, op3's, op1+2's,
op2+3's, etc.  then it is necessary to understand (and be able to
represent in the eventual SWSL language) that an instance of
op1+2 can be used in place of an op1 and an op2. For example, assume
that when op2 is invoked on the event "conference" it allows both for
registering to the conference and for booking the hotel . Now, as
explained before, if behavior is not modeled, the service S4TP_tourist
can be returned to the researcher. But S4TP_tourist performs op3 (book
a hotel room) first, therefore, when op2 (register for event) is
executed, where the "event" is "conference", the hotel is booked
again!  

------------------------------------------------------------

I think this scenario is a good example of why truly compositional
techniques are needed for web services.  Berardi says that

   "... all these services (S4TP,
    S4TP_researcher, S4TP_manager, S4TP_tourist) would be modeled..."

I am not sure she means this literally, but it seems to me to be
unacceptable for there to be three or four different web services,
each representing a different composition of underlying services for
booking a hotel, reserving a seat on a plane, and registering at a
conference.  It seems to me that the researcher, the manager, and the
tourist all have different goals:

  researcher: Attend the conference, using a hotel in the usual way

  tourist: Stay in a hotel in area A for a period of length L during
          interval I

  manager: Meet with persons P1, P2, ..., Pk in city C at some point
           in the interval J, using the usual hotel

What we need is a theory of how reasoning about these goals and their
subgoals leads to a series of interactions with web services that can
accomplish them.  If all such interactions have to be figured out in
advance, and indexed to the people requesting service, I will be
disappointed.

If I am correct, then the scenario doesn't really support the claim
that the profile must mention the way the service is carried out.
Until the technique (AI planning?) for composing the services is
figured out, we really don't know anything about how the services must
be described.


-- 
                                             -- Drew McDermott
                                                Yale University CS Dept.

Received on Monday, 2 February 2004 15:31:53 UTC