Re: Web-service descriptions and behaviors

[Here are a few comments on Daniela's use case from the OWL-S 
perspective.  Note these comments do not take into account Drew's 
remarks.  SWSL members - these are the same comments I sent to our 
private list.]

Daniela --

Thanks for putting forward this use case.  I agree that it calls out 
some important issues, and when the HTML version is ready, the addition 
to our use cases page will be most welcome.

I think you make a clear case that it's important to have behavior 
modeled, at least in some cases, for purposes of discovery and matchmaking.

My only comment at present is that in the work on OWL-S, we've had some 
recognition of this problem, and we have talked about one kind of solution.

We normally think in terms of preconditions and effects doing the work 
of specifying "behavior".  That is, if we were describing any of your 
S4TP variants, an effect expression might say:
     [hotel_reservation_made, event_reservation_made,
      flight_reservation_made]
where I'm obviously glossing over a lot of details.  But you are quite 
right, it seems to me, that in an effect expression we would not 
distinguish the order in which these things happened (or at least I've 
never heard any discussion about how it might do so.)  So 
S4TP_researcher, S4TP_manager, S4TP_tourist would not be distinguished 
in a registry, which is your point of course.  So I'm just agreeing.

However, we've always imagined a 2-phase approach to discovery, where 
the first phase would return S4TP_researcher, S4TP_manager, and 
S4TP_tourist.  Then, if the requesting agent is smart and realizes that 
it needs to obtain a particular order of the events, it would obtain the 
process models to look at those orders, and thus determine which 
serfvice best meets its needs.

I'm not claiming this is a fully-worked-out solution; in fact, it hasn't 
really gotten beyond the hand-waving stage.  I'm just adding this 
context to the discussion.

It seems to me the most obvious concern about the OWL-S approach 
outlined above is this:

The "procedural" style of process model that OWL-S has might not be 
supportive of the kind of reasoning that the requester agent needs to do 
in Phase 2.  Or, even if it is supportive, it might be unnecessarily 
complex for this kind of reasoning.  I don't know if this is true. 
(Actually, the OWL-S PM is based on some work that is intended to 
support reasoning more-or-less of this sort, but we have never focused 
on that very much.) But it's definitely worthwhile raising it as an 
important question for (at least some of us) to think about.

Regards,
David


Drew McDermott wrote:

> 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.
> 
>

Received on Monday, 2 February 2004 19:51:35 UTC