A Scheme for Requirements Monitoring of Web Service Based Systems

A Scheme for Requirements Monitoring of Web Service Based Systems Khaled Mahbub and George Spanoudakis

Department of Computing City University Technical Report Series TR/2004/DOC/02 ISSN 1364-4009

A Scheme for Requirements Monitoring of Web Service Based Systems Khaled Mahbub and George Spanoudakis Department of Computing City University London EC1V 0HB ABSTRACT This technical report proposes a framework for monitoring the compliance of systems composed of web-services with requirements set for them. This 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 properties to be monitored. The monitorable properties may include behavioural properties of a 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.

1. Introduction The verification that a software system meets its requirements at run-time has been acknowledged as a significant problem in requirements engineering research [3][6][7]. This is because, even if it can be demonstrated that a system can meet its requirements prior to deployment, at run-time these requirements may be violated. This may be the result of unpredicted changes in the environment of a system or failure to anticipate the behaviour of all the agents (i.e. other systems and human users [3]) that may interact with it at run-time. 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 at run-time and reports violations of the requirements. In a monitoring setting, events are typically generated by the system to be monitored either through instrumentation (i.e., the insertion of code statements that can generate the expected events) [3][6][7], or by querying the system if it has reflective capabilities [12]. As they focus on systems with no autonomous components, existing requirements monitoring techniques fail to deal adequately with some significant complications which arise in service-based systems. More specifically, in service-based systems, the failure of specific services to function as expected may lead other system components (i.e., services and the system composition process) to make incorrect assumptions about the state of the system and take actions which may be compliant with the requirements but would not have been taken if the correct state of the system was known to them (see examples in Sections 3.3-3.5). This possibility requires the introduction of types of requirements deviation beyond classical inconsistency and the development of appropriate reasoning mechanisms for detecting them. Also, in service-based systems the generation of events through code instrumentation may not be possible as the provider of a system might not own the individual services which constitute it. Thus, monitoring has to be based on events and state information that can be obtained from the system composition process which can be reasonably assumed to be in the ownership of the system provider. Requirements for individual services may still be specified and monitored but only if this is possible through events which are known to the composition process of the system, or events that can be derived from them. In this paper, we propose a framework that supports the monitoring of requirements for service-based systems and provides a foundation for addressing the above limitations. In this framework, requirements may express behavioural properties of or assumptions about a service-based system or agents in its environment that should be satisfied. Behavioural properties are automatically extracted from the specification of the composition process of the service based system that is expressed in BPEL4WS [1]). These properties are specified in terms of: (i) events which signify the invocation of operations in different system services or the system composition process and responses generated at the completion of these executions, (ii) the effects that these events may have on state variables of the system (e.g., assignment of values), and (iii) conditions about the values of state variables at different time instances. The events, effects and state variable conditions are restricted to those which can be observed during the execution of the system composition process. Assumptions are additional constraints about the behaviour of agents in the environment of a system, or the individual services of it. These constraints are specified by system providers and must be expressed in terms of events, effects and state variable conditions which are used in the behavioural properties directly or indirectly. Behavioural properties and assumptions are expressed in a restricted form of event calculus [17] which supports the

1

specification of temporal constraints, and makes it possible to monitor them by a variant of techniques developed for checking integrity constraints in temporal deductive databases [14]. Our framework can monitors five different types of deviation from behavioural properties and assumptions. These are (i) inconsistencies w.r.t recorded system behaviour, (ii) inconsistencies w.r.t expected system behaviour, (iii) unjustified system behaviour, (iv) potential inconsistencies w.r.t expected system behaviour, and (v) potentially unjustified system behaviour. The rest of the paper is structured as follows. In Section 2, we introduce event calculus and give an example of expressing behavioural properties and assumptions in it. In Section 3, we define the different forms of deviations from requirements and give examples of them. In Section 4, we overview BPEL4WS and the scheme for extracting behavioural properties expressed in event calculus. In Sections 5 and 6, we discuss the monitoring scheme of the framework and related work, respectively. Finally, in Section 7, we summarise our approach and outline directions for future work on it.

2. Requirements and their representation In our framework, we assume that behavioural properties and assumptions are specified in event calculus [17].

2.1

Overview of event calculus

The event calculus (EC) is a logic language based on first-order predicate calculus that can be used to represent and reason about events, and states of dynamic systems called fluents. EC allows the specification of system events and the time when they occur. It also allows the specification of initialisations and modifications of system states in response to these events at specific times. In our framework, the specification of behavioural properties and assumptions uses the following predicates: ƒ Happens(e,t,ℜ(t1,t2)) − This predicate is a special case of the Happens predicate of standard EC (see [17]) signifying the occurrence of an event e of instantaneous duration at some time t that is within the time range ℜ(t1,t2). This time range must be specified for each time variable appearing in a Happens literal. Thus, Happens(e,t,ℜ(t1,t2)) in our framework is equivalent to the formula: Happens'(e,t) ∧ (t1 ≤ t) ∧ ( t ≤ t2) where Happens'(e,t) is the predicate that signifies an event occurrence in standard event calculus. ƒ InitiallyP(f) − This is a standard predicate of EC signifying that a fluent f holds at time 0. ƒ InitiallyN(f) − This is a standard predicate of EC signifying that a fluent f does not hold at time 0. ƒ Initiates(e,f,t)− This is a standard predicate of EC signifying that a fluent f starts to hold after the event e at time t. ƒ Terminates(e,f,t) − This is a standard predicate of EC signifying that a fluent f ceases to hold after the event e occurs at time t. ƒ HoldsAt(f,t) − This predicate signifies that the fluent f holds at time t. ƒ Clipped(t1,f,t2) − This is a standard predicate signifying that a fluent f ceases to hold at some time instance between t1 and t2. In addition to the above predicates, formulas which express behavioural properties and assumptions in our framework can use (i) the predicates