To follow the different possible matching between queries and services, and how these matches can be compensated, assume that a service S with the operations OP i (1 ≤ i ≤ 6) becomes unavailable. Consider query Q, with operations from service S, and service S1 as a candidate service for S.
C1: S1 fully matches Q.
Action: Replace S by S1 in the service composition.
C2: S1 matches part of the signature of S, and for the part of the signature that is matched, S1 fully matches the behaviour described in Q.
Actions:
1. Calculate the part of the query that is not matched (Q′);
2. Check if there is another service S2 that is already bound in the WF that could match Q′. If such S
2 exists, replace S by S1 and S2 in the composition. Otherwise, invoke the service selection component with a new query with Q′.
C3: S1 matches part of the signature of S, and S1 matches part of the behaviour in Q for the part of the signature that is matched. In this case, the behaviour of S1 can fall in one of the following examples, with respect to query Q:
a. S.OP1->S.Op3
b. S.Op1->S.Op3->S.OP4
c. S.Op1->S.Op4->S.Op3 (S has extra operations in the middle of the logical flow)
d. S.Op4->S.Op1->S.Op3 (S has extra operations in the beginning of the logical flow)
e. S.Op1->S.Op6->S.Op3
Actions:
1. If the behaviour of the operations in S appear in the correct order when not considering the missig or additional parts of the signature in the query (examples a, b, c, d), proceed to step 2; otherwise this is not a valid candidate (example e).
2. If there are no other additional operations in the behaviour of S (ex- ample a), proceed as in case C2; otherwise proceed to step 3 (examples b,c,d).
3. If the additional operations in the bahaviour of S, which are not in the query, can be found in the WF (i.e., the operations are supported in WF by other services), and if these additional operations in S satisfy the properties and constraints of WF (example b), proceed as in case C2; otherwise, this is not a valid candidate (examples c, d, e).
C4: S1 fully matches the signature of S and S1 matches only part of the be- haviour for that signature.
Action: This case will be treated as cases C2 or C3, depending on the behaviour match. Note that the fact that S fully matches the signature of S1, does not change on how to deal with the situation.
Action: In this case the execution of the service composition cannot be continued, unless a service provider creates a service with the necessary functionality.
The above matching and compensation cases are supported by the notion of decomposition of a query into a list of partition described in Subsection 5.3.
Example: Consider query Q = {f indCar → lookupCar → f indcarCB} of the Car Rental Service (CRS) and the query presented below. The decompositions of query Q into sub-queries are:
D1 = {{f indCar → lookupCar → f indcarCB}} D2 = {{f indCar}, {lookupCar → f indcarCB}} D3 = {{f indCar → lookupCar}, {f indcarCB}} D4 = {{f indCar → f indcarCB}, {lookupCar}} D5 = {{f indCar}, {lookupCar}, {f indcarCB}}
The approach tries to identify a service that can be matched with D1. If such service does not exist, the approach will try to identify services that can be matched with the two elements in D2. If these services are not found, the approach carries on trying to identify services that can be matched with the elements of the other decompositions. In the case in which a service that matches certain elements of a decomposition is identified, the approach tries to identify services
that match elements in other decompositions that together include all operations in the query.
For the repository above, service S1 will be matched with set D1. However, suppose that we have a repository with services S2, S3, S4, and S5 above, but not with service S1. In this case, the elements of set D2 will be matched with services S3 and S5, respectively. Another possibility is the match of elements in decomposition D4 with services S2 and S4, respectively.
For another example, suppose that we have a repository with services S3, S4, and S7 above. In this case, the first element of D2 {findCar} will be matched with service S3, the second element of D4 {lookupCar} will be matched with service S4, and the third element of D5 {findcarCB} will be matched with service S7. If we consider the situation in which we have service S5 and S6 in the repository, a possible match will be a match between the first element of P2 {findCar} with service S6; and the match of the second element of P2 with either service S5 or service S6.
Feasability
The decomposition and matching processes can be very expensive, given that the number of sub-queries grows fast in response to the size of the query. The two factors that impact its complexity and computational cost are generation of sub-queries and the interactions with the service discovering tool.
Decompositions for the composition as a whole, logic regions, and services, can be computed in parallel of the execution of the compositions but require constant consumption of system memory. Thus, the generation of sub-queries does not affect much the feasability of the approach.
ever, depends on the number of distinct sub-sets of a query. Formally speaking, the maximum number of attempts to compensate through decomposition is given by the number of subsets of the power set of query minus one. In other words, given a query with n elements, the maximum number of attempts would be 2n−1. In our experiments, the actual number of interactions is roughly two thirds of this maximum, which is related to the order in which sub-queries are attempted and the available repository of candidate services. Considering that the commu- nication with the service discovering tool is expensive, this is the major concern regarding deploying out approach in a real setting.