1 / 35

A Petri Net Siphon Based Solution to Protocol-level Service Composition Mismatches

wendi
Download Presentation

A Petri Net Siphon Based Solution to Protocol-level Service Composition Mismatches

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. 1 A Petri Net Siphon Based Solution to Protocol-level Service Composition Mismatches

    2. 2 Web service composition Everyone wants seamless composition of Web services What’s missing in achieving this goal is the mismatch between invokers and invokees. Now interface mismatches have been well addressed while protocol mismatches remain a challenge.

    3. 3 A concrete example A client has developed a web service called client An online-shop has developed another web service called online shop They should be composed together to complete transactions However, when we simulate the scenario by Oracle JDeveloper BPEL Designer, it will show you that the two processes are blocked. The Oracle JDeveloper BPEL Designer only shows the blocking result. It does not provide any traces or any solutions to the problem.A client has developed a web service called client An online-shop has developed another web service called online shop They should be composed together to complete transactions However, when we simulate the scenario by Oracle JDeveloper BPEL Designer, it will show you that the two processes are blocked. The Oracle JDeveloper BPEL Designer only shows the blocking result. It does not provide any traces or any solutions to the problem.

    4. 4 Agenda Background about mismatches in web service composition Related works and our contributions Modeling methods Message ordering mismatch detection and solution Conclusion

    5. 5 Mismatches in Web Service Composition Interface mismatches (Mostly solved) Message signature mismatches (by schema matching-based method, information retrieval techniques) Message split/merge mismatches (by clustering-based approach) Protocol-level mismatches (Partially solved) Unspecified reception (by adaptor-based method) Message deadlock (remains a challenge) message ordering mismatches non-local choice mismatches There is a difference between message deadlock and resource deadlock. With resource deadlock, a deadlock exists if there is a closed loop or cycle, which depicts process dependencies. In resource case, one process is dependent on another if the latter holds a resource that the former requires. With message deadlock, the condition for deadlock is that all successor of activity set S are themselves in S. [Operating Systems by William Stallings, 18-31] We do not have live lock in web service composition because there is no ‘starvation’ scenario. We assume that web services can proceed once it receives specific messages.There is a difference between message deadlock and resource deadlock. With resource deadlock, a deadlock exists if there is a closed loop or cycle, which depicts process dependencies. In resource case, one process is dependent on another if the latter holds a resource that the former requires. With message deadlock, the condition for deadlock is that all successor of activity set S are themselves in S. [Operating Systems by William Stallings, 18-31] We do not have live lock in web service composition because there is no ‘starvation’ scenario. We assume that web services can proceed once it receives specific messages.

    6. 6 Message deadlock example (1)

    7. 7 Message deadlock example (2) At this time, the programmer has to make a decision, ask Customer to send delivery info and/or ask Online shop to send payment info.At this time, the programmer has to make a decision, ask Customer to send delivery info and/or ask Online shop to send payment info.

    8. 8 Solving the problem using reachability tree based method Choice 1, provide delivery and payment information.

    9. 9 Solving the problem using reachability tree based method Choice 2, provide payment information.

    10. 10 Solving the problem using reachability tree based method Choice 3, provide delivery information.

    11. 11 Limitations of reachability tree based method The cost for the construction of a reachability tree is exponential, i.e., O(eN)(N is the number of nodes) 2k is the number of choices (k is the number of messages) Some choice can not solve the problem completely, which needs a second interfere by programmer, e.g., choice 2. Some choice is not optimal, which requires more information than really needed, e.g., choice 1. Total cost to find the best choice is O(2keN )

    12. 12 Our contributions We model web service composition as a special kind of Petri nets in which we have a hypothesis: there is a deadlock in web service composition if and only if there is an empty siphon in Petri nets. The cost for enumerating all the empty siphon is exponential, i.e., O(eN)(N is the number of nodes) By linear programming, we can find the optimal solution. The cost for linear programming is polynomial. Total cost will be O(eN)(N is the number of nodes) O(eN) + polynomial = O(eN)O(eN) + polynomial = O(eN)

    13. 13 Agenda Background about mismatches in web service composition Related works and our contributions Modeling methods Message ordering mismatch detection and solution Conclusion

    14. 14 Petri nets and Composition net (C-net) We divide the basic structures in BPEL, i.e., receive, reply, invoke, assign, throw, terminate, wait, empty and link into two categories. The first category is internal control logic that includes assign, terminate, wait and empty. We model them as internal status places and transitions. The second category is external control logic that includes receive, reply, invoke, throw and link. we model them as transitions connected with internal status places and interface places Here is a “Receive” statement in BPEL: <receive name="Receive_Order" partnerLink="client" portType="client:OrderIn“ operation="Order" variable="Order" createInstance="yes"/> And here is the petri net model corresponding to that Here is a “Receive” statement in BPEL: <receive name="Receive_Order" partnerLink="client" portType="client:OrderIn“ operation="Order" variable="Order" createInstance="yes"/> And here is the petri net model corresponding to that

    15. 15 Petri nets and modeling (1)

    16. 16 Petri nets and modeling (2) t1 fires, order is sent from customer. The status of customer changes from p1 to p2 t6 fires, order is received from customer. The status of online shop changes from p6 to p7t1 fires, order is sent from customer. The status of customer changes from p1 to p2 t6 fires, order is received from customer. The status of online shop changes from p6 to p7

    17. 17 Physical Siphon A physical siphon is a continuous tube that allows liquid to drain from a reservoir through an intermediate point that is higher, or lower, than the reservoir. The liquid can only go from higher point to the lower point

    18. 18 Siphon in Petri nets A siphon of a Petri net is defined as a set S of places such that :the input set of S :the output set of S

    19. 19 Siphon in Petri nets The number of tokens in a siphon will never increase and an empty siphon will always remain empty. This is an important property of siphons. And we used this property in our paper to get the theorem.This is an important property of siphons. And we used this property in our paper to get the theorem.

    20. 20 Agenda Background about mismatches in web service composition Related works and our contributions Modeling methods Message ordering mismatch detection and solution Conclusion

    21. 21 Detecting message ordering mismatch (1) Theorem 1: There is a dead transition in C-net if and only if there is an empty siphon. For example, there are 5 minimum siphons in the fig, i.e., S1={p1-5}, S2={p6-10}, S3={p1, p3-5, p7-9, p11, p14}, S4={ p3, p8-9, p12, p14}, S5={ p3-4, p9, p13-14}. M0(S1-3)=1 and M0(S4-5)=0. We show S1-S5 using animations. S1-S3 is always marked with one token while S4-S5 is empty all the time.We show S1-S5 using animations. S1-S3 is always marked with one token while S4-S5 is empty all the time.

    22. 22 Non-empty siphons We show S1-S5 using animations. S1-S3 is always marked with one token while S4-S5 is empty all the time.We show S1-S5 using animations. S1-S3 is always marked with one token while S4-S5 is empty all the time.

    23. 23 Empty siphons We show S1-S5 using animations. S1-S3 is always marked with one token while S4-S5 is empty all the time.We show S1-S5 using animations. S1-S3 is always marked with one token while S4-S5 is empty all the time.

    24. 24 Detecting message ordering mismatch (2) Since there are initial empty siphons, i.e., S4 and S5, there exists message ordering mismatching. This is true because after t1 and t6 fire, there is a message deadlock

    25. 25 Correcting message ordering mismatch Developers provide additional information to break the message deadlock. Developers will have too many choices if using reachability based method and some of the choices will lead to additional work in the future and some of them are not optimal. We optimize the choices by linear programming. Previously, when deadlock happens, the developers construct messages and test if there is any deadlock. The developer has too many choices and some of them will lead to additional work in the future and some of them are not optimal. Now, we can test if there will be any message deadlock by checking empty siphons. When it happens, we add tokens to empty siphons, which is corresponding to adding messages. And by this way, we can also guarantee that the solution will not cause any more work in the future and the solution is optimal. Previously, when deadlock happens, the developers construct messages and test if there is any deadlock. The developer has too many choices and some of them will lead to additional work in the future and some of them are not optimal. Now, we can test if there will be any message deadlock by checking empty siphons. When it happens, we add tokens to empty siphons, which is corresponding to adding messages. And by this way, we can also guarantee that the solution will not cause any more work in the future and the solution is optimal.

    26. 26 Linear programming to optimize choices (1) Objective: minimum number of messages Constraint: (1)the relationship between information places and siphons (2) all the empty siphons marked Compute the following linear programming problem: Minimize 1*L s.t. A*L?1T L: A list of messages that should be provided. A: The contribution matrix of every message to a siphon.

    27. 27 Linear programming to optimize choices (2) Note that, a siphon is a set of places. Siphon S4 contains p12 and p14, so the contribution matrix should be (0,1,0,1)T. This means, if p12 has a token, the siphon S4 will be marked. If p11 has a token, S4 is still unmarked. Thus we can say, p12 contributes to S4 and p11 does not contribute to S4Note that, a siphon is a set of places. Siphon S4 contains p12 and p14, so the contribution matrix should be (0,1,0,1)T. This means, if p12 has a token, the siphon S4 will be marked. If p11 has a token, S4 is still unmarked. Thus we can say, p12 contributes to S4 and p11 does not contribute to S4

    28. 28 Choices Choice 1: Provide both the delivery information and the payment information. L1=(0,1,0,1)T Choice 2: Provide the payment information. L2=(0,1,0,0)T Choice 3: Provide the delivery information. L3=(0,0,0,1)T (Solution of linear programming)

    29. 29 Choice 1: provide both info. L1=(0,1,0,1)T. It is a feasible solution of the linear programming, but not an optimal solution.

    30. 30 Choice 2: provide only payment info. L2=(0,1,0,0)T. It is NOT a feasible solution of the linear programming. Because A*L’=(1,0)T, although S4 is marked, S5 is still empty.

    31. 31 Choice 3: provide only delivery info. L3=(0,0,0,1)T. It is the optimal solution of the linear programming. Because S4 contains p14 and S5 also contains p14, if we add a token to p14, then both S4 and S5 will be markedBecause S4 contains p14 and S5 also contains p14, if we add a token to p14, then both S4 and S5 will be marked

    32. 32 Local choice mismatch solution Different from the message ordering mismatch where there are initial empty siphons, there are no initial empty siphons in local choice mismatch. But some of the siphons may lose their tokens if some transitions fire. We propose a method based on additional information channels in [6] to hold the tokens in siphons such that every siphon is always marked.

    33. 33 Agenda Background about mismatches in web service composition Related works and our contributions Modeling methods Message ordering mismatch detection and resolution Conclusion

    34. 34 Conclusion Although the existing studies can analyze the mismatch problems at the interface and protocol levels based on reachability analysis, they do not provide a direct solution. The main contribution of this paper is to propose a siphon-based analysis technique that yields a variant of component service without mismatches. Without checking the state space, our approach provides an optimized and also automatic solution for correcting protocol-mismatches. This approach greatly reduces the amount of interactions with developers.

    35. 35 Thank you!

More Related