- From: Drew McDermott <drew.mcdermott@yale.edu>
- Date: Mon, 2 Feb 2004 15:31:17 -0500 (EST)
- To: public-sws-ig@w3.org, hull@lucent.com, berardi@lucent.com
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