important, because Web services may run unobserved
order of A and B cannot be enforced
trivial control flow issues can also avoid controllability
trivial control flow issues can also avoid controllability
hard to oversee (Online Shop IBM)from now on open nets: least constraints (channels, conflicting receives)other languages can be translated to open nets
idea: use anti-patterns to detect uncontrollablity
no structural approaches known
the composed system should be (weak) soundcontrollability is property of _one_ partno relationship to soundness
we cannot recycle existing approaches
we find no graph we can use as counterexample
state of the art: tool tells me THAT net is not controllable, but not WHY
we want to distinguish necessary (safe) communication from unsafe
diagnosis is important, because uncontrollability is very subtle
Why does my service have no partners? - Presentation Transcript
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
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
Uncontrollable services 3 decision not communicated (non-local choice): resubmission necessary?
Uncontrollable services (2) 4 infinite message queue necessary: not controllable
Uncontrollable services (3) 5 WS-BPEL asynchronous message transfer yields non-local choice:which branch was taken?
Uncontrollable services (4) 6 YAWL decision communicated, but control flow may deadlock
Uncontrollable services (5) 7 Open Petri Net control flow may run into livelock
Uncontrollability can have many different reasons is independent of specification language 8
Patterns for Uncontrollability 9 controllable net containing the pattern pattern for non-local choice controllable net containing the pattern
Uncontrollability can have many different reasons is independent of specification language is a non-local criterion 10
Uncontrollability can have many different reasons is independent of specification language is a non-local criterion has no relationship to soundness 12
Witness for controllability 13 ✗ remaining graph iswitness for controllability
Witness for uncontrollability 14 ✗ ✗ ✗ ✗ ✗ no graph left to witness uncontrollability
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
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
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
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!
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?
0 comments
Post a comment