LTS Composition Algorithm

We proposed an algoirthm to compose the requested and offered LTSs in a gradual manner and consequently achieve the operation mapping-based composed LTS defined in Def.10. This algorithm is presented in Listing9.

It takes as input the LTS of a service request ltsr and the set of LTSs of the selected service offers {lts_o1, ..., lts_ok}. Additionally, it takes the requester operation mapping, i.e., OpM ap_r as input. As output, it returns a set of determined service compositions, i.e., Resultcomp. If there is no possible service composition, a failure is notified and the requester is provided with suggestions to restructure his/her request based on identified partial com-positions.

The algorithm in Listing9 works as follows:

Step¬ In the first step, a composed LTS ltscomp is initiated, which is ini-tially empty. Later, a composed state scomp, which is a composition of the initial states of all the participating LTSs is created through createState() and added to ltscomp through addState(). Based on Def. 10(i), r.so in scomp represents the initial state in ltsr. Similarly, scomp comprises of the initial states of all the participating LTSs. As shown in Fig.7.6, cs1 shows the initial state of lts_comp. In this case all the participating LTSs, i.e., ltshrs, ltshotelX, ltshotelY, ltsf lightBooker, lts_payOnline are in their respective initial states.

Step­ scuris a variable to track the currently traversed composed state during the construction of the composed LTS. In this case, s_curcan be repre-sented through the vector of participating states (r.sc, o1.sc, ...ok.sc).

Listing 9: Algorithm to compose the LTSs of the service partners and to determine valid service compositions

Input: LTS of Service Request lts_r

Input: Set of LTSs of selected offers {lts_o1, ..., lts_ok} Input: Set of operation mappings OpM apr for r

Output: Set of possible service compositions ResultcompOR Failure Notification

findServiceCompositions(ltsr, {lts_o1, ..., lts_ok}, OpM apr)

lts_comp = null; // Step ¬

createState(s_comp: (r.s₀, o₁.s₀, ..., o_k.s_o));

lts_comp.addState(scomp);

scur: (r.sc, o1.sc, ...ok.sc) = null; // Step ­ while lts_comp.hasMoreTraversableStates() do // Step ®

s_cur=lts_comp.nextTraversedState();

while scur.hasInvocableCorr(OpM apr) do // Step ¯ corr=scur.nextInvocableCorr() where corr = (seqr, seqo) ∧ r.s_c−^seq−−→ r.s^r _i ∧ ∃o_x∈ {o₁, ..., o_k} : o_x.s_c−^seq−−→ o^o _x.s_j;

createState(star: (r.st, o1.st, ...ok.st)): r.st= r.si ∧

o_x.s_t= o_x.s_j ∧ ∀o ∈ {o1, ..., o_k} \ {ox} : o.st= o.s_c; // Step ° lts_comp.addState(star);

createTransition(tcomp:scur

seq_rkseqo

−−−−−−→ star); // Step ± ltscomp.addTransition(tcomp);

end end

if ltscomp.hasValidTraces() then // Step ² Resultcomp= ltscomp.getValidTraces();

return Resultcomp; end

else return Failure Notification;

; end

183

Step® Next, the while-loop traverses over the states of the composed LTS lts_compin a breadth-first manner. In every iteration, the next traversed state determined through nextTraversedState() is referred by scur, which is used to further construct the composed LTS if possible. The traversal continues until hasMoreTraversableStates() is false, i.e., there are no more states to be traversed.

Step¯ For every state scurthat is currently traversed, every invocable opera-tion correspondence from OpM ap_r is referred through corr and is de-termined by nextInvocableCorr(). This is continued until there are no more invocable correspondences for s_cur, i.e., hasInvocableCorr() is false.

corr represented as (seqr, seqo) is invocable in the state scur because its requested operation sequence seq_r can be invoked on the requested LTS ltsrfrom its respective state comprising scur, i.e., r.sc. As a result of these transitions, ltsrachieves a state r.si. Similarly, the offered op-eration sequence seq_o can also be invoked on one of the offered LTS ltsox from its respective state in scur, i.e., ox.sc and the resulting state for ltsox is ox.sc. According to Def.10, this invocation of the compris-ing operation sequences is carried out in parallel on the participatcompris-ing LTSs. For cs1 in Fig. 7.6, there are two invocable correspondences in OpM ap_hrs. First correspondence under consideration is (hrs.-checkAvailability() → hrs.viewDetails() , hotelX.searchRoom()), which is invocable in cs1 because hrs.checkAvailability() → hrs.view-Details() can be invoked from hrs.s1 reaching hrs.s1. Additionally, hotelX.searchRoom() can be invoked from one of the offered LTSs, i.e., lts_hotelX from its comprising state hotelX.s1. As a result of the transition, hotelX.s2 is reached.

Step° For every invocable operation correspondence corr of scur, a new com-posed state star represented as (r.st, o1.st, ...ok.st) is created and added to lts_comp. In s_tar, the requester LTS lts_r and the particular offered LTS lts_ox are in their respective new states reached after the invoca-tion of corr, i.e., r.st = r.si and ox.st = ox.sj, respectively. All the other offered LTSs are in their same respective states comprising scur. For instance, for the considered invocable operation correspondence for cs1, cs7 in Fig. 7.6is created, where LT Shrs and LT ShotelX are in hrs.s3 and hotelX.s2, respectively after the invocation of the opera-tion sequences in corr. All the other offered LTSs maintain their state from cs1 in cs7.

Step± Later, a composed transition tcomp with the action seqr k seq_o is created between s_cur and the newly created s_tar through createTransition() and added to ltscomp through addTransition(). According to Def.10(v), tcomp represents the com-position of the transitions in participating LTSs resulting from the parallel invocation of the operation sequences in corr. For exam-ple, the composed transition between cs1 and cs7 in Fig. 7.6 (a) represents the composition of the parallel transitions resulting from hrs.checkAvailability() → hrs.viewDetails() and hotelX.search-Room()in LT S_hrs and LT S_hotelX, respectively. As a result, a com-posite state and a corresponding composition transition is created for every invocable correspondence of scur. Conceptually, this can be un-derstood as a composition of the overlapping parts of the participating LTSs.

Step² Analogously, the composed states cs2 and cs7 are traversed in the next iteration and as a result, lts_comp is further constructed. It is completely constructed if there are no more states to be traversed.

For our running example, the composed LTS is shown in Fig. 7.7.

After the complete construction, lts_comp has to be examined to deter-mine its valid traces, which represent the valid service compositions.

This is done through hasValidTraces(). In case it holds true, these are added to Result_comp through getValidTraces() and returned.

Otherwise, a failure notification is returned. In the next section, we discuss the notion of valid traces in detail and how the composed LTS can be examined to determine such valid traces.

As mentioned earlier, a strength of the proposed approach is its selective LTS composition strategy, where only those parts of the offered LTSs are considered that are relevant to the requester and hence overlap with the requested LTS on the basis of the determined operation correspondences.

Consequently, the composed LTS comprises of only parallel transitions re-sulting from the parallel invocation of the requested and offered operations in the operation correspondences. In most cases, this strategy results in a smaller composed LTS as compared to a conventionally composed LTS and hence makes its examination to determine potential service compositions easier. For instance, apart from the parallel transitions in the participating LTSs, a conventionally composed LTS can also comprise the interleaving transitions in the participating LTSs. These interleaving transitions result from the operation invocations, which does not participate in any opera-tion correspondence, e.g., from cs1, we have so far considered the composed 185

cs1

Figure 7.7: Composed LTS for our running Example

transitions that result from the parallel transitions of the participating LTSs.

However in a conventional setting, further composed transitions are also pos-sible resulting from the invocation of operations hotelX.arrangeEvent(), payOnline.signIn(), etc. in their respective LTSs. But in our selective composition strategy, these transitions are not relevant since they are not part of any invocable operation correspondences from the composed state

under consideration and hence are not included to ltscomp.

In the next section, we explain the mechanism that is used to examine the composed LTS and determine the valid service compositions. In case of valid service composition, there are some further important observations that we also discuss in the next section.

7.4 Determination and further Examination of valid