This document discusses diagnosing uncontrollability in services. It explains that uncontrollability can have many different reasons and is independent of specification language. It presents patterns that can cause uncontrollability and discusses the relationship between uncontrollability and soundness. The document proposes an algorithm to diagnose uncontrollability by partitioning graphs into "good" and "bad" parts and analyzing how moves occur from good to bad. Blacklists are used in the algorithm to identify issues like deadlocks.

1. Why does my servicehave no partner? Diagnosing uncontrollability Niels Lohmann WS-FM 2008 ▪ Milan ▪ 5 September 2008 http://service-technology.org/wsfm2008 UNIVERSITÄT ROSTOCK

2. Controllability "soundness for services" answer to "Does my service have partners?" or "Can anyone use my service?" existence of partner proves controllability implemented in tool Fiona (see next talk) 2

3. Uncontrollable services 3 decision not communicated (non-local choice): resubmission necessary?

4. Uncontrollable services (2) 4 infinite message queue necessary: not controllable

5. Uncontrollable services (3) 5 WS-BPEL asynchronous message transfer yields non-local choice:which branch was taken?

6. Uncontrollable services (4) 6 YAWL decision communicated, but control flow may deadlock

7. Uncontrollable services (5) 7 Open Petri Net control flow may run into livelock

8. Uncontrollability can have many different reasons is independent of specification language 8

9. Patterns for Uncontrollability 9 controllable net containing the pattern pattern for non-local choice controllable net containing the pattern

10. Uncontrollability can have many different reasons is independent of specification language is a non-local criterion 10

11. Relationship to Soundness 11 unsound, uncontrollable sound, uncontrollable sound, controllable relaxed sound, uncontrollable unsound, controllable

12. Uncontrollability can have many different reasons is independent of specification language is a non-local criterion has no relationship to soundness 12

13. Witness for controllability 13 ✗ remaining graph iswitness for controllability

14. Witness for uncontrollability 14 ✗ ✗ ✗ ✗ ✗ no graph left to witness uncontrollability

15. Uncontrollability can have many different reasons is independent of specification language is a non-local criterion has no relationship to soundness current algorithm provides no witness next step (very briefly): provide diagnosis information answer "Why does my service have no partners?" 15

16. Diagnosing Uncontrollability goal: find reasonable partof the graph idea: partition graph into two parts: good: no error occurred (yet) bad: error already occurred or unavoidable diagnosis: analyze moves from good to bad part realization: blacklists 16

17. Blacklists preprocessing of the open net deadlocks and livelocks(communication-independent issues) during graph generation covered final marking(can be related to a non-local choice) exceeded message bound 17

18. Diagnosis Algorithm consider states that can be left with sending events if successors are blacklisted, print the reason otherwise consider non-blacklisted successors 18 non-local choice between b and c may yield to cover final marking!

19. Wrap up uncontrollability… is a very undesired property of a service can have a lot of reasons cannot be avoided using anti-patterns can now be diagnosed! next steps: implementation provide assistance towards controllability extend diagnosis to cope with choreographies 19 Thank you! Any questions?