A DYNAMIC RULE EDITOR FOR SENTINEL
Contents
1. PRIMITIVE instance set price new PRIMITIVE instance_set_price IBM begin void set price float price Creating Rule R2 RULE R2 new RULE R2 seq_event cond2 action2 R2 set priority 20 R2 gt set trigger mode PREVIOUS Creating Rule R2 RULE R3 new RULE R3 p_event cond3 action3 RECENT Notify NULL OODB beginT begin system list OpenOODB gt beginTransaction Notify NULL OODB beginT end system list 22 IBM set_price 115 00 DEC set_price 100 00 Microsoft sell_stock 200 DEC get_price IBM set price 75 95 Notify NULL OODB commit T begin system list OpenOODB gt commit Notify NULL OODB commitT end system_list J Open OODB preprocessed program class STOCK public virtual Wrapper public REACTIVE i private int sell stock OOdbFn int qty int sell stock int 100Agr0 void set price OOdbFn float price void set price float _looAgr0 int get price OOdbFn int get price J int STOCK sell stock OOdbFn int qty i original sell stock method J 23 int STOCK sell stock int 100Arg0 i J Open OODB code Parameters are collected in a linked list PARA LIST sell stock list new PARA LIST sell stock list gt insert gty INT 100Arg0 if is begin of this subscribed Notify begin of method Noti2. Ieuonu oAoO uonnooxq uoneorjddy uone1ouon uoneorddy uoyvoyddp sof sajna YI Jo 1010347 DYNAMIC RULE EDITOR DATA STRUCTURES The Global_Data data structure stores information about each application exist ing It is in the format below and is stored in the EXODUS storage manager struct Global_Data int storage_group_number Storage group number in which the details of aplication exist char Application name VARIABLE LENGTH Application_name The Event Data data structure stores information about all the existing primitive events for a particular application struct Event_Data char method signature VARIABLE LENGTH method signature char begin end VARIABLE LENGTH begin event or end event char class name VARIABLE LENGTH the event s class name char event type VARIABLE LENGTH PRIMITIVE event or COMPOSITE event char event name VARIABLE LENGTH The name of the event 1 The Rule_Data data structure stores information about all the rules asscocitaed with a particular event struct Rule_Data 45 44 char rule_name VARIABLE_LENGTH Name of the rule char condition_key VARIABLE_LENGTH condition key string to retrieve its pointer from con fun pointer c char action_key VARIABLE_LENGTH action key string to to retrieve its pointer from con fun pointer c char context VARIABLE_LENGTH context of the rule char coupling_mode VARIABLE_LENGTH coupling of the rul
3. Context gt button and you will get four types of context s to select CUMULATIVE 48 49 RECENT CHRONICLE and release it over the one which you want to select Cou pling Click and HOLD DOWN the LEFT mouse button over the lt Coupling gt button and you will get three types of coupling modes to select DEFFERED DE TACHED IMMEDIATE and release it over the one which you want to select Priority An entry widget is provided to enter the priority value TriggerMode Click and HOLD DOWN the LEFT mouse button over the lt TriggerMode gt button and you will get two types of trigger modes to select PREVIOUS NOW and release it over the one which you want to select Condition functions Click and HOLD DOWN the LEFT mouse button over the lt Condition functions gt button and you will get two options to select WANT TO USE EXISTIING CONDITIONS CREATE A NEW CONDITION and release it over the one which you want to select If you select the first option then it will display the list of all the files that can be selected and release it over the one which you want to select If you select the second option then it will pop up a window to accept the name of the condition file and after you enter the filename in the entry widget click lt OK gt Once you give the file name it displays the body of the file inside the box beneath it and will allow you to edit the code Action functions Click and HOLD DOWN the LEFT mouse button over the Action func
4. So the user has to painstakingly edit the source code to add a rule to a particular event and then compile the whole source code to see the changes This becomes a tedious task especially if you keep adding one rule at a time Hence there is a need for the tool through which you can add rules to an existing application without going through all the above mentioned tasks Dynamic Rule Editor has been implemented for that very pupose All that a user needs to do to add a rule to an application is to add a rule through the user friendly interface and then link the corresponding condition action library to the application and he can see all the changes immedaitely The objective of this thesis is to provide the user the capability of adding database rules from outside the application in an compilation based environment and see the behaviour of the rule execution without changing the application source code 1 3 Organization of Thesis This thesis is organized as follows Chapter 2 explains how rules are supported in different systems by gicing an example Chapter 3 explains the sentinel architecture in detail Chapter 4 explains about the Architecture of the Dynamic Rule Editor Chapter 5 discusses the design while Chapter 6 discusses the implementation issues involved The final chapter Chapter 7 presents the conclusion and highlights future areas of work CHAPTER 2 RELATED WORK 2 1 How Rules are Supported in Different Systems 2 1 1 ADAM A
5. can be specified only outside of a reactive class defini tion STOCK IBM DEC event end e4 IBM int STOCK sell_stock int number The instance name should be specified as well as the class name It is transformed as PRIMITIVE e4 new PRIMITIVE e4 IBM end int sell stock int number 3 2 1 Composite Event A composite event is specified with a name and an event expression The event expression specifies its constituent primitive or composite events using the Snoop operators When an event expression is processed calls for creating the event graph for that event expre ssion which itself composes an event tree are added to the ap plication code The examples are followed event e8 A el e2 e3 e2 A e4 e5 e6 e7 event e9 e3 el e2 The two examples are transformed each as A star e8 new A star new NOT el e2 e3 e2 new A e4 e5 new AND e6 e7 16 AND STOCK_e9 new AND new OR STOCK e3 STOCK e1 STOCK_e2 Primitive event If the above event is specified in the reactive class named STOCK it is transformed as PRIMITIVE STOCK rell new PRIMITIVE STOCK rel1 TEMPORAL ud a hr P STOCK_e10 new P STOCK el STOCK rell STOCK_e2 The name rell is given by the preprocessor The number here it is 1 starts from 1 and i ncreases by 1 in every reactive class If the above example is specified in an application pro gram then it is converted
6. checks whether the rule has been added to an existing event If yes then it just adds a rule node to that event node else it creates a new event node and adds arule node for that particular event node 6 2 2 Implementation of Modify Rule This routine updates the values in the existing rule node data structure 6 2 3 Implementation of Delete Rule This routine deletes the rule node If it is the only last rule for that event then it deletes the event node along with the rule node 6 3 Run Time Details As soon as the application is started it first executes the load dynamic rules procedure In that procedure it executes the following steps e It first retrieves the Rule catalogue data structure from EXODUS e Traverse the Rule Catalogue data structure and get the keys for the condi tion action pointers Then with the key it traverses the con fun pointer c file and if the key matches it retrieves the corresponding condition action pointer con fun h It is the header file for con fun pointer c include Sentinel h include lt stdio h gt 38 WILISO1J Jo uonno x umunqi 7 9 mr TTAN P Sowa4 pdas 34242 HAILLIATAd P 8270247 do oJ suajuiod UOYID UOYIPUOI LOS Skay ay SILNDID PUD 181 ay SOSLIADA ZAS 194498 SAAOXA 1J1 WOLf 151 ay Sadatyay Y dais pdois dojg days I das UOVA 14245 aang U01094 any DS494DAL 1STT 194498 SNPOXT uo1 po11ddy 39 struct con
7. code Action functions Click and HOLD DOWN the LEFT mouse button over the lt Action functions gt button and you will get two options to select WANT TO USE EXISTIING ACTIONS CREATE A NEW ACTION and release it over the one which you want to select If you select the first option the n it will display the list of all the files that can be selected and release it over the one w hich you want to select If you select the second option then it will pop up a window to accept t he name of the action file and after you enter the filename in the entry widget click lt OK gt O nce you give the file name it displays the body of the file inside the box beneath it and will al low you to edit the code After you have finished changing the Rule Details you have three options 1 Save Compile This will save the rule in the data structure click lt Save Compile gt to select this 2 Previous Menu This will take you back to the previously invocated men click lt Previ ous Menu gt to select this 3 Exit Editor This will pop up a window to confirm whether you really want to exit the dynamic rule editor If Yes then click lt Yes gt Delete Rules Delete Rules allows you to delete rules of a particular event The event in the browsing window of the dynamic rule editor is taken as default and the rules are displayed for that particular event Once you select a rule it will display the existing details of that particular rule click lt Delete Rules gt
8. method that permits us to invoke notification of an event to the composite event detector e A composite event detector for detecting composite events in various contexts There is a composite event detector for each open OODB application or client each application of Open OODB is a client to the Exodus server e A transaction manager for executing rules Light weight processes are used both for prioritized and concurrent rule execution 11 12 3 1 2 Compilation Based Approach vs Interpreter Based Approach An application can be written in two types of environments namely compilation based environment and interpreter based environment In compilation based envi ronment the application is written in languages which have strong type checking like C C and ADA In an interpreter based environment the written code is in terpreted by an interpreter and is written in languages like in Prolog Small Talk and CommonLisp In the first approach the user would have to define the rules in the source code and compile to source code whereas in the second approach there is an interpreter which interprets all the code written and there is no need to compile it In Sentinel events and rules can be specified either as part of the schema class definitions or as part of the application main program Now Sentinel processes the above and generates C code The generated code is inserted into the application in main program and at the execu
9. particular application In the third level we have all the rules associated with a particular rule 6 1 Interface Details 6 1 1 Save Compile for Insert Rules The following steps are executed when we use the Save Compile button in the Insert Rules Window e Adds the necessary header files and saves the condition and action files in tmp directory as C files e Compiles the condition and action files to obtain their o files e Gives all the details to the Cmd procedure for it to include in the data structure e The insertrule procedure checks for that particular event if it exists then it adds a rule to that corresponding event else a new event is created and a rule is appended to the data structure 6 1 2 Save Compile for Modify Rules The following steps are executed when we use the Save Compile button in the Modify Rules Window 34 35 SIIMPNIIS EWA 1ojpgo nw 9 21031 Aod ZOT any ppow 25514 L any opo duydno 1x2ju0 kay uoyoy y UOYIPUO ounN ami IYIN PDA AMY Aadd SUPN Ju d ad L 14047 ouIDN SSD pug uisag o4AnjpUBIS POYIINW apoud E IXIN x 424d s WAN PIDA 19q01D pouT ADJAJ wl 4aqunw 3g aunw uogvogddy E 36 e Adds the necessary header files and saves the condition and action files in tmp directory as C files e Compile
10. A DYNAMIC RULE EDITOR FOR SENTINEL DESIGN AND IMPLEMENTATION By PRAHLAD MADABHUSHI A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 1997 Dedicated to Shirdi Sai Baba and my Parents ACKNOWLEDGEMENTS I would like to express my sincere gratitude to Dr Sharma Chakravarthy for giving me an opportunity to work on this challenging topic and for providing con tinuous guidance advice and support throughout the course of this research work I thank Dr Herman Lam and Dr Haniph Latchman for serving on my supervisory committee and for their careful perusal of this thesis I would like to thank Sharon Grant for maintaining a well administered research environment I am grateful to Shiby Thomas and Hyoungjin Kim for their invaluable help and fruitful discussions during the design and implementation of this work I also take this oppurtunity to thank Aravind Yalamanchi Ramana Nyapathy and Mahesh Jagannath for being helpful in times of need I also thank my best friends Madhav Durbha Mahidhar Gundepudi and Sabrina Karkera for making my stay here in Gainesville a memorable one On a more personal note I would like to thank my father Dr M Padmanabha Iyyangar my mother Mrs Srinivasamma my grandmother P T Sarala Devi my great brother Kalyan Ram my sister in law Vaishali my wonderful sister Rekha my brother in la
11. Anatomy of a Composite Event Detector Technical Report UF CIS TR 93 039 University of Florida Gainesville December 1993 4 S Gatziu K R Dittrich Samos An active object oriented database system IEEE Quarterly Bulletin on Data Engineering March 1993 9T BIOGRAPHICAL SKETCH Prahlad Madabhushi was born on January 28 1973 in Hyderabad India He received a Bachelor of Science degree from Osmania University India in June 1993 He joined the Department of Electrical and Computer Engineering at the Univer sity of Florida in August 1994 to pursue a master s degree He has worked as a research assistant in the Department of Anesthesiology Shands Hospital at the University as a Paradox Programmer from 1994 Fall to 1996 Spring and since then has worked in the Database Systems Research and Development Cen ter of the Computer Information Sciences Department His research interests include computer networks and active database systems 98
12. DAM is an interpreter based system It is implemented in PROLOG Rules and events in ADAM cannot be specified as a part of an object class specification Both the events and rules are treated as first class objects which are created deleted and modified in the same fashion as other objects An object s definition is enlarged to indicate which rules to check when the object raises an event Thus each class structure is augmented with a class rules attribute this attribute has as its value the set of rules that are to be checked when the class raises an event A Rule class is defined where each rule is an instance of that class The structure of the Rule class consists of the attributes event active class is it enabled disabled for condition and action The event attribute indicates the event which triggers the rule the active class attribute indicates the class name on which the rule is applicable the is it enable attribute specifies whether the rule is enabled or not the disabled for attribute has as its value the set of instances for which the rule is disabled while the condition and action attributes specify the rule s condition and action respectively Rule operations are implemented as class methods 2 1 2 Ode Ode is a compiler based system It is implemented in O It incorporates rules in the form of constraints and triggers Both constraints and triggers consist of a condition and action and are defined within a class definition Constr
13. ONPA UX uoqy muuo mei Ju a2 ayi fo s 19 q uoyvoyddv abs powop oam nox 79 190I8 I2 3J901S asmoaq U 098 m suoyvoy dd y 1u244n7 SJUDAT BUYSIX sam smoag 10 1pa any INMVULG ONPI any onuvu amp q 29 e Modify Rules The user is displayed all the rules that he can modify for a particular event He has to double click it to get all the details for that particular rule He has the option to either modify the rule or just ignore it 4 3 Exodus 4 3 1 Introduction The EXODUS Storage Manager is a multi user object storage system support ing versions indexes single site transactions distributed transactions concurrency control and recovery 4 3 2 Architecture The EXODUS Storage Manager has a client server architecture An application program that uses the Storage Manager may reside on a machine different from the machine or machines on which the Storage Manager server or servers run The Storage Manager server is a multi threaded process providing asynchronous I O file transaction concurrency control and recovery services to multiple clients The server stores all data on volumes which are either Unix files or raw disk partitions 4 3 3 Facilities The EXODUS Storage Manager provides objects for storing data versions of objects files for grouping related objects and indexes for supporting efficient ob ject access The
14. Storage Manager also provides volumes transactions concurrency control receovery and configuration options CHAPTER 5 DESIGN OF DYNAMIC RULE EDITOR 5 1 Introduction Rules in the context of an active DBMS consist primarily of three components an event a condition and an action An event is an indicator of a happening which can be either primitive or composite T he condition can be a simple or a comple query on the current database state or on the previous and the current states or even on historical data Actions specify the operations to be performed when an event has occured and the condition evaluates to true There are two types of rules Application level Rules and Rules Added Dynami cally In first the rules which are based on events within the appliation rules added along with the application In second the rules are added from outside the applica tion without editing the application source code Sentinel uses compilation based environment In sentinel to design an applica tion we first need to define schema as classes then define methods and then compile the application and link the application with sentinel libraries and then finally ex ecute Change to either schema or methods require recompilation of the changed source code and relinking to produce a new executable The problem here in using the compilation based environment is that Pointers to functions unlike pointers in data structure cannot be persisted and used
15. aints are used to maintain the notion of object consistency and hence are applicable to all 10 instances of the class in which they are declared Triggers on the other hand are used for monitoring database conditions other than those representing consistency violations and are applicable only to those instances specified explicitly by the user at runtime Triggers in Ode are parameterized The activation of all types of triggers occurs explicitly by the user Triggers are checked at the end of each method and are appended to a to be executed list if they evaluate to true Trigger bodies are executed in seperate transactions after the commit not necessarily immediately after of the transaction firing them 2 1 3 SAMOS SAMOS is a compiler based system The rule definer specifies in SAMOS when a condition has to be evaluated and or an action has to be executed relative to the triggering event by means of coupling modes Examination of the integration of the execution of triggered operations within a transaction model based on multi level transactions and semantic concurrency control In this approach condition eveluation and action execution are implemented as own sub transactions On the basis of semantic concurrency control on the level of methods the system has to be told about conflict relations over the set of methods of a class Class external rules call methods which in turn are synchronized with other methods and rules Class internal rul
16. and retrieve the applications data structure in Exodus storage manager class Glist public Glist GlistO 46 void Insertafter user_class int Glist void Insertrule Gnode char char char charx char char char char char char char char charx void traverse This is to return the number of applications under the host and port Gnode traverse_application int This is to return the pointer for a particular application void traverse_linked_list char This is to display rall the events and rules for a particular applcation void traverse_events Gnode void traverse_event_rule Gnode char char To get all rules associated with a event Rnode traverse rules Gnode char char void Modify rules Rnode char char char char char char int First 0 int Last 0 int Prev int Next Gptr Retrieve void Delete Rnode void glprint void glprint2 void glprint3 Gnode void glprint4 void update cond action int private struct Gnode head tail curr 47 DYNAMIC RULE EDITOR USER MANUAL Note The bracketed notation e g lt BROWSE gt in this manual represents an option on the screen to be selected Click lt BROWSE gt means to click that selection with the LEFT button of the mouse unless otherwise specified The Dynamic Rule Editor is Designed to aid a rule designer to graphically Insert Modify Delete and Bro
17. as PRIMITIVE rell new PRIMITIVE rell TEMPORAL a hr P el0 new P el rell e2 The number in the name rell starts from 1 at the beginning of the application program and increases by 1 Absolute temporal event event ell 14 25 00 04 23 96 If the above absolute temporal event is specified in a reactive class definition where the cl ass name is STOCK it is converted as PRIMITIVE STOCK_el1 new PRIMITIVE STOCK_e5 TEMPORAL 14 25 00 04 23 96 If it is specified outside of the class definition it is transformed as PRIMITIVE e11 new PRIMITIVE e5 TEMPORAL 14 25 00 04 23 96 event e12 P 00 00 00 01 01 96 7 days 00 00 00 12 31 96 17 In the above example two absolute temporal events are specified without their names The Snoop preprocessor give them names If an absolute temporal event is specified outside of a class definition an integer number is given with abs string as abs1 for the event If it is specified in a reactive class definition the class name is prefixed as STOCK abs1 The integer starts from 1 and increases by 1 in every reactive class definition The above example is transformed as PRIMITIVE abs1 new PRIMITIVE abs1 TEMPORAL 00 00 00 01 01 96 1 3 2 2 Rule There should be an event a condition and an action to specify a rule As you can see in the rule specification a
18. cation intervention Furthermore active databases provide an elegant means for supporting integrity constraints access control maintenance of derived data and materialized views and snapshots Rules in the context of an active DBMS consist primarily of three components an event a condition and an action An event is an indicator of a happening either simple or complex The condition specifies an optional predicate over the database state which is evaluated when its corresponding event occurs Actions are the oper ations to be performed when an event occurs and its associated condition evaluates to true vil An active OODBMS application can be written in two types of environments namely Compilation based environment and Interpreter based Environment In the first approach the user would have to define the rules in the source code and compile to source code whereas in the second approach there is an interpreter which interprets all the code written and there is no need to complie it Rules can be classified into two types They are Application level rules and Ex ternal rules Application level rules are based on events within the application i e rules which are hardcoded in the application External rules are based on exist ing potential events which are added from outside the application External Rules can be added to an application in both kinds of environments In the compilation based approach we need to edit the source cod
19. ck void STOCK sell stock int gty Creating class level P event event p event P 00 00 00 01 01 96 7 days 00 00 00 12 31 96 Creating a rule which contains both class level and instance level events rule R2 seg event cond2 action2 20 PREVIOUS Creating a class level rule rule R3 p event cond3 action3 RECENT OpenOOBD gt beginTransaction IBM set price 115 00 DEC set price 100 00 Microsoft sell_stock 200 DEC get price IBM set_price 75 95 OpenOODB gt commitTransaction J Preprocessed program class STOCK public REACTIVE private public int sell stock int qty void set_price float price int get price J Main program STOCK IBM DEC Microsoft LOCAL EVENT DETECTOR Event detector void init func main i 20 21 Creating the local event detector Event_detector new LOCAL EVENT DETECTOR init func Creating primitive events PRIMITIVE STOCK e1 new PRIMITIVE STOCK_el STOCK end int sell stock int gty PRIMITIVE STOCK_e2 new PRIMITIVE STOCK_e2 STOCK begin void set price float price PRIMITIVE STOCK 63 new PRIMITIVE STOCK_e3 STOCK end void set price float price Creating Rule R1 RULE R1 new RULE R1 STOCK e4 cond1 action CUMULATIVE R1 gt set_mode DEFERRED Creating instance level primitive event
20. d_key_ptr char cond key 400 int cond_ptr L OF L LIST F extern int condi L OF L LIST bf Explanation The structure cond_key_ptr has two members one of char type which stores the structure and another of int type which stores the condition and action function pointer con fun pointer c The file which stores all the keys and its corresponding condition action pointers include con fun h struct cond key ptr key ptr 300 cis database15 sentinel OpenOODB 1 1 Sentinel0 9 Rule_Catalog uice8600 8608 cond_function condstock C int L OF L LIST condstock 1 bf Explanation Here we populate the data structure with their keys and condition action pointers The assumption here is that the right brace should be in the 40 next line so that we can edit the file An instance of the event is created by calling the EVENT constructor with the following parameters PRIMITIVE new_event new PRIMITIVE new_event tmp event ptr gt dat gt class name tmp evnt ptr gt dat gt begin end char new signature RULE is created by calling the RULE constructor with the following parame ters The action function method is executed when the condition is met RULE new rule new RULE new rule new event key ptr condition ptr cond ptr void L OF L LIST key ptr action ptr l cond ptr RECENT CHAPTER 7 CONCLUSION AND FUTURE WORK 7 1 Creation of ECA rules in Conve
21. ditor 41 DYNAMIC RULE EDITOR DATA STRUCTURES 43 DYNAMIC RULE EDITOR USER MANUAL 48 REFERENCES s nt A ul sus sp Bed SUQ 57 BIOGRAPHICAL SKETCH san Be ead RE Jm 58 3 1 7 1 7 2 7 3 7 4 7 9 LIST OF FIGURES Rule Processing in Sentinel a ee ee OEE REA 14 Dynamic Rule Edo cat ss e poke RES eA 52 Dynamic Rule Editor Browse Rules 53 Dynamic Rule Editor Insert Rules 54 Dynamic Rule Editor Modify Rules 55 Dynamic Rule Editor Delete Rules 56 vi Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science A DYNAMIC RULE EDITOR FOR SENTINEL DESIGN AND IMPLEMENTATION By Prahlad Madabhushi August 1997 Chairman Dr Herman Lam Cochairman Dr Sharma Chakravarthy Major Department Electrical and Computer Engineering Over the last few years there has been a surge of interest in active databases This is mainly because the needs of a variety of nontraditional applications that are not readily met by traditional database management systems DBMSs Active data bases have been proposed to meet some of the requirements of nontraditional applications Active OODBMSs extend the normal functionality of OODBMSs with support for monitoring user defined situations and reacting to them without user or appli
22. e char rule trigger mode VARIABLE LENGTH The mode in which the rule has to get executed char rule flag VARIABLE LENGTH rule flag char priority VARIABLE_LENGTH the priority in which it should be executed The Rnode struture is a doubly linked list with pointers to its previous node its next node and a pointer to Rule Data data structure struct Rnode int type struct Rnode prev points to previous node struct Rnode next points to next node struct Rule Data dat points to Rule Data data structure Fi struct Rnode rule curr rule tail tail and current The Enode struture is a doubly linked list with pointers to its previous node its next node and a pointer to Event Data data structure 45 struct Enode int type struct Enode prev points to previous node struct Enode next points to next node struct Event_Data dat points to Event_Data data structure struct Rnode rule 1 struct Enode evnt_curr evnt_tail tail and current The Gnode structure is a doubly linked list with pointers to its previous node its next node and a pointer to Global_Data data structure struct Gnode int type l integer 2 float 3 char 4 char 5 classi struct Gnode prev points to previous node struct Gnode next points to next node struct Global Data dat points to Global Data data structure struct Enode event Ju The Glist class is used to store
23. e rules in run time For the event methods which will be created and subscribed by these rules the notifications are inserted to all of the methods of a reactive class with a condition The condition checks to see if there are any rules subscribing the method at that time If there are the notifications go to the local event detector before and after the invocation of the original user method Before any notification of the method the parameters of the method are collected linked in a list and sent with the notifications to the event detector An example of a wrapper method after the Open OODB and Snoop postprocessing can be found in sec 3 4 Example of Preprocessing Original program class STOCK public REACTIVE private event end el int sell stock int qty event begin e2 amp amp end e3 void set_price float price 19 int get_price event e4 el e2 AND operator class level rules rule R1 e4 cond1 actionl CUMULATIVE DEFERRED h int STOCK sell_stock int qty i void STOCK set price float price i int STOCK get price i Main program STOCK IBM DEC Microsoft main Creating instance level primitive event event begin instance set price IBM void STOCK set_price float price SEQUENCE operator event seg event STOCK e4 gt gt instance set price Creating class level primitive event event begin sell sto
24. e to add new rules to the existing application for them to be triggered whereas in the interpreter based approach there will be an interpreter which will interpret the changes made to the application and the rules can be defined on an event externally from outside the application without editing the application source Sentinel uses compilation based environment The problem here in using the compilation based environment is that Pointers to functions unlike pointers in data structure cannot be persisted and used later In sentinel conditions and actions are functions And in a C environment the pointers to these condition and action functions are bound at compilation Link Time and are used at runtime Hence by making the condition and action functions part of the application code the above difficulty is avoided Once the application has been developed addition deletion or modification of rules requires changes to the source code recompilation and relinking The objective of this thesis is to provide user the capability of adding database rules from outside the application in an compilation based environment and see the behaviour of the rule execution without changing the application source code viii CHAPTER 1 INTRODUCTION Over the last few years there has been a surge of interest in active databases This is mainly because the needs of a variety of nontraditional applications that are not readily met by traditional database manage
25. ent a condition and an action to specify a rule Rule can have atmost four options for detecting the event which it subscribes along with a few more parameters such as coupling mode parameter context event consumption mode and priority of the rule Usage rule rl el check price set price RECENT IMMEDIATE NOW 10 Among the optional parameters of a rule definition the parameter context should be specified first and others can be given in any order using the keyword match The parameter_context of the event which a rule subscribes should be placed right after action function if it exists If several rules need to be defined on the same event in different parameter contexts then the rule definition has to be duplicated for each context Parameter context can be one of the RECENT CHRONICLE CONTINUOUS or CUMULATIVE Coupling mode defines the mode of the rule execution An arbitrary number of totally ordered priority classes can be defined Rule Trigger Mode can be used for specifying the time at which event occurences are to be considered for the rule two options NOW and PREVIOUS are supported as rule triggering modes The parameters of a primitive event are the parameters of the method that this primitive is declared on and the time of the event occurrence The parameter of a composite event is the combination of parameters of its constituent events In Sentinel multiple rule executions nested rule executions and prioritized rule e
26. erating over clusters of persistent objects and associating constraints and triggers with ob jects Treatment of rules Ode provides active behaviour by incorporating rules in the form of constraints and triggers Both constraints and triggers consist of a condition and a action and are defined within a class definition Events in Ode are implicit and are considered as the disjunction of all nonconstant public methods Constraints are used to maintain the notion of object consistency and hence are applicable to all instances of the class in which they are declared Triggers on the other hand are used for monitoring database conditions other than those representing consistency violations and are ap plicable only to those instances specified explicitly by the user at runtime Triggers in Ode are parameterized The activation of all types of triggers occurs explicitly by the user Triggers are checked at the end of each method and are appended to a to be executed list if they evaluate to true Trigger bodies are executed in seperate transactions after the commit not necessarily immediately after of the transaction firing them More recently Ode has proposed a language for specifying composite events They specify composite events using a set of operators Events are declared within a class definition Basic primitive events are defined and composite events are constructed by applying operators to basic events The basic events supported are ob
27. es on the other hand can manipulate values of objects directly and thus behave comparable to methods Consequently a class implementor has to provide conflict relations with condition or action parts of class internal rules Finally SAMOS also handles the execution of multiple rules which are triggered by the same event by means of priorities However this is only necessary when condition and action have the same coupling mode In this case the effect of rules depends on the execution order the action of one rule may invalidate the condition of others CHAPTER 3 OVERVIEW OF SENTINEL AND RULE PROCESSING 3 1 Sentinel 3 1 1 Sentinel Architecture The Sentinel an active OODBMS being developed at the University of Florida extends the passive Open OODB system The Open OODB Toolkit uses Exodus as the storage manager and supports persistence of C objects Concurrency control and recovery are provided by the Exodus storage manager A full C pre processor is used for transforming the user class definitions as well as the application code Extensions incorporated for making the Open OODB active are as follows e Specification of ECA rules either as a part of the class definition or as a part of an application This is preprocessed by using an enhanced C pre processor into appropriate code for detection and rule execution e Detection of primitive events by using the sentry mechanism of the Open OODB Sentry mechanism provides a wrapper
28. essing and C compilation The preprocessing declares appropriate events and rules with user defined event and rule specifications expressed in Snoop and inserts them in the application program Here we show how these events and rules preprocessing takes place and how the non Snoop codes are processed with examples e Class level event specified in a reactive class definition class STOCK public REACTIVE 1 event begin el int buy stock int number J The event specification in the above example is transformed as PRIMITIVE STOCK_el new PRIMITIVE STOCK_el STOCK begin int buy stock int number e Class level event specified not in a reactive class definition event begin e2 amp amp end e3 void STOCK set_price float price The above example is transformed into two primitive events as Application Generation Design amp Edit Application Sentinel N Processing and C compilation Application o s Sentinel Libraries 14 Application Application Data Load and Executable Execute Figure 3 1 Rule Processing in Sentinel 15 PRIMITIVE e2 new PRIMITIVE e2 STOCK begin void set_price float price PRIMITIVE e3 new PRIMITIVE e3 STOCK end void set_price float price e Instance level event An instance level event
29. for that particular condition or action After acquiring the key it travereses the array of structures and obtains the corresponding condition action pointer 5 2 Steps Followed by the Application Level Rules The application goes through the following procedure e The application source code goes though a set of three pre processors SPP PPCC CPP e Then the application o s are made e Then they are linked to form an executable The drawback of the above procedure is that all the rules are defined inside an application 5 3 Example of How to Create Rules Through DRed e Use the user friendly Dred interface to create the rules Store the rule catlogue in EXODUS Create o s for condition action files by using CPP pre processor Create condition action libraries 33 e Linking those libraries with the application e Create a new executable Because of the simplicity of the above design we thought that DReSS is an effective way of adding rules to an application CHAPTER 6 IMPLEMENTATION OF DYNAMIC RULE EDITOR This chapter discusses about the implementation of Dynamic Rule Editor includ ing the datastructures used to store the information and insert modify and delete in the RuleEditor frontend The ruleeditor data structure that we maintain in Exodus is a three level linked list on the top level we have all Application name and the storage group In the next level we have all the events associated with a
30. fy this STOCK int sell stock int qty begin sell stock list The original sell stock method is invoked here int ret value sell stock OOddbFn 100Arg0 Only if this event is subscribed if is end of this subscribed Notify end of method Notify this STOCK int sell stock int gty end sell stock list return ret value void STOCK set price OOdbFn float price i J original set price method void STOCK set price float looArg0 i 24 Open OODB code Parameters are collected in a linked list PARA LIST set_price_list new PARA LIST set price list gt insert price FLOAT 1ooArg0 if is begin of this subscribed Notify begin of method Notify this STOCK void set price float price begin set price list The original set price method is invoked here set price OOdbFn 100Argd0 if is end of this subscribed Notify end of method This example illustrates the use of class level and instance level events and rules and also shows the wrapping of the methods with a collection of parameters which are done by the Open OODB preprocessor A class level composite event e4 is defined which is an AND of el and e2 A class level rule R1 is defined on event e4 Instance level primitive event set IBM price is defined for STOCK object IBM A composite seguence event is defined which is a combination of an ins
31. ject state events method execution events timed events and transaction events The event operators supported are relative prior sequence choose every fa and faAbs Detection of events is accomplished by using a finite automata 1 1 2 ADAM Adam is an active OODB implemented in PROLOG It focuses on providing a uniform approach to the treatment of rules in an object oriented environment Treatment of rules Rules are incorporated in ADAM by using an object Based Mechanism Both the events and rules are treated as first class objects which are created deleted and modi fied in the same fashion as other objects An object s definition is enlarged to indicate which rules to check when the object raises an event Thus each class structure is augmented with a class rules attribute this attribute has as its value the set of rules that are to be checked when the class raises an event A Rule class is defined where each rule is an instance of that class The structure of the Rule class consists of the attributes event active class is it enabled disabled for condition and action The event attribute indicates the event which triggers the rule the active class attribute indicates the class name on which the rule is applicable the is it enable attribute specifies whether the rule is enabled or not the disabled for attribute has as its value the set of instances for which the rule is disabled while the condition and action attributes specify
32. later In sentinel conditions and actions are functions And in a C environment the pointers to these condition and action functions are bound at compilation Link Time and are used at runtime Hence by making the condition and action functions part of the application code the above difficulty is avoided Once the application has 30 31 been developed addition deletion or modification of rules requires changes to the source code recompilation and relinking In DReSS function pointers for the condition and action functions were needed The problem was overcome by maintaining a static file which stores an array of structures con fun h It is the header file for con fun pointer c include Sentinel h include lt stdio h gt struct cond_key_ptr char cond_key 400 int cond_ptr L_OF_L_LIST extern int condi L OF L LIST This function stores the condition action key and its pointer con fun pointer c The file which stores all the keys and its corresponding condition action pointers include con fun h struct cond_key_ptr key_ptr 300 1 cis database15 sentinel Open00DB 1 1 Sentinel0 9 32 Rule_Catalog juice8600 8608 cond_function condstock C int L_OF_L_LIST condstock T This is the actual data structure This static file is compiled and its o is linked with the application At run time it traverses the rule catlogue linked list that we persisted and gets the key
33. ment systems DBMSs These applications network management air traffic control program trading computer integarted manufacturing CIM and engineering design to name a few need to as part of their application semantics continually monitor changes to the database state and initiate appropriate actions preferably without user or application intervention Active data bases have been proposed to meet some of the requirements of non traditional applications Active OODBMSs extend the normal functionality of OODBMSS with support for monitoring user defined situations and reacting to them without user or application intervention These DBMSs continuously monitor situa tions to initiate appropriate actions in response to data base updates occurrence of particular states or transition between states possibly within a response time win dow Furthermore active databases provide an elegant means for supporting integrity constraints access control maintenance of derived data and materialized views and snapshots Rules in the context of an active DBMS consist primarily of three components an event a condition and an action An event is an indicator of a happening ei ther simple or complex Events are recognized by the system or signalled by the user For example database events such as insert delete and update are detected by the OODBMS The condition specifies an optional predicate over the database state which is evaluated when its corres
34. mple of Preprocessing dune do aac ee a oe Poen ge restet 4 ARCHITECTURAL DETAILS 153 32 AR E KALPA AAA 4 1 4 2 4 3 Difference Between Application Rules and External Rules Interface u e m ede OO uk Yn Oe dixe deb deed qoi Ae Sec Ur d nd EAS abad a esf qe cedo odit le rode eor dese a e BO e RC am Cay L ie EUER O GO DA ON y C cO cO LO Aa troduction ao 8 l A TAE A AREA 29 4 3 2 Architect r fai a ou e al Seale fS Ee w On n N A 29 Anwo FACIES r eatem E A GB A E de ede e 29 5 DESIGN OF DYNAMIC RULE EDITOR 30 Dus ITA CON A RR AR A E A RIA ctae o CAE enone de 30 5 2 Steps Followed by the Application Level Rules 32 5 3 Example of How to Create Rules Through DRed 32 6 IMPLEMENTATION OF DYNAMIC RULE EDITOR 34 6 1 Interface Details BOs ew SE RU e RO s e e 34 6 1 1 Save Compile for Insert Rules 34 6 1 2 Save Compile for Modify Rules 34 6 1 3 Save Compile for Delete Rules 36 6 1 4 Commit Abort kat e anan ye e ie eS 36 6 2 Implementation of The back end for the Interface 37 6 2 1 Implementation of Insert Rule 37 6 2 2 Implementation of Modify Rule 37 6 2 3 Implementation of Delete Rule 37 6 3 Run Time Details a ek CB a Ak io RUE 37 7 CONCLUSION AND FUTURE WORK iso RR n 41 7 1 Creation of ECA rules in Conventional way and using RuleE
35. n METHOD EVENT NAME The user can choose any of the existing prim itive events or methods from the Isitbox provide RULE NAME The user has to enter the rule name CONTEXT It can be one of these four options RECENT CHRONICLE CONTINOUS or CUMULATIVE COUPLING Coupling mode defines the mode of the rule execution cur rently IMMEDIATE and DEFFERED coupling modes are supported PRIORITY It can be any of the interger values from 1 to 50 TRIGGER MODE Two options NOW start detecting all constituent events starting from this time instant and PREVOIUS all constituent events are acceptable are supported as rule triggering modes with NOW being the default CONDITION FUNCTIONS The code for the condition function will be processed and compiled into a o file ACTION FUNCTIONS The code for the action function will be processed and compiled into a o file After giving all the information he can either save the rule or just ignore it e Delete Rules The user is displayed all the rules that he can delete He has to double click it to get all the details for that particular rule He has the option to either delete the rule or just ingone it 28 OWIQJONPAANY p 2314 mel samy amp fipopy samy amp fipopy so my apa sopa shpon say 142su NUI 5101494 sapny 142su sapny 142su 1980 A
36. n the application External rules are based on exist ing potential events which are added from outside the application The problem here is that sentinel uses an compiation based approach In sentinel to design an application we first need to define schema as classes then define meth ods and then compile the application and link the application with sentinel libraries and then finally execute Change to either schema or methods require recompilation of the changed source code and relinking to produce a new executable Hence we thought that DReSS would be an effective way to add rules from outside the application 4 2 Interface The interface has been developed keeping the user in mind The whole demo is divided into five windows e Dynamic Rule Editor This window displays all the existing applications The user is asked to select an application for which he wants to browse insert modify or delete rules e Browse Rules This window displays all the existing events for that particular application The user is provided with three options He can either select Insert Modify or Delete Rules Also the user can see all the existing primitive 26 27 events for that particular application and if he double clicks on that particular event he can see all the rules associted with that event e Insert Rules This window allows you to enter all the necessary information to create a rule The user has to give the following informatio
37. ntional way and using RuleEditor This thesis extends the sentinel system to support dynamic rules we divided the whole work into two modules First Maintaining the Dynamic Rule Editor User Interface and keeping track of all the the data structures along with the condition and action libraries Second the retrieval of the data structure and calling the RULE and EVENT constructor to add a node in the event graph The diagram below clearly outlines the creation of ECA rules in both the Con ventional Way and also using the Dynamic Rule Editor Presently Dynamic rule editor Sentinel system supports primitive events and it can also be extended to support composite events 41 42 TOP APNG Sursn pue kem QuUONUSAUO UI SI NI VIA Jo uoneor TL 910314 a O EN A A A TE 1000 qE M X i i wq uoneorddy MIN I I IJINJINIIS JON nes j uoneiduro eje us op any i S i ep y pue NG SUSAN So g O sory I E i Mm NDA NA uonoe uonruoo l i 338J193U i dNIIXY SOLIB1Q Susy SI NSIJY pue peo Bunea sony UBISIQ I So nr orureu p peoj i l k siroddns jounuas 9 n5 x syms s y H 2 N po pue peo T y N uoneqidwoo 4491 pue Sursso201q i i i pupas SILIBAQF ME lt unu eje uoneonddy I n s i uoneotddy I i UPA X usq AEN 3 QLINIIXH I
38. ons with condition or action parts of class internal rules Finally SAMOS also handles the execution of multiple rules which are triggered by the same event by menas of priorities However this is only necessary when condition and action have the same coupling mode In this case the efect of rules depends on the execution order the action of one rule may invalidate the condition of others 1 2 Motivation An active OODBMS application can be written in two types of environments namely Compilation based environment and Interpreter based Environment In the compilation based environment the application is written in languages which have strong type checking lke C C and ADA In an interpreter based environment the written code is interpreted by an interpreter and is written in languages like in Prolog SmallTalk and CommonLisp In the first approach the user would have to define the rules in the source code and compile to source code whereas in the second approach there is an interpreter which interprets all the code written and there is no need to complie it Sentinel uses compilation based environment In Sentinel to design an applica tion we first need to define schema as classes then define methods and then compile the application and link the application with sentinel libraries and then finally ex ecute Change to either schema or methods require recompilation of the changed source code and relinking to produce a new executable
39. ponding event occurs The conditions to be 1 monitored may be arbitrarily complex and may be defined not only on single data values or individual database states but also on sets of data objects transitions be tween states of materialized derived objects trends and historical data Actions are the operations to be performed when an event occurs and its associated condition evaluates to true Actions may be programs which may in turn cause the occurrence of other events Once rules are specified declaratively to the system it is the sys tem s responsibility to monitor the situations event condition pairs and execute the corresponding action when the condition is satisfied without any user or application intervention The advantage of using rules as a means of providing active behavior is the freedom from explicitly hard wiring code which checks the situations being monitored into each program that updates the database 1 1 Previous Research On Active OODBMS 1 1 1 Ode Ode 1 is a database system and environment based on object paradigm The database is defined queried and manipulated using the database programming lan guage O which is an upward compatible extension of the object oriented pro gramming language C O extends C by providing facilities suitable for database applications such as facilities for creating persistent and versioned objects defining and manipulating sets organizing persistent objects into clusters it
40. provided to enter the name of the rule Context Click and HOLD DOWN the LEFT mouse button over the lt Context gt button and you will get four types of context s to select CUMULATIVE RECENT CHRONICLE and release it over the one which you want to select Coupling Click and HOLD DOWN the LEFT mouse button over the lt Coupling gt button and you will get three types of coupling modes to select DEFFERED DETACHED IMMEDIATE and release it over the one which you want to select Priority An entry widget is provided to enter the priority value TriggerMode Click and HOLD DOWN the LEFT mouse button over the lt TriggerMode gt button and you will get two types of trigger modes to select PREVIOUS NOW and release it over the one which you want to select Condition functions Click and HOLD DOWN the LEFT mouse button over the Condition functions button and you will get two options to select WANT TO USE EXISTIING CONDITIONS CREATE A NEW CONDITION and release it over the one which you want to select If you select the firs option then it will display the list of all the files that can be selected and release it over the one which you want to select If you select the second option then it will pop up a window to accept the name of the condition file and after you enter the filename in the entry 51 widget click lt OK gt Once you give the file name it displays the body of the file inside the box beneat h it and will allow you to edit the
41. rule can have at most four options for detecting the event which it subscribes or for triggering the rule in a certain mode Exce pt the first option which is parameter_contezt they can be specified in any order rule rl el check_price set_price RECENT IMMEDIATE NOW 10 The above rule specification is converted as the following if it is a class level rule whose c lass is STOCK RULE rl new RULE rl STOCK el check price set price RECENT r1 gt set_mode IMMEDIATE r1 set parameter NOW rl gt set priority 10 The regular C codes are passed through the Snoop prepro cessing without any modifications The preprocessor also inserts Sentinel related codes in the application program to make it easy for the user to use the Sentinel local event detector without worrying about details 18 3 3 Postprocessing and Integrating into Open OODB Preprocessor Event methods that can generate primitive events should be wrapped with no tifications The Open OODB preprocessor also wraps class methods for its sentry mechanism The Open OODB preprocessor renames an original method by post fixing it with a string OOdbFn creates a wrapper method which has the origi nal method name and inserts calls into the wrapper method The function named xwrapper func_code generates OODB code for the wrapped methods We modified it to insert notifications if the method is one of a reactive class The rule editor allows the user to creat
42. s the condition and action files to obtain their o files e Gives all the details to the Cmd procedure for it to include in the data structure e The modifyrules procedures updates the details of the rule in the right place 6 1 3 Save Compile for Delete Rules e It goes and deletes an entry for that particular rule in the data structure e It also maintians a list of all the entires that need to be deleted from the con fun pointer c file 6 14 Commit Abort Commit It commits all the changes made to the application It executes the following steps Adds the condition action pointers to the file it first checks whether an entry exists for that particular condition action in that file if it already exist then it doesnt add it else it adds it e Checks whether all the condition action files that exist in the directory has a corresponding condition action key entry in the data structure if it doesn t exist then it deletes that file and its corresponding o from that directory e Compiles the condition action function pointers file e Creates the condition and action libraries so that they can be linked by the application and the rules can be executed e Persists the whole data structure in EXODUS 37 Abort It aborts all the changes made to the application until then and quits the Dynamic Rule Editor 6 2 Implementation of The back end for the Interface 6 2 1 Implementation of Insert Rule This routine first
43. tance level and class level event and finally rule R2 is defined on the sequence event seq event A periodic event p event is defined with absolute time interval R3 subscribes p event Notice that after preprocessing the user defined methods sell stock set price and get price are renamed as sell stock OOdbFn set price OOdbFn and get price OOdbFn and wrapper methods sell_stock set_price and get price are introduced Currently 25 get price is not subscribed by any of event of rule but the reason why it is also wrapped is that we allow the user to create the r ules subscribing the event later through the rule editor As seen from the example appropriate code is introduced in the wrapper methods to notify the events Also the processing of the application level rule and event specification procues appropriate code for generation of event and rule objects along with the relevant parameters All the proprocessed code is then compiled by the C compiler and is linked to form an executable We run the executable and it goes and retrieves the application data from Exodus and processes the rules accordingly CHAPTER 4 ARCHITECTURAL DETAILS 41 Difference Between Application Rules and External Rules Rules can be classified into two types They are Application level rules and Ex ternal rules Application level rules are based on events within the application i e rules which are hardcoded i
44. the rule s condition and action respectively Rule operations are implemented as class methods Only primitive events are supported The Advantages of using ADAM are as follows e Since complex events are not supported in ADAM attaching the rules as at tributes to a class leads to efficient rule detection e Rules are treated as objects as they can be created deleted and modified like any other object e Inheritance of rules is supported but it cannot be adopted to other environ ments 1 1 3 SENTINEL Sentinel is an active object oriented database management system which support ECA rules in both centralized and now in a distributed environment An event spec ification language Snoop has been developed to specify events which include local events local primitive events and local composite events as well as global events global primitive events and global composite events Two event detection mecha nisms namely a local event detector and a global event detector are implemented to monitor the behavior of local events as well as global events across applications Events and rules 2 3 can be defined at the class level inside a class definition as well as at the instance level outside of a class definition A class level event and rule is applicable to every object of this class whereas an instance level event and rule is applicable only to the specific object instance Treatment of rules There should be an ev
45. tion time the generated code builds eventgraphs for detection and rules are asssociated with events 3 1 3 Why Sentinel Uses Compilation Based Approach In order to process ECA rules in Sentinel it needs pointers to condition action functions to call the RULE constructor Pointers to functions unlike pointers in data structure cannot be persisted and used later In sentinel conditions and actions are functions And in a C environment the pointers to these condition and action functions are bound at compilation Link Time and are used at runtime Hence by making the condition and action functions part of the application code the above difficulty is avoided Once the application has been developed addition deletion or modification of rules requires changes to thesource code recompilation and relinking Hence in Sentinel to design an application we first need to define schema as classes then define methods and then compile the application and link the appli cation with sentinel libraries and then finally execute Change to either schema or 13 methods require recompilation of the changed source code and relinking to produce a new executable 3 2 Rule Processing in Sentinel The Rule Processing the sentinel goes through the following steps e Designing and Editing Phase The user designs and edits the application code He specifies the events and rules for the application along with the Class definitions for e Sentinel proc
46. tions gt button and you will get two options to select WANT TO USE EXISTIING ACTIONS CREATE A NEW ACTION and release it over the one which you want to select If you select the first option then it will display the list of all the files that can be selected and release it over the one which you want to select If you select the second option then it will pop up a window to accept the name of the action file and after you enter the filename in the entry widget click lt OK gt Once you give the file name it displays the body of the file inside the box beneath it and will allow you to edit the code After you have finished entering the Rule Details you have three options 1 Save Compile This will save the 50 rule in the data structure but will not commit the changes onto the Exodus server click lt Save Compile gt to select this 2 Previous Menu This will take you back to the previously invocated men click lt Previous Menu gt to select this 3 Exit Editor This will pop up a window to confirm whether you really want to exit the dynamic rule editor If Yes then click lt Yes gt Modify Rules Modify Rules allows you to modify rules to a particular event The event select ed in the browsing window of the dynamic rule editor is taken as default Once you select a rule it will display the existing details of that particular rule You also have the option of changing the rule details by doing the following Rule Name An entry widget is
47. to delete that particular rule Dynamic Rule Editor Figure 7 1 Dynamic Rule Editor 92 Dynamic Rule Editor Browse Events Figure 7 2 Dynamic Rule Editor Browse Rules 53 54 Dynamic Rule Editor Insert Rules Hospitalrule Patient Physician amp family_dr Patient Set MedicalRecord records Patient int pat id Patient void pat_id int 1 printf processing OQL n 4 Query Select from Hospital ki Figure 7 3 Dynamic Rule Editor Insert Rules Dynamic Rule Editor Delete Rules CUMULATIVE DEFERRED include lt Sentinel h gt include lt Schema h gt include lt defmacro h gt int shcond L OF L LIST ni list include lt defmacro h gt void shact L OF L LIST ni list return 1 ant Iam in shact n Figure 7 4 Dynamic Rule Editor Modify Rules 95 Dynamic Rule Editor Modify Rules A Modify Rules An 4 gt Figure 7 5 Dynamic Rule Editor Delete Rules 56 REFERENCES 1 N H Gehani and H V Jagadish Ode as an Active Database Constraints and Triggers In Proceedings 17th International Conference on Very Large Data Bases pages 327 336 Barcelona Catalonia Spain Sep 1991 2 V Hyesun Lee Support for temporal events in Sentinel Design implemen tation and preprocessing Master s thesis University of Florida Gainesville 1996 3 S Chakravarthy V Krishnaprasad E Anwar and S K Kim
48. w Ramakanth Without their love support and constant encouragement this work would not have been possible 111 TABLE OF CONTENTS ACGENOMIEEDOGMENT W Das a E LIST OP FIGURES tira oput ieee ae E lo tata Wepre A Cape ADS TRACI a aa L EKK Bee AA a AA on OU CHAPTERS C PC ccr EL T INTRODUCTION a aate ada Erg ec dere AE E sp en 1 1 1 2 1 3 Previous Research On Active OODBMS LT O A Saa a Tha e Jp CADA Mi e ee ae o es ek Ge Ga B ASI 11 3 SENTINEE 2 04 dann E Be eck See Gok Sb eee weit VGA SAMOS ooo ea Mou ee a QURE a ee ee Motivation a okt koki bd A Organization of Thesis pacas at Voitto n e BP r E Se oes 2c RELATED WORK cor sal ra A EE RA TASTA ARE 2 1 How Rules are Supported in Different Systems AAA 53 hom e s Weta a S water ES phe N E CR uu ditt 2002 KONNEN rot pad abuse apo Sama 9308 Man Rh se 2 1 9 SAMOS sata deu a a Es 3 OVERVIEW OF SENTINEL AND RULE PROCESSING 3 1 3 2 3 3 3 4 A Mn tus gt La Ana a ST ger ge S owa 3 1 1 Sentinel Architecture 4 0 69x 384 8 1 0 e s e ao 3 1 2 Compilation Based Approach vs Interpreter Based Approach 3 1 3 Why Sentinel Uses Compilation Based Approach Rule Processing in Sentinels Ve Seas Gee ce bode ek o e y 3 2 1 Composite Event x SESE EVA A SS NN JE n MID sais ote ge Sin e ay S sess BY ROME A m Ri a W te ue Yaba Postprocessing and Integrating into Open OODB Preprocessor Exa
49. wse rules In this User Manual we will go through the windows used to insert modify delete and browse rules for an existing set of applications Invoke a session by typing RuleEditorDemo You are now at the top level menu of the Dynamic Rule Editor This gives you a list of all the current applications on which you can insert modify delete and update the rules lt Double click gt on the application for which you want to browse Then Click lt BROWSE gt Browse Rules Now You are in the browsing window of the dynamic rule editor Double click on the event to select and view rules for that particular event You have three options in browse events 1 To Add rules for that particular event For this click lt Insert Rules gt 2 To Modify the existing rules for a particular event For this option you have to make sure that you select an event before you click lt Modify Rules gt 3 To Delete the existing rules for a particular event Again for this option you have to make sure that you select an event before you click lt Delete Rules gt Insert Rules Insert Rules allows you to add rules to a particular event To add rules first you have to select an event for which you want to add rules If you donot select an event then the event selected in the browsing window of the dynamic rule ed itor is taken as default Rule Name An entry widget is provided to enter the name of the rule Context Click and HOLD DOWN the LEFT mouse button over the lt
50. xecutions are supported Two coupling modes immediate and deferred are imple mented 11 4 SAMOS SAMOS 4 is an active OODBMS It supports two types of rules class internal rules and class external rules class internal rules are part of the class definition They are encapsulated within instances and are visible to the class implementor only Conditions and actions of class internal rules are allowed to operate directly on values Class external rules can be defined by any user or application independently of a class definition Rule execution The rule definer specifies in SAMOS when a condition has to be evaluated and or an action has to be executed relative to the triggering event by means of coupling modes immediate deferred decoupled like in HiPAC Examination of the integration of the execution of triggered operations within a transaction model based on multi level transactions and semantic concurrency control In this approach condition eveluation and action execution are implemented as own sub transactions On the basis of semantic concurrency control on the level of methods the system has to be told about conflict relations over the set of methods of a class Class external rules call methods which in turn are synchronized with other methods and rules Class internal rules on the other hand can manipulate values of objects directly and thus behave comaprable to methods Consequently a class implementor has to provide conflict relati
Download Pdf Manuals
Related Search