CA2065521A1 - Extensible event-action system - Google Patents
Extensible event-action systemInfo
- Publication number
- CA2065521A1 CA2065521A1 CA 2065521 CA2065521A CA2065521A1 CA 2065521 A1 CA2065521 A1 CA 2065521A1 CA 2065521 CA2065521 CA 2065521 CA 2065521 A CA2065521 A CA 2065521A CA 2065521 A1 CA2065521 A1 CA 2065521A1
- Authority
- CA
- Canada
- Prior art keywords
- event
- events
- user
- daemon process
- attribute
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Abstract of the Disclosure An extensible event-action system which permits a user of a computer system to specify actions to be performed in response to combinations of user-defined and/or system events. A user-defined event takes place when a process sends an announce message to a daemon process in the system. The system de-fined events include clock events, file system events, machine events, process events, user events, and terminal events. The daemon process maintains ta-bles of event definitions and event-action specifications which specify a com-bination of events and an action. The daemon process further keeps track of the occurrence of system- and user-defined events and performs the action specified in an event-action specification when the events specified therein have occurred. The actions may include commands which affect the event definition and event-action specification tables. Events are defined in terms of objects and attributes. An event has occurred when an attribute of an instance of an object is set to a value which is specified for the attribute.
The attributes may be predefined or may be user-defined. Values are set in predefined attributes by system defined events and in user-defined attributes by the announce message.
The attributes may be predefined or may be user-defined. Values are set in predefined attributes by system defined events and in user-defined attributes by the announce message.
Description
Exte~lsible E~e~t~Action ~ysten~
Background of the Invention Field ~>~ the Invention The invention is directed generally towards the coordination of operations of a computer system and more specifically towards coordination of operations by permitting users of the computer system to define both events to which the computer system responds and actions to be taken by the computer system in response to the events.
Descriptia~n o~ the Prior ~r~
In a computer system, an event is an occurrence which the computer system must respond to but which is as~nchronous to the execution of instructions by the computer system, i.e., its occurrence cannot be determined from the sequence of instructions itself. For example, if the computer system is exe-cuting an interactive program, it must respond to keystrokes received from a keyboard. The computer system has of course no control over when the keystrokes will be made, but must respond when a keystroke event occurs.
Other examples of events include interrupts from peripheral devices other than the keyboard and clock or timer interrupts. The latter events occur when the system clock reaches a time which has been defined to be impor-tant to the system or when a timer set to measure a period of time runs out.
At the level of the operating system, the response made by the system to an event has generally been programmable: when an interrupt occurs, - ,~ , , :~: . .
the result is the execution of an interrupt vector, that is, code which deter-mines how the computer system responds to the interrupt. Some machine instruction sets further include software interrupt instructions: execution of the instruction causes an interrupt to which the computer system responded by executing an interrupt vector specified in the instruction. However, be-cause of the close relationship between interrupts and the physical machine, operating systems have generally not made the system's event mechanisms directly available to users of the operating system. For instance, when a process consumes keystrokes from a keyboard, the process does not respond directly to the interrupts that result when the computer system receives the keystrokes. Instead, the process executes a ~ait system call which causes the operating system to suspend execution of the process until the next keystroke arrives. The operating system then responds to the interrupt by placing the keystroke in memory accessible to the process and continuing execution of the process. The term process as used here and in the following means the entity in a computer system which executes a program. A process typically includes a pattern of bytes that the CPU interprets as machine instructions, data, and stack. Many processes appear to execute simultaneously as the operating system schedules them for execution. See Maurice J. Bach, The Design of the UNIX Operating System, Prentice-Hall, 1986, p. 24.
Because of the usefulness of the event model in dealing with phenomena which are asynchronous to the execution of instructions, systems have been developed which permits users of a system to provide high-level specifications of responses to events. Such systems are termed event-action systems. The systems fall into two broad classes: open systems which permit any user of an operating system to quickly and easily specify an arbitrary action to be performed in response to a system event and closed systems which provide techniques for specifying arbitrary events and constraints based on the oc-currence or non-occurrence of the arbitrary events, but which specify actions which are meaningful only in the context to which the closed system belongs.
Two examples of the first class of system are cron and omicron. cron is a utility provided with the UNIX@) operating system which permits users to indicate programs to be executed when the system clock reaches a certain time of day. There are two parts to the utility: the crontab shell command (the shell is the UNIX command line interface) and the cron process. A user of the cron utility employs crontab to specify the relevant times of day and the shell commands (including invocations of user programs) which he wishes to have executed at those tirmes. The shell responds to the crontab command by adding the information provided by the user to a table which is accessible to the cron process. The cron process executes periodically, and each time it executes, it scans the table and executes any command whose specified time for execution was between the last execution of cron and the current execution of cron. For details, see the discussion of cron in Kochan and Wood, E~ploring the UNIX System, Hayden Books, Indianapolis, IN, 198~, pp. 277-278 and the crontab l~lAN pages for UNIX System V Release 4.
The usefulness of cron is of course limited by the fact that the only events cron can respond to are those involving the system clock. An extended version of cron, called omicron has been implemented which permits the user to define responses not only to events involving the system clock, but also to events involving modifications to files. omicron further permits the execution of a program to be dependent on the occurrence of more than one event. For example, omicron can specify that a periodic check be made to determine whether a file had been modified and can-then specify the action to be taken if the file had in fact been modified. omicron is described in detail in Balachander Krishnamurthy and Craig E. Wills, Omicron: Events~Action, Purdue University Technical Report CSD TR 594, Department of Computer . ':
, -- , '' Sciences, Purdue University, April 1986.
While omicron is as easy to use as cron and more powerful, it still responds only to system-initiated events and provides no mechanism by which a user can define his own events and then arbitrarily specify that such an event has occurred.
Systems belonging to the other class include one which is used in a database system to determine whether prerequisites for the execution of a transaction have been fulfilled prior to executing the transaction and one which is used to determine whether prerequisites ~or the execution of part of a program have been fulfilled before that part of the program is executed. The transaction checking system is disclosed in ~ndrea H. Skarra, "A Model of Concurrent, Cooperating Transactions in an Object-Oriented Database", in:
Computer-a~ded Cooperative Product Development: MIT-JS~E WorkshopJ
MIT, Cambridge, MA, Nov. ~0-21, 1989: Proceedings, Sviram1 Logcher, Fukuda, eds., Springer-Verlag, 1991, In the reference, a group of transac-tions which are interdependent form a transaction group. In order for a given transaction in the group to take place, conditions involving other transac-tions in the group must be fulfilled. Lists of these conditions are associated with the transactions in the group and a monitor updates the lists and makes sure that all of the conditions are fulfilled before the given transaction is per-mitted to take place. The monitor may in addition specify actions to be performed by the database system.
A system which is used in program development to check the execution of a program has been disclosed in David S. Rosenblum, "Specifying Concurrent Systems with TSL", IEEE Software, May 1991, pp. 52-61. In this system, programs which are to be concurrently executed are instrumented by adding event statements and constraint statements written in the TSL language.
Each event statement specifies the occurrence of an event. Each constraint , ~. , ~ ,:
statement specifies one or more events which must have occurred or not occurred before a given statement of the program can be executed.
When the programs with the added statements are compiled, the event statements become system calls whose execution results in messages speci-fying that the events have occurred being sent to a monitor process. The constraint statements become tables accessible to the monitor process and messages to the monitor process indicating that constraint checks must be made. The monitor process responds to the messages indicating the occur-rences of the events by updating the tables and to the messages indicating that constraint checks must be made by determining whether all of the con-straints have been fulfilled; if they have not been, the monitor transfers control to a debugger.
The foregoing systems for monitoring transaction and program execution are more powerful than cron or omicron in that they permit the user to define events and further permit specification of multiple constraints that must be satisfied before an action occurs. They are however not available to any user of the system, and the actions taken when the constraints are satisfied are limited to the realms of the database system and program development respectively.
What is needed, therefore, and what the art has not yet provided, is an event-action system which permits a user to specify event occurrences and constraints with the freedom provided by the second class of systems while retaining the openness, the freedom to specify actions, and the ease of use characteristic of the first class of system. It is an object of the apparatus and methods disclosed herein to provide such a system;
.
Summ~ry of the Invention The invention is an event-action system including e A client process which provides an announce message indicating the occurrence of a user-defined event; and o a daemon process for responding to the announce message by locating an action specification indicating the user-defined event and an arbi-trary action and responding to the user-defined event as specified in the action specification.
The foregoing and other objects and advantages of the invention will be apparent to one of ordinary skill in the art who peruses the following Drawing and Detailed Description, wherein:
Brief Description o~ the I)rawing FIG.l is an overview of the architecture of a preferred embodiment of an extensible event-action system.
FIG. 2 is a diagram of the format of a client command employed in a preferred embodiment;
FIG.3is a list of the client commands employed in the preferred embod-iment;
FIG. 4 is a diagram of the internal structure of the object definitiondatabase in a preferred embodiment;
FIG.5is a diagram of the internal structure of the specification database in a preferred embodiment;
FIG.6is a diagram of the internal structure of the polled event queue in a preferred embodiment; and ., ,~
,~
FIG. 7 is a diagram of the internal structure of the announced event table in a preferred embodiment.
The reference numbers employed in the Drawing and the Detailed De-scription have three or more digits. The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, the element with the reference number "305" is first shown in FIG. 3.
Detailed Description Architecture of t~e Preferred Emb~di~nent The architecture of the preferred embodiment of the event-action system, shown in FIG. 1, is now described.
The daemon process (103) is a central entity that accepts client com^
mands (111), including specifications and queries, from user processes (102).
The interaction between a user process (102) and the daemon process (103) is synchronous and interactive. Each specification comprises an event pat-tern and an action. An event corresponds to a change in the value of an attribute of an object belonging to some object class. This model of events was described by Yih-Farn Chen, Atul Prakash and C. V. Ramamoorthy in "The Network Event Manager", Proceedings of t11e II~EE Comp~ter Nehoork-ing 53/mpo3ium, ~Vashington, DC, 1986. pp. 169-178. All attributes have a type, and the type must be one of the following predefined types recognized by the daemon process (103?
integer, o real, e string, ~, `' .
,, .:.
`
boolean, pro~status (operating system process states), 9 systime (absolute points in time, such as 8:45 am, January 1, 1992), and o reltime (relative amounts of time, such as 2 days and 10 hours).
Event occurrences can either be automatically detected by the daemon pro-cess (103) (in which case the daemon process (103) polls the system environ-ment for their occurrences) or else must be announced to the daemon process (103) by user processes (102). The daemon process (103) triggers the action of a specification (113) within a process running the system's command in-terpreter (108) whenever the daemon process (103) matches an occurrence of the specification's event pattern. All output from the execution of the action (115) is deposited in the mailbox of the user who submitted the specification (107). The daemon process (103) uses as support data structures a specifica-tion database (109), an object definition database (104), a queue for polled events (105), and a table for announced events (106).
The user processes (102) execute the system's command interpreter, al-lowing users to contact the daemon process (103), either locally in the ma-chine or over a communication network, by typing client command strings (111) to the command interpreter. The client command executables are made available to users in a public directory in the host computer's file sys-tem; users include this directory name in their command search path so that the system's command interpreter can find the client command executables whenever the user invokes a client command (111). The client command executables are embedded with knowledge about the location of the daemon ;, ~
- . : :, , . .
; , ~, - , : , process (103). In a typical system, such as a network of Sun-4 workstations that supports UNIX operating system BSD 4.3 mechanisms for network com-munication and on which the preferred embodiment runs, this l;nowledge includes the name of the machine on which the daemon process (103) is ex-ecuting as well as the number of the communication port over which the daemon process (103) communicates. The action portion of a specification can include invocations of client commands (111).
The client commands (111) are messages that include a variety of infor-mation. FIG. 2 depicts the format of client command messages that aTe communicated betweeu user processes (102) and the daemon process (103) in the preferred embodiment. As shown in the figure, the messages include the name of the particular client command that was invoked (202), the login ID of the user who invoked the client command (203), the current file system directory (204) in which the user process (102) is executing, the command string the user typed (205) to invoke the client command, and information about the environment (206) in which the user process (102) is executing.
For instance, in a UNIX operating system the environment information in-cludes information such as the name of the user's home directory, the default te~ct editor used by the user, and the user's command search path. Among other things, client commands (111) are used to submit specifications to the daemon process (103), to define new object classes and their attributes, and to announce events to the daemon process (103). The client commands are described in further detail below.
The specification database (109) holds specifications made by user pro-cesses (102). The object definition database (104) contains the definitions of object classes and attributes that are predefined at the time of starting the daemon process (103), as well as object and attribute definitions that . .
~ ~ ; :- , , ,: :
are subsequently made by user processes (102). Along with the event pat-tern and action, information regarding the owner of the specification (i.e., the user on whose behalf the specification was made) is maintained. The set of predefined object classes can vary between different instances of the daemon process (103) and is dependent on the resources that are available in the computer system on which the daemon process (103) executes. A typical set of predefined object classes includes ~les, directories (collections of files), file systems (corresponding to physical partitions of the file system on long term storage devices), machines, processes, users, and terminals. Each of the predefined object class have a set of predefined attributes. The object class file, for example, has predefined attributes indicating the read/write status of the file (mode), the last time the file was accessed (atime) or modified (mtime), the number of bytes in the file (~ize), and the user ID of the owner of the file (owner).
Event patterns can be a primitive event or a compound event pattern consisting of primitive events combined with connectives and, or, and then.
A compound event combined with and is considered to be matched if and only if the constituent events match at the same time. A compound event pattern combined with or is considered to be matched when either of the constituent events match. In the case of a then connective, the daemon process (103) matches the event pattern on the left side of the operator then before it attempts to match the event pattern on the right side of the operator then; only after the right side is matched is the complete pattern combined with then considered to be matched.
A prirnitive event can either be a predefined event (those events the dae-mon process (103)) can automatically detect) or a user-defined event (those events that must be announced to the daemon process (103)). In the lat-,~9 '~
: ' , `' ter case, the daemon process (103) does not have the knowledge to matchthe event, and instead user processes (102) must notify the daemon process (103) via a client command that announces occurrences of such events. The predefined event patterns are stored in the polled event queue (105) in the order of the time in which they will next be checked for a match. The events that have to be announced are stored in the announced event table (106).
Upon receipt of a client command (111), the daemon process (103) parses it and, based on the particular client command, either adds information to the specification database (109) or object definition database (104) or else retrieves information from them. Adding information to the specification database (109) might also re~uire adding or removing one or more event patterns in the polled event queue (lOS) or the announced event table (106).
A client command (111) that requires a simple lookup in the object definition database (104) or addition of an object or attribute definition does not requireinteraction with the polled event queue (105) or the announced event table (106).
Any output from a client command (111) is sent in a return message (112) to the user process (102). In addition, should the client command (111) result in some error, information about the error (112) is sent back in the interactivestream to the user process (102). Any subsequent problems discovered during matching of a specification results in diagnostic output (114) that is depositedin the mailbox of the user who submitted the specification (107). If the specification action should generate any output (115), that is mailed back to the user who made the specification as well. The mail is deposited in the User Mailbox (107).
, ~
:
'~
. . . .
Client (~ommands of the :Preferred Embodiment The client commands of the preferred embodiment are summarized in FIG. 3.
This section describes some of the features of the client commands.
Client Co~nmands That Qperate On ~;pecilqcations A user process (102) submits a specification to the daemon process (103) through an invocation of the client command addspec (302). Normally a specification is discarded by the daemon process (103) once the daemon pro-cess (103) has matched the event pattern of the specification and triggered its action. However, an invocation of the client command addspec (302) can optionally specify the keyword repeat, in which case the daemon pro-cess (103) retains the specification and begins the matching process again each time it triggers the action of the specification. This process of repeated matching will continue indefinitely unless the user invokes the client com-mand rmspec (304) to remove the specification.
Existing specifications can be examined by invoking the client command Isspec (303). The output (112) returned by Isspec (303) lists all specifica-tions that have been submitted by the user who invoked Isspec (303). Each specification is identified by a unique integer that can be used to refer to thespecification in client commands that operate on specifications. An invoca-tion of lsspec (303) that specifies an explicit specification number will also return as output (112) information on when the daemon process (103) will next perform a matching operation on the specification.
A specification that has been submitted to the daemon process (103) re-mains under the control of the daemon process (103) until either the daemon process (103) has successfully matched the event pattern of the specifica-.
. ` :
.
tions or until the daemon process (103) determines that the evellt patterncan never be matched. Meanwhile, the user who submitted the specification can suspend matching on the specification by invoking the client command suspspec (305) with the specification's identifying integer as argument. The user can then resume matching the specification by invoking the client com-mand fgspec (306) with the specification's identifying integer as argument.
Specifications that form logically related sets can be grouped together by invoking the client command modgrp with a specification group name and the list of specifications to be added to or removed from the group. In addition, a specification can be added to one or more specification groups by specifying the group names in the invocation of the client command addspec (302) that is used to submit the specification. A specification can belong to more than one specification group. The specification group label can be used as an argument to the client commands that operate on specifications in order to cause the client command operation to be carried out on each member of the group.
Other Client Commands Users define new object classes and their attributes by invoking the client commands defobj (309) and defattr (312), respectively. The list of available object classes, both predefined and user-defined, can be obtained by invoking the client command Isobj (310). Likewise, the list of attributes of an object class is obtained by invoking the client command Isattr (313).
Each user-defined object class and attribute is owned by the user who de-fined it. Only the owner of an object class or attribute is permitted to submit specifications that name the object class or attribute in its event pattern.
Users announce events involving user-defined object classes and attributes .~
~ 1i, .
. .
.
.. , . ., .; :
,, , to the daemon process (103) by invoking the client command allnounce (315). However, the owner of an object class or attribute can give access privileges to other users by invoking the client command authobj (316) or authattr (317), respectively. Only the owner of an object class or attribute can announce events involving the object class or attribute. The levels of access are, from lowest to highest, read-access (allowing authorized users to name the object class or attribute in the event portion of a specification), announce-access (allowing authorized users to announce events involving the object class or attribute), write-access (allowing authorized users to define new attributes ~or the object class) and ownership (allowing authorized users to remove the object class or attribute through an invocation of the client commands rmobj (311) or rmattr (31d~), respectively). Each level of access includes the privileges of the access levels below it.
Opera~ion ~f the In~n~ion The operation of the event-action system and its data structures and the use of the event-action system to manipulate user-defined events are described through a representative example. The example is described with reference to the overall architecture of the preferred embodiment (FIG. 1), the list of client commands available in the preferred embodiment (FIG. 3) and the data structures of the preferred embodiment (FIG. 4, FIG. 5, FIG. 6, and FIG. 7).
In the example, a user desires to register specifications that trigger actions in response to events involving software tools. The user decides to model the tools as a class of objects called tool. The user (operating within a user process (102)) defines the object class tool to the daemon process (103) ~' :
hrough an invocation of the client command defobj (309):
def obj tool As shown, an invocation of defobj (309) requires the specification of the name of a new object class. The daemon process (103) consults the table of object classes (402) within the object definition database (104) to determine whether or not the object class was previously defined. If it was, the daemon process (103) rejects the definition request and returns an error message (112) to the user process (102). Otherwise, the daemon process (103) creates an entry for the new object class in the table of object classes (402) along with atable of attributes for the object class (405) that is initially empty. The entry contains the name of the object class (403), a Boolean-valued indication of whether or not the object class is user-defined (404) and the memory address of the table of attributes for the object class (405). As shown in FIG. 4, the entry in the table of object classes (402) for object class Iqle (403) indicatesthat file is pre-defined (404). The invocation of defobj (309) illustrated above would cause the daemon process (103) to add to the table of object classes (402) the entry for object class tool (403) shown in FIG. 4, with the indication that tool is user-defined (404).
One kind of event the user is interested in is the event of a software tool being debugged. The user decides to model occurrences of such events as changes to a Boolean-valued attribute called debugged that is to be associated with all objects of the object class tool. The user intends that an occurrence of a tool event for a tool T with a true value for the attribute debugged will represent the successful debugging of T. Likewise, the user intends that an occurrence of a tool event for a tool T with a false value for the attribute debugged will represent the unsuccessful debugging of T. The user process (102) defines the attribute debugged of the object class tool ',, ; ', ' ;~ ' ' , ~
to the daemon process (103) through an invocation of the client command defattr (312):
defattr tool debugged boolean As shown, an invocation of defattr (312) requires the specification of the name of an existing object class, the name of a new attribute, and the name of the type of the new attribute. The daemon process (103) consults the table of object classes (402) of the object definition table (104) to determine if thespecified object class has been defined and, if so, if the specified attribute has been defined for the object class. If the object class is undefined, if the attribute was previously defined, or if the type name is not one of the predefined types recogni~ed by the daemon process (103), then the daemon process (103) rejects the definition request and returns an error message (112) to the user process (102). Otherwise, the daemon process (103) creates a new entry for the attribute in the table of attributes (405) that is associated with the specified object class. The entry contains the name of the attribute (406), a Boolean-valued indication of whether or not the attribute is user-defined (407), and the name of the type of the attribute (408). As shown in FIG. 4, the entries for the attributes mtime and size (406) in the table of attributes (405) associated with object class file indicate that both attributesare predefined (407) and that their types are systime and integer (408), respectively. The invocation of defattr (312) illustrated above would cause I
the daemon process (103) to add to the table of attributes (405) associated with object class tool the entry for attribute debugged (406) shown in FIG. 4, with the indication that debu~sged is user-defined (407) and that its type is booleall (408).
Users can now submit specifications that specify actions that are to be :
triggered in response to tool debugging events, or in response to patterns of events involving tool debugging events. For instance, a user U1 can submit a specification that sends mail to Ul whenever tool T~ has been successfully de-bugged and file F1 contains more than 1024 bytes (indicating, say, that there is sufficient data within Fl with which to test T1). The user process (102) submits the specification to the daemon process (103) through an invocation of the client command addspec (302):
addspec file ~I size > 1024 and tool Tl debugged =- true do Mail -g "Tl was dabugged" Ul As shown, an invocation of addspec (302) requires the specification of an event pattern and an action that are separated by the keyword do. This e~ample uses the UNIX operating system's command Mail in the action to illustrate the sending of mail; the option -s to Mail specifies a subject head-ing for the mail message. The daemon process (1~3) parses the specification to determine whether or not the specification has a legal structure. If there are any errors in the specification as described below, the daemon process (103) rejects the specification and returns an error message (112) to the user process (102). Otherwise, the daemon process (103) creates an entry for the specification in the array of specifications (502) in the specification database(109).
The entry contains the unique identifying integer (503) that is used to identify the specification in invocations of client commands that operate on specifications, as well as the user ID of the person who submitted the specifi-cation (5~5) (i.e., the owner of the specification), the textual representation of the specification (504), a 13oolean-valued indication of whether or not matching has been suspended on the specification (506), and the address of "~
., a data structure (507) used by the daemon process to carry out the matching of the specification. The matching structure (507) contains a Boolean-valued indication of whether or not the specification is repeatable (508), the textual representation of the action portion of the specification (S09), and the ad-dress of a data structure (510) that contains a structural representation of the event portion of the specification as a hierarchy of primitive events (512, 513). The primitive event is the unit of matching of the daemon process (103).
Each primitive event (512, S13) specifies the name of an object class (515), the name of an object in that object class (516), the name of an attribute of the object class (517), a Boolean-valued indication of whether or not the primitive event has been matched (514), and an event expression. The event expression of a primitive event consists of a relational operator (518) followedby a value of the type of the specified attribute (519); the relational operatoris one of the following:
o < (is-less-than), o <= (is-less-than-or-equal-to), > (is-greater), ?= (is-greater-than-or-equal-to), == (is-equal-to), and ! = (is not-equal-to).
If the event pattern contains multiple primitive events that are joined by the compound connectives and, or and then, then each compound event formed .
' .
by the compound connective is represented in the hierarchical data structure associated with the matching structure (507). The representation of a COIIl-pound event (510) contains the name of the compound connective (511), a Boolean-valued indication of whether or not the compound event has been matched (514), the event on the left-hand side of the connective (512), and the event on the right-hand side of the connective (513). The invocation of addspec (302) illustrated above would cause the daemon process to create the entry for the specification shown in FIG. 5. The entry shows that the identifying integer for the specification is 23, that its owner is user dsr, andthat it is not suspended for matching (506). The matching structure (507) for the specification indicates that the specification is not repeatable (508), that the event portion of the specification contains a compound event (510) comprising two primitive events (512, 513) joined by the connective and, and that no portion of the event pattern has been matched (514). The left side of the connective and is a primitive event involving the size attribute (517) of object Fl (516) of object class file (515); its event expression indicates that the primitive event matches whenever the si~e attribute (517) of object Fl (516) of object class file (515) becomes greater than (518) 1024 (519). The right side of the connective and is a primitive event involving the debugged attribute (517) of object Tl (516) of object class tool (515); its event ex-pression indicates that the primitive event matches whenever the debugged attribute (517) of object Tl (516) of object class tool (515) becomes equal to (518) True (519).
When parsing the specification for errors, the daemon process (103) con-sults the object definition database (104) to ensure that the object class specified in each primitive event (515) is represented by an entry in the table ' .
:
.
.
~ ,: . . . .
:v .
'.
of object classes (402) and that the attribute specified for the object class ina primitive event (517) is represented by an entry in the table of attributes (405) associated with the object class. If an object class (515) or attribute (517) is not defined in the object definition database (104), or if the type of the attribute value (519) is not of the type of the specified attribute (408), or if the specification otherwise contains errors that for some reason make the specification unacceptable to the daemon process (103), the daemon process (103) rejects the submitted specification and returns an error message (112) to the user process (102).
To determine if a primitive event (512, S13) matches, the daemon pro-cess (103) constructs a Boolean-valued relational expression by prefixing the event expression of the primitive event (518, 519) with the actual value of the specified attribute, which the daemon process (103) determines during a matching operation (described below). The daemon process (103) then eval-uates this constructed expression; a true value for the expression indicates a successful match of the primitive event.
The daemon process (103) creates an entry (602) in the polled event queue (105) for each unmatched primitive event that specifies an attribute that is predefined to the daemon process (103), as determined by consulting the entry for the attribute (517) in the table of attributes (405) associated with the attribute's object class in the object definition database (104). By definition such attributes must only be defined for predefined object classes.
The entry in the polled event queue (105) contains the time at which the daemon process (103) will next attempt to match the event (S03), the final time at which the event can be matched (604) (if applicable), the address (605) of the specification database'3 (109) representation of the primitive ..~
:, ~
.
- . . .
' ~ I
event to be matched (512), the address (606) of the specification database's (109) matching structure for the specification with which the primitive event is associated (507), and the address of the next entry in the queue (607).
The entries (602) in the polled event queue (105) are ordered in increasing order of the time of next match (603). For the specification submitted by the invocation of client command addspec (302) illustrated above, the daemon process (103) would create the entry in the polled event queue (105) shown in FIG. 6. The entry indicates that the daemon process (103) will next attempt to match the primitive event involving the file object F1 (512) at 9:27:55 in the morning on March 10, 1992, and it successfully matches whenever the daemon process (103) polls file Fl and finds that it contains more than 1024 bytes.
The daemon process (103) creates an entry in the announced event table (106) for each unmatched primitive event that specifies a user-defined at-tribute (of either a predefined or user-defined object class), as determined by consulting the entry for the attribute (517) in the table of attributes (405) associated with the attribute's object class in the object definition database (104). If the announced event table (106) does not contain an entry in its table of object classes (702) for the object class (515) specified in the primi-tive event, the daemon process creates a new entry. The new entry contains the name of the object class (705) and the address of a table of attributes (703) that is created for the object class and is initially empty. Next, if the table of attributes (703) associated with the object class does not contain an entry for the attribute (517) specified in the primitive event, the daemon process (103) creates a new entry. The new entry contains the name of the attribute (706) and the address of a list of primitive events (704) that is .~
,...
created for the attribute and is initially empty. Finally, the daemon process (103) creates a new entry for the primitive event in the event list (704) as-sociated with the attribute (517) specified in the primitive event. The entry contains the address (707) of the specification database's (109) entry fo~ the primitive event to be matched (513) and the address (708) of the specifica-tion database's (109) matching structure for the specification with which the primitive event is associated (507). The entries in the event list (704) are ordered randomly. For the specification submitted by the invocation of client command addspec (302) illustrated above, the daemon process (103) would create the entry in the announced event table (106) shown in FIG. ~. The entry is for the primitive event involving the tool object T1 (513), and it suc-cessfully matches whenever the daemon process (103) receives an invocation of the client command announce announcing that the attribute debugged of object T1 of object class tool has been set to True.
If the daemon process (103) at any time subsequent to the successful sub-mission of the specification and during matching of the specification detects a problem with the specification that it cannot resolve, the daemon process (103) removes the entry for the specificat;on from the specification database (109), the daemon process (103) removes all primitive events of the specifi-cation from the polled event queue (105) and announced event table (106), and the daemon process (103) sends a mail message (115) that is deposited by the host computer system's mailing command in the mailbox (107) of the user who submitted the specification (505).
The daemon process (103) matches polled events by taking the first entry (602) off the polled event queue (105) and polling the specified object in the host computer system for a match. If the match is successful, the entry (602) -. .
, . :
.
.
is removed from the polled event queue (105), and the entry for the primitive event (512) in the the specification database (109) is marked as having been matched (514). If the match is unsuccessful, the event is reinserted into the polled event queue with a new, later time for the next match attempt (603).
A match of a polled event is successful if and only if the polled attribute value of the polled object satisfies the expression constructed by the daemon process (103) from the primitive event's event expression (518, 519).
The daemon process (103) matches announced events against invocations of the client command announce (315), which is illustrated below. The daemon process matches an announcement against all primitive events (513) in the event list (704) associated with the attribute (706) and object class (705) specified in the announcement. In particular, the daemon process (103) hashes the object class name (705) in the table of object classes (702) to re-trieve the table of attributes (703) associated with the object class (705), andit then hashes the attribute name (706) in this table of attributes to retrieve the event list (704) associated with the object class (705) and attribute (706).If a match against a primitive event from this event list (704) is successful, the entry for the primitive event is removed from the event list (704), and the entry for the primitive event (513) in the the specification database (109) is marked as having been matched (514). If the match is unsuccessful, the entry remains in the event list (704) for matching against subsequent invo-cations of the client command announce (315). A match of an announced event is successful if and only if the announced object class, object name and attribute match those in the primitive event and if`the announced attribute value satisfies the expression constructed by the daemon process (103) from the primitive event's event expression (518, 519).
-. , ' .
, .. ' ' ~ ~ ;' As the daemon process matches constituent events (512, 513) of a com-pound event (510), it marks the entry for the compound event (510) in the specification database (109) as having been matched. A compound event with the connective and matches if and only if the daemon process (103) can successfully match both constituent events simultaneously. A compound event with the connective or matches if and only if the daemon process (103) can successfully match either constituent event. A compound event with the connective then matches if and only if the daemon process (103) can suc-cessfully match the constituent event on the right side of the connective then after having first successfully matched the constituent event on the left side of the connective then.
Once the daemon process (103) successfully matches the entire event pat-tern of a specification, the daemon process (103) triggers the action of the specification by submitting the action to a process that is running the host computer system's command interpreter (108). This process sends all output from the specification action as a mail message (115) that is deposited by the host computer system's mailing command in the mailbox (107) of the user who submitted the specification. Additionally, if the specification is repeat-able (508), the daemon process (103) leaves the entry for the specification in the array of specifications (502) in the specification database (109), sets all of the matching indication values (514) to False, and adds the primitive events of the specification to the polled event queue (105) and announced event table (106) as before. If the specification is not repeatable (508), the daemon process (103) removes the entry for the specification from the array of specifications (502).
Users can now announce tool debugging events to the daemon process (103) whenever they debug a tool. ~or instance, consider a user who suc-`' ' ' ' L
' cessfully debugs the tool Tl. The user process (102) announces this eventto the daemon process (103) through an invocation of the clie~t command announce (315):
announce t~ol Tl debugged = true As shown, an invocation of the client command announce (315) must spec-ify the name of an object class, the name of an object within the specified object class, the name of an attribute o~ the specified object class, and the operator = followed by the new value for the attribute, which must be of the type of the specified attribute. Users can only announce events for user-defined attributes of predefined or user-defined object classes. The daemon process (103), upon receiving this announcement, consults the object defi-nition database (104) to ensure that the specified object class has an entry in the table of object classes (402), that the specified attribute has an en-try in the table of attributes associated with the object class (405) and that the specified attribute is user-defined (d~07). The daemon process (103) then checks the new attribute value specified in the announcement to ensure that the value is of the type of the specified attribute (408). If any of these checks fail, the daemon process tl03) rejects the announcement and returns an er-ror message (112) to the user process. Otherwise, the daemon process (103) matches the announcement against all primitive events in the event list (704) associated with the specified object class and attribute, as described above.
Assuming the example invocation of the client command announce (315) shown above had been preceded by the example invocation of the client com-mand addspec (302) shown above, the example announcement would have the e~ect of causing the daemon process (103) to mark the primitive event involving the object class tool (513) as having been matched (514). Once the , :
- , , .
.
' daemon process (103) has successfully matched the primitive event involving the object class file (512), the complete event portion of the specification will have been matched. As a result of the match, the daemon process (103) would then create a new process running the system's command interpreter (108) and submit the action string (509) of the example specification (113) (the invocation of the command Mail) to the created command interpreter process (108), resulting in the depositing of a mail message with subject heading "Tl was debugged" in user U1's mailbox (107). Because the exam-ple specification is not repeatable (508), the daemon process (103) would finally remove the specification from the array of specifications (502) in the specification database ~109).
Conclusiorl The foregoing Detailed Description has disclosed to those of ordinary skill in the art how to make and use an extensible event-action system which is avail-able for use by any user of the computer system in which it is implemented, which is easy to use, and which permits the user to define actions to be taken in response to user-specified events. The event-action system is further re-sponsive to system events, and an action may be taken in response to a combi-nation of system and user-specified events. Additionally, the object-attribute mechanism for defining events permits user-defined events to be associated with system entities such as files. Moreover, since the commands used by the event-action system are executed by the command line interpreter, the action specified for a combination of events may include commands ~or the event-action system, and consequently may modify the behavior of the sys-tem.
As will be readily apparent to those of ordinary skill in the art, implemen-tations of an extensible event-action system may differ in many ways from the preferred embodiment disclosed herein. In particular, different forms of user interface may be used, for instance, a graphical user interface with rnenus, icons, and a pointing device instead of a command line interface. Fur-ther, different commands and different command formats may be employed and the daemon process may employ different data structures and different algorithms for constructing the data structures and determining when an ac-tion may take place. Additionally, though the preferred embodiment receives commands from UNIX processes and provides them to a daemon which is a UNIX process, the invention may be implemented using any entities which can communicate with each other and independently execute programs.
All of this being the case, the Detailed Description is to be understood as being in all respects exemplary but not restrictive, and the scope of the invention ;s to be determined not from the Detailed Description, but rather from the appended claims as determined in light of the Detailed Description and according to the Doctrine of Equivalents.
' ' .
~ , :
`
.
.
Background of the Invention Field ~>~ the Invention The invention is directed generally towards the coordination of operations of a computer system and more specifically towards coordination of operations by permitting users of the computer system to define both events to which the computer system responds and actions to be taken by the computer system in response to the events.
Descriptia~n o~ the Prior ~r~
In a computer system, an event is an occurrence which the computer system must respond to but which is as~nchronous to the execution of instructions by the computer system, i.e., its occurrence cannot be determined from the sequence of instructions itself. For example, if the computer system is exe-cuting an interactive program, it must respond to keystrokes received from a keyboard. The computer system has of course no control over when the keystrokes will be made, but must respond when a keystroke event occurs.
Other examples of events include interrupts from peripheral devices other than the keyboard and clock or timer interrupts. The latter events occur when the system clock reaches a time which has been defined to be impor-tant to the system or when a timer set to measure a period of time runs out.
At the level of the operating system, the response made by the system to an event has generally been programmable: when an interrupt occurs, - ,~ , , :~: . .
the result is the execution of an interrupt vector, that is, code which deter-mines how the computer system responds to the interrupt. Some machine instruction sets further include software interrupt instructions: execution of the instruction causes an interrupt to which the computer system responded by executing an interrupt vector specified in the instruction. However, be-cause of the close relationship between interrupts and the physical machine, operating systems have generally not made the system's event mechanisms directly available to users of the operating system. For instance, when a process consumes keystrokes from a keyboard, the process does not respond directly to the interrupts that result when the computer system receives the keystrokes. Instead, the process executes a ~ait system call which causes the operating system to suspend execution of the process until the next keystroke arrives. The operating system then responds to the interrupt by placing the keystroke in memory accessible to the process and continuing execution of the process. The term process as used here and in the following means the entity in a computer system which executes a program. A process typically includes a pattern of bytes that the CPU interprets as machine instructions, data, and stack. Many processes appear to execute simultaneously as the operating system schedules them for execution. See Maurice J. Bach, The Design of the UNIX Operating System, Prentice-Hall, 1986, p. 24.
Because of the usefulness of the event model in dealing with phenomena which are asynchronous to the execution of instructions, systems have been developed which permits users of a system to provide high-level specifications of responses to events. Such systems are termed event-action systems. The systems fall into two broad classes: open systems which permit any user of an operating system to quickly and easily specify an arbitrary action to be performed in response to a system event and closed systems which provide techniques for specifying arbitrary events and constraints based on the oc-currence or non-occurrence of the arbitrary events, but which specify actions which are meaningful only in the context to which the closed system belongs.
Two examples of the first class of system are cron and omicron. cron is a utility provided with the UNIX@) operating system which permits users to indicate programs to be executed when the system clock reaches a certain time of day. There are two parts to the utility: the crontab shell command (the shell is the UNIX command line interface) and the cron process. A user of the cron utility employs crontab to specify the relevant times of day and the shell commands (including invocations of user programs) which he wishes to have executed at those tirmes. The shell responds to the crontab command by adding the information provided by the user to a table which is accessible to the cron process. The cron process executes periodically, and each time it executes, it scans the table and executes any command whose specified time for execution was between the last execution of cron and the current execution of cron. For details, see the discussion of cron in Kochan and Wood, E~ploring the UNIX System, Hayden Books, Indianapolis, IN, 198~, pp. 277-278 and the crontab l~lAN pages for UNIX System V Release 4.
The usefulness of cron is of course limited by the fact that the only events cron can respond to are those involving the system clock. An extended version of cron, called omicron has been implemented which permits the user to define responses not only to events involving the system clock, but also to events involving modifications to files. omicron further permits the execution of a program to be dependent on the occurrence of more than one event. For example, omicron can specify that a periodic check be made to determine whether a file had been modified and can-then specify the action to be taken if the file had in fact been modified. omicron is described in detail in Balachander Krishnamurthy and Craig E. Wills, Omicron: Events~Action, Purdue University Technical Report CSD TR 594, Department of Computer . ':
, -- , '' Sciences, Purdue University, April 1986.
While omicron is as easy to use as cron and more powerful, it still responds only to system-initiated events and provides no mechanism by which a user can define his own events and then arbitrarily specify that such an event has occurred.
Systems belonging to the other class include one which is used in a database system to determine whether prerequisites for the execution of a transaction have been fulfilled prior to executing the transaction and one which is used to determine whether prerequisites ~or the execution of part of a program have been fulfilled before that part of the program is executed. The transaction checking system is disclosed in ~ndrea H. Skarra, "A Model of Concurrent, Cooperating Transactions in an Object-Oriented Database", in:
Computer-a~ded Cooperative Product Development: MIT-JS~E WorkshopJ
MIT, Cambridge, MA, Nov. ~0-21, 1989: Proceedings, Sviram1 Logcher, Fukuda, eds., Springer-Verlag, 1991, In the reference, a group of transac-tions which are interdependent form a transaction group. In order for a given transaction in the group to take place, conditions involving other transac-tions in the group must be fulfilled. Lists of these conditions are associated with the transactions in the group and a monitor updates the lists and makes sure that all of the conditions are fulfilled before the given transaction is per-mitted to take place. The monitor may in addition specify actions to be performed by the database system.
A system which is used in program development to check the execution of a program has been disclosed in David S. Rosenblum, "Specifying Concurrent Systems with TSL", IEEE Software, May 1991, pp. 52-61. In this system, programs which are to be concurrently executed are instrumented by adding event statements and constraint statements written in the TSL language.
Each event statement specifies the occurrence of an event. Each constraint , ~. , ~ ,:
statement specifies one or more events which must have occurred or not occurred before a given statement of the program can be executed.
When the programs with the added statements are compiled, the event statements become system calls whose execution results in messages speci-fying that the events have occurred being sent to a monitor process. The constraint statements become tables accessible to the monitor process and messages to the monitor process indicating that constraint checks must be made. The monitor process responds to the messages indicating the occur-rences of the events by updating the tables and to the messages indicating that constraint checks must be made by determining whether all of the con-straints have been fulfilled; if they have not been, the monitor transfers control to a debugger.
The foregoing systems for monitoring transaction and program execution are more powerful than cron or omicron in that they permit the user to define events and further permit specification of multiple constraints that must be satisfied before an action occurs. They are however not available to any user of the system, and the actions taken when the constraints are satisfied are limited to the realms of the database system and program development respectively.
What is needed, therefore, and what the art has not yet provided, is an event-action system which permits a user to specify event occurrences and constraints with the freedom provided by the second class of systems while retaining the openness, the freedom to specify actions, and the ease of use characteristic of the first class of system. It is an object of the apparatus and methods disclosed herein to provide such a system;
.
Summ~ry of the Invention The invention is an event-action system including e A client process which provides an announce message indicating the occurrence of a user-defined event; and o a daemon process for responding to the announce message by locating an action specification indicating the user-defined event and an arbi-trary action and responding to the user-defined event as specified in the action specification.
The foregoing and other objects and advantages of the invention will be apparent to one of ordinary skill in the art who peruses the following Drawing and Detailed Description, wherein:
Brief Description o~ the I)rawing FIG.l is an overview of the architecture of a preferred embodiment of an extensible event-action system.
FIG. 2 is a diagram of the format of a client command employed in a preferred embodiment;
FIG.3is a list of the client commands employed in the preferred embod-iment;
FIG. 4 is a diagram of the internal structure of the object definitiondatabase in a preferred embodiment;
FIG.5is a diagram of the internal structure of the specification database in a preferred embodiment;
FIG.6is a diagram of the internal structure of the polled event queue in a preferred embodiment; and ., ,~
,~
FIG. 7 is a diagram of the internal structure of the announced event table in a preferred embodiment.
The reference numbers employed in the Drawing and the Detailed De-scription have three or more digits. The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, the element with the reference number "305" is first shown in FIG. 3.
Detailed Description Architecture of t~e Preferred Emb~di~nent The architecture of the preferred embodiment of the event-action system, shown in FIG. 1, is now described.
The daemon process (103) is a central entity that accepts client com^
mands (111), including specifications and queries, from user processes (102).
The interaction between a user process (102) and the daemon process (103) is synchronous and interactive. Each specification comprises an event pat-tern and an action. An event corresponds to a change in the value of an attribute of an object belonging to some object class. This model of events was described by Yih-Farn Chen, Atul Prakash and C. V. Ramamoorthy in "The Network Event Manager", Proceedings of t11e II~EE Comp~ter Nehoork-ing 53/mpo3ium, ~Vashington, DC, 1986. pp. 169-178. All attributes have a type, and the type must be one of the following predefined types recognized by the daemon process (103?
integer, o real, e string, ~, `' .
,, .:.
`
boolean, pro~status (operating system process states), 9 systime (absolute points in time, such as 8:45 am, January 1, 1992), and o reltime (relative amounts of time, such as 2 days and 10 hours).
Event occurrences can either be automatically detected by the daemon pro-cess (103) (in which case the daemon process (103) polls the system environ-ment for their occurrences) or else must be announced to the daemon process (103) by user processes (102). The daemon process (103) triggers the action of a specification (113) within a process running the system's command in-terpreter (108) whenever the daemon process (103) matches an occurrence of the specification's event pattern. All output from the execution of the action (115) is deposited in the mailbox of the user who submitted the specification (107). The daemon process (103) uses as support data structures a specifica-tion database (109), an object definition database (104), a queue for polled events (105), and a table for announced events (106).
The user processes (102) execute the system's command interpreter, al-lowing users to contact the daemon process (103), either locally in the ma-chine or over a communication network, by typing client command strings (111) to the command interpreter. The client command executables are made available to users in a public directory in the host computer's file sys-tem; users include this directory name in their command search path so that the system's command interpreter can find the client command executables whenever the user invokes a client command (111). The client command executables are embedded with knowledge about the location of the daemon ;, ~
- . : :, , . .
; , ~, - , : , process (103). In a typical system, such as a network of Sun-4 workstations that supports UNIX operating system BSD 4.3 mechanisms for network com-munication and on which the preferred embodiment runs, this l;nowledge includes the name of the machine on which the daemon process (103) is ex-ecuting as well as the number of the communication port over which the daemon process (103) communicates. The action portion of a specification can include invocations of client commands (111).
The client commands (111) are messages that include a variety of infor-mation. FIG. 2 depicts the format of client command messages that aTe communicated betweeu user processes (102) and the daemon process (103) in the preferred embodiment. As shown in the figure, the messages include the name of the particular client command that was invoked (202), the login ID of the user who invoked the client command (203), the current file system directory (204) in which the user process (102) is executing, the command string the user typed (205) to invoke the client command, and information about the environment (206) in which the user process (102) is executing.
For instance, in a UNIX operating system the environment information in-cludes information such as the name of the user's home directory, the default te~ct editor used by the user, and the user's command search path. Among other things, client commands (111) are used to submit specifications to the daemon process (103), to define new object classes and their attributes, and to announce events to the daemon process (103). The client commands are described in further detail below.
The specification database (109) holds specifications made by user pro-cesses (102). The object definition database (104) contains the definitions of object classes and attributes that are predefined at the time of starting the daemon process (103), as well as object and attribute definitions that . .
~ ~ ; :- , , ,: :
are subsequently made by user processes (102). Along with the event pat-tern and action, information regarding the owner of the specification (i.e., the user on whose behalf the specification was made) is maintained. The set of predefined object classes can vary between different instances of the daemon process (103) and is dependent on the resources that are available in the computer system on which the daemon process (103) executes. A typical set of predefined object classes includes ~les, directories (collections of files), file systems (corresponding to physical partitions of the file system on long term storage devices), machines, processes, users, and terminals. Each of the predefined object class have a set of predefined attributes. The object class file, for example, has predefined attributes indicating the read/write status of the file (mode), the last time the file was accessed (atime) or modified (mtime), the number of bytes in the file (~ize), and the user ID of the owner of the file (owner).
Event patterns can be a primitive event or a compound event pattern consisting of primitive events combined with connectives and, or, and then.
A compound event combined with and is considered to be matched if and only if the constituent events match at the same time. A compound event pattern combined with or is considered to be matched when either of the constituent events match. In the case of a then connective, the daemon process (103) matches the event pattern on the left side of the operator then before it attempts to match the event pattern on the right side of the operator then; only after the right side is matched is the complete pattern combined with then considered to be matched.
A prirnitive event can either be a predefined event (those events the dae-mon process (103)) can automatically detect) or a user-defined event (those events that must be announced to the daemon process (103)). In the lat-,~9 '~
: ' , `' ter case, the daemon process (103) does not have the knowledge to matchthe event, and instead user processes (102) must notify the daemon process (103) via a client command that announces occurrences of such events. The predefined event patterns are stored in the polled event queue (105) in the order of the time in which they will next be checked for a match. The events that have to be announced are stored in the announced event table (106).
Upon receipt of a client command (111), the daemon process (103) parses it and, based on the particular client command, either adds information to the specification database (109) or object definition database (104) or else retrieves information from them. Adding information to the specification database (109) might also re~uire adding or removing one or more event patterns in the polled event queue (lOS) or the announced event table (106).
A client command (111) that requires a simple lookup in the object definition database (104) or addition of an object or attribute definition does not requireinteraction with the polled event queue (105) or the announced event table (106).
Any output from a client command (111) is sent in a return message (112) to the user process (102). In addition, should the client command (111) result in some error, information about the error (112) is sent back in the interactivestream to the user process (102). Any subsequent problems discovered during matching of a specification results in diagnostic output (114) that is depositedin the mailbox of the user who submitted the specification (107). If the specification action should generate any output (115), that is mailed back to the user who made the specification as well. The mail is deposited in the User Mailbox (107).
, ~
:
'~
. . . .
Client (~ommands of the :Preferred Embodiment The client commands of the preferred embodiment are summarized in FIG. 3.
This section describes some of the features of the client commands.
Client Co~nmands That Qperate On ~;pecilqcations A user process (102) submits a specification to the daemon process (103) through an invocation of the client command addspec (302). Normally a specification is discarded by the daemon process (103) once the daemon pro-cess (103) has matched the event pattern of the specification and triggered its action. However, an invocation of the client command addspec (302) can optionally specify the keyword repeat, in which case the daemon pro-cess (103) retains the specification and begins the matching process again each time it triggers the action of the specification. This process of repeated matching will continue indefinitely unless the user invokes the client com-mand rmspec (304) to remove the specification.
Existing specifications can be examined by invoking the client command Isspec (303). The output (112) returned by Isspec (303) lists all specifica-tions that have been submitted by the user who invoked Isspec (303). Each specification is identified by a unique integer that can be used to refer to thespecification in client commands that operate on specifications. An invoca-tion of lsspec (303) that specifies an explicit specification number will also return as output (112) information on when the daemon process (103) will next perform a matching operation on the specification.
A specification that has been submitted to the daemon process (103) re-mains under the control of the daemon process (103) until either the daemon process (103) has successfully matched the event pattern of the specifica-.
. ` :
.
tions or until the daemon process (103) determines that the evellt patterncan never be matched. Meanwhile, the user who submitted the specification can suspend matching on the specification by invoking the client command suspspec (305) with the specification's identifying integer as argument. The user can then resume matching the specification by invoking the client com-mand fgspec (306) with the specification's identifying integer as argument.
Specifications that form logically related sets can be grouped together by invoking the client command modgrp with a specification group name and the list of specifications to be added to or removed from the group. In addition, a specification can be added to one or more specification groups by specifying the group names in the invocation of the client command addspec (302) that is used to submit the specification. A specification can belong to more than one specification group. The specification group label can be used as an argument to the client commands that operate on specifications in order to cause the client command operation to be carried out on each member of the group.
Other Client Commands Users define new object classes and their attributes by invoking the client commands defobj (309) and defattr (312), respectively. The list of available object classes, both predefined and user-defined, can be obtained by invoking the client command Isobj (310). Likewise, the list of attributes of an object class is obtained by invoking the client command Isattr (313).
Each user-defined object class and attribute is owned by the user who de-fined it. Only the owner of an object class or attribute is permitted to submit specifications that name the object class or attribute in its event pattern.
Users announce events involving user-defined object classes and attributes .~
~ 1i, .
. .
.
.. , . ., .; :
,, , to the daemon process (103) by invoking the client command allnounce (315). However, the owner of an object class or attribute can give access privileges to other users by invoking the client command authobj (316) or authattr (317), respectively. Only the owner of an object class or attribute can announce events involving the object class or attribute. The levels of access are, from lowest to highest, read-access (allowing authorized users to name the object class or attribute in the event portion of a specification), announce-access (allowing authorized users to announce events involving the object class or attribute), write-access (allowing authorized users to define new attributes ~or the object class) and ownership (allowing authorized users to remove the object class or attribute through an invocation of the client commands rmobj (311) or rmattr (31d~), respectively). Each level of access includes the privileges of the access levels below it.
Opera~ion ~f the In~n~ion The operation of the event-action system and its data structures and the use of the event-action system to manipulate user-defined events are described through a representative example. The example is described with reference to the overall architecture of the preferred embodiment (FIG. 1), the list of client commands available in the preferred embodiment (FIG. 3) and the data structures of the preferred embodiment (FIG. 4, FIG. 5, FIG. 6, and FIG. 7).
In the example, a user desires to register specifications that trigger actions in response to events involving software tools. The user decides to model the tools as a class of objects called tool. The user (operating within a user process (102)) defines the object class tool to the daemon process (103) ~' :
hrough an invocation of the client command defobj (309):
def obj tool As shown, an invocation of defobj (309) requires the specification of the name of a new object class. The daemon process (103) consults the table of object classes (402) within the object definition database (104) to determine whether or not the object class was previously defined. If it was, the daemon process (103) rejects the definition request and returns an error message (112) to the user process (102). Otherwise, the daemon process (103) creates an entry for the new object class in the table of object classes (402) along with atable of attributes for the object class (405) that is initially empty. The entry contains the name of the object class (403), a Boolean-valued indication of whether or not the object class is user-defined (404) and the memory address of the table of attributes for the object class (405). As shown in FIG. 4, the entry in the table of object classes (402) for object class Iqle (403) indicatesthat file is pre-defined (404). The invocation of defobj (309) illustrated above would cause the daemon process (103) to add to the table of object classes (402) the entry for object class tool (403) shown in FIG. 4, with the indication that tool is user-defined (404).
One kind of event the user is interested in is the event of a software tool being debugged. The user decides to model occurrences of such events as changes to a Boolean-valued attribute called debugged that is to be associated with all objects of the object class tool. The user intends that an occurrence of a tool event for a tool T with a true value for the attribute debugged will represent the successful debugging of T. Likewise, the user intends that an occurrence of a tool event for a tool T with a false value for the attribute debugged will represent the unsuccessful debugging of T. The user process (102) defines the attribute debugged of the object class tool ',, ; ', ' ;~ ' ' , ~
to the daemon process (103) through an invocation of the client command defattr (312):
defattr tool debugged boolean As shown, an invocation of defattr (312) requires the specification of the name of an existing object class, the name of a new attribute, and the name of the type of the new attribute. The daemon process (103) consults the table of object classes (402) of the object definition table (104) to determine if thespecified object class has been defined and, if so, if the specified attribute has been defined for the object class. If the object class is undefined, if the attribute was previously defined, or if the type name is not one of the predefined types recogni~ed by the daemon process (103), then the daemon process (103) rejects the definition request and returns an error message (112) to the user process (102). Otherwise, the daemon process (103) creates a new entry for the attribute in the table of attributes (405) that is associated with the specified object class. The entry contains the name of the attribute (406), a Boolean-valued indication of whether or not the attribute is user-defined (407), and the name of the type of the attribute (408). As shown in FIG. 4, the entries for the attributes mtime and size (406) in the table of attributes (405) associated with object class file indicate that both attributesare predefined (407) and that their types are systime and integer (408), respectively. The invocation of defattr (312) illustrated above would cause I
the daemon process (103) to add to the table of attributes (405) associated with object class tool the entry for attribute debugged (406) shown in FIG. 4, with the indication that debu~sged is user-defined (407) and that its type is booleall (408).
Users can now submit specifications that specify actions that are to be :
triggered in response to tool debugging events, or in response to patterns of events involving tool debugging events. For instance, a user U1 can submit a specification that sends mail to Ul whenever tool T~ has been successfully de-bugged and file F1 contains more than 1024 bytes (indicating, say, that there is sufficient data within Fl with which to test T1). The user process (102) submits the specification to the daemon process (103) through an invocation of the client command addspec (302):
addspec file ~I size > 1024 and tool Tl debugged =- true do Mail -g "Tl was dabugged" Ul As shown, an invocation of addspec (302) requires the specification of an event pattern and an action that are separated by the keyword do. This e~ample uses the UNIX operating system's command Mail in the action to illustrate the sending of mail; the option -s to Mail specifies a subject head-ing for the mail message. The daemon process (1~3) parses the specification to determine whether or not the specification has a legal structure. If there are any errors in the specification as described below, the daemon process (103) rejects the specification and returns an error message (112) to the user process (102). Otherwise, the daemon process (103) creates an entry for the specification in the array of specifications (502) in the specification database(109).
The entry contains the unique identifying integer (503) that is used to identify the specification in invocations of client commands that operate on specifications, as well as the user ID of the person who submitted the specifi-cation (5~5) (i.e., the owner of the specification), the textual representation of the specification (504), a 13oolean-valued indication of whether or not matching has been suspended on the specification (506), and the address of "~
., a data structure (507) used by the daemon process to carry out the matching of the specification. The matching structure (507) contains a Boolean-valued indication of whether or not the specification is repeatable (508), the textual representation of the action portion of the specification (S09), and the ad-dress of a data structure (510) that contains a structural representation of the event portion of the specification as a hierarchy of primitive events (512, 513). The primitive event is the unit of matching of the daemon process (103).
Each primitive event (512, S13) specifies the name of an object class (515), the name of an object in that object class (516), the name of an attribute of the object class (517), a Boolean-valued indication of whether or not the primitive event has been matched (514), and an event expression. The event expression of a primitive event consists of a relational operator (518) followedby a value of the type of the specified attribute (519); the relational operatoris one of the following:
o < (is-less-than), o <= (is-less-than-or-equal-to), > (is-greater), ?= (is-greater-than-or-equal-to), == (is-equal-to), and ! = (is not-equal-to).
If the event pattern contains multiple primitive events that are joined by the compound connectives and, or and then, then each compound event formed .
' .
by the compound connective is represented in the hierarchical data structure associated with the matching structure (507). The representation of a COIIl-pound event (510) contains the name of the compound connective (511), a Boolean-valued indication of whether or not the compound event has been matched (514), the event on the left-hand side of the connective (512), and the event on the right-hand side of the connective (513). The invocation of addspec (302) illustrated above would cause the daemon process to create the entry for the specification shown in FIG. 5. The entry shows that the identifying integer for the specification is 23, that its owner is user dsr, andthat it is not suspended for matching (506). The matching structure (507) for the specification indicates that the specification is not repeatable (508), that the event portion of the specification contains a compound event (510) comprising two primitive events (512, 513) joined by the connective and, and that no portion of the event pattern has been matched (514). The left side of the connective and is a primitive event involving the size attribute (517) of object Fl (516) of object class file (515); its event expression indicates that the primitive event matches whenever the si~e attribute (517) of object Fl (516) of object class file (515) becomes greater than (518) 1024 (519). The right side of the connective and is a primitive event involving the debugged attribute (517) of object Tl (516) of object class tool (515); its event ex-pression indicates that the primitive event matches whenever the debugged attribute (517) of object Tl (516) of object class tool (515) becomes equal to (518) True (519).
When parsing the specification for errors, the daemon process (103) con-sults the object definition database (104) to ensure that the object class specified in each primitive event (515) is represented by an entry in the table ' .
:
.
.
~ ,: . . . .
:v .
'.
of object classes (402) and that the attribute specified for the object class ina primitive event (517) is represented by an entry in the table of attributes (405) associated with the object class. If an object class (515) or attribute (517) is not defined in the object definition database (104), or if the type of the attribute value (519) is not of the type of the specified attribute (408), or if the specification otherwise contains errors that for some reason make the specification unacceptable to the daemon process (103), the daemon process (103) rejects the submitted specification and returns an error message (112) to the user process (102).
To determine if a primitive event (512, S13) matches, the daemon pro-cess (103) constructs a Boolean-valued relational expression by prefixing the event expression of the primitive event (518, 519) with the actual value of the specified attribute, which the daemon process (103) determines during a matching operation (described below). The daemon process (103) then eval-uates this constructed expression; a true value for the expression indicates a successful match of the primitive event.
The daemon process (103) creates an entry (602) in the polled event queue (105) for each unmatched primitive event that specifies an attribute that is predefined to the daemon process (103), as determined by consulting the entry for the attribute (517) in the table of attributes (405) associated with the attribute's object class in the object definition database (104). By definition such attributes must only be defined for predefined object classes.
The entry in the polled event queue (105) contains the time at which the daemon process (103) will next attempt to match the event (S03), the final time at which the event can be matched (604) (if applicable), the address (605) of the specification database'3 (109) representation of the primitive ..~
:, ~
.
- . . .
' ~ I
event to be matched (512), the address (606) of the specification database's (109) matching structure for the specification with which the primitive event is associated (507), and the address of the next entry in the queue (607).
The entries (602) in the polled event queue (105) are ordered in increasing order of the time of next match (603). For the specification submitted by the invocation of client command addspec (302) illustrated above, the daemon process (103) would create the entry in the polled event queue (105) shown in FIG. 6. The entry indicates that the daemon process (103) will next attempt to match the primitive event involving the file object F1 (512) at 9:27:55 in the morning on March 10, 1992, and it successfully matches whenever the daemon process (103) polls file Fl and finds that it contains more than 1024 bytes.
The daemon process (103) creates an entry in the announced event table (106) for each unmatched primitive event that specifies a user-defined at-tribute (of either a predefined or user-defined object class), as determined by consulting the entry for the attribute (517) in the table of attributes (405) associated with the attribute's object class in the object definition database (104). If the announced event table (106) does not contain an entry in its table of object classes (702) for the object class (515) specified in the primi-tive event, the daemon process creates a new entry. The new entry contains the name of the object class (705) and the address of a table of attributes (703) that is created for the object class and is initially empty. Next, if the table of attributes (703) associated with the object class does not contain an entry for the attribute (517) specified in the primitive event, the daemon process (103) creates a new entry. The new entry contains the name of the attribute (706) and the address of a list of primitive events (704) that is .~
,...
created for the attribute and is initially empty. Finally, the daemon process (103) creates a new entry for the primitive event in the event list (704) as-sociated with the attribute (517) specified in the primitive event. The entry contains the address (707) of the specification database's (109) entry fo~ the primitive event to be matched (513) and the address (708) of the specifica-tion database's (109) matching structure for the specification with which the primitive event is associated (507). The entries in the event list (704) are ordered randomly. For the specification submitted by the invocation of client command addspec (302) illustrated above, the daemon process (103) would create the entry in the announced event table (106) shown in FIG. ~. The entry is for the primitive event involving the tool object T1 (513), and it suc-cessfully matches whenever the daemon process (103) receives an invocation of the client command announce announcing that the attribute debugged of object T1 of object class tool has been set to True.
If the daemon process (103) at any time subsequent to the successful sub-mission of the specification and during matching of the specification detects a problem with the specification that it cannot resolve, the daemon process (103) removes the entry for the specificat;on from the specification database (109), the daemon process (103) removes all primitive events of the specifi-cation from the polled event queue (105) and announced event table (106), and the daemon process (103) sends a mail message (115) that is deposited by the host computer system's mailing command in the mailbox (107) of the user who submitted the specification (505).
The daemon process (103) matches polled events by taking the first entry (602) off the polled event queue (105) and polling the specified object in the host computer system for a match. If the match is successful, the entry (602) -. .
, . :
.
.
is removed from the polled event queue (105), and the entry for the primitive event (512) in the the specification database (109) is marked as having been matched (514). If the match is unsuccessful, the event is reinserted into the polled event queue with a new, later time for the next match attempt (603).
A match of a polled event is successful if and only if the polled attribute value of the polled object satisfies the expression constructed by the daemon process (103) from the primitive event's event expression (518, 519).
The daemon process (103) matches announced events against invocations of the client command announce (315), which is illustrated below. The daemon process matches an announcement against all primitive events (513) in the event list (704) associated with the attribute (706) and object class (705) specified in the announcement. In particular, the daemon process (103) hashes the object class name (705) in the table of object classes (702) to re-trieve the table of attributes (703) associated with the object class (705), andit then hashes the attribute name (706) in this table of attributes to retrieve the event list (704) associated with the object class (705) and attribute (706).If a match against a primitive event from this event list (704) is successful, the entry for the primitive event is removed from the event list (704), and the entry for the primitive event (513) in the the specification database (109) is marked as having been matched (514). If the match is unsuccessful, the entry remains in the event list (704) for matching against subsequent invo-cations of the client command announce (315). A match of an announced event is successful if and only if the announced object class, object name and attribute match those in the primitive event and if`the announced attribute value satisfies the expression constructed by the daemon process (103) from the primitive event's event expression (518, 519).
-. , ' .
, .. ' ' ~ ~ ;' As the daemon process matches constituent events (512, 513) of a com-pound event (510), it marks the entry for the compound event (510) in the specification database (109) as having been matched. A compound event with the connective and matches if and only if the daemon process (103) can successfully match both constituent events simultaneously. A compound event with the connective or matches if and only if the daemon process (103) can successfully match either constituent event. A compound event with the connective then matches if and only if the daemon process (103) can suc-cessfully match the constituent event on the right side of the connective then after having first successfully matched the constituent event on the left side of the connective then.
Once the daemon process (103) successfully matches the entire event pat-tern of a specification, the daemon process (103) triggers the action of the specification by submitting the action to a process that is running the host computer system's command interpreter (108). This process sends all output from the specification action as a mail message (115) that is deposited by the host computer system's mailing command in the mailbox (107) of the user who submitted the specification. Additionally, if the specification is repeat-able (508), the daemon process (103) leaves the entry for the specification in the array of specifications (502) in the specification database (109), sets all of the matching indication values (514) to False, and adds the primitive events of the specification to the polled event queue (105) and announced event table (106) as before. If the specification is not repeatable (508), the daemon process (103) removes the entry for the specification from the array of specifications (502).
Users can now announce tool debugging events to the daemon process (103) whenever they debug a tool. ~or instance, consider a user who suc-`' ' ' ' L
' cessfully debugs the tool Tl. The user process (102) announces this eventto the daemon process (103) through an invocation of the clie~t command announce (315):
announce t~ol Tl debugged = true As shown, an invocation of the client command announce (315) must spec-ify the name of an object class, the name of an object within the specified object class, the name of an attribute o~ the specified object class, and the operator = followed by the new value for the attribute, which must be of the type of the specified attribute. Users can only announce events for user-defined attributes of predefined or user-defined object classes. The daemon process (103), upon receiving this announcement, consults the object defi-nition database (104) to ensure that the specified object class has an entry in the table of object classes (402), that the specified attribute has an en-try in the table of attributes associated with the object class (405) and that the specified attribute is user-defined (d~07). The daemon process (103) then checks the new attribute value specified in the announcement to ensure that the value is of the type of the specified attribute (408). If any of these checks fail, the daemon process tl03) rejects the announcement and returns an er-ror message (112) to the user process. Otherwise, the daemon process (103) matches the announcement against all primitive events in the event list (704) associated with the specified object class and attribute, as described above.
Assuming the example invocation of the client command announce (315) shown above had been preceded by the example invocation of the client com-mand addspec (302) shown above, the example announcement would have the e~ect of causing the daemon process (103) to mark the primitive event involving the object class tool (513) as having been matched (514). Once the , :
- , , .
.
' daemon process (103) has successfully matched the primitive event involving the object class file (512), the complete event portion of the specification will have been matched. As a result of the match, the daemon process (103) would then create a new process running the system's command interpreter (108) and submit the action string (509) of the example specification (113) (the invocation of the command Mail) to the created command interpreter process (108), resulting in the depositing of a mail message with subject heading "Tl was debugged" in user U1's mailbox (107). Because the exam-ple specification is not repeatable (508), the daemon process (103) would finally remove the specification from the array of specifications (502) in the specification database ~109).
Conclusiorl The foregoing Detailed Description has disclosed to those of ordinary skill in the art how to make and use an extensible event-action system which is avail-able for use by any user of the computer system in which it is implemented, which is easy to use, and which permits the user to define actions to be taken in response to user-specified events. The event-action system is further re-sponsive to system events, and an action may be taken in response to a combi-nation of system and user-specified events. Additionally, the object-attribute mechanism for defining events permits user-defined events to be associated with system entities such as files. Moreover, since the commands used by the event-action system are executed by the command line interpreter, the action specified for a combination of events may include commands ~or the event-action system, and consequently may modify the behavior of the sys-tem.
As will be readily apparent to those of ordinary skill in the art, implemen-tations of an extensible event-action system may differ in many ways from the preferred embodiment disclosed herein. In particular, different forms of user interface may be used, for instance, a graphical user interface with rnenus, icons, and a pointing device instead of a command line interface. Fur-ther, different commands and different command formats may be employed and the daemon process may employ different data structures and different algorithms for constructing the data structures and determining when an ac-tion may take place. Additionally, though the preferred embodiment receives commands from UNIX processes and provides them to a daemon which is a UNIX process, the invention may be implemented using any entities which can communicate with each other and independently execute programs.
All of this being the case, the Detailed Description is to be understood as being in all respects exemplary but not restrictive, and the scope of the invention ;s to be determined not from the Detailed Description, but rather from the appended claims as determined in light of the Detailed Description and according to the Doctrine of Equivalents.
' ' .
~ , :
`
.
.
Claims
1. An event-action system comprising:
first process means which provides an announce message indicating the occurrence of a user-defined event; and second process means for responding to the announce message by locating an action specification indicating the user-defined event and an arbitrary action and responding to the user-defined event as specified in the action specification.
first process means which provides an announce message indicating the occurrence of a user-defined event; and second process means for responding to the announce message by locating an action specification indicating the user-defined event and an arbitrary action and responding to the user-defined event as specified in the action specification.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US86046492A | 1992-04-03 | 1992-04-03 | |
US860,464 | 1992-04-03 |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2065521A1 true CA2065521A1 (en) | 1993-10-04 |
Family
ID=25333280
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA 2065521 Abandoned CA2065521A1 (en) | 1992-04-03 | 1992-04-09 | Extensible event-action system |
Country Status (1)
Country | Link |
---|---|
CA (1) | CA2065521A1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5799149A (en) * | 1996-06-17 | 1998-08-25 | International Business Machines Corporation | System partitioning for massively parallel processors |
US5854896A (en) * | 1996-06-17 | 1998-12-29 | International Business Machines Corporation | System for preserving logical partitions of distributed parallel processing system after re-booting by mapping nodes to their respective sub-environments |
US5881227A (en) * | 1996-06-17 | 1999-03-09 | International Business Machines Corporation | Use of daemons in a partitioned massively parallel processing system environment |
US5941943A (en) * | 1996-06-17 | 1999-08-24 | International Business Machines Corporation | Apparatus and a method for creating isolated sub-environments using host names and aliases |
-
1992
- 1992-04-09 CA CA 2065521 patent/CA2065521A1/en not_active Abandoned
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5799149A (en) * | 1996-06-17 | 1998-08-25 | International Business Machines Corporation | System partitioning for massively parallel processors |
US5854896A (en) * | 1996-06-17 | 1998-12-29 | International Business Machines Corporation | System for preserving logical partitions of distributed parallel processing system after re-booting by mapping nodes to their respective sub-environments |
US5881227A (en) * | 1996-06-17 | 1999-03-09 | International Business Machines Corporation | Use of daemons in a partitioned massively parallel processing system environment |
US5941943A (en) * | 1996-06-17 | 1999-08-24 | International Business Machines Corporation | Apparatus and a method for creating isolated sub-environments using host names and aliases |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6049799A (en) | Document link management using directory services | |
Chamberlin et al. | A history and evaluation of System R | |
US6742141B1 (en) | System for automated problem detection, diagnosis, and resolution in a software driven system | |
CA2483963C (en) | A method, computer program and computer for accessing data in an environment of multiple data repositories | |
CA2258252C (en) | Delta model processing logic representation and execution system | |
US7827159B2 (en) | Automated data model extension through data crawler approach | |
US5581758A (en) | Computer program product for object specification, generation, and management in a distributed database | |
KR100623245B1 (en) | Automatic configuration generation | |
US5446878A (en) | Method for selectively enabling subset of embedded event-making instructions and selecting types and items of event-based data to be collected per enabled instruction | |
US7398263B2 (en) | Sequenced modification of multiple entities based on an abstract data representation | |
US7725524B2 (en) | Process automation system and method having a hierarchical architecture with multiple tiers | |
JP2710555B2 (en) | System and method for automating the enforcement of constraints in a database | |
US20030167274A1 (en) | Modification of a data repository based on an abstract data representation | |
US7886265B2 (en) | Process automation system and method employing property attachment techniques | |
IL142484A (en) | Impact analysis of a model | |
US7225177B2 (en) | Generating a knowledge base | |
EP1616249A2 (en) | Rule application management in an abstract database abstract of the disclosure | |
WO2000068793A1 (en) | System for automated problem detection, diagnosis, and resolution in a software driven system | |
US8042089B2 (en) | Process automation system and method employing multi-stage report generation | |
CA2065521A1 (en) | Extensible event-action system | |
US7089232B2 (en) | Method of synchronizing distributed but interconnected data repositories | |
JPH0756794A (en) | Document managing device | |
Koschel et al. | Configurable event triggered services for CORBA-based systems | |
Bergeron et al. | Automated repair service bureau: Software tools and components | |
KR100238439B1 (en) | Method of managing object-orient route index of schema manager |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
FZDE | Dead |