1. WSMX Execution Semantics Executable Software Specification Eyal Oren DERI eyal.oren@deri.org

2. WSMX execution semantics2 eyal.oren@deri.org Background information WSMX: execution environment for dynamic discovery, selection, mediation and invocation of semantic web services WSMX is built on WSMO: services, ontologies, goals and mediators WSMX: manages repository, achieves user’s goal by selecting matching service, mediating and invoking

3. WSMX execution semantics3 eyal.oren@deri.org Designing WSMX Conceptual model: what are we talking about Architecture: components, how they interact Execution semantics: system behaviour

4. WSMX execution semantics4 eyal.oren@deri.org What did we do? Design of WSMX includes formal specification of system behaviour Reasons: –enlarging developers’ understanding of the system –proving properties of the system –enabling model-driven component execution We present the execution semantics of WSMX Did our approach address the objectives?

5. WSMX execution semantics5 eyal.oren@deri.org What are execution semantics? Four phases in software development: requirements, design, implementation, testing Formal methods can be used during design: to improve the design process and the result Formal method: a mathematically-based language for specifying systems Execution semantics: a formal definition of operational behaviour of a system.

6. WSMX execution semantics6 eyal.oren@deri.org Why model execution semantics? Formal methods do not make correct programs! Increase understanding and agreement between project members (by explicit specification process) To check properties of the constructed specification: discover future properties of the modelled system

7. WSMX execution semantics7 eyal.oren@deri.org Why model execution semantics? Execute the specification –general idea: specification is input for execution engine; engine executes model, informs components to perform a task (workflow management, business process management) –main argument in favour: flexibility, not hard- coding this interplay, no need to translate specification into programming code –main argument against: inefficient implementation; might not be important: if composition is simple and components themselves are implemented efficiently

8. WSMX execution semantics8 eyal.oren@deri.org Requirements Enlarge developers’ understanding: technique must be easily readable yet unambiguous Check properties of the system: technique must be formal and have a proof system Automate coordination between components: technique must have operationalisation, and execution procedure for a model

9. WSMX execution semantics9 eyal.oren@deri.org How to model execution semantics? We want to automate control flow between components Components treated as black-boxes: we know their functionality but not how they operate Using Petri nets –graphical, supposedly easily understood –formalised, well analysable –executable

10. WSMX execution semantics10 eyal.oren@deri.org WSMX execution semantics (see paper)

11. WSMX execution semantics11 eyal.oren@deri.org Using execution semantics The goal was: –understandability –model checking –model-driven execution Did this work?

12. WSMX execution semantics12 eyal.oren@deri.org Did it work? Understandability –not easily readable: syntax is very simple, but model gets complex –hard to write and time-consuming to maintain –simulation is very helpful Executing specification –technical problems: synchronous invocation from the engine –work in progress – the general idea is ok

13. WSMX execution semantics13 eyal.oren@deri.org Did it work? Model checking –large amount of work on problems in Petri nets (algorithms, tools, decidability & complexity results) –however, we did not use this possibility: –during implementation developers had to manually translate the Petri net specification into Java code. –but model is not easily readable: implementation did not strictly follow model! –model checking not very useful

14. WSMX execution semantics14 eyal.oren@deri.org Conclusion Specifying execution semantics as part of software development Three objectives: understandability, model checking, component execution Used Petri nets to specify the behaviour of WSMX Petri nets are not a useful technique for this specification: –not easily readable (and not easily writable) –model checking and executability in principle possible

15. WSMX execution semantics15 eyal.oren@deri.org Future Investigate other techniques that overcome these problems –take into account: we want to do model checking and execute the specification –UML Activity diagrams: easily readable, more intuitive, no model execution –YAWL: builds on Petri nets, designed for usability, no good tools yet Separate techniques: –use one model for proving and executing –use second model for clarification and understanding –(second would be generated from the first)

16. WSMX execution semantics16 eyal.oren@deri.org Questions?