Pushing reactive services to XML repositories using active rules
Proceedings of the 10th international conference on World Wide Web
A Policy-Based Approach to Personalization of Communication over Converged Networks
POLICY '02 Proceedings of the 3rd International Workshop on Policies for Distributed Systems and Networks (POLICY'02)
Real-time event handling in an RFID middleware system
DNIS'07 Proceedings of the 5th international conference on Databases in networked information systems
Towards a dynamic and extensible middleware for enhancing exhibits
CCNC'10 Proceedings of the 7th IEEE conference on Consumer communications and networking conference
Managing RFID events in large-scale distributed RFID infrastructures
Information Technology and Management
EPAL based privacy enforcement using ECA rules
ICISS'05 Proceedings of the First international conference on Information Systems Security
| Hi-index | 0.00 |
Active systems have been proposed as a paradigm to satisfy the needs of many database and other applications that require a timely response to situations. Event - Condition - Action (or ECA) rules [1] are used to capture the active capability in a system. The utility and functionality of active capability (ECA rules) has been well established in the context of databases. In order for the active capability to be useful for a large class of advanced applications, it is necessary to go beyond what has been proposed/developed in the context of databases. Specifically, extensions beyond the current state of the art in active capability are needed along several dimensions: - i. make the active capability available for non-database applications, in addition to database applications; ii. make the active capability available in distributed environments, and iii. make the active capability available for heterogeneous sources of events (whether they are databases are not). The objective of this paper is to provide an architecture and framework to support ECA rules for distributed and heterogeneous systems. We will describe the design of our ECA rule service, the alternatives considered at each step and the reasons for our choice of a particular alternative. Finally we will draw conclusions about the architecture of our system and the utility of our system for a wide range of applications.