Embed Size (px)
Citation preview
Paradigm: Event-driven Computing
(white paper)
Jeroen van Bemmel, Partricia Dockhorn and Ing Widya
Lucent Technologies, CTIT
10-12-2004
Freeband/AWARENESS/D2.7a
http:/ /awareness.freeband.nl
Abstract:
This whitepaper addresses the Event-driven Computing paradigm which is typically based on
Event-Condition-Action (ECA) rules and is known in areas where changes within a system or the
environment of a system trigger adaptation of the system’s behavior. This paper presents an
overview of the different appearances of ECA rules in different research areas and provides some
examples of the use of such rules in context aware systems, in an attempt to reuse rather than
reinvent the existing knowledge base.
Freeband/AWARENESS/D2.7a 2
1 Introduction The Freeband Awareness project aims to construct a supporting infrastructure to build, configure and deploy context aware services and applications. These services and applications are characterized by the collection and usage of context information which influences their behavior. Moreover, if a context aware service is a composite of elementary or less complex components, a change of the context information may cause a dynamic compositional rebinding with other (typically, alternative) component instantiations. This binding may be needed to ensure service continuity by adaptation of the provisioning of the service or to ensure adaptation of the service itself to achieve a better match with the preferences of the user or the user’s task objectives. For example, a mobile service user may be handed off from GPRS to WLAN if he roams into a hotspot (i.e. new context) with WLAN support, so to achieve service adaptation which better match with his/her profile or preferences.
Event-driven techniques for adaptation of services or applications (and the adaptation of the provisioning) are well-known and are often used in areas where changes in the environment of the service or the application trigger the behavioral adaptations, for example the area of network management, control and agent collaborations {[17], [19], [23]}. These techniques are therefore considered suitable for context aware services (cf. [16]).
When studying event-driven techniques it was found that research is scattered over many different research groups and application areas. We see a high degree of similarity between various proposals and approaches, however such links are seldom made in literature. This white paper attempts to remedy this issue to some extent.
Event-based systems are typically based on Event-Condition-Action (ECA) rules (/patterns) [2]. These rules specify actions that will be enabled by the occurrence of specified events if certain conditions are satisfied. The ECA rules therefore structure (composite) service behavior and the interaction between the components by the propagation of events. Upon reception of an event a composite service evaluates a set of rules that trigger execution of actions when the activation condition is satisfied.
Examples:
• Consider a patient health monitoring system. The patient carries a device that monitors his heart rate. When this device detects irregularities in the heartbeat (e.g. irregular pulses are received) it sends an alarm message to the monitoring system at a hospital. This system dispatches the alarm based on the severity, availability of doctors, etc., to notify the buddies or the care team of the patient and also triggers an emergency response system which sends an ambulance.
• Many real-life situations can be described as the occurrence of some event which triggers a chain of reactions, subject to context conditions. Think of an avalanche triggered by a dynamite explosion of sufficient force. A broad class of digital systems and features of such systems can also be modeled as Event-Condition-Action chains, for example a mouse click in a GUI that triggers the display of the next web page.
Event-driven computing and in particular the Event-Condition-Action rules are considered useful in the following cases:
• A component should react to the occurrence of some (set of) event(s);
• The reaction of the component is subject to some conditions other than the mere occurrence of the event;
• (Service) logic should be separated from execution of procedures.
This paper addresses event-driven computing, in particular it describes the common aspects of -and to some extent the differences between- behavioral specifications which use ECA patterns or rules, and provides links to related work. In particular, this paper aims to provide better insight in the different appearances of ECA rules and patterns and their use.
Freeband/AWARENESS/D2.7a 3
2 ECA rules ECA rules have many appearances and have been used in many areas (cf. {[23], [17], [22], [18]}). Common elements of ECA rules are
• Event: Models the occurrence of a relevant change in the ECA-based system or its environment. An event typically triggers the evaluation of the ECA rule, in particular, the evaluation of the event parameters and the condition of the rule. As described in a journal paper by Liu et al. [20], evaluation of the ECA rule (policy rule) may be triggered by a pattern of events instead of the occurrence of a singular event. That is, a next state of a system may depend on a sequence of preceding states or events, if a (pattern of) event(s) is viewed in terms of bringing a system from its current state to a next state. For example in a health-care working diagnostic approach, a complex pattern of patient’s symptoms or monitored etiological signs may be needed to trigger the treatment phase (/next state) activities (e.g. reservation of an operating room, schedule a neurosurgeon);
• Condition: Represents the situation under which the actions of the rule are enabled in occurrence of specified events. A condition is typically expressed as a Boolean expression, it can range from a simple to a complex expression, which often represents the context or the state of the ECA-based system or its environment. Moreover, in some event-driven computing systems like the IETF policy based systems, event detection and evaluation are combined within the condition part of the rule (i.e. policy rule);
• Action: Represents the operations of the rule that determine the behavior of the ECA-based system. This element may represent a singular operation or a set of operations and, if appropriate, their (partial) order. Further, ECA rules can be classified in terms of how to interpret enabled actions, including {[21], [19]}:
o Obligation rules: actions of these ECA rules are compulsory and have to be enforced on the system;
o Permission rules: actions are defined in terms of rights;
o Prohibition rules: actions of these ECA rules are prohibited when the conditions and events are satisfied;
Other terminology used in several ECA based systems includes:
• Goal: Defines the objectives of the rule. It is a meta-description of the ECA rule and therefore often used for rule refinement from abstract to concrete specification levels, i.e. from human interpretable to machine interpretable levels [23]. Goals may also be used for selection of rules which meet service user’s preferences or profiles, or download of rules from a rule repository.
• Subject (sometimes called role): An active entity in the system, usually a process running on behalf of a user or role, that causes information to flow among objects or changes the system state
• Target: Represents the entities on which actions of obligation ECA rules are enforced. These entities execute the enabled actions of the rules. In the IETF policy model [25], targets are the so-called Policy Enforcement Points (PEP);
Examples of ECA rules (cf. [19]):
template instance instance
whenever <event>
if <condition>
then <target>
is <deontic operator>
to <action>
whenever “bandwidth use exceeds limit”
if gold_user
then comm_manager
is permitted
to disconnect
whenever “bandwidth use exceeds limit”
if bronze_user
then comm_manager
is obliged
to disconnect
Freeband/AWARENESS/D2.7a 4
instance instance instance
whenever “rain in 10 min.”
if Is_foundation_wet
then foreman
is obliged
to foundation(cover_it)
whenever “rain in 10 min.”
if foundation_phase = = on_schedule
then foreman
is permitted
to insert (coffee_break)
whenever “rain in 10 min.”
if foundation_phase = = on_schedule
then foreman
is prohibited
to foundation(pour_concrete_mortar)
2.1 Structure
Figure 1 Structure of ECA as UML model
A rule in an ECA system consists of a definition of event(s) that trigger evaluation of the rule, possibly additional conditions that should hold, and zero or more (usually at least one) actions to be taken. The distinction between events and conditions can be cumbersome (one could e.g. define a rule that applies ‘when it rains’ (condition) or ‘when it starts raining’(event)). Events, conditions and actions may also have internal structure, i.e. there can be a structural hierarchy. For example a condition may consist of multiple sub-clauses, or an action is implemented as a procedure call that invokes several sub procedures. The structure may impose a particular ordering, such as the order in which statements should be executed. A (partial) ordering of a set of rules may be defined using priorities, which may also be used to make choices between conflicting rules.
Rules may be aggregated into a policy, which defines the set of rules that should be applied for event processing. Within a policy multiple rules may conflict, for example because their corresponding actions are mutually exclusive. Such cases may be resolved using priorities (which can also be seen as an extra condition on the conflicting rules).
3 ECA refinements and the consequences This section describes some refinements of the ECA rules or the rule elements and the consequences of the choices of these refinements.
Freeband/AWARENESS/D2.7a 5
3.1 Chaining of ECA system components One type of action an ECA-based system component would typically perform is the sending of some message. This message can in turn be received by another ECA component (or the same component which contains several ECA rules), which considers it as an event that triggers evaluation of conditions. In such a way multiple ECA components can be chained; the entire chain of components can subsequently be viewed as one (distributed) ECA system composed of ECA components or as collaborating ECA systems, each of which possibly administrated under own authority.
To chain ECA components there are several compatibility issues to be resolved. In particular, the syntax and semantics of events (messages) sent by an originating component must be understood by a receiving component [12]. This is most easily solved by introducing a standard (protocol data unit) format and semantics for representing and reasoning about events or messages.
Conflicts between the enabled actions of different components are another issue. A coordinator component may resolve rule conflicts. However, these conflict resolving components are difficult to realize in multi-authority domains.
3.2 Representation of events For maximum interoperability the representational format used for events should be independent of any particular processing platform. A possible choice could be a textual format such as programming code (see [2] for examples) or XML [14], possibly semantically annotated using e.g. RDF as in [30].
To support the chaining of ECA components, the event representation format could reflect the chain of components through which the event propagated. Every component in the chain may add more information or meaning to the event, which helps subsequent components to make better informed decisions about how to handle the event.
3.3 Classification and matching of events A typical ECA based system will distinguish several different types or classes of events. This can be achieved using an event ontology, where an ontology is defined as “an explicit specification of a shared conceptualization” [31]. The term is borrowed from philosophy, where an ontology is a systematic account of Existence. For AI systems, what "exists" is that which can be represented. When the knowledge of a domain is represented in a declarative formalism, the set of objects that can be represented is called the universe of discourse [10]. A taxonomic hierarchy of classes is an example form of an ontology, but ontologies are more general.
In an ECA system, incoming events must be matched against the set of behavioral rules. A typical approach is to classify the events based on the event data itself or the context in which it occurs, and then to evaluate the rules that apply to that class of events. Events may carry an explicit ‘type’ indicator which can be a simple number or string denoting an application-specific type of event, e.g. “heartbeat” or “heart failure”. Alternatively, rules can be matched against other event properties, e.g. “match when event.source contains ‘@here.*’”. As demonstrated in this example, regular expressions may used here.
An example of using ontologies for distributed event-based systems is given in [12].
3.4 Configurability of behavioral rules One consideration during the design of an ECA system is whether the reaction patterns of a component are fixed or expected to either change often or depend on the deployment context. In the fixed case it is possible to ‘hardcode’ the component’s behavior using programming language constructs at compile time (e.g. if-then-else). There are several degrees of fixedness, for example the actions can be hard coded but the conditions configurable.
In case a high degree of configurability / programmability is desired, it can be considered to introduce a special language. This language must be able to express rules, conditions and actions, and is interpreted by the component (or a special engine) to respond to incoming events. The introduction of a new language
Freeband/AWARENESS/D2.7a 6
is the most prominent pitfall of this pattern, since it imposes additional knowledge requirements on both deployers and users. It should be noted that the choice of ECA language is a component internal design decision; there is no need to use the same language across all parts of the system. A consideration could be to use an existing “standard” language, but also here there are many possible choices (see e.g. [18] for examples).
3.5 Evaluation context and nature of conditions There can be a variety in the nature and expressiveness of conditions. Conditions are Boolean expressions that evaluate to either ‘true’ or ‘false’. They are typically composed of terms joined by Boolean operators (AND, OR, NOT, etc). Possible inputs to the evaluation of conditions include:
• Properties (characteristics) of the incoming event (type, time of occurrence, …)
• State of the component (including configuration state, history of events)
• System time
• Global state
• Expressions / functions over all of the above
3.6 Establishing next-in-chain relations There are several design options for identifying the component that is to receive an event generated by the execution of some action:
• Statically through configuration (either globally (send all events to IP 1.2.3.4) or expressed in the rule)
• Dynamically at run time using a subscription mechanism
• Implicitly using a form of broadcasting
The above are all examples of receiver binding mechanisms; applicability depends on the context and application in which ECA rules are used.
4 Links to various research areas As is often the case the ECA paradigm is not new in the sense that the core concepts have been around for a long time. The problem is that the research and information is scattered across multiple difference research groups and areas, with various backgrounds. This makes it difficult to locate and identify relevant existing work. In particular, the terminology used to designate the various concepts differs significantly. This section attempts to describe cross links between several areas of research.
4.1 Active Databases The concept of Event-Condition-Action rules originally comes from the domain of database technology (cf. [28]). The events are triggers that result from the execution of database operations (insert, update, etc), the condition is a Boolean expression over the database content, the operation causing the trigger and the environment, and actions are new database operations.
As databases are heavily used in enterprises, many examples of the application of ECA (-rules) in such a context can be found (e-Business, workflow systems, etc).
4.2 Artificial Intelligence
Rule-based systems or “expert systems” An expert system simulates human reasoning in some application domain by using heuristic or approximate deduction rules. Such systems originated in AI research in the 70s and 80s. The basic
Freeband/AWARENESS/D2.7a 7
approach is that knowledge is stored as facts, and new facts are derived using a set of deduction rules. This type of systems is applicable when the problem domain is well defined and understood, and the knowledge can be represented as facts and rules.
Neural networks A neural network is a type of information processing system whose architecture is similar to the structure of biological neural systems [29]. The neural network tries to mimic the way a brain and nervous system work by analyzing sensory inputs and calculating an outcome. Dendrites receive input signals from synapses, which are averaged with other signals by the soma (cell body). A sufficiently large average will trigger the axon to fire a pulse to the next neuron.
The parallel with ECA systems is easily identified: The electric signals can be considered as events, the averaging of the inputs as the activation condition, and the firing of the cell as the action performed. Single neurons are relatively simple in that they execute only one rule in which the complexity of the condition and the variety of possible events are limited. The power of neural networks comes from the interconnection of many of such elementary processing elements, and a learning process in which the weights of inputs are determined based on training (presenting input and desired output).
Collaborating Agents In the area of intelligent agents these rules may specify the norms of the agents, i.e. the typically expected behavior of the (autonomous) agents. Therefore, the agents’ behavior will be better predictable and other agents may anticipate to these behavior allowing coordination and collaboration between these agents. Accordingly, this approach of using ECA rules is called a norm-based approach [19].
Many authors have investigated the stories of the science fiction writer Isaac Asimov who built basic social rules into the positron-brains of robots. These robots typically fail due to the lack of refined context awareness as indicated by the following citation from [17] “In most situations, although the robots usually behaved “logically”, they often failed to do the “right” things – typically because the particular context of application required subtle adjustments on the part of the robot (e.g. determining which law took priority in a given situation, or what constituted helpful or harmless behavior)”.
4.3 Management and Control Another approach of using ECA rules is the policy-based approach. In policy-based systems, one may observe the separation of the ECA rules that govern the behavior of the system from the functionality provided by the system [23]. In these systems, one may distinguish two system parts, a controlled and a controlling part. The controlling part controls the controlled part using policy (ECA) rules. That is, the behavior of the controlled part is constrained by the rules of the controlling part. This approach is considered useful in cases when a controlled part has many choices/options and a controller intervenes by enforcing a choice in accordance with a particular policy goal. In some area, these controlling and controlled parts are typically distributed and so do these parts themselves (e.g. network management systems), but in other areas (e.g. policy-based system control) they may also be collocated.
Policy-based control and management is considered flexible because the system can adapt to the changes in the environment (of the system), for instance by run-time reconfiguration using activation of new policy rules without reengineering the controlled part of the system {[23], [24], [26]}.
The difference between a policy-based and for instance a norm-based approach is often subtle. A survey of the literature (cf. [17]) indicates that a norm-based rule is more descriptive (e.g. describing the behavior of an agent) and a policy-based rule more prescriptive (e.g. prescribing the behavior of the controlled part by interventions, often in a pre-emptive (i.e. instantaneous) way. This way prevents the controlled part to continue its preceding behavior, which in the particular context is considered to be less optimal or even erroneous.
Freeband/AWARENESS/D2.7a 8
4.4 Design Pattern In the classical “Design Patterns – Elements of Reusable Object-Oriented Software” [[1]] by Gamma et al. a total of 23 design patterns is described. The ECA pattern is not amongst those, although several of the behavioral patterns are related in some way. The original patterns in the book are described in terms of objects interacting within the context of a single system, but the concepts are equally applicable at a larger scale (component or system level).
Related design patterns include the following:
Chain of Responsibility “Chain of Responsibility (223): Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it” [1]
The passing of a request down the chain is similar to passing an event through several consecutive ECA systems. The chain stops when the action of the last ECA system does not include forwarding the event. The difference is that the event message in an ECA chain “grows”, as semantic information is added in each step. The event is thus always considered to be “handled” by each ECA system in the chain.
The chain of responsibility pattern could possibly be used in the implementation of ECA rule evaluation locally within a component. An incoming event would be passed along all rules until one is found that handles the event. The order of rules then determines the handling priority. Such an implementation may not be feasible when the set of rules is large.
Observer “Observer (293): Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically” [1].
The publish-subscribe-notify mechanism (see e.g. [2]) can be used to implement a chain of ECA systems. In this way each ECA system subscribes to certain events from “upstream” systems and becomes an observer of these systems. The benefit of this approach (as opposed to statically configuring next-in-chain ECA systems) is that it allows dynamic reconfiguration. An implication is that the upstream ECA system must be locatable and addressable to receive subscribe requests, which may not be possible in some environments (e.g. because of NAT routers, dynamic IP addresses, etc)
Reactor The reactor pattern [5] deals with the dispatching of incoming service requests from multiple clients concurrently. It effectively serializes the handling of asynchronous events, which may or may not be desirable in a given context. The examples given demonstrate a way to associate an event handler with a particular type of events (essentially a single-threaded local subscribe-notify mechanism). This pattern is only applicable within a component, and not to interaction between components.
Proactor The proactor pattern [6] deals with the dispatching of asynchronous completion events resulting from I/O operations to completion handlers. As such it demonstrates how asynchronous I/O interfaces offered by current day operating systems can be used effectively within applications. It is proactive in the sense that a completion event can be anticipated when the I/O operation is requested. This pattern is only applicable within a component, and not to interaction between components.
Mediator (Event channel) “Mediator (273): Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and lets you vary their interaction independently” [1]
Freeband/AWARENESS/D2.7a 9
An “event channel” (or bus) is an application of the mediator pattern, where the communication mechanism between components is represented as an object. It can be used in an ECA system to decouple chained ECA components: rather than sending a message to a successor directly, an ECA component submits the message to an event channel (which can be generic for all events or dedicated to a specific ‘topic’). Interested receivers may subscribe to this channel, instead of to the sending ECA component directly.
4.5 Middleware There are links between ECA and Aspect Oriented Programming [13]. In short, AOP defines point cuts as points in the system where hooks are inserted. When during execution of the system such a point is reached (event) the associated code (action) is executed, possibly subject to additional conditions. Occurrence of events in this case is more predictable and more synchronous than in general event-based systems, since typically the source of events and the AOP code are co-located.
Some researchers have defined the concept of “reactive middleware” {[11], [15]} as the joining of middleware, active databases (with ECA rules) and AOP. They observe the commonalities between these approaches, in particular the common goal of separation of concerns.
4.6 Programming languages Rule-based systems are reflected in declarative programming languages. The amount of existing languages and flavors is enormous; therefore this list is by no means exhaustive:
• (Functional) Reactive Programming (Haskell);
• Logic / declarative programming (ProLog).
4.7 Modeling In modeling and in particular in UML state diagrams, the ECA pattern is reflected in transitions between states: a transition occurs as the result of a trigger (event) under a certain guard (condition), and may as a side effect execute a defined action [27].
5 Conclusions Event-driven computing is typically based on Event-Condition-Action rules or patterns and is applied in areas where changes in the environment of a system should trigger behavioral adaptations of the system. The ECA paradigm has many appearances, e.g. guarded normative behavior, software patterns, permission or obligation policy rules, and it is known in many areas like the area of agent collaborations and network management and application component control. It is furthermore considered suitable for context-aware services, because behavior of these services depend on the context information or the changes of the context.
Acknowledgements This work is part of the Freeband AWARENESS project (http://awareness.freeband.nl). AWARENESS stands for Context AWARE mobile NEtworks and ServiceS. The Freeband AWARENESS project focuses on service and network infrastructures that are needed to support context aware and pro-active applications on heterogeneous mobile networks. Particular attention is paid to mobile health applications for tele-monitoring and tele-treatment. The following organisations participate in Freeband AWARENESS: Lucent Technologies, Centre for Telematics and Information Technology, Telematica Instituut, Roessingh R&D, Ericsson, Twente Institute for Wireless and Mobile Communications, Yucat and TMS International.
Freeband AWARENESS is part of the Freeband program (www.freeband.nl). Freeband is a large national research program in the field of 4G telecommunication, in which fixed, mobile and wireless connections are integrated. Key research questions take place in three main themes: (1) enabling technology, (2) service provisioning, networking and access, and (3) society, users and applications. Freeband comprises over 30 organisations and is sponsored by the Dutch government under contract BSIK 03025.
Freeband/AWARENESS/D2.7a 10
References [1] Gamma et al., “Design Patterns – Elements of Reusable Object-Oriented Software”
[2] N. H. Gehani, H. V. Jagadish, and O. Shmueli, “Event specification in an active object--oriented database”, In Proc. Intl. Conf. on Management of Data (SIGMOD), pages 81--90, San Diego, California, 1992
[3] Y. Huang and H. Garcia-Molina,“Publish/Subscribe in a mobile enviroment”, MobiDe '01, pp 27-34
[4] JSR 94 – Java™ Rule Engine API, http://jcp.org/en/jsr/detail?id=94
[5] Reactor - An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events, http://www.cs.wustl.edu/~schmidt/PDF/reactor-siemens.pdf
[6] Proactor - An Object Behavioral Pattern for Demultiplexing and Dispatching Handlers for Asynchronous Events, http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf
[7] Functional Reactive Programming for Real-Time Reactive Systems , http://www.haskell.org/yale/papers/zwthesis/index.html
[8] Functional Reactive Programming from first principles, http://haskell.cs.yale.edu/yale/papers/pldi00/frp-1st.pdf
[9] Gruber, “Toward principles for the design of ontologies used for knowledge sharing”, http://ksl-web.stanford.edu/KSL_Abstracts/KSL-93-04.html
[10] “What is an ontology”, http://www-ksl.stanford.edu/kst/what-is-an-ontology.html
[11] Reactive Middleware, http://www.dvs1.informatik.tu-darmstadt.de/research/reactive/
[12] Cilia et all., “Dealing with Heterogeneous Data in Pub/Sub Systems: The Concept-Based Approach”, http://www.dvs1.informatik.tu-darmstadt.de/publications/pdf/Concept-based04.pdf
[13] “Event-based Aspect Oriented Programming”, http://www.irisa.fr/lande/jensen/Dispo/Slides/sudholt.pdf
[14] XML 1.1 (W3C recommendation), http://www.w3.org/TR/xml11/ (visited 16/12/2004)
[15] Cilia et all., “The Convergence of AOP and Active Databases: Towards Reactive Middleware”, http://www.st.informatik.tu-darmstadt.de/database/publications/data/gpce03.pdf?id=77
[16] Yang, K., Galis, A. and Todd, C., “Policy-driven Mobile Agents for Context-aware Service in Next Generation Networks”, in Proceedings of the 5th International Workshop on Mobile Agents for Telecommunication Applications MATA03, Marrakech, Morocco, Oct. 8-10th, 2003, LNCS-2881, pp. 111-20;
[17] Bradshaw, J.M., Beautement, P., et al., “Making Agents Acceptable To People”, Chapter 12 of the Handbook of Intelligent Information Technology, N. Zhong and J. Liu (Eds.), Amsterdam IOS Press, 2003;
[18] Damianou, N., Bandara, A.K., Sloman, M. and Lupu, E.C., “A Survey of Policy Specification Languages”, Dept. of Computing, Imperial College of Science Technology and Medicine, London, April 2002;
[19] Liu, K., Sun, L., Dix, A., Narasipuram, M., “Norm Based Agency for Designing Collaborative Systems”, Information Systems Journal, (11) 2001, pp. 229 – 247;
[20] Lobo, J., Bhatia, R. AND Nagvi, S. “A Policy Description Language”, American Association for Artificial Intelligence, 1999;
[21] Steen, M.W.A. and Derrick, J., “ODP Enterprise viewpoint specification”, Computer Standards & Interfaces, Elsevier Science (22) 2000, pp. 165 – 189;
[22] Tonti, G., Bradshaw, J.M., et al., “Semantic Web Languages for Policy Representation and Reasoning: A Comparison of KAoS, Rei and Ponder”, Intern. Semantic Web Conference 2003, Oct. 20-23, Florida;
Freeband/AWARENESS/D2.7a 11
[23] M. Cox and R. Davison, “Concepts, Activities and Issues of Policy-based Communications Management”, BT Technology Journal, Volume 17, Issue 3, July 1999, Pages 155 – 169;
[24] H. Lytfiyya, F. Garcia and J. Moffett, , “Policy 2003: Workshop on Policies for Distributed Systems and Networks”, Journal of Network and Systems Management, Vol.11, No.3, September 2003, pp. 373-376;
[25] R.Yavatkar, D. Pendarakis and R. Guerin, “A Framework for Policy-based Admission Control”, RFC 2753, January 2000;
[26] S. Calo and M. Sloman, “Policy-Based Management of Networks and Services”, Journal of Network and Systems Management, Vol.11, No.3, September 2003, pp. 249-252;
[27] Dumas, M. and Hofstede, A.H.M. ter, “UML Activity Diagrams as a Workflow Specification Language”, in Proceedings of the UML’2001 Conference, 2001, pp. 76-90;
[28] Buchmann, A.P., “Architecture of Active Fatabase Systems”, Chapter 2 in Active Rules in Database Systems, 1998;
[29] M. Caudill & C. Butler, “Naturally intelligent systems”, Cambridge: MIT Press, 1990
[30] G. Papamarkos, A. Poulovassilis, and P. T. Wood. RDFTL: An Event-Condition-Action Language for RDF. In Proc. 3rd Web Dynamics Workshop, at WWW'2004
[31] KTweb information - glossary, http://www.ktweb.org/rgloss.cfm (visited 18/1/2005)
