Semantic Web Service Choreography: Contracting and Enactment

1. Semantic Web Service Choreography:Contracting and Enactment 7th International Semantic Web Conference (ISWC) October 26-30 2008, Karlsruhe, Germany Dumitru Roman1and Michael Kifer2 1University of Innsbruck / STI Innsbruck, Austria 2State University of New York at Stony Brook, New York, U.S.A. dumitru.roman@sti2.at, kifer@cs.sunysb.edu

2. Outline • Context and motivation: Automated service contracting • Modeling and reasoning about service behavior for automated service contracting • Elements of service contracts • Expressivity of the modeling language for service contracts • Reasoning technique for service contracting • Related work • Conclusions and outlook 2

3. Semantic Web Services Tasks to be automated in SWS; paper focus and areas of contributions SWS Approaches: OWL-S, SWSF, WSMO, SAWSDL 3

4. Automated service contracting • Overall aim: Automate service contracting • Problems with traditional service contracting • High costs for contract establishment and management • Slow for rapidly changing business situations • Automated service contracting can potentially • Lower contract establishment and management costs • Speed up and improve contract establishment and management • Current status: No expressive modeling frameworks and contract establishment techniques • General approach • Focus on those aspects of contracting that constrain interactions in processes • Define the conceptual framework • Formalization, representation, and reasoning 4

5. Service contracting – overview and objectives Service Contract = Choreography + Service Policies + Client Contract Requirements Main objectives: • An expressive language for contracting • Service choreography • Service policies • Client contract requirements • A reasoning mechanism to decide if service contracting is possible 5

6. Is this contract’s execution possible? Service contracting – a motivating example control flow data flow 6

7. Language for service contracts • Aim • An expressive representational framework for service contracts: combining procedural and declarative aspects • Common requirements • Service choreographies • Conditional control flow: Sequential, concurrent, non-deterministic, and iterative interactions • Data flow: Local and non-local data passing between interactions • Service Policies and Client Contract Requirements • Temporal and conditional constraints 7

8. Modeling service choreography control flow • Tasks: Primitive, non-iterative, and iterative composite • Composition of tasks: Sequential, concurrent, and non-deterministic • Hierarchical representation of service choreography control flow 8

9. Modeling service choreography data flow • Local and non-local data passing between interaction tasks: Data flow graph 9

10. Modeling policies as constraints • Primitive constraints • existence(task,n), absence(task), exactly(task,n) • Serial constraints • after(task1,task2), before(task1,task2), blocks(task1,task2), between(task1,task2, task1), not-between(task1,task2, task1) • Immediate serial constraints • right-after(task1,task2), right-before(task1,task2), not-right-after(task1,task2) • Complex constraints – if C1 and C2 are constraints, then so are • C1 and C2 • C1 or C2 10

11. Examples absence(full_payment) or (before(deliver,full_payment) andblock(full_payment.deliver)) 11

12. More examples of constraints • A task a must execute at most n times • absence(a) or existence(a,1)or existence(a,2) or …or existence(a,n) • Every occurrence of task a must be followed by an occurrence of b and there must be an occurrence of a before every occurrence of b • after(a,b) andbefore(a,b) • Tasks a and b must alternate • between(a,b,a) andbetween(b,a,b) • If task a is executed then b must execute after it, and before that there can be no other a • absence(a) orbetween(a,b,a) • If task b is executed, it has to be preceded by an occurrence of a. The next b can be executed only after another a • absence(a) or (before(a,b) andbetween(b,a,b)) 12

13. The Problem of Service Contracting and Enactment • Service contracting: Decide if the contract is satisfiable • Service enactment: If it is, find an enactment Service choreography What is the actual order of interactions if service contracting is possible? Is this contract’s execution possible? 13 13

14. Solution overview • Concurrent Transaction Logic (CTR) – our formalism for • Choreographies • Service policies • Client contract requirements • Extend CTR when necessary • Prove correctness 14

15. Short introduction to CTR • Why CTR? • Logic for specification and execution of transactional processes • Integrates queries, updates, and transaction composition • Has proof procedure for concurrent Horn formulas: proof =execution • Can express a wide variety of constraints • Has been applied in the area of workflow verification and scheduling with promising results • Atomic CTR formulas: same as in classical logic • More complex formulas: built using connectivesab, a | b, a /\ b, a \/ b, ¬a, a b a g d and • Process  a ( b | Subproc ) g • Subproc ( c ( d ( ef ))) or c f e Subproc Process 15

16. Service contract formalization with CTR ConcurrentHorn /\ Constraints … … /\ … … 16

17. Contributions • Prior work • Original CTR proof theory does not handle constraints • Prior work added simple constraints, but • No iterative processes • No constraints on iterations • No data flow • New • Add the necessary modeling primitives • Extend the CTR proof theory to handle service contracting with iterations, data flow, etc. • As a result • Can capture much of BPMN and WS-BPEL process modeling • And contracting over them 17

18. Reasoning about service contracts with CTR • Contracting: Find out if an execution of the CTR formula Choreography/\ Policy /\ ClientRequirements exists • Enactment: Find a constructive proof for this execution Main result: The extended inference system is sound and complete for proving the above • Soundness: Every found execution is correct • Completeness: All possible executions can be found 18

19. Extended proof theory – An overview • Sequent: • Meaning: can execute starting at D given P • Each inference rule looks like this: For example: • Has five inference rules and one axiom sequent1 sequent2 19

20. Inference rules • Applying transaction definitions • If a ← b is in P then ’ is  with an occurrence of a replaced with b • Querying the database • if a is a database predicate in  and D|=a then ’ is  with an occurrence of a deleted 20

21. Inference rules (cont’) • Simplification • If δ is a primitive constraint then where S is a simplification transformation that does things like this (details in the paper): 21

22. Inference rules (cont’) • Executing primitive task • If D1— a —> D2 is an elementary update then • ’ is with an occurrence of a deleted C’ is C after deleting/adding/modifying constraints (details omitted) • Executing atomic transactions • If α occurs in  then ’ is with an occurrence of α deleted 22

23. Related Work • E-contracting • Pieces of frameworks, models, architectures and different aspects and phases of e-contracting (negotiation, enforcement, violation detection, monitoring, legal aspects), but no unifying formalism • We provide a unifying and general framework for e-contracting • Workflow/process modeling • Most languages are procedural (WS-BPEL, BPMN, YAWL). The declarative ones (DecSerFlow) are inexpressive • Our framework: very expressive. Integrates conditional control flow, data flow, hierarchical modeling, and complex constraints • Process verification • Most of the existing approaches use temporal logic/model checking. No obvious way to handle certain aspects: data flow, hierarchical modeling • We use CTR. More natural modeling language. Sometimes has better complexity. 23

24. Conclusions and Outlook • Summary • Identified main element of service contracts and formulated the problem of service contracting in SWS • Modeling: Developed an expressive representational framework for service contracts, combining procedural and declarative elements • Reasoning: Developed a sound and complete proof theory for deciding if contracting for a service is possible • Future work • Integration of service contracting with other SWS tasks, e.g. discovery, negotiation, composition • Complexity study, e.g. subsets of constraints for which the verification problem has a better complexity 24

25. ISWC 2008 Thank you! ? \/ ! 25

26. Tasks and their composition

27. Constraints formalization (1)

28. Constraints formalization (2)

29. Constraints formalization (3)

30. Inference system – preliminary definitions

31. Inference rules (1)

32. Inference rules (2)

33. Inference rules (3)

34. Simplification transformation (1)

35. Simplification transformation (2)

36. Simplification transformation (3)