EE. Pimentel, V. Valero (Eds.): Workshop on Formal Languagesand Analysis of Contract-Oriented Software 2011 (FLACOS’11)EPTCS 68, 2011, pp. 23–37, doi:10.4204 / EPTCS.68.4 c (cid:13)
A. Francalanza, A. Gauci & G.J. PaceThis work is licensed under theCreative Commons Attribution License.
Distributed System Contract Monitoring
Adrian Francalanza Andrew Gauci Gordon J. Pace
Department of Computer Science, University of Malta ∗ { adrian.francalanza|agau0006|gordon.pace } @um.edu.mt The use of behavioural contracts, to specify, regulate and verify systems, is particularly relevant toruntime monitoring of distributed systems. System distribution poses major challenges to contractmonitoring, from monitoring-induced information leaks to computation load balancing, communica-tion overheads and fault-tolerance. We present mDP i , a location-aware process calculus, for reason-ing about monitoring of distributed systems. We define a family of Labelled Transition Systems forthis calculus, which allow formal reasoning about di ff erent monitoring strategies at di ff erent levels ofabstractions. We also illustrate the expressivity of the calculus by showing how contracts in a simplecontract language can be synthesised into di ff erent mDP i monitors. As systems continue to grow in size and complexity, the use of behavioural contracts is becoming crucialin specifying, regulating and verifying correctness. Various notions of contracts have been used, but mostprevailing variants enable the regulation of the behaviour of a system, possibly with consequences in caseof violations. Such contracts can then be used in multiple ways, from system validation and verification,to conflict analysis of the contract itself. One important use of contracts is in runtime monitoring: systemtraces are analysed at runtime to ensure that any contract violating behaviour is truncated before it leadsto any further consequences, possibly applying reparations to recover from anomalous states.More and more systems are deployed in a distributed fashion, whether out of our choice or necessity.Distribution poses major design challenges for runtime monitoring of contracts, since monitors them-selves can be distributed, and trace analysis can be carried out remotely across location. This impactsdirectly various aspects of the system being monitored, from the security of sensitive information, toresource management and load balancing, to aspects relating to fault tolerance. Various alternative solu-tions have been presented in the literature, from fully orchestrated solutions where monitors are located ata central location, to statically distributed monitors where the contract monitor is statically decomposedinto di ff erent components hosted at the location where system traces are generated.The primary contribution of this paper is a unified formal framework for studying di ff erent monitor-ing strategies. We present a location-aware calculus supporting explicit monitoring as a first class entity,and internalising behavioural traces at the operational level rather than at a meta-level. We show theexpressivity of the calculus by using it to model di ff erent distributed system monitoring strategies fromthe literature. We also present a novel architecture in which contract monitors migrate across locations tokeep information monitoring local, while limiting remote monitor instrumentation in certain situations.The versatility of the contract-supporting calculus is later illustrated by showing how it can model di ff er-ent instrumentation strategies. In particular, we show how behavioral contracts expressed using regularexpressions can be automatically translated into monitors of di ff erent monitoring strategies. ∗ The research work disclosed in this publication is partially funded by the Strategic Educational Pathways ScholarshipScheme (Malta). The scholarship is part financed by the European Union European Social Fund. Distributed System Contract Monitoring
The paper is organised as follows. In section 2, we outline the contract monitoring strategies fordistributed systems from the literature. We present a monitoring distributed calculus in sections 3 and 4,and illustrate its use for monitoring behavioural contracts expressed as regular expressions in section 5.We discuss related work and conclude in section 6.
Monitoring distributed systems is distinct from monolithic monitoring. These systems are usually char-acterised by the absence of a global clock when ordering events across location boundaries. They oftenconsist of autonomous, concurrently executing subsystems communicating through message passing,each with its local memory, where communication across subsystems is considerably slower than localcommunication. The topology of such systems may sometimes change at runtime through the additionof new subsystems or the communication of private channels. Most internet-based and service-orientedsystems, peer-to-peer systems and Enterprise Service Bus architectures [4] are instances of such systems.These characteristics impinge on contract monitoring. For instance, the absence of a global clockprohibits precise monitoring for consequentiality contracts across locations [11]. Distribution impacts oninformation locality; subsystem events may contain confidential information which must not be exposedglobally thereby requiring local monitoring. The possibility of distributing monitors also introducesconcerns for monitor load balancing and monitor replication for fault tolerance.Whether monitored contracts are known at compile time or else become known at runtime also a ff ectsdistributed monitoring. Static contracts, ones which are fully known at compile time, are typically notexpressive enough for distributed systems with dynamic topologies. Dynamic contracts, ones whichare partially known at compile time, tend to be more appropriate for such systems. They are found inintrusion detection [8], where suspicious user behaviour is learnt at runtime, and in systems involvingservice discovery, where the chosen service may come with a fixed or negotiated contract upon discovery. Existing approaches for distributed system monitoring can be broadly classified into two categories: or-chestration -based or choreography -based. Orchestration-based approaches relegate monitoring respon-sibility to a central monitor overhearing all necessary information whereas choreography-based typicallydistribute monitoring across the subsystems. Orchestration, used traditionally in monolithic systems, isrelatively the simplest strategy and its centralisation facilitates the handling of dynamic contracts. Theapproach is however susceptible to data exposure when contacts concern private information; it alsoleads to considerable communication overhead across locations, and poses a security risk by exposingthe monitor as a central point of attack. By contrast, choreography-based approaches push verificationlocally, potentially minimising data exposure and communication overhead. Communication betweenlocalised monitors is typically substantially less than that induced by the remote monitoring of a centralmonitor. Choreography is however more complex to instrument, as contracts need to be decomposedinto coordinating local monitors, is more intrusive, burdening monitored subsystems with additional lo-cal computation, and is applicable only when the subsystems allow local instrumentation of monitoringcode. Choreographed monitors are also instrumented upfront, which may lead to redundant local instru-mentation in the case of consequential contracts; if monitoring at location k is dependent on verificationat location l , and the check at l is never satisfied, upfront monitor instrumentation at k is never needed. . Francalanza, A. Gauci & G.J. Pace e.g., [3], where web-service compositions are monitored in an orchestrated fashion. By contrast, [1] uses orchestration tomonitor for dynamic properties: web services are centrally monitored against BPMN workflow specifi-cations, facilitating the verification of contracts (representing system properties) discovered at runtime on-the-fly . Extensive work has also been done in static choreography monitoring [13, 7, 10, 12, 14],where communication overhead is mitigated by breaking up contracts into parts which can be monitoredindependently and locally, synchronising between the monitors only when necessary. However, to thebest of our knowledge, these approaches cannot fully handle dynamic contracts with runtime contractdecomposition and distribution, nor do they tackle monitor-induced data exposure.An alternative approach is that of using migrating monitors , which adequately supports dynamiccontracts whilst still avoiding orchestration; in particular, it limits instrumentation of distributed monitorsin cases were monitoring is dependent on computation. Using this approach, monitors reside where theimmediate confidential traces reside, and migrate to other subsystems, possibly discovered at runtime,when information from elsewhere is required i.e., on a by-need basis. This enhanced expressivity alsopermits support for dynamic topologies and contracts learnt at runtime. Example
Consider the hospital system contract:A nurse will have access to a patient’s records after requesting them, as long as his or herrequest is approved by a doctor assigned to the patient.We assume that (i) the nurse requests (and eventually accesses) the patient’s data from a handheld device,(ii) the information about which doctors have been assigned to which patients resides at the central site,and (iii) the patient’s information is stored on the doctors’ private clinic systems, where doctors can alsoallow nurses permission to access patients’ data.A migrating monitor starts on the nurse’s system; upon receiving a patient-information request,it migrates to the hospital system, decomposes, and spreads to the systems of the patient’s assigneddoctors to check for permissions allowing the nurse access to the records. Finally, if the permissionis given, the decomposed monitors migrate back to the nurse’s device to check that the records areavailable. As with choreographed monitoring, and in contrast to orchestration, migrating monitors canensure that monitoring is performed locally. The main di ff erence is that instrumentation of monitorscan be performed at runtime. For instance, when monitoring the hospital contract clause, no monitor isinstalled on a doctor’s system unless a nurse has made a request for information about a patient assignedto that doctor, which is less intrusive. The added expressivity of migrating monitors requires a trust management infrastructure to ensuresafe deployment of received monitors. Various solutions can be applied towards this end, from monitorssigned by a trusted entity showing that they are the result of an approved contract negotiation procedure,to proof-carrying monitors which come with a proof guaranteeing what resources they access. This issuewill not be discussed further here, but is crucial for the practicality of migrating monitors.There are a number of issues relating to these di ff erent monitoring approaches that are unresolved.For instance, it is somewhat unclear, at least from a formal perspective, what added benefits migrationbrings to distributed monitoring. There are also issues relating to the monitoring of consequential proper-ties across locations, which cannot be both sound and complete: in Example 2.1, by the time the monitormigrates to the doctor’s system, the doctor may have already approved the nurse’s request. Distributionprecludes precise analysis of the relative timing of the traces, and one has the option of taking a worst orbest case scenario, avoiding false positives or false negatives respectively. This problem is also prevalentin both orchestrated and choreographed approaches. We therefore require a common formal framework where all three approaches can be expressed. This would, in turn, permit rigorous analysis and evaluationwith respect to these issues.6 Distributed System Contract Monitoring
We present mDP i , an adaptation of the distributed π -calculus in [9], where processes are partitionedacross a flat organisation of locations; their behaviour is amenable to monitoring through traces, admin-istered at a local level. The syntax, presented in Figure 1, assumes denumerable sets of channel names c , d ∈ C hans , location names l , k , h ∈ L ocs , indices n , m , o ∈ I dx and variables x , y ∈ V ars ; identifiers u , v range over I dents = C hans ∪ L ocs ∪ I dx ∪ V ars , with identifier list v , . . . , v n denoted as ¯ v . S , R ∈ S ys :: = k (cid:126) P (cid:127) | S (cid:107) R | new c . SP , Q ∈ P roc :: = stop | u ! v . P | u ? x . P | new c . P | if u = v then P else Q | P (cid:107) Q | ∗ P | { M } ( l , n ) | TT ∈ T rc :: = t ( c , ¯ d , n ) M , N ∈ M on :: = stop | u ! v . M | u ? x . M | new c . M | if u = v then M else N | M (cid:107) N | ∗ M | q ( c , ¯ x ). M | sync( u ). M | getI( x , y ). M | setI( u , v ). M | go u . M | ok | fail Figure 1: mDP i Syntax
Systems , S , R , are made up of located processes k (cid:126) P (cid:127) (the tag k denotes the current location hosting P ) which can be composed in parallel and subject to scoping of channel names.Located entities are partitioned into three syntactic categories: Processes , P roc , comprise the stan-dard communication constructs for output, c! ¯ d .P, and input, c? ¯ x .P (variables ¯ x are bound in the con-tinuation P ), together with the name-matching conditional, replication, parallel composition and namerestriction; Traces , are made up of individual trace entities, t ( c , ¯ d , n ) ∈ T rc recording communication ofvalues ¯ d on channel c at timestamp n - they are meant to be ordered as a complete log recording pastcomputation at a particular location; Monitors , M on , are similar in structure to processes, and are delim-ited at the process level by enclosing brackets { M } ( k , n ) , where ( k , n ) denotes the monitoring context i.e., the location and log position of the trace being monitored . In addition, they can: • query traces for records of communication on channel c , q ( c, ¯ x ). M, where the index and locationof the trace monitored is inferred from the enclosing monitoring context, ( k , n ). • get the information relating to the current monitoring context, getI( x , y ). M ( x , y bound in M ), andset the monitoring context to specific values k and n , setI( k , n ). M , or else update to the currenttimestamp of a location k , sync( k ). M , • migrate to location k , go k. M, and • report success, ok , or failure, fail . Shorthand:
We often elide trailing stop processes. We thus represent asynchronous outputs such asc!¯ v . stop as c!¯ v and branches such as if u = v then P else stop as if u = v then P. We also denote k { [ M ] } ( l , n ) as syntactic sugaring for k (cid:126) { M } ( l , n ) (cid:127) .Our calculus describes distributed, event-based, asynchronous monitoring. Monitoring is asyn-chronous because it happens in two phases, whereby the operational mechanism for tracing is detachedfrom the operational mechanism for querying the trace. This two-set setup closely reflects the limits im-posed by a distributed setting and is more flexible with respect to the various monitoring mechanisms we . Francalanza, A. Gauci & G.J. Pace event-based because we chose only to focus on recording and analysingdiscrete events such as communication.For simplicity, our calculus only records e ff ected output process events in traces (which dually implye ff ected inputs); we can however extend traces to record other e ff ects of computation in straightforwardfashion. In order to extract realistic temporal ordering of traces across locations, the calculus providestwo mechanisms for monitor re-alignment: the coarser (and real-time) sync operation is used to startmonitoring from a particular instant in time; the more explicit context update setI enables hard-codedcontrol of relative timing at the level of monitors. For instance, together with getI , it enables decomposedmonitoring to hand over tracing at a specific index in a local trace. This mechanism gives more controland can improve distributed monitoring precision, but may also lead to unsound monitoring. Tracing:
Whenever communication occurs (possibly across two locations) on some channel c withvalues ¯ v , a trace entity of the form t ( c,¯ v ,n ) is produced at the location where the output resides . Theoutput location, which keeps a local counter, assigns the timestamp n to this trace entity and incrementsits counter to n +
1. Local timestamps induce a partial-order amongst all trace entities across the system .In particular, we obtain a finite (totally ordered) chain of traces per location . Example (Distributed Tracing) . Consider the distributed system of outputs:l (cid:126) c ! v (cid:127) (cid:107) l (cid:126) c ! v (cid:127) (cid:107) k (cid:126) c ! v (cid:127) Assuming that locations l and k have the respective timestamp counters n and m, once all outputs areconsumed we can obtain either of the following possible sets of trace entities (for simplicity, we assumethat v (cid:44) v ): l (cid:126) t ( c , v , n ) (cid:127) , l (cid:126) t ( c , v , n + ) (cid:127) , k (cid:126) t ( c , v , m ) (cid:127) (1) l (cid:126) t ( c , v , n + ) (cid:127) , l (cid:126) t ( c , v , n ) (cid:127) , k (cid:126) t ( c , v , m ) (cid:127) (2) The timestamps of trace-set (1) record the fact that the output on c was consumed before that on c ,whereas those of trace-set (2) record the opposite. However, in both of these trace-sets, the timestampassigned to the trace-entity relating to c , recorded at location k, does not indicate the order it wasconsumed, relative to the outputs on c and c , which occurred at location l. Concurrent Monitoring:
In our model, traces may be queried by multiple concurrent entities, whichallows for better separation of concerns when monitors are instrumented. Trace querying is performedexclusively by monitors, l { [ M ] } ( k , n ) , parameterised by the monitoring context ( k , n ); indicating that moni-tor M is interested in analysing the n th trace record at location k . Example (Parallel Monitoring) . Consider the trace-set (1) from Example 3.1. A (local) monitordetermining whether, from timestamp n onwards, a value v was communicated on the first output onchannel c at location l, can be expressed as:l { [ q ( c , x ).if x = v then ok else fail ] } ( l , n ) The counter n of this monitor indicates that it starts analysing the trace-set (1) from the trace entityl (cid:126) t ( c , v , n ) (cid:127) and continues moving up the chain of trace entities until the first trace entity describingoutputs on channel c is encountered. Since l (cid:126) t ( c , v , n ) (cid:127) states that the event occurred on anotherchannel, namely c , the monitor skips the irrelevant trace entity and its index is incremented to n + i.e., Distributed System Contract Monitoring l { [ q ( c , x ).if x = v then ok else fail ] } ( l , n + . The monitor analyses the trace entity with the incrementedtimestamp n + i.e., l (cid:126) t ( c , v , n + ) (cid:127) , which happens to match the required event on channel c ; themonitor thus substitutes v , obtained from the trace entity l (cid:126) t ( c , v , n + ) (cid:127) , for x and proceeds with themonitor processing, which should eventually yield ok . Traces can be concurrently queried by multiplemonitors. For instance, consider another monitor running in parallel with the previous one of the form:l { [ q ( c , x ). q ( c , y ).if x = y then ok else fail ] } ( l , n ) which checks that equal values are communicated on channels c and c . Thus it is important that traceentities, such as l (cid:126) t ( c , v , n + ) (cid:127) , are persistent and not consumed once analysed, as in the case ofoutputs in a message passing setting. Distributed Monitoring:
Distribution adds another dimension of complexity to monitor instrumenta-tion, in terms of how to partition monitors across locations and how this partitioning evolves as compu-tation progresses. In our calculus, remote querying can be syntactically expressed as k { [ q ( c , x ). M ] } ( l , n ) forsome c and n , where k (cid:44) l . We can also describe the di ff erent classifications of distributed monitoringoutlined earlier in Section 2. Example
Consider a distributed system
Sys (cid:44) l (cid:126) c ? x . c ! x (cid:127) (cid:107) new d . ( k (cid:126) d ? x . c ! x (cid:127) (cid:107) l (cid:126) c ! v . d ! v . c ? x . stop (cid:127) ) where c ? x . c ! x and c ! v . d ! v . c ? x . stop are located at l whereas d ? x . c ! x is located at k. Moreover,process d ? x . c ! x shares a scoped channel d with c ! v . d ! v . c ? x . stop . For some timestamps n and m, Sys non-deterministically produces either of the traces (3) or (4) below; the non-determinism is caused bythe competition for the output on channel c by respective inputs at l and k: new d . ( l (cid:126) t ( c , v , n ) (cid:127) , l (cid:126) t ( d , v , n + ) (cid:127) , l (cid:126) t ( c , v , n + ) (cid:127) ) (3) new d . ( l (cid:126) t ( c , v , n ) (cid:127) , l (cid:126) t ( d , v , n + ) (cid:127) , k (cid:126) t ( c , v , m ) (cid:127) ) (4) The preservation of the property ‘Whenever a value e is communicated on the first output on c atlocation l, then this value is not output on a subsequent output on channel c at k’ in general cannot beadequately determined statically, due to the non-deterministic nature of the computation, as exhibited bythe possible traces (3) and (4). However, the property can be monitored at runtime in a number of ways:M orch (cid:44) h { [ q ( c , x ). if x = e then sync( k ). q ( c , y ). if x = y then fail ] } ( l , n ) M chor (cid:44) new d (cid:48) . ( l { [ q ( c , x ). if x = e then d (cid:48) ! x ] } ( l , n ) (cid:107) k { [ d (cid:48) ? x . sync( k ). q ( c , y ). if x = y then fail ] } ( k , m ) ) M mig (cid:44) l { [ q ( c , x ). if x = e then go k . sync( k ). q ( c , y ).if x = y then fail ] } ( l , n ) M orch monitors for this property in orchestrated fashion, querying traces at both l and k from a remotecentral location h; this monitor is well-aligned with location l to start with, but has to explicitly re-alignwith location k once monitoring shifts to that location. M chor is an instance of a choreographed monitorsetup, instrumenting local monitors at each location where trace querying needs to be performed, namelyl and k. These local monitors synchonise between them using remote communication on the scopedchannel d (cid:48) . Note that the monitor at k updates its context upon channel synchronisation on d (cid:48) to ensurea temporal ordering on analysed trace records; without synchronisation, the monitor would potentiallybe reading past parts of the trace which may lead to unsound sequentiality conclusions. Finally, M mig is a case of a migrating monitor , that starts monitoring at location l but then migrates to location k if itneeds to continue monitoring there, re-aligning its index to that of the destination location. . Francalanza, A. Gauci & G.J. Pace wrt. the property stated, in the sense that theynever falsely flag a violation. They are nevertheless incomplete, and may miss out on detecting propertyviolations. For instance, M orch may realign with location k after the trace k (cid:126) t ( c , v , m ) (cid:127) is generated by k , which sets the monitor timestamp index to ( k , m + k from index m + k (cid:126) t ( c , v , m ) (cid:127) . This aspect ishowever not a limitation of our encoding, but rather an inherent characteristic of distributed computingas discussed earlier in Section 2. We define the semantics of mDP i in terms of a number of related Labelled Transition Systems (LTSs),which are then used to compare systems through the standard notion of weak-bisimulation equivalence,denoted here as ≈ . This framework allows us to state and prove properties from a behavioural perspectiveabout our monitored systems. For instance, we could express the fact that, ignoring monitoring location, M orch and M chor from Example 3.3 monitor for the same properties wrt. Sys , using the statement: Sys (cid:107) M orch ≈ Sys (cid:107) M chor (5)Using an LTS that does not express observable monitor actions, the property that a monitor, say M orch ,does not a ff ect the observable behaviour of the system Sys could be stated as:
Sys ≈ Sys (cid:107) M orch (6)Using di ff erent LTSs, the same system could be assigned more restricted behaviour. For instance, this isuseful to ensure that the monitor M mig of Example 3.3 does not perform remote querying at any stageduring its computation by establishing the comparison: Sys (cid:107) M mig ≈ (( Sys (cid:107) M mig ) without remote monitoring) (7)where the lefthand system is subject to an LTS allowing remote querying whereas the righthand monitoris subject to an LTS that prohibits it. Intuitively, if the behaviour is preserved when certain internal movesare prohibited, this means that these moves are not used (in any useful way) by the monitor. Closer inspection of the comparisons (5), (6) and (7) reveals that the di ff erent LTSs required are stillexpected to have substantial common structure; typically they would di ff er with respect to either theinformation carried by actions and / or the type of actions permitted. For instance, in (5) we would wantactions that restrict information relating to the location of where monitoring is carried out, as this ad-ditional information would distinguish between the two monitors. On the other hand, for (7) we wouldwant to prohibit actions relating to remote monitoring.We therefore construct these related LTSs in modular fashion through the use of a preLTS , i.e., anLTS whose transitions relate more systems, and whose action labels carry more information than actuallyneeded. The excess transitions and label information are then pruned out as needed by a filter function from actions in the preLTS to actions in the LTS required.0 Distributed System Contract Monitoring i Our preLTS is defined over systems subject to a local logical clock at every location used by the system,which are used to generate ordered trace-entities and to re-align monitors. These clocks are modelled asmonotonically increasing counters and expressed as a partial function δ ∈ ∆ :: L ocs (cid:42) N , where δ ( l ) de-notes the next timestamp to be assigned for a trace entity generated at l . Moreover, the counter incrementis defined using standard function overriding, inc ( δ, k ) = δ [ k (cid:55)→ ( δ ( k ) + O ut P δ (cid:66) k (cid:126) c ! d . P (cid:127) c ! ¯ d (cid:104) p : k , l (cid:105) −−−−−−→ inc ( δ, k ) (cid:66) k (cid:126) P (cid:127) (cid:107) k (cid:126) t ( c , ¯ d , δ ( k ) ) (cid:127) I n P δ (cid:66) l (cid:126) c ? x . P (cid:127) c ? ¯ d (cid:104) p : k , l (cid:105) −−−−−−−→ δ (cid:66) l (cid:126) P { ¯ d / ¯ x } (cid:127) O ut T δ (cid:66) k (cid:126) t ( c , ¯ d , n ) (cid:127) c ! ¯ d (cid:104) t : k , l : n (cid:105) −−−−−−−→ δ (cid:66) k (cid:126) t ( c , ¯ d , n ) (cid:127) I n T δ (cid:66) l { [ q ( c , ¯ x ). M ] } ( k , n ) c ? ¯ d (cid:104) t : k , l : n (cid:105) −−−−−−−→ δ (cid:66) l { [ M { ¯ d / ¯ x } ] } ( k , n + O ut M δ (cid:66) k { [ c ! d . M ] } ( l , n ) c ! ¯ d (cid:104) m : k , h (cid:105) −−−−−−−→ δ (cid:66) k { [ M ] } ( l , n ) I n M δ (cid:66) l { [ c ? x . M ] } ( k , n ) c ? ¯ d (cid:104) m : h , l (cid:105) −−−−−−−→ δ (cid:66) l { [ M { ¯ d / ¯ x } ] } ( k , n ) O pen δ (cid:66) S (¯ b ) c ! ¯ d γ −−−−−−→ δ (cid:48) (cid:66) S (cid:48) δ (cid:66) new b . S ( b , ¯ b ) c ! ¯ d γ −−−−−−−→ δ (cid:48) (cid:66) S (cid:48) [ b (cid:44) c , b ∈ ¯ d ] R es δ (cid:66) S µ −−→ δ (cid:48) (cid:66) S (cid:48) δ (cid:66) new b . S µ −−→ δ (cid:48) (cid:66) new b . S (cid:48) [ b (cid:60) fn ( µ )]C om δ (cid:66) S (¯ b ) c ! ¯ d γ −−−−−−→ δ (cid:48) (cid:66) S (cid:48) δ (cid:66) R c ? ¯ d γ −−−−→ δ (cid:66) R (cid:48) δ (cid:66) S (cid:107) R τ γ −−→ δ (cid:48) (cid:66) new ¯ b . ( S (cid:48) (cid:107) R (cid:48) ) [¯ b ∩ fn ( R ) = ∅ ]S kip δ (cid:66) S (¯ b ) c ! ¯ d (cid:104) t : l , k : n (cid:105) −−−−−−−−−−→ δ (cid:66) S δ (cid:66) k { [ M ] } ( l , n ) c ?¯ e (cid:104) t : l , k : n (cid:105) −−−−−−−−→ δ (cid:66) k { [ M (cid:48) ] } ( l , n + δ (cid:66) S (cid:107) k { [ M ] } ( l , n ) τ (cid:104) t : l , k : l , n (cid:105) −−−−−−→ δ (cid:66) S (cid:107) k { [ M ] } ( l , n + [ c (cid:44) c ]S et I δ (cid:66) k { [ setI( h , m ). M ] } ( l , n ) τ (cid:104) m : k , k (cid:105) −−−−−→ δ (cid:66) k { [ M ] } ( h , m ) S ync δ (cid:66) k { [ sync( l ). M ] } ( h , n ) τ (cid:104) m : k , k (cid:105) −−−−−→ δ (cid:66) k { [ M ] } ( l ,δ ( l )) G et I δ (cid:66) k { [ getI( x , y ). M ] } ( l , n ) τ (cid:104) m : k , k (cid:105) −−−−−→ δ (cid:66) k { [ M { l , n / x , y } ] } ( l , n ) G o δ (cid:66) k { [ go l . M ] } ( h , n ) τ (cid:104) m : k , l (cid:105) −−−−−→ δ (cid:66) l { [ M ] } ( h , n ) Figure 2: mDP i preLTS main rulesA Configuration C , D ∈ C onf :: ∆ × S ys is thus a system subject to a set of localised counters. ThepreLTS is a ternary relation → :: C onf × p A ct × C onf , denoted using the suggestive notation C µ −→ D ,where µ ∈ p A ct is a preLTS action label of the form, τ γ , an internal action, (¯ b ) c ! ¯ d γ , an output action, or c ? ¯ d γ , an input action. In case of the output action, ¯ b denotes the (possibly empty) set of channel namesexported during an eventual interaction. These actions are standard [9], but are decorated with additionalinformation γ which can be of the following three formats: . Francalanza, A. Gauci & G.J. Pace (cid:104) p : l , k (cid:105)− This states that it is a process ( p ) action, involving locations l and k . (cid:104) m : l , k (cid:105)− This states that it is a monitor ( m ) action, involving locations l and k . (cid:104) t : l , k : n (cid:105)− This states that it is a trace ( t ) action at timestamp n , involving locations l and k , .The main rules defining the relation C µ −→ D are outlined in Figure 2. The rule for process input, I n P,is standard, except for the additional label tag (cid:104) p : k , l (cid:105) encoding the fact that the input is a process input,it resides at location l , and is reading from some location k (when communication is local, then l = k ).A central rule to our monitoring semantics is O ut P. Apart from the additional label decoration, it di ff ersfrom standard output rules in two respects: first it generates a trace entity, k (cid:126) t ( c , ¯ d , δ ( k ) ) (cid:127) , recording thechannel name, c , the values communicated, d , timestamped by δ ( k ), and second, it increments the clockat k once the trace entity is generated, necessary for generating a total order of trace-entities at k . Monitorcommunication, defined by rules O ut M and I n M, is similar albeit simpler since neither trace entities aregenerated, nor is the local counter updated .Rule O ut T models trace actions as output labels with tags (cid:104) t : k , l : n (cid:105) , where the timestamp of thetrace, n , is recorded in the tag as well. Crucially, the trace entity is not consumed by the action (therebyacting as a broadcast), and its persistence allows for multiple monitors to query it. This action can bematched by a query action, I n T, expressed as an input action with a matching tag (cid:104) t : k , l : n (cid:105) wherethe source location of the trace entity, k , and time stamp n must match the current monitoring context( k , n ). Since the action describes the fact that a trace entity has been matched by the monitor query, thetimestamp index of the monitoring context is incremented, ( k , n +
1) to progress to the next entitity in thelocal trace log.Scope extrusion of channel names may occur both directly, through process or monitor communica-tion, or else indirectly through trace querying; these are both handled by the standard scoping rules O pen and R es . All three forms of communication i.e., process, monitor and trace, are also handled uniformly,this time by the communication rule C om τ γ that is decorated with the corresponding tagging information from the constituent inputand output actions of the premises. This tagged information must match for both input and output actionsand, in the case of the trace tags, (cid:104) t : k , l : n (cid:105) , this also implies a matching of the timestamp n . When, fora particular timestamp, querying does not match the channel of the trace entity at that timestamp, ruleS kip allows the monitor to increase its timestamp index and thus querying to move up the trace-chain atthat location. Finally, S ync allows monitors to realign with a trace at a particular location, G et I and S et Iallow for explicit manipulations of the monitoring context whereas G o describes monitor migration. Although necessary to encode extended information of system execution, the preLTS presented is too dis-criminating. For instance, the internal action τ γ is now compartementalised into distinct silent actions,each identified by the tag information γ , which complicates their use for weak actions when verifyingbisimilar configurations. Similarly, external actions di ff erentiating between a process or a monitor carry-ing out that action may also be deemed to discriminating. Finally, we may also want to disallow certainactions such as remote trace querying.We obtain LTSs with the necessary level of discriminating actions using (i) the preLTS of Section 4.2,together with (i) a filter function, Ω . This function maps actions in the preLTS, µ ∈ p A ct , to actions in Note that rule O ut M refers to an indeterminate location h , to match a reader in any such location. Distributed System Contract Monitoring the required LTS, α ∈ A ct , through the rule: F ltr C µ −−→ C C α −−→ Ω C [ Ω ( µ ) = α ] Notation:
Note that filter function applications are essentially abstractions of the preLTS. LTSs ob-tained in this manner can e ff ectively be indexed by their respective filter function, Ω , and for clarity wedenote a configuration C subject to a behaviour obtained from the preLTS and a filter function Ω as C Ω .We also denote transitions obtained in this form as C α −−→ Ω C . Example (Filter Functions) . Consider the following filter function definitions: Ω NTg ( τ γ ) (cid:44) τ Ω Prc ( τ γ ) (cid:44) τ Ω LTr ( τ (cid:104) t : l , l : n (cid:105) ) (cid:44) τ Ω NTg ( c ! ¯ d γ ) (cid:44) c ! ¯ d Ω Prc ( c ! ¯ d (cid:104) p : l , k (cid:105) ) (cid:44) c ! ¯ d (cid:104) l , k (cid:105) Ω LTr ( τ (cid:104) : l , k (cid:105) ) (cid:44) τ Ω NTg ( c ? ¯ d γ ) (cid:44) c ? ¯ d Ω Prc ( c ? ¯ d (cid:104) p : l , k (cid:105) ) (cid:44) c ? ¯ d (cid:104) l , k (cid:105) Ω LTr ( c ! ¯ d γ ) (cid:44) c ! ¯ d Ω LTr ( c ? ¯ d γ ) (cid:44) c ? ¯ d Ω NTg removes all tags from decorated actions, which in turn allows for a straightforward definitionof weak actions, ˆ α = ⇒ , as ( τ −−→ ) ∗ if α = τ and ( τ −−→ ) ∗ α −−→ ( τ −−→ ) ∗ otherwise. In addition to stripping τ actiontags, the second filter function, Ω Prc , allows only process external actions, filtering out the p componentin this case. The function is partial as it is undefined for all other preLTS actions. This is useful when wedo not want to discriminate configurations based on the tracing and monitoring actions. The final filterfunction, Ω LTr , removes all tags but uses them to prohibit silent tracing actions where the two locationsin the tag are distinct; this in e ff ect rules out remote trace querying, thereby enforcing localised tracemonitoring . We assume a certain well-formedness criteria on our filter functions, such as that they do not changethe form of an action ( e.g., an output action remains an output action), and that whenever they mapto silent actions, τ , these are not decorated; the filter functions in Example 4.1 satisfy these criteria.Through this latter requirement we re-obtain the standard silent τ -action at the LTS level. The technical development in sections 4.2 and 4.3 allows us to immediately apply weak bisimulation [9]as a coinductive proof technique for equivalence between LTSs obtained for our preLTS and well-formedfilter functions. Two (filtered) LTSs, C Ω and D Ω , are bisimilar, denoted as C Ω ≈ D Ω , if they matcheach other’s transitions; we use the weak bisimulation variant, ≈ , as this abstracts over internal τ -actionswhich yields a more natural extensional equivalence. Example
Using the filter functions defined in Example 4.1, we can formally state and prove equiv-alences (5), (6) and (7) outlined earlier, for a localised clock-set δ including locations l and k: ( δ (cid:66) Sys (cid:107) M orch ) Ω NTg ≈ ( δ (cid:66) Sys (cid:107) M chor ) Ω NTg (8)( δ (cid:66) Sys ) Ω Prc ≈ ( δ (cid:66) Sys (cid:107) M orch ) Ω Prc (9)( δ (cid:66) Sys (cid:107) M mig ) Ω NTg ≈ ( δ (cid:66) Sys (cid:107) M mig ) Ω LTr (10)
Equivalence (8) formalises the behaviour expected for (5) using an LTS whose actions prohibit distinc-tions based on action tags; including monitoring location, i.e., Ω NTg . Since in (6) we wanted to analyse . Francalanza, A. Gauci & G.J. Pace how monitors a ff ect process computation, in its corresponding equivalence (9) we use an LTS that tagsprocess external actions with location information while prohibiting any actions relating to tracing ormonitoring. Finally (10) compares M mig with itself, subject to a restricted semantics where remote mon-itoring is prohibited, i.e., Ω LTr . The instrumentation of contracts as distributed monitors is non-trivial and can easily lead to unsoundcontract monitoring. In this section we illustrate how the instrumentation of contracts, expressed usinga simple regular expression-based temporal logic specifying violation traces, can be safely automatedaccording to di ff erent monitoring approaches. The syntax of the contract language is: E :: = ( c , ¯ v )@ k | E . E | E ∗ | E + EBasic events have the form ( c , ¯ v )@ k indicating that a communication on channel c with value ¯ v occursat location k . We adopt a semantics allowing for multiple matches, rather than opt only for the shortestmatch and thus any trace terminating with a communication c !¯ v at location k is considered to be aviolating trace. The other operators are the standard ones used in regular expressions: E . F correspondsto the traces which can be split into two, with the first matching E , and the second matching F ; expression E ∗ corresponds to traces which can be split into a number (possibly zero) parts, each of which satisfies E ; and E + F corresponds to the set of traces which match either E or F . Notation: (cid:80) e ∈ I E corresponds to the generalised choice over finite I , which is equal to E { i / e } + E { i / e } + . . . E { i n / e } (where I = { i , i . . . , i n } ).Despite the apparent simplicity of this expository contract language, we can already express interest-ing contracts. Example
Consider a simplification of the contract outlined in Example 2.1: “The release of apatient’s record must be approved by supervising doctors.”
Stated in terms of what leads to a violation,we get: “If a patient’s medical record is released regardless of a doctor’s disapproval, the contract isviolated” which can be expressed as the regular expression: (cid:88) p ∈ Patient ( req , ())@ p . (cid:88) d ∈ Doctor ( withhold , p )@ d . ( send , p )@ hwhere p, d and h are locations referring to the patient’s, the doctor’s and the hospital domain, channelnames req , withhold and send denote actions requesting, withholding and sending medical records, andsets Patient and Doctor range over the finite patients and doctors in the system. There are di ff erent ways in which one may transform a regular expression into an mDP i term. Forinstance, ( c , v )@ k . ( c , v )@ k may be matched by either one monitoring process, M , or by the splitmonitors, M , below: M (cid:44) sync( k ). q ( c , x ).if x = v then ( sync( k ). q ( c , x ).if x = v then fail ) M (cid:44) ( sync( k ). q ( c , x ).if x = v then m !) (cid:107) ( m ? . sync( k ). q ( c , x ).if x = v then fail ) In any case, when runtime monitoring one may choose to halt the system on the shortest match. Distributed System Contract Monitoring
Figure 3: Compiling E . F , E + F and E ∗ (respectively) where C , B correspond to comb , bifurc.We find that the second translation, M , lends itself better towards illustrating how monitors can bedistributed in di ff erent ways across locations — for example, in an orchestrated approach, we wouldplace all the monitoring processes in a single location, while in a choreographed approach, we woulddistribute the processes as required. A sequential approach such as M , may be more approriate in anorchestrated approach (since it avoids unnecessary parallelism), but would not be possible to distributeto enable choreographed monitoring without further manipulation.In this paper, we adopt the maximally parallelised approach, primarily to be able to observe simi-larities and distinctions between di ff erent compilation approaches. In particular we use this translationfor a compilation strategy corresponding closely to standard approaches used in hardware compilationof regular expressions [6], producing circuits with two additional wires: an input which is signaled uponto start matching the regular expression, and an output wire which the circuit uses to signal a match withthe regular expression. In our case, the wires correspond to channels: basic events ( c , v )@ k with startchannel s and match channel f would be translated into an expression which waits for input on channel s , then outputs on channel f when an instance of c with v occurs at location k . Our translations also em-ploy two standard monitor organisations for funneling two output signals into one and forking channelcommunication onto two separate ones; these are expressed below as the macros comb and bifurc:comb( f , f , f ) (cid:44) ∗ ( f ? ¯ x . f ! ¯ x ) (cid:107) ∗ ( f ? ¯ x . f ! ¯ x ) bifurc( s , s , s ) (cid:44) ∗ s ? ¯ x . ( s ! ¯ x (cid:107) s ! ¯ x )We define three compilation strategies, ψ O , ψ C and ψ M , corresponding respectively to monitoring usingorchestration, static choreography and migrating monitoring as discussed in section 2. The compilationprocedures use three parameters: two control channels (used to notify when the regular expression is tostart being matched, and to notify when it has matched) and the expression to be compiled. For simplicity,all three translations follow a similar pattern shown by the block diagrams in Figure 3, varying only inthe location placement of the monitors and synchronisation strategy. Orchestration places the monitor at some predefined central location, h . As stated earlier, the lack ofa global clock prevents it from deducing with certainty the order of events happening across di ff erentlocations. Nevertheless, our translation attempts to mitigate this imprecision for sequence of eventsoccurring at the same location using the following mechanism: when a basic event is matched, themonitoring context, ( k , n ), at that moment is recorded using getI and passed as arguments on the matchsignaling channel; this allows subsequent matching to explicitly adjust the monitoring context to thesevalues using setI in cases where the location of subsequent events does not change; in cases wherethe location changes, this information is redundant and alignment is carried out using the coarser sync command. ψ (cid:48) O ( s , f , (( c , ¯ v )@ k )) (cid:44) ∗ ( s ?( x loc , x idx ) . if k = x loc then ( setI( x loc , x idx ). trg ( c , ¯ v , f )) else ( sync( k ). trg ( c , ¯ v , f )))In either case, a listener triggers a signal with the updated index of the trace on the match channel forevery event c with data ¯ v . Specifically, the macro trg( c , ¯ v , f ) repeatedly reads from channel c , outputting . Francalanza, A. Gauci & G.J. Pace f every time the data traced matches ¯ v :trg( c , ¯ v , f ) (cid:44) ∗ ( q ( c , ¯ x ).if ¯ x = ¯ v then getI( x loc , x idx ). f !( x loc , x idx ))The compilation of the regular expression operators matches the compilation schemata of figure 3: ψ (cid:48) O ( s , f , ( E . F )) (cid:44) new m . ( ψ (cid:48) O ( s , m , E ) (cid:107) ψ (cid:48) O ( m , f , F )) ψ (cid:48) O ( s , f , E ∗ ) (cid:44) new c , s (cid:48) , f (cid:48) . comb( s , f (cid:48) , c ) (cid:107) bifurc( c , s (cid:48) , f ) (cid:107) ψ (cid:48) O ( s (cid:48) , f (cid:48) , E ) ψ (cid:48) O ( s , f , ( E + F )) (cid:44) new s , s , f , f . (cid:16) bifurc( s , s , s ) (cid:107) ψ (cid:48) O ( s , f , E ) (cid:107) ψ (cid:48) O ( s , f , F ) (cid:107) comb( f , f , f ) (cid:17) The combined monitors are located at the predefined central location h , with a dummy initial monitorcontext continuation parameters ( h , E is thus: ψ O ( E ) (cid:44) h { [ new s , f . ( s !( h , (cid:107) ψ (cid:48) O ( s , f , E ) (cid:107) f ? ¯ x . fail ) ] } ( h , Instead of instrumenting the whole monitor at a single central location, a choreography-based approachdecomposes the monitor into parts, possibly placing them at di ff erent locations. Once again, monitorsare made up of two kinds of components: (i) the event listeners; and (ii) the choreography control logicmade up of comb and bifurc components. The event listeners are located locally, where the event takesplace, but are otherwise exactly the same as in the orchestrated approach: ψ (cid:48) C ( s , f , (( c , ¯ v )@ k )) (cid:44) k { [ ψ (cid:48) O ( s , f (( c , ¯ v )@ k ))] } ( k , On the other hand, the choreography control logic can be placed at any location. For instance one maychoose to locate them at the node where the next input will be expected, or where the last one occurred.For a particular choice of locations l and h , choice E + F is compiled as follows: new s , s , f , f . (cid:16) l { [bifurc( s , s , s )] } ( l , (cid:107) ψ (cid:48) C ( s , f , E ) (cid:107) ψ (cid:48) C (( s , f ) , F ) (cid:107) h { [comb( f , f , f )] } ( h , (cid:17) Finally, we add the necessary start signal (from some start location k ) to initiate the monitoring: ψ C ( E ) (cid:44) new s , f . k { [ s !( k , (cid:107) f ? ¯ x . fail ] } ( k , (cid:107) ψ (cid:48) C ( s , f , E )Note that unless all the locations enable the execution of new (monitoring) process at runtime, thecontracts must be known at compile-time, which is guaranteed in the simple regular expression logic weare using. For the migrating monitors technique, we use a simplified translation where the monitors generated aresimilar to the ones used in orchestration, except that the monitor migrates when required to the relevantlocation (using the go operator). ψ (cid:48) M is defined identical to ψ (cid:48) O except for basic events: ψ (cid:48) M ( s , f , (( c , ¯ v )@ k )) (cid:44) ∗ ( s ?( x loc , x idx ) . go k . if k = x loc then ( setI( x loc , x idx ). trg ( c , ¯ v , f )) else sync( k ). trg ( c , ¯ v , f ))6 Distributed System Contract Monitoring
Note how migration (thus monitor instrumentation) is delayed and happens only once the start signalon channel s is received. Initially, the monitor can be chosen to reside anywhere. For a particular locationchoice h , the migrating monitor approach for a contract E would be the following: ψ M ( E ) (cid:44) h { [ new s , f . ( s !( h , (cid:107) ψ (cid:48) M ( s , f , E ) (cid:107) f ? ¯ x . fail ) ] } ( h , Despite the resemblances resulting from our simplistic translations, migration improves on an orches-trated approach by avoiding remote tracing. As in the choreographed approach, one can also choose toexplicitly run the combining and bifurcation processes at particular locations by adding explicit migra-tion instructions. A better approach would be to nest all the monitors within each other to avoid monitorsmigrating or installed before they are actually required. For example, monitoring for an expression ofthe form: ( c , v )@ l . ( c , v )@ k . ( c , v )@ h would be transformed into a monitor of the form: go l . ( q ( c , x ).if x = v then go k . ( q ( c , x ).if x = v then go h . ( q ( c , x ).if x = v then fail )))Note that using this approach entails minimal local monitor instrumentation since this happens on aby-need basis: the translation avoids installing any monitor at location k unless c ! v happens at l .Even within this simplistic formal setting, migrating monitors can be seen to be more versatile than achoreographed approach. For instance, if our contract language is extended with variables and a bindingconstruct, ∃ x . E , we could express a more dynamic form of contract such as ∃ x . ( c , x )@ k . ( c , v )@ x ;in such a contract the location of the second event depends on the location communicated in the firstevent and, more importantly, this location is not known at compile time. Because of this last point, thiscontract cannot be handled adequately by traditional choreographed approaches which would need topreemptively instrument monitors at every location . However, in a migrating monitor approach, thisnaturally translates to a single runtime migration. We have shown how one can formulate di ff erent monitoring strategies of the same contract using mDP i .The contract language and its compilation procedure have intentionally been kept simple to avoid theircomplexity from obscuring the underlying monitoring choices. The di ff erent approaches mostly di ff eronly in the location of the monitors. The migrating monitor approach also allows for straightforwardsetting up of new contracts at runtime, including references to locations not known at compile-time.Furthermore, the migrating approach procrastinates from setting up monitors in remote locations untilnecessary. In contrast, on a choreographed approach, monitors are set up at all locations, even thoughsome of them may never be triggered.Formalising the compilation of regular expression contracts into mDP i also gives us opportunities toformally verifying certain properties. For instance, as a generalisation of (8) we can state and prove that,for arbitrary expression E , di ff erent compilation approaches give the same monitoring result. We canstate this as: δ (cid:66) Sys (cid:107) ψ O ( E )) Ω NTg ≈ ( δ (cid:66) Sys (cid:107) ψ C ( E )) Ω NTg ≈ ( δ (cid:66) Sys (cid:107) ψ M ( E )) Ω NTg and prove it by giving witness bisimulations defined by induction on the structure of E . One can provesimilar results on the lines of the equivalences given in section 4.4. . Francalanza, A. Gauci & G.J. Pace We have presented a novel process calculus framework in which distributed contract monitoring canbe formalised and analysed. We have shown it to be expressive enough to encode various distributedmonitoring strategies. To the best of our knowledge, it is unique in that it traces are first class entitiesrather than meta-constructs. We modularly developed various semantics for this calculus, using transitionabstraction techniques that enable selective reasoning about aspects such as locality of communicationand distinctions between monitor and process actions.We are currently working on an implementation in Erlang [2], guided by the design decisions madefor our calculus. This should give us insight into practical issues, such as that of addressing trust is-sues when installing monitors and the avoidance of indirect data exposure due to monitoring. We arealso studying mDP i further, addressing issues such as clock boundaries and real-time operators. Asthe calculus stands, the monitoring component is non-intrusive, in that it reads system events but doesnot otherwise interact with it. To handle reparations and enforcements upon contract violation, and tobe able to express monitor-oriented programming [5] we require potentially intrusive monitoring. Webelieve that our bisimulation approach can also handle reasoning about monitor intrusiveness. References [1] C. Abela, A. Calafato & G.J. Pace:
Extending WISE with Contract Management . In:
WICT 2010 .[2] Joe Armstrong (2007):
Programming Erlang: Software for a Concurrent World . Pragmatic Bookshelf.[3] Fabio Barbon, Paolo Traverso, Marco Pistore & Michele Trainotti (2006):
Run-Time Monitoring of Instancesand Classes of Web Service Compositions . In:
ICWS ’06: Proceedings of the IEEE International Conferenceon Web Services , IEEE Computer Society, Washington, DC, USA, pp. 63–71, doi:10.1109 / ICWS.2006.113.[4] David Chappell (2004):
Enterprise Service Bus . O’Reilly Media.[5] Feng Chen & Grigore Ros¸u (2003):
Towards Monitoring-Oriented Programming: A Paradigm Combin-ing Specification and Implementation . In:
Runtime Verification (RV’03) , ENTCS / S1571-0661(04)81045-4.[6] Koen Claessen & Gordon J. Pace (2002):
An Embedded Language Framework for Hardware Compilation .In:
Designing Correct Circuits ’02, Grenoble, France .[7] T. Cook, D. Drusinksy & M.-T. Shing (2007):
Specification, Validation and Run-time Moniroting of SOABased System-of Systems Temporal Behaviors . In:
System of Systems Engineering , IEEE Computer Society.[8] Dorothy E. Denning (1987):
An intrusion-detection model . IEEE Transactions on Software Engineering / TSE.1987.232894.[9] Matthew Hennessy (2007):
A Distributed Pi-Calculus . Cambridge University Press, New York, NY, USA.[10] I. H. Kr¨uger, M. Meisinger & M. Menarini (2010):
Interaction-based Runtime Verification for Systems ofSystems Integration . J Logic Computation / logcom / exn079.[11] L. Lamport (1977): Proving the Correctness of Multiprocess Programs . IEEE Trans. Softw. Eng.
3, pp.125–143, doi:10.1109 / TSE.1977.229904.[12] Masoud Mansouri-Samani & Morris Sloman (1997):
GEM: a generalized event monitoring language fordistributed systems . Distributed Systems Engineering / / / / E ffi cient Decentralized Monitoring ofSafety in Distributed Systems . International Conference on Software Engineering , pp. 418–427.[14] W. Zhou, O. Sokolsky, B. Thau Loo & I. Lee (2009):
DMaC: Distributed Monitoring and Checking.
In:
Runtime Verification 09 , LNCS //