260 likes | 381 Views
Reasoning about 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. Overview.
E N D
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
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
Modeling & Reasoning about Service Behavior Center for E-Business Technology
Modeling & Reasoning about Service Behavior: Example Center for E-Business Technology
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
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
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
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
Modeling Services with CTR: Control Flow Center for E-Business Technology
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
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
Modeling Services with CTR: Constraints, Cont. Center for E-Business Technology
Modeling Services with CTR: Data Flow and Conditional Control Flow • Data flows imply constraints Center for E-Business Technology
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
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
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
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
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
Reasoning about Choreography and Contracts,Phase 2:Step 1 • Check inconsistency • Inconsistent patterns • Eliminate redundancy • Examples Center for E-Business Technology
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
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
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
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
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
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
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