1 / 36

Semantic Web Service Choreography: Contracting and Enactment

Semantic Web Service Choreography: Contracting and Enactment. 7 th International Semantic Web Conference (ISWC) October 26-30 2008, Karlsruhe, Germany Dumitru Roman 1 and Michael Kifer 2 1 University of Innsbruck / STI Innsbruck, Austria

becca
Download Presentation

Semantic Web Service Choreography: Contracting and Enactment

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. 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)

More Related