Presentation is loading. Please wait.

Presentation is loading. Please wait.

Binding and Execution of Web Service Compositions

Similar presentations


Presentation on theme: "Binding and Execution of Web Service Compositions"— Presentation transcript:

1 Binding and Execution of Web Service Compositions
K. Vidyasankar Memorial University of Newfoundland, CANADA V.S. Ananthanarayana National Institute of Technology Karnataka, INDIA

2 Web Service Composition
Composition relates to dealing with the assembly of autonomous components so as to deliver a new service out of the existing services.

3 Hierarchical Composition
Hierarchical composition refers to the ability to form a composite service by combining already existing services, which themselves might be composed of other composite/primitive services. Composite Travel & Shipping Service Composite Travel Booking Service Shipping Service Flight Booking Service Hotel Booking Service

4 Web Service Composition (Composite Activity)
Consists of (basic or composite) activities with some ordering constraints. Describes program logic to execute a higher level activity in terms of lower level activities. Low level activities are intended to be executed by (other) service providers as services. Availability of services is paramount for the choice and description of the activities in a composition. We assume that the composition is designed such that there exist service providers to execute the activities in the composition.

5 Two Classes of Composition
User Composition Primarily for end user Customized for user requirements Typically executed once Provider Composition Primarily for Composite Service Provider (CSP) Enables modular, hierarchical, design of highly complex software systems To be used in several, varied, higher level compositions

6 Designing and Executing Composite Services
First, design the composition using other activities (services). Second, find providers for the selected services and invoke their executions. Functional properties of the services and non-functional properties of the services and providers influence both stages. These stages may overlap. We assume that a composition is given and consider finding service providers for execution, that is, static composition and dynamic binding.

7 Service Execution Input and output constraints.
Provider is expected to execute the service satisfying the input constraints. We assume that the input constraints are known before and are used for binding. Some output constraints may be known before the execution. Others will be known only after the execution.

8 Composite Service Execution
Involves execution of the constituent activities. Arbitrary executions of the individual activities may not constitute an execution of the composite activity. The individual execution instances must be (mutually) compatible. Providers must be selected so as to produce compatible executions of the composition.

9 Compatibility Example
Flight reservations for a trip to New Delhi (India) from St. John’s (Canada). There is no direct flight from St. John’s to New Delhi, and so two flight segments Flt-1 and Flt-2 are considered. These two flights must be compatible in many ways.

10 Compatibility Requirements
(Connection city) The destination of Flt-1 is the origin of Flt-2. The connection city could be Toronto, New York, London, etc. Flights must be available from St. John’s to this place, and from this place to New Delhi.

11 Compatibility Requirements
(Connection city) The destination of Flt-1 is the origin of Flt-2. (Connection time) The connection time must be at least two hours. Probably imposed by the travel industry to complete the formalities of baggage transfer and passenger transfer.

12 Compatibility Requirements
(Connection city) The destination of Flt-1 is the origin of Flt-2. (Connection time) The connection time must be at least two hours. (Connection date) The arrival date of Flt-1 is the departure date of Flt-2. Perhaps a user constraint, to avoid arranging overnight accommodation. If the airline provides accommodation, the user may not object.

13 Compatibility Requirements
(Connection city) The destination of Flt-1 is the origin of Flt-2. (Connection time) The connection time must be at least two hours. (Connection date) The arrival date of Flt-1 is the departure date of Flt-2. (Connecting airport) The arrival airport of Flt-1 is the departure airport of Flt-2. User constraint to avoid the necessity of a visa to enter the country. (An example of different airports is New York JFK and Newark.)

14 Compatibility Requirements
(Connection city) The destination of Flt-1 is the origin of Flt-2. (Connection time) The connection time must be at least two hours. (Connection date) The arrival date of Flt-1 is the departure date of Flt-2. (Connecting airport) The arrival airport of Flt-1 is the departure airport of Flt-2. (Connecting airlines) The airlines of both flights should be Star Alliance members. To get reward points for air miles.

15 Our Contributions Several compatibility requirements may exist between activities and among providers to be selected. We propose: A simple formalism to express the compatibility requirements in a composition, and A methodology for the selection of a composite service provider for a composite activity, and the selection of (other) service providers for the constituent activities of the composition, to ensure an execution of the composition satisfying the compatibility requirements.

16 Compatibility Formalism
Compatibilities can be classified broadly into: Instance Level For example, the value of an output parameter of one activity becomes the value of an input parameter of another activity. Activity level Data types of an output parameter of an activity and an input parameter of another activity should be the same. An example of incompatibility is when the output is in inches but the input is in cms. Provider level The choice of a provider for one activity restricts the choice of providers for another activity.

17 Rationale for Formalism - 1
A (mutual) compatibility requirement may involve two or more activities (or their instances or their providers). For simplicity, we restrict our attention to those between just two activities. Then, we can use graphs with vertices corresponding to activities and edges indicating existence of compatibility requirements between their end vertices.

18 Rationale for Formalism - 2
Compatibility requirements do not necessarily dictate precedence relationship. (In our example, an instance of either Flt-1 or Flt-2 can be picked first and the compatible instance of the other flight can be looked for, with respect to any of the requirements.) Therefore, we choose undirected edges, not directed ones.

19 Rationale for Formalism - 3
There may be many compatibility requirements between two activities. We associate a set of requirements with each edge. Each requirement can be stated as a predicate.

20 One-level Compatibility Graphs
Definition: For a composition C, the one-level compatibility graph 1-CG(C) is an undirected graph G = (A, E, χ) where vertices A correspond to activities in C, and edges E indicate compatibility requirements between their end points. With edge e, we associate a set χ(e) of compatibility requirements.

21 India Trip – 1-CG

22 1-CG Example Figure shows a 1-CG with three activities: flight reservation Flights-R, hotel reservation Hotel-R, and a tour reservation Tour-R. Flights-R includes flight segments Flt-1 and Flt-2 for the forward journey and similar segments Flt-3 and Flt-4 for the return journey. Hotel is in New Delhi. Tour is described later. Compatibility requirements are: The dates of the hotel stay should correlate to the arrival and departure dates of the reserved flights, and The tour is on one of the days the user stays in Delhi.

23 Generalization – n-CG 1-CG describes the activities in one level (top level). The activities may be basic or composite. For a composite activity A, the composer may have knowledge of its constituent activities {a1, a2, …} and may indicate compatibility requirements among them. Again, if aj is a composite activity, its component activities and compatibility requirements among them may be expressed too. This may go on for several levels. We generalize our definition to accommodate this. We define n-level compatibility graph n-CG (in the paper). A 2-CG for the India trip example is given below.

24 India Trip – 2-CG

25 Binding and Execution Next, we consider binding for a composite service and execution of that service. We introduce our methodology through an example. (The concepts are formalized in the paper.)

26 Taj Mahal Tour Example A trip to Agra to visit Taj Mahal
Available options: One-day or two-day tours: Both will cover visits to Taj Mahal and Agra Fort and some shopping; Two-day trip will cover, in addition, Fateh Pur Sikri and a few other nearby attractions. Taj Mahal visit is possible in mornings, afternoons or evenings. Lunches are included in the tours but can be skipped. Two shopping locations, one near Taj Mahal and the other near Agra Fort, are available. Wheel chair facility is available.

27 Tour Example (Contd.) User preferences: One-day trip;
Afternoon or evening, not morning, visit to Taj Mahal; Shopping near Taj Mahal; and Wheel chair access.

28 Tour Example (Contd.) Several tour companies offer tours.
Lovely-Agra offers three types of one-day tours: Morning-Taj; Afternoon-Taj; and Evening-Taj. Each type includes the same four activities, in different order: Taj Mahal visit T; Agra Fort visit F; Lunch in restaurant L; and Shopping S. Two sets of restaurants Fort-Restaurants and Taj-Restaurants. Two shopping areas Fort-Shopping and Taj-Shopping. Tours are described in the following figure.

29 Lovely-Agra Tours

30 Lovely-Agra Compatibility Graphs

31 Lovely-Agra Compatibility Graphs (Contd.)
Compatibility edges denote vicinity (provider compatibility). In the figure, (a) and (b) are applicable to Morning-Taj: For (a), lunch will be in a Taj-Restaurant, and for (b) it will be in a Fort-Restaurant. For both, shopping will be in Fort-Shopping. Figures (c) and (d) are applicable to Afternoon-Taj, and (b), (c) and (d) to Evening-Taj tours. We call these Provider Compatibility Graphs (PCGs). User requirements can be expressed in a User Compatibility Graph (UCG).

32 User Compatibility Graph

33 Binding and Execution Steps
S1. Selecting a CSP for a composite service Select a provider such that the UCG is “covered” by a PCG of that provider, that is, an execution adhering to the PCG will satisfy the user requirements.

34 Covering UCG PCGs In our example, the UCG is covered by the PCGs (c) and (d). Therefore Lovely-Agra can satisfy the user requirements.

35 Selection Process The selection process would involve the user requesting a tour reservation for a particular date and Lovely-Agra accepting the reservation, thus guaranteeing an “execution” satisfying the user requirements. The tour company may not take any further steps at this time.

36 Binding and Execution Steps
S2. CSP selecting a (composite) service (the tour company selecting a tour) The PCGs (c) and (d) are appropriate for both Afternoon-Taj and Evening-Taj. Company chooses (checking with the user) chooses PCG (c) applied to Afternoon-Taj, some time prior to the tour date and time. We call this tour (c)-Afternoon.

37 Binding and Execution Steps
S3. Selecting a service instance Several groups may be present for (c)-Afternoon. One of them, denoted (c)A, is selected for the user. We assume this selection includes assignments of a van with wheel chair facility and a tour guide.

38 Binding and Execution Steps
S4. Selecting providers for the constituent activities of the service instance In our example, the only remaining selection is a restaurant, say, Res-A (among Fort-Restaurants) for lunch, for the day of the tour.

39 Binding and Execution Steps
S1. Selecting a CSP for a composite service User selecting Lovely-Agra, say, at time T1 S2. CSP selecting a (composite) service The tour company selecting a tour, say, at time T2 S3. Selecting a service instance Selecting an instance of the tour, say, at time T3 S4. Selecting providers for the constituent activities of the service instance Selecting a restaurant Res-A, say, at time T4 It is likely that T1 ≤ T2 ≤ T3 ≤ T4.

40 Compatible Executions of Composite Services
Consider a composition consisting of two activities t1 and t2 with a compatibility requirement r between them. We need to find providers, say, P1 for t1, and P2 for t2, such that they produce instances of t1 and t2 that satisfy the compatibility requirement r.

41 Compatible Executions - Cases
1. For any instance of t2 by P2, P1 may guarantee a compatible instance of t1. Then P2 can be executed first and then (with the output constraints of t2 possibly contributing to the input constraints of t1) P1 can be executed. 2. For any instance of t1 by P1, P2 may guarantee a compatible instance of t2. Then P1 can be executed first and then P2. 3. Compatible instances of t1 and t2 may have to be found by trial and error. For an instance of t1, try for a compatible instance of t2. Or, for an instance of t2, try for a compatible instance of t1. Try for several instances. Assign responsibility to PC, the CSP, or some other provider.

42 Compatible Executions – Binding Proposal
Some service provider should be given responsibility to satisfy a compatibility requirement Binding for a composite activity C should involve selection of service providers for each activity of C and each compatibility requirement between activities of C.

43 Further on Selection of a CSP
A CSP can be selected for one or more activities of a composition and compatibility requirements between those activities Then, the CSP would guarantee not just an execution of the activities, but an execution that satisfies the compatibility requirements. This would be the added value provided by the CSP. That is, “executing several activities in a compatible way” is the added value.

44 Guaranteeing Service Execution
When we bind a service provider for executing a service with certain input constraints, we expect that the provider can guarantee a successful execution of that service. This holds for a CSP too.

45 Guaranteeing A Composite Service Execution
A CSP, for executing a composite service C, has to find providers for each of the activities and the compatibility requirements of C. To find a combination of providers that can produce compatible instances of the activities, (at least a limited form of) exhaustive search may be required. This is time consuming and the execution may fail due to unavailability of service providers. To guarantee a successful execution, the CSP can pre-select a set of combinations of providers, on the basis of some search done in advance, and choose one combination among them, appropriate for the given input constraints, for actual execution.

46 Pre-selection Method - 1
Each combination will contain one (not necessarily distinct) provider for each activity and each compatibility requirement.

47 Pre-selection Example - 1
In our example, with Flt-1 and Flt-2, for each airline flying from St. John’s, and for each destination that airline flies, possibility of connections from that destination to New Delhi has to be checked. The search can be limited by pre-selection of provider sets like the following: {Air Canada (for both St. John’s to Toronto and Toronto to New Delhi flights)} {Air Canada (for St. John’s to London), Hilton Airport Hotel in London (for overnight accommodation), Air India (for London to New Delhi flight)} {Air Canada (for St. John’s to New York Newark airport), Yellow Cab (for transportation from Newark to JFK), United Airlines (from JFK to New Delhi)}. The combinations can be periodically updated by the CSP.

48 Pre-selection Method - 2
Pre-select a collection of sets of providers for the individual activities and compatibility requirements, and select one provider for each activity and compatibility requirement from the respective sets, again based on the input constraints.

49 Pre-selection Example - 2
For our flights example, provider set for Flt-1 can be {Air Canada}, and for Flt-2 can be {Air Canada, Air India, Lufthansa}, assuming that all the compatibility requirements can be taken care of by each of these airlines. The travel agent can pick one airline from each set. Contents of each set can be altered depending on the availability of airlines, for future binding.

50 Some Salient Points Service descriptions need to encompass several semantic details in addition to syntactic ones for selecting appropriate services for the activities. Our compatibility graph formalism adds to the semantic description of a composition or composite service. “Binding for a service” usually means selection of a service provider to execute that service. For a composite service, (1) a composite service provider has to be selected and, recursively, (2) providers need to be selected for the constituent services. We have suggested that, in addition, service providers be identified for each compatibility requirement also. We have identified two more stages of binding - after the selection of a composite service provider and before selecting providers for its constituent services, namely, (1) selecting a composite service and (2) selecting an instance of that service.

51 Scalability of our Method
Binding for a (multi-level hierarchical) composite activity involves binding for its constituent activities and compatibility requirements at every level of the composition. For guaranteed execution of a (static) composition, we may wish to select all necessary providers before starting the execution. This can be done one level at a time. That is, at each level of the composition, once providers are selected for that level, the execution in that level can start. In the 2-CG of our example, once providers are found for Flights-R, Hotel-R and Tour-R, the user can start the trip. The CSP for Tour-R, Lovely-Agra, can bind providers for its activities T, F, L and S afterwards. Thus, our method scales well with any number of levels in the composition.

52 Compatibility Notions
Many different compatibility notions have been proposed in the literature. Some examples are: Syntactic, semantic, and policy level compatibilities Input-output, interface, and behavior compatibilities Safety and liveness compatibilities Service coupling and service cohesion Composition soundness These classifications are orthogonal to each other. Our classification as instance, activity and provider levels is orthogonal to each of the above. We cannot expect a single formalism and mechanism to take care of all compatibility requirements.

53 Conclusion We have addressed how, and when, to take care of (several) mutual compatibility requirements in Web service compositions: A simple formalism to express the compatibility requirements; and A methodology for selecting providers and executing the composite service satisfying the compatibility requirements. There may be other, more elaborate, ways of expressing the compatibility requirements. We believe that our methodology for binding and execution is applicable to any such formalism.

54 User Composition Graph

55 Provider Compatibility Graphs


Download ppt "Binding and Execution of Web Service Compositions"

Similar presentations


Ads by Google