Reasoning about the Behavior of Semantic Web Services with Concurrent Transaction Logic

1. Reasoningabout the Behavior of Semantic Web Services with Concurrent Transaction Logic Presented By Dumitru Roman, Michael Kifer University of Innsbruk, State University of New York 2008-01-04 Summerized By Sungchan Park

2. Overview • Improve the authors’ previous works on Web Service modeling • Concurrent Transaction Logic(CTR) • Logic based Modeling and Analysis of Workflows. 1998 • A Logical Framework for Scheduling Workflows under Resource Allocation Constraints. 2002 • CTR-S: A Logic for Specifying Contracts in Semantic Web Services. 2004 • Reasoning about behavior about WS • Contracting, Enactment • Improvement • Conditional control, data flow • More general constraints • Simpler logic than CTR-S Center for E-Business Technology

3. Modeling & Reasoning about Service Behavior Center for E-Business Technology

4. Modeling & Reasoning about Service Behavior: Example Center for E-Business Technology

5. The Basics of CTR • Atomic formula • P(t1, t2, …, tn) • P : predicate • ti : function term • Complex formulas are built using connectives and quantifiers • Informal Sematics • Database states • Eg. s1, s2, …, sn • Paths( sequences of states) • Eg. <s1>, <s1, s2>, … • Truth value of CTR formula is determined over path • Formula a is true over a path <s1, s2, …, sn> iff a can “excute” starting at state s1, change to s2, s3, … etc. Will terminate at state sn. Center for E-Business Technology

6. The Basics of CTR, Cont. • CTR Connectives • a ⊗ b • execute athen execute b • a | b • a and bmust both execute concurrently in an interleaved fashion. • a ᴧ b • a and b must both execute along the same path • Constraints • a ᴠ b • execute a or execute b non-deterministically • ¬a • execute in any way, provided that this will not be a valid execution of a • ⊙a • execute a in isolation execution i.e., without interleaving with other concurrently running activities Center for E-Business Technology

7. Concurrent-Horn subset of CTR • Concurrent-Horn rule • p ← q • Means “if q can execute along path <s1, … , sn>, then so p can do” • p : atomic formula • q : concurrent horn goal • Atomic formula • a ⊗ b, a | b, a V b when a and b are concurrent horn goals • ⊙a when a is concurrent horn goal • Examples • Process ← a ⊗ ( b | Subproc ) ⊗ g • Subproc ← ( c ⊗ ( d v ( e ⊗ f ))) Center for E-Business Technology

8. Concurrent-Horn subset of CTR, Cont. • Can use SLD-like proof procedure • In previous work, G ᴧ C can be transformed into horn goal by limiting class of constraints • In present work, however, the extended proof theory of CTR overcomes the limitation of constraints Center for E-Business Technology

9. Modeling Services with CTR: Control Flow Center for E-Business Technology

10. Modeling Services with CTR: Constraints • Unlike previous works, we use predicates with variables—not just propositions—to represent control and data flow. • Constraints Algebra • Event • e = ∃DataFlowVar eventName(DataFlowVar) • Primitive • ∇e : Event e must happen = path ⊗ e ⊗ path • ¬ ∇e : Event e must not happen • Immediate serial constraints • ∇ ⊙(e1⊗ … ⊗ en) : e1, …, en happen next to each other with no other event in-between • Serial constraints • ∇ (e1⊗ … ⊗ en) : e1, …, en excute in that order with possible interleaving • Complex constraints • C1∧ C2, C1 ∨C2 Center for E-Business Technology

11. Modeling Services with CTR: Constraints, Cont. • Expression Examples • Events e and f must both occur (in any order) • ∇e ∧ ∇f • It is not possible for e and f to happen together • ¬ ∇e ∧ ¬ ∇f • If event e occurs, then f must also occur (before or after e) • ∇e → ∇f • If event e occurs, then f must occur later • ∇e → (∇e ⊗ ∇f) • If event f has occurred, then event e must have occurred some time prior to that • ∇f → (∇e ⊗ ∇f) • If both e and f occur, then e must come before f • (∇e ∧ ∇f) → (∇e ⊗ ∇f) • If event e occurs, then f must occur right after e with no event in-between • ∇e → ∇ ⊙(e ⊗ f) • If k and d both occur then d must happen right after k with no other event in-between • (∇k ∧ ∇d) → ∇ ⊙(k ⊗ d) Center for E-Business Technology

12. Modeling Services with CTR: Constraints, Cont. Center for E-Business Technology

13. Modeling Services with CTR: Data Flow and Conditional Control Flow • Data flows imply constraints Center for E-Business Technology

14. Modeling Services with CTR: Data Flow and Conditional Control Flow • Conditions in control flow are checked ahead and unsatisfiable branches are eliminated Center for E-Business Technology

15. Reasoning about Choreography and Contracts • Contracting • Determine if contracting for the service is possible • Find out if there is an execution of the CTR formula G ∧ C given the set of service choreography definition R • Check that there is a path s1, s2, …, such that • R, s1, …, skㅑG ∧ C • Enactment • Find a constructive proof that • R, s1, …, skㅑ G ∧ C for some paht s1, …, sk • Eachproof is a way to execute the choreography so that all constraints are satisfied Center for E-Business Technology

16. Reasoning about Choreography and Contracts, Cont. • Phase 1 • Transform to normal form • From G ∧ C to ∨i(Gi∧j serialConstrij) • Gi is a concurrent-Horn goal and SerialConstrij is either an immediate serial constr. or a serial constr. • NP-Complete in the size of largest number of disjuncts in C • Phase 2 • Find the proof using inference rules • If proof is found, them enactment of the service is possible • Linear in the size of the execution path Center for E-Business Technology

17. Reasoning about Choreography and Contracts, Phase 1 • Transformation rules • Applying Complex Constraints • Applying Primitive Constraints • If the result is ¬path, then enactment is not possible • Otherwise, the result is a formula of the form ∨i(Gi ∧j serialConstrij) Center for E-Business Technology

18. Reasoning about Choreography and Contracts, Phase 2 • Phase 2 has two step • Check constraints for internal consistency and eliminate redundancy • Apply inference rules Center for E-Business Technology

19. Reasoning about Choreography and Contracts,Phase 2:Step 1 • Check inconsistency • Inconsistent patterns • Eliminate redundancy • Examples Center for E-Business Technology

20. Reasoning about Choreography and Contracts,Phase 2:Step 2 • Extended Inference System • hot(Ψ) • “ready to be excute” • hot(Ψ) = Ψ , if Ψ is atomic formula • hot(Ψ ⊗ Ф) = hot(Ψ) • hot(Ψ | Ф) = hot(Ψ) | hot(Ф) • hot(Ψ∨Ф) = hot(Ψ) ∨ hot(Ф) • enabled(C) • The set of enabled component of a set of constraints C is as follows:enabled(C) = {x | x is a root node of C or x is not in C} • eligible(Ψ) • x, if x ∈ hot(Ψ) ∩ enabled(C) and x is and exclusive node in C • hot(Ψ) enabled(C), otherwise • eligible(Ψ) ⊆ hot(Ψ) Center for E-Business Technology

21. Reasoning about Choreography and Contracts,Phase 2:Step 2, Cont. • Inference rules • Applying transactional definitions • If b ←β be a rule in P and assume that its variables have been renamed so that none are shared with Ψ. If a and b unify with the most general unifier σ then then, • Ψ’ is Ψ with some occurrence replaced with b • C’ is C after deleting a and splicing edges adjacent on a • Querying the database • If (∃)aσ is true in D and aσ and G’σshare no var. then, • Ψ’ is Ψ with some occurrence of a deleted Center for E-Business Technology

22. Reasoning about Choreography and Contracts,Phase 2:Step 2, Cont. • Inference rules, cont. • Executing elementary updates • If aσ is an elementary state transition from state D1 to D2 then • Ψ’ is Ψ with some occurrence of a deleted • C’ is C with after deleting some nodes • Executing atomic transactions • If ⊙α is hot component in then, • Ψ’ is Ψ with some occurrence of a deleted Center for E-Business Technology

23. Reasoning about Choreography and Contracts,Phase 2:Step 2, Cont. • Difference with previous CTR inference system • Rule 3 operates on eligible occurrence of atomic formula, while previous one did on a larger set of hot occurrence • Rule 1 and 3 also modify the set of constraints Center for E-Business Technology

24. Bird’s Eye View of the Approach • The Web service designer starts to build Web service choreography by drawing a control flow graph, a data flow graph, and specifying service policy using a GUI tool. • The logical representations can be constructed automatically from an appropriately instrumented GUI tool. • The designer then uses the algorithm to find un-enactable parts of the control flow graph. • The designer uses the CTR reasoner-based algorithm to make sure that the control graph is consistent with the service policies. • The client submits the contract requirements to verify that a contract is possible. As before, verification is done using the CTR. Center for E-Business Technology

25. Related Work • Service contracting • Existing work focuses on defining frameworks, models, and architectures different aspects and phases of e-contracting (negotiation, enforcement, violation detection, monitoring, legal aspects) • We provide a simple yet realistic and useful framework for e-contracting • Solve a concrete problem in establishing of contracts and enacting Web services • Workflow/process modeling • Many languages for process modeling, e.g. YAWL, DecSerFlow • Ours is as expressive as DecSerFlow, and additionally integrates with conditional control flows, data flows, provides reasoning mechanisms • Process verification • Most of the existing approaches use model checking for verification • Complexity exponential in the size of the control graph • CTR’s integrates several process modeling paradigms: conditional control flows, data flows, hierarchical modeling, constraints • Complexity polynomial in the size of the control graph and exponential in the size of the constraints (due to better structuring of the problem) Center for E-Business Technology

26. Conclusion • Formulated the problems of choreography, contracting, and enactment for semantic Web services using Concurrent Transaction Logic • complex set of constraints • data flow and conditional process controls • extended CTR proof theory • Presented reasoning techniques for • deciding if automatic contracting for a service is possible • finding a choreography that obeys the policy of the service and the user requirements of the contract • enacting the service • Can be extended to multi-party contracts • Possible extensions • more expressive interaction patterns, e.g. loops • subsets of constraints for which the verification problem has a better complexity Center for E-Business Technology