Consider, for instance, a car rental system (CRS) which acts as a broker offering its customers the ability to rent cars provided by different car rental companies.
Requirements Monitoring for Service-Based Systems: Towards a framework based on Event Calculus George Spanoudakis and Khaled Mahbub Department of Computing City University London EC1V 0HB E-mail: {gespan | am697}@soi.city.ac.uk ABSTRACT This paper proposes a framework for run-time monitoring of the compliance of systems composed of web-services with requirements set for them. The framework assumes systems composed of web-services which are co-ordinated by a service composition process expressed in BPEL4WS and uses event calculus to specify the requirements to be monitored. These requirements include behavioural properties of the system which are automatically extracted from the specification of its composition process in BPEL4WS and/or assumptions that system providers can specify in terms of events extracted from this specification. Requirements are checked using a variant of techniques for checking integrity constraints against temporal deductive databases.
1. Introduction Even if it can be demonstrated that a software system can meet its requirements prior to deployment, the ability to verify the same conclusion at run-time is also necessary. This is because at run-time requirements may be violated as a result of unpredicted changes in the environment of a system or failure to anticipate the behaviour of all the agents that may interact with it (i.e. other systems and human users [2]). For systems which are composed dynamically from autonomous web services co-ordinated by some composition process (referred to as "service based systems" in the following), the ability to monitor the compliance of run-time system behaviour with requirements is even more important. This is because in such systems, both the agents interacting with the system and the individual services that constitute it that may change or behave in unpredictable ways. The common approach that underpins techniques developed to support requirements monitoring at run-time assumes that system providers must identify the set of requirements to be monitored, specify them in some formal language, and then derive from each formal requirement statement a pattern of events whose occurrence at run-time would imply the violation of the requirement. The event patterns are subsequently fed into some monitor which checks a log of events generated by the system and reports violations of the requirements. In a monitoring setting, system events are typically generated either through instrumentation (i.e., the insertion of code statements that can generate the expected events)
[2][5][6], or by querying the system if it has reflective capabilities [9]. Existing requirements monitoring techniques fail to deal adequately with some significant complications which arise in service-based systems, as they focus on systems with no autonomous components. The first complication arises due to the possibility of some components failing to function as expected. Such failures may lead other components to make incorrect assumptions about the state of the system and, consequently, take actions which would not have been taken if the correct state of the system was known. Consider, for instance, a car rental system (CRS) which acts as a broker offering its customers the ability to rent cars provided by different car rental companies directly from car parks at different locations. Suppose also that CRS is implemented as a service based system that consists of a service composition process that interacts with: Car information services (IS) that are provided by different car rental companies, and maintain registries of cars, check car availability and allocate cars to customers as requested by CRS. Sensoring services (SS) that are provided by different car parks to sense cars as they are driven in or out of car parks and inform CRS accordingly. User interaction services (UI) that provide CRS with a front-end that handles interactions with the end-users. In a typical operational scenario, CRS receives car rental requests from UI services and checks for the availability of cars by contacting IS services. If an available car can be found at the requested location, CRS books the car rental through an IS service, and takes payment. When cars move in and out of car parks, SS services inform CRS, which subsequently invokes operations in IS services to update the availability status of the moved car. In this scenario, CRS may wrongly accept a car rental request and allocate a specific car to it if, due to malfunctioning of an SS service, the departure of the relevant car from a car park has not been reported and, as a consequence, the car is considered to be available by IS. Covering for possibilities like this requires the introduction of types of requirements deviation beyond classical inconsistency and the development of appropriate reasoning mechanisms for detecting them. A second complication arises as in service-based systems the generation of events through code
instrumentation may not be possible. This is because the provider of such systems may not own the individual services which constitute it and individual services may change dynamically. In CRS, for example, typically the SS and IS services won’t be owned by the owner of CRS. Also, new instances of these services may be deployed when new car rental companies and car parks make their offerings available to the system, and existing instances may be withdrawn when companies and car parks stop their collaboration with CRS. In such settings, monitoring has to be based on events and state information that can be obtained from the system composition process that can be reasonably assumed to be in the ownership of the system provider and is fixed at run-time. Requirements for individual services may still be specified and monitored but only if this is possible through events that are known to the composition process of the system, or events that can be derived from them. In this paper, we describe a framework that supports the monitoring of requirements for service-based systems and provides a foundation for addressing the above complications. In this framework, requirements specify behavioural properties of the composition process of a service-based system, or assumptions about the behaviour of the system as a whole, its constituent services or external agents that interact with it. Behavioural properties are automatically extracted from the specification of the composition process of the service based system which is expressed in BPEL4WS [1] (i.e., an XML based language for specifying executable business processes which deploy web-services to achieve their goals). Assumptions are specified by system providers and expressed in terms of events, effects and state variable conditions which are used in the behavioural properties. Both behavioural properties and assumptions are expressed in event calculus [13] and our framework can monitor three different types of deviations from them, namely: (i) inconsistencies w.r.t recorded system behaviour, (ii) inconsistencies w.r.t expected system behaviour and (iii) unjustified system behaviour. Monitoring is based on events which are exchanged between the composition process and the constituent services of a service-based system and uses a variant of techniques developed for checking integrity constraints in temporal deductive databases [4][10]. The rest of the paper is structured as follows. In Section 2, we introduce event calculus and give examples of specifying requirements using it. In Section 3, we discuss the different forms of requirement deviations that can be detected by our framework. In Section 4, we discuss the monitoring scheme of the framework. In Section 5, we overview related work. Finally, in Section 6, we summarise our approach and outline directions for future work on it.
2. Requirements specification in event calculus Event calculus (EC) is a logic language based on firstorder predicate calculus that can be used to represent and reason about the behaviour of dynamic systems. Its choice as the requirements specification language of our
framework has been motivated by the need to express the properties to be monitored in a formal language with welldefined semantics that allows: (a) the specification of temporal constraints and (b) reasoning based on the inference rules of first-order logic (this criterion has led to the choice of event calculus instead of another temporal logic language). In EC, the behaviour of a system is specified in terms of events and fluents. An event is something that occurs at a specific instance of time and may change the state of a system (e.g., invocation of an operation, assignment of a value to a variable). A fluent is a signifier of a system state (e.g., the value of a variable). To specify behavioural properties and assumptions for service-based systems, we use 5 different types of events. These events signify: (i) The invocation of an operation by the composition process of a service based system in one of its partner services. These events are represented by terms of the form: ic:Service:OperationName(Parameters) (ii) The return from the execution of an operation invoked by the composition process in a partner service. These events are represented by terms of the form: ir:Service:OperationName(Parameters). (iii) The invocation of an operation in the composition process by a partner service. These events are represented by terms of the form: rc:Service:OperationName(Parameters). (iv) The reply following the execution of an operation that was invoked by a partner service in the composition process. These events are represented by terms of the form: re:Service:OperationName(Parameters). (v) The assignment of a value to a variable. Assignment events are represented in our framework by terms of the form: as:AssignmentName(assignmentId)1 We also use fluents to signify conditions over the values of specific variables of the composition process of a service-based system. The fluents that we use are: equalTo(x,y) − This fluent signifies that the value of the variable x is equal to y. greaterThan(x,y) − This fluent signifies that the value of the variable x is greater than y. lessThan(x,y) − This fluent signifies that the value of the variable x is less than y. The occurrence of an event is signified by the special predicate Happens(e, t, ℜ(t1,t2)). This predicate signifies that an event e occurs at some time t that is within the time range ℜ(t1,t2)2. An event may initiate or terminate a fluent specifying part of the state of a system. In EC, these effects are represented by the predicates Initiates(e,f,t) and Terminates(e,f,t), respectively. The former of these predicates signifies that a fluent f starts to hold after the event e at time t. The latter predicate signifies that a fluent f ceases to hold after the event e occurs at time t. An EC 1
In (i)-(ii), Service denotes the service that executes the operation while (iii) and (iv) it denotes the service that invokes the operation. 2 Happens(e,t,ℜ(t1,t2)) in our framework is equivalent to Happens’(e,t) ∧ (t1 ≤ t) ∧ ( t ≤ t2) where Happens’(e,t) is the predicate that signifies an event occurrence in standard EC [13].
specification may also use the predicates InitiallyP(f) and HoldsAt(f,t). The former of these predicates signifies that the fluent f holds in the beginning of the operation of a system and the latter predicate signifies that the fluent f holds at time t. In addition to the above predicates and event/fluent denoting terms, the formulas that express behavioural properties and assumptions in our framework can use the predicates < and = to express time conditions (the literal t1 < t2 is true if t1 is a time instance that occurred before t2, and the literal t1 = t2 is true if t1 is a time instance that is equal to t2). Behavioural properties: (B1) (∀ v:Car,c:Customer, l: Park, t1: Time) Happens (ic:UI:RelKey(v,c,l),t1,ℜ(t1,t1)) ∧ ¬(∃t2) Happens (rc:SS:Depart(v,l),t2, ℜ(t1,t1+6*tu) ⇒ (∃t3:Time) Happens(ic:IS:Available(v,l),t3, ℜ(t1+6*tu,t1+6*tu)) (B2) (∀ v:Car, c:Customer, l: Park, t1,t2: Time) Happens (rc:UI:CarRequest(c,l),t1,ℜ(t1,t1)) ∧ Happens (ir:IS:FindAvailable(l,veh),t2, ℜ(t1,t1+tu)) ∧ Initiates (ir:IS:FindAvailable(l,veh),equalTo(veh,v),t2) ⇒ (∃t3:Time)Happens(re:UI:CarHire(c,l,v),t3, ℜ(t2,t2+tu)) Assumptions: (A1) (∀l1,l2:CarPark, v:Car, t1,t2:Time) Happens(rc:SS:Enter(v,l1),t1, ℜ(t1,t1)) ∧ Happens(rc:SS:Enter(v,l2),t2, ℜ(t1+tu,t2))⇒ (∃t3:Time) Happens(rc:SS:Depart(v,l1),t3, ℜ(t1+tu,t2−tu)) (A2) (∀ l:CarPark, v:Car, t1:Time) Happens(rc:SS:Enter(v,l), t1, ℜ(t1,t1)) ⇒ (∃t2:Time) Happens(rc:UI:RetKey(v,l),t2, ℜ(t1+tu, t1+tu*10)) (A3) (∀ v:Car, c:Customer, l: Park, t1:Time) Happens(ir:IS:FindAvailable(l,veh),t1, ℜ(t1,t1)) ∧ HoldsAt(equalTo(availability(v), “not avail”),t1−tu)⇒ ¬Initiates(ir:IS:FindAvailable(l,veh),equalTo(veh,v),t 1) (A4) (∀ v:Car, c:Customer, l:Park, t1,t2,t3:Time) Happens(rc:UI:RelKey(v,c,l),t1,ℜ(t1,t1)) ∧ Happens(rc:UI:RetKey(v,l),t2,ℜ(t2,t2)) ∧ (t1 ≤ t3) ∧ (t3 ≤ t2) ⇒ HoldsAt(equalTo(availability(v), “not avail”) ,t3) Note: In the above formulas, tu refers to the minimum time between the occurrence of two events. tu can be set by the system provider.
Figure 1: Behavioural properties and assumptions of the car rental system
Figure 1 shows examples of specifications of behavioural properties and assumptions of the CRS system that was introduced in Section 1 in the above representation framework. The behavioural property B1 in Figure 1, for instance, specifies that when CRS invokes an operation in UI ic:UI:RelKey(v,c,l) that signifies the release of a car key to a customer, it waits for an event signifying the exit of the car from the car park for 6 time units (this message is to be sent by SS). If the latter event does not occur, CRS invokes the operation Available(v,l) in IS to mark the relevant car as available. Also, according to assumption A1 in Figure 1, if a car is sensed to enter a car park at some time t1 (see the literal Happens(rc:SS:Enter(v,l1),t1,ℜ(t1,t1)) in A1) and later at
some time t2 the same car is sensed to enter in the same or a different car park, then the SS service should invoke the operation Depart to handle the car departure event that must have been occurred between the two entrance events. As we discussed in Section 1, the behavioural properties of service based systems are extracted automatically from the BPEL4WS specification of their composition process. Following this extraction, system providers may specify additional assumptions about the composition process and the constituent services of a service-base system. These assumptions must be specified in terms of the event and state condition literals that have been extracted from the BPEL4WS specification and consitute parts of the behavioural properties. A full description of the extraction scheme used for this purpose is given in [15].
3. Types of Deviations Assuming a set of behavioural statements BS and a set of assumptions AS all expressed in the form of the event calculus that we introduced in Section 2, we define three types of behavioural deviations from a requirements specification, BS ∪ AS, of a service-based system. These types of deviations are defined in terms of the recorded and expected behaviour of a system. The definitions of these types of behaviour are: Definition 1: The recorded behaviour of a system S at time t’, ER(t’), is a set of events, and fluent initiation or termination literals of the forms: Happens(e,t,ℜ(t1,t2)), Initiates(e,f,t), HoldsAt(f,t) which have been recorded during the operation of S and for which 0 ≤ t1, t2 ≤ t’, 0 ≤ t, and t ≤ t’. Definition 2: The unrecorded expected behaviour of a system S given a subset FS of its behavioural properties and assumptions (FS ⊆ (BS ∪ AS)) at time t is a set of events EU(FS,t) that is defined as: EU(FS,t) = {e |(ƒ∈FS) and {ER(t),ƒ}|=nf e } where |=nf signifies entailment using the normal rules of inference of first-order logic and the principle of negation as failure According to Definition 2, the unrecorded expected behaviour of a system includes events which can be derived from the formulas in FS but may have not been generated by the system. The recorded and expected behaviour of a system are used to define the different types of run-time system deviations as discussed in the following sections.
3.1 Inconsistency of recorded behaviour The first type of deviations that can be detected by our framework are inconsistencies between the recorded behaviour of a system S and an assumption about the behaviour of S, some constituent service of it or an agent interacting with it. This type of deviations is defined as follows: Definition 3: An assumption statement ƒ of the form ƒ: C⇒A is inconsistent with the recorded behaviour of a system S until time t if and only if: {ER(t)} |=nf ¬ƒ
Definition 3 establishes a classic notion of inconsistency in system behaviour that can be detected by checking whether the negation of an assumption is entailed by the recorded run-time behaviour of a system. Thus, it is equivalent to the notion of inconsistency discussed in [5]. Example. Suppose that the log of events of the CRS system includes the literals shown in Figure 2. L1 L2 L3 L4 L5 L6 L7 L8 L9 L10 L11 L12 L13 L14 L15 L16
: Happens(rc:SS:Enter(v1,l1),1,ℜ(1,1)) : Happens(ic:UI:RelKey(v1,c1,l1),5,ℜ(5,5)) : Happens(ic:IS:Available(v1,l1),9,ℜ(9,9)) : Happens(rc:UI:RetKey(v1,l1),15,ℜ(15,15)) : Happens(rc:SS:Enter(v2,l2),18,ℜ(18,18)) : Happens(rc:UI:RetKey(v2,l2),23,ℜ(23,23)) : Happens(ic:IS:Available(v2,l2),26,ℜ(26,26)) : Happens(rc:SS:Enter(v1,l1),27,ℜ(27,27)) : Happens(ic:UI:RelKey(v2,c2,l2),28, ℜ(28,28)) : Happens(ic:IS:Available(v2,l2),34, ℜ(34,34) : Happens(rc:UI:CarRequest(c1,l2),49, ℜ(49,49)) : Happens(ic:IS:FindAvailable(l2,veh),50, ℜ(50,50)) : Happens(ir:IS:FindAvailable(l2,veh),51, ℜ(51,51)) : Initiates(ir:IS:FindAvailable(l2,veh), equalTo(veh,v2),51) : Happens(re:UI:CarHire(c1,l2,v2),52, ℜ(52,52)) : Happens(rc:UI:RetKey(v2,l2),54,ℜ(54,54))
Figure 2: Event log of car rental system
Given ER, an inconsistency of the recorded behaviour with respect to the assumption A1 can be detected at time t=27. This is because at this time point, we can deduce by negation as failure that ¬Happens(rc:SS:Depart(v1,l1),t,ℜ(2,26). This literal in conjunction with the literals L1 and L8 entail ¬A1. In this case, the inconsistency has occurred as the SS service has failed to act according to assumption A1 and signify the departure of vehicle v1 from car park l1.
3.2 Inconsistency of expected behaviour The second type of deviations that can be detected in our framework is inconsistencies between a behavioural property or an assumption of a system S and the expected behaviour of S. This type of deviations is defined as follows: Definition 4: A behavioural property or assumption of the form ƒ: C⇒A is inconsistent with the expected behaviour of a system S at time t if and only if: {ER(t), EU(dep(ƒ),t), ECa} |= nf ¬ƒ where dep(ƒ) is the set of formulas F: B⇒H in (BS ∪ AS) − {ƒ} which ƒ depends on. A formula F: B⇒H belongs to dep(ƒ), if its head H has a literal L that unifies with: (i) some literal K in the body C of f, or (ii) some literal K in the body B’’ of another formula F’’ that belongs to dep(ƒ), and ECa is the set of standard EC axioms (see [13][15]). According to this definition, the check about the inconsistency of a formula ƒ with the expected behaviour of a system must, in addition to events which are recorded in ER(t), take into account events which should have been generated according to other formulas in BS ∪ AS and can affect the satisfiability of ƒ. The definition of the set dep(ƒ) in Definition 4 is similar to notions of direct and indirect dependence in [10].
Example. Given the event log of Figure 2, the assumption A3 is found to be inconsistent with the expected behaviour of CRS at t=54. A3 is an assumption about the behaviour of the IS service stating that when IS executes the operation FindAvailable it should not report a car as available unless this is indeed the case. The inconsistency arises because the literals L13 and L14 in Figure 2 and the literal HoldsAt(equalTo(availability(v2) “not avail”),50), which is derived from the literals L9 and L16 and the assumption A4 (A4 ∈ dep(A3) entail the negation of A3. In this example, the inconsistency is caused by the failure of the SS service to send an rc:SS:Depart(v2,l2) event to CRS following the event Happens(ic:UI:RelKey(v2,c2,l2),28,ℜ(28,28)). Thus, according to B1, CBS invoked the operation Available to mark the vehicle v2 as available (see the literal L10 in Figure 2). Subsequently, when the operation ic:IS:FindAvailable(l2,veh) was invoked in IS (see literal L12), IS reported v2 as an available vehicle. Note, however, that this inconsistency could only be spotted after the event signified by the literal L16 and by virtue of A4 (according to A4, a car whose key is released should not be considered as available until the return of its key).
3.3 Unjustified behaviour The third type of deviation occurs when the conditions of a behavioural property ƒ are satisfied by the recorded system behaviour but are violated by the expected system behaviour. In such cases, if the system has also functioned according to ƒ, the event(s) in the consequent part of it must have also been generated. These events, however, should not have been generated if the system were functioning according to its expected behaviour. This type of deviation is defined as follows: Definition 5: A behavioural property of the form ƒ: C⇒A is said to generate unjustified behaviour if and only if there is a literal e such that (i) e is an element of ER(T) that can be unified with A (ii) {ER(T) − {e}, ƒ, ECa} |=nf e (iii) {ER(T) − {e}, BS − {ƒ}, ECa} |≠nf e and (iv) there is a literal L in C for which, {ER(T), EU(dep(ƒ),T), ECa} |=nf ¬L The conditions (i)-(iii) in Definition 5 identify an event e which must have been generated by the system due to the realisation of a formula ƒ whose conditions C are satisfied by the recorded system behaviour (condition (iii) guarantees that e cannot have been generated by some other formula). Note, however, that according to condition (iv), C would not be satisfied if all the events that could be generated by formulas which f depends on are taken into account. In such cases, e is the result of behaviour that is based on wrong assumptions about the satisfiability of the conditions of ƒ that the system makes at run-time. Thus, we refer to it as "unjustified behaviour". Example. At t=54, the event L15 which was generated due to B2 can be detected as unjustified behaviour. This is because this event can only have been generated by B2. Note that, although in this case CRS has
functioned according to B2, one of the conditions of this property is violated by the literal ¬Initiates(ir:IS: FindAvailable(l2,veh), equalTo(veh,v2),51). This literal can be deduced from A3 (A3 ∈ dep(B2)), the literal L13, and the literal HoldsAt(equalTo(availability(v2), “not avail”),50). The latter literal is deduced from L9 and L16 and assumption A4 (A4 ∈ dep(A3)). As in the example of Section 3.2, this unjustified behaviour is the result of the failure of the SS service to send an rc:SS:Depart(v2,l2) event to CRS. Note, however, that the violation of A3 that is detected as an inconsistency of expected behaviour does not indicate that the event L15 that was generated by B2 is unjustified. The identification of L15 as an unjustified event is only possible through the detection of the violation of one of the conditions of B2.
4. Monitoring scheme The different types of deviation from behavioural properties and assumptions, are monitored according to an algorithm that we discuss in detail in [15] and briefly overview in this paper. According to this algorithm, at run-time our monitoring framework maintains templates that represent different instantiations of the formulas under monitoring and captures events which, are generated during the execution of the composition process of a service-based system. Templates store the state of different instantiations of a formula f, including: The identifier (FID) and type of f. The type of f is F (future) if all the predicates p in f whose time variables are constrained by time variables of other predicates, must occur after these predicates (e.g., formula A2), and P (past) if there is at least one p predicate that must occur before the q predicate that constraints it (e.g., formula A1). A dependants list (DP) of (id, P) which indicate other formulas which depend on f (id is the identifier of a formula that depends on f and p is the predicate that creates the dependency (see Definition 4)), and For each predicate p in f − the signature and the variable bindings (VB) of p; − a time range (LB,UB) that indicates when p should occur. The boundaries of this range are set according to the time constraint of p in f; − the truth value (TV) of p which can be: Un (if the truth value of p has not been established), True (if p is true), or False (if p is false). − a time stamp (Ti) that indicates the time in which the truth value of p is established (Ti = UD if the truth value of p is not known); and − the source of the evidence for the truth value of p which can be: UN if p’s TV is not known, RE if p’s TV is established by a recorded event unified with it, DE if p’s TV is established by a derived event unified with it, or NF if p’s TV is established by the principle of negation as failure. The template for formula A2, for example, is:
FID: A2 Type: F DP: (A4, RetKey)
Predicate-1: Q: Forall Happens(rc:SS:Enter(v,l1)) VB: (v=UD, l1=UD) TV: UN Source: UN T1: UD LB: ANY UB: ANY
Predicate-2: Q: Exists Happens(rc:UI:RetKey(v,l1) ) VB: (v=UD, l1=UD) TV: UN Source: UN T2: UD LB: T1 UB: T1+10
The event receiver identifies in the execution log of the composition process events that correspond to different predicates of the formulas using regular expressions, and the templates that incorporate these predicates3. Subsequently, it checks if there are instances of these templates that should be updated by the events. Updates may be made only if the signature, the event variable bindings and the time of the event comply with the predicate signature, the predicate variable bindings, and the time constraint of the predicate in a template instance, respectively. New instances of templates may also be generated if the event corresponds to an unconstrained predicate of a template. Two separate copies of template instances are created and used to check for different types of deviations from a formula and to derive events from it. Following the occurrence of literal L1 in Figure 2, for example, a new instance of the template of A2 will be created for checking for deviations from it. This instance will have the following values: TID: 1 FID: A2 Type: F DP: (A4, RetKey)
Predicate-1: Q: Forall Happens(rc:SS:Enter(v,l)) VB: (v=v1, l=l1) TV: True Source: RE T1: 1 LB: ANY UB: ANY
Predicate-2: Q: Exists Happens(rc:UI:RetKey(v,l)) VB: (v=v1, l=l1) TV: UK Source: UN T2: UD LB: 1 UB: 11
Another instance of the template of A2 will be created following L5 in the log of Figure 2 since L5 cannot be unified with the above instance of the template of this formula. The status of a predicate in a template instance may also be updated by applying the principle negation as failure. This will happen depending on the quantifier of the time variable of the predicate and its time constraint. At t=15, for instance, by negation as failure it is established that the predicate Happens(rc:UI:RetKey(v1,l1), t2, R(1,11) is false in the above instance of the template for A2. This is because no such event has appeared and t2 is existentially quantified. This update will occur when the monitoring system encounters the event L4 in Figure 2 which indicates the current time in the execution of the composition process. Following L4, the previous template for A2 becomes: TID: 1 FID:A2 Type: F DP: (A4, RetKey)
3
Predicate-1: Q: Forall Happens(rc:SS:Enter(v,l)) VB: (v=v1, l=l1) TV: True Source: RE T1: 1 LB: ANY UB: ANY
Predicate-2: Q: Exists Happens(rc:UI:RetKey(v,l)) VB: (v=v1, l=l1) TV: False Source: NF T2: 15 LB: 1 UB: 11
In our experiments, where we have used the bpws4j process execution engine [11] that uses log4j [12] to generate logs of the events during a BPEL4WS process execution.
When the truth values of all predicates in a template instance have been determined, a check for possible formula violations is performed according to the criteria described in [15]. In the case of F-formulas, for example, if the truth-value of all the predicates in the template is true the formula is satisfied, and if the truth-value of all the unconstrained predicates in the formula is true and the truth-value of at least one constrained predicate is false and the source of all predicates is RE or NF, the formula is marked as inconsistent with the recorded behaviour of the system.
5. Related Work Run-time requirements monitoring has been the focus of different strands of requirements engineering research (e.g. [2][5][6]). These strands have investigated: (i) ways of specifying requirements and transforming them into events that can be monitored at run-time; (ii) the development of event-monitoring mechanisms; (iii) the development of mechanisms for generating system events that can be used in monitoring; and (iv) the development of mechanisms for adapting systems in order to deal with deviations from requirements at run-time. Most of the existing techniques (e.g. [5][6][14]) express requirements as high level goals that must be achieved by a system using the KAOS framework [7]. These goals must be mapped onto events that can be monitored at run-time To monitor the existence of events that indicate violations of goals, existing techniques use either special purpose architectures (e.g. AMOS [3] and FLEA [5][2]) that maintain event logs and offer proprietary event pattern specification languages, or store events in relational databases and deploy standard SQL querying for detecting requirement violations [14]. Typically, these approaches assume that the events to be monitored are generated by special statements which must be inserted in the code of a system for this purpose (i.e., instrumentation) [8][6]. The problem of system adaptation following run-time violations of requirements is the focus of [5]. In this approach, alternative system designs for realising specific requirements are explicitly defined. If at runtime a violation of a requirement is detected an alternative design for this requirement may be selected by changing the values of design control parameters.
6. Conclusions In this paper, we have presented a framework for monitoring requirements for service-based systems at runtime. These requirements may take the form of behavioural properties or assumptions of these systems, their individual services or the agents interacting with them, and are specified in event calculus. The behavioural properties are initially extracted from the specification of the composition process of a service-based system. This ensures that these properties are expressed in terms of events occurring during the interaction between the composition process and the constituent services of the system that can be detected from the log of the execution. The assumptions to be monitored are subsequently defined
in terms of the identified detectable events by system providers. The framework supports the monitoring of three different types of deviation from requirements, namely: inconsistencies with respect to recorded and expected system behaviour, and unjustified system behaviour. The framework is still under development. Ongoing work on it is concerned with the development of: (i) capabilities for reasoning about events that might have happened and can give rise to deviations from requirements, and (ii) support for specifying realistic time constraints for behavioural properties and assumptions based on analysis of time delays in execution histories.
References [1] Andrews T. et al. "Business Process Execution Language for Web Services", v1.1, http://www106.ibm.com/developerworks/library/ws-bpel. [2] Feather M., Fickas S. "Requirements Monitoring in Dynamic Environments". Proc. of Int. Conf. on Requirements Engineering, 1995. [3] Cohen D. et al. "Automatic Monitoring of Software Requirements". Proc. of the 19th Int. Conf. on Software Engineering, 1997. [4] Chominski J. "Efficient Checking of Temporal Integrity Constraints Using Bounded History Encoding", ACM Transactions on Database Systems, 20(2), 1995. [5] Feather M.S., Fickas S., Van Lamsweerde A. and Ponsard C.. "Reconciling System Requirements and Runtime Behaviour". Proc. of 9th Int. Work. on Software Specification & Design, 1998. [6] Robinson W. "Monitoring Software Requirements using Instrumented Code". Proc. of the Hawaii Int. Conf. on Systems Sciences, 2002. [7] Dardenne A., van Lamsweerde A. and Fickas S., "Goal-Directed Requirements Acquisition", Science of Computer Programming, 20, pp. 3-50, 1993. [8] Dingwall-Smith A., Finkelstein A. "From Requirements to Monitors by Way of Aspects". Proc. of 1st Int. Conf. on Aspect-Oriented Software Development, 2002. [9] Capra L., Emmerich W., and Mascolo C. "Reflective middleware solutions for context-aware applications", LNCS 2192, 2001. [10] Plexousakis D. "Integrity Constraint and Rule Maintenance in Temporal Deductive Knowledge Bases", Proc. of the 19th Int. Conf. on Very Large Data Bases, 1993. [11] BPWS4J, http://alphaworks.ibm.com/tech/bpws4j [12] http://logging.apache.org/log4j/docs/, September 2003 [13] Shanahan M. "The event calculus explained", In Artificial Intelligence Today, 409-430, Springer, 1999 [14] Robinson W.N., "Monitoring Web Service Requirements", Proc. of 12th Int. Conf. on Requirements Engineering, 2003. [15] Mahbub K., Spanoudakis G. "A Scheme for Requirements Monitoring of Web Service Based Systems", Technical Report, Department of Computing, City University, London, 2004.
