Method and apparatus for event modeling6578043Abstract The present invention provides a method that allows a developer to add complex dependency logic to an existing database without having to modify the underlying structure of the database. One embodiment of the present invention provides a way to flexibly handle record state transitions by using an event model. The event model is a set of one or more items called an event. Each event in the event model has an associated event type and contains dependency logic that interrelates the events in the event model with one another. Each event represents a set of actions that are optionally contingent upon a condition. The actions and conditions that comprise an event are determine when the event is created. Each event may have a different set of actions and conditions. This enables an event to represent a number of different things. An event can represent anything it is defined to represent. In one embodiment of the present invention an event metamodel is instantiated to represent a number of different event models and the corresponding dependencies that interrelate them. The event metamodel enables the model creator to control what happens to each and every event in the event metamodel without having to modify the underlying structure of the database. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
bolts, fabric, fuel, otherthings parts
airplane
Bob, Sue, other people labor
Another useful htcr, say of containment type b a, might be Hb defined as
Bob, Sue, rubber, fabric nonhazardous materials
airplane
fuel, cleaning chemicals hazardous materials
This implementation of type containment represents a compromise between the ease-of-use of a tree structure and the flexibility of a mesh. An event instance, or event, is a set of actions, possibly empty, which is optionally contingent upon a condition. An event is associated with one abstract type te called the event type. An event can depend upon zero or more events, and zero or more events can depend on it. And an event can optionally have a trigger function t.sub.e, a state function t.sub.e, or both. The name of the stored procedure which implements t.sub.e for te is given by the TRIGGER FUNCTION datum associated with te. The name of the stored procedure which implements t.sub.e, for te is given by the STATE FUNCTION datum associated with te. The model semantics of "depends" and "state" are given by t.sub.e and t.sub.e respectively. t.sub.e takes as input the set of events upon which an event e depends and their respective states, and returns a value of one or zero indicating whether the event e has been "triggered" or "not triggered" respectively. It expresses a model's policy of when to continue processing events dependent upon the state of event and when not to. The case where t.sub.e is null is equivalent to te having no trigger function at all. The state t.sub.e will be computed only if an event is triggered. t.sub.e returns an event_state se, based on the outcome of the ordered set of actions t.sub.e tries to perform. The case where t.sub.e is null is equivalent to t, having no state function at all. The set S of possible event states is defined by the model developer and will vary according to the event sets being modeled. Consider, for example, if modeling set of events relating to a credit card authorization, then a useful set of states for these events might include the following states: "Authorization approved", "Authorization declined", "Hardware error--cannot retry", "Line is busy--retry later". Let N be the set of natural numbers, .vertline.X.vertline. denote the number of elements in a finite set X, E={e1, e2,, ei,, e.sub..vertline.E.vertline. } be the set of modeled events, S={s1, s2,, si,, s.sub..vertline.S.vertline. } be the set of all possible event states, T={t1, t2,, ti,, t.sub..vertline.T.vertline. } be the set of all abstract types, D={d1, d2,, di,, d.sub..vertline.D.vertline. } be the set of all datums, EDi=(ed1, ed2,, edj,, ed.sub..vertline.ED.sub..sub.i .sub..vertline.).OR right.D be the ordered set of all elements of event-specific data associated with event i, TDi=(td1, td2,, tdj,, td.sub..vertline.TD.sub..sub.i .sub..vertline.).OR right.D be the ordered set of all elements of type-specific data associated with abstract type I, .GAMMA.(x, c) denote the supertype operator relative to containment type c, which for an abstract type t returns the unique supertype of x in the type hierarchy selected by c if such a supertype exists, and the empty set otherwise, .GAMMA.(x, c) denote the nth repeated application of to x, relative to c, .DELTA.(x) denote the dependency operator, which for an event x returns the set of events upon which x depends. Subsets of G The set of active events is the set of events whose state se is of a type which derives from either the abstract type Y et=YET To HAPPEN or the abstract type Happening=HAPPENING. The set Active can be written as Active={e .epsilon.E:.E-backward.n .epsilon.N,.E-backward.t, .epsilon.Tsuch.that.GAMMA..sup.n (t.sub.e,State).epsilon.{Yet, Happening}} where State is equal to the containment type STATE and te is the type of event e. An event which is not active is called inactive. The set of inactive events is just the set complement of Active relative to E, that is Inactive=E.backslash.Active. An event upon which no event depends is called a leaf event. The set of leaf events can be written as Leaf={e.epsilon.E:e.epsilon slash.U.sub.i.epsilon.E.sub..sup..DELTA.(i) }. An active leaf event is said to be a computable event. The set of computable events can be written Computable=Active.andgate. Leaf. Propagation of Event Logic During each tick of the internal clock, all computable events are processed in random order. The following steps occur once per clock cycle, or tick, for each computable event e of event type te: ##EQU1## 2. If z=0 and .phi..sub.t.sub..sub.e exists, then let se=.phi..sub.t.sub..sub.e (e). Thus complex application logic propagates in G at the rate of at most one complex operation, or node traversal, per tick. Multiple logic paths execute in parallel. Example Embodiment FIG. 5 illustrates how one embodiment of the invention handles state transitions. This embodiment of the present invention provides a single metaphor for representing state transitions. This is accomplished by using an event model 500. The event model 500 is a set of events 501-506. Each event 501-506 in the event model 500 has an associated event type 511 and contains dependency logic that interrelates the events in the event model. An event in the event model can represent any kind of action it is defined to represent. Each event model 500 contains one or more events 501-506. An event provides a way to manipulate data that is not dependent upon the structure of the data it is manipulating. Once an event is instantiated it is referred to as an event or an event instance. Each event 501-506 represents a set of actions that are optionally contingent upon a condition. The actions and conditions that comprise an event are determine when the event is created. Event 503, for example, has a condition 532 that causes an action 533 to occur. Each event may have a different set of actions and conditions. This enables an event to represent a number of different things. For example, an event can be created that represents the users in a database. An event could also represent the number of people who chose to visit a certain web page. An event can represent anything it is defined to represent. An event can depend on past events. In one embodiment of the invention when an event is created it is called an event instance. In one embodiment of the invention an event model M.sub.c is defined by defining an event, an event type, a dependency operator, and an event state. In this embodiment event model M.sub.c represents a model for cellular automaton. An event is defined as follows: let m,n.epsilon.N, and let E be a set of m*n events. This is written as E={e.sub.11,e.sub.12, . . . ,e.sub.ln,e.sub.21, . . . ,e.sub.2n, . . . ,e.sub.ml, . . . ,e.sub.mn } Event E, for example, could represent a set of cells. Each event in the event model is associated with an abstract type called the event type 511. An event type 511 is a label supplied by the event model developer that supplies the external semantics for elements of an event metamodel. For example, in one embodiment of the invention all event types define all the event of E to be of the same event type. That is, for all x.epsilon.E, define t.sub.x =c, where c is a constant event type. An event type 511, for example, represents an abstract object type. An abstract object type is itself a typed object. Thus, the set of abstract object types represented by this entity includes meta-types, meta-meta-types, meta-meta-meta-types, and meta-k-types where k is some natural number. In one embodiment of the invention an event type 511 is created to represent more than one event in the event model 511. If an event model creates three events that carry out similar tasks, one event type 511 can represent all three event. For example, if three events are created to send out electronic mail on different days these events can share the same event type 511. In FIG. 5 events 501-506 all share the same event type 511. In one embodiment of the present invention the data that is associated with an event type is called type datum. In one embodiment of the present invention events can process data that is held in a database. For example, if a database containing user information is processed by an event called "subscription expired." The "subscription expired" event may have actions and conditions that define how it behaves. If the condition is satisfied the action is taken. For example, if the "subscription expired" event is processing the user database and it discovers a user whose subscription is expired the event will send that user a newsletter. In one embodiment of the invention each event in an event model may depend on one or more other events. When this occurs an event dependency relationship 521 is created. An event dependency relationship is represented by the dependency operator. In one embodiment of the invention a bounding function b(x,u) is defined as: ##EQU2## The dependency operator .DELTA. is the defined as: ##EQU3## The function says that if E is written as an m*n array, then each event e.sub.ij depends upon all of its neighboring elements in the array. The above set of functions can be used to create a dependency relationship for an event model that emulates a simple cellular automaton. An event dependency relationship 521 exists between an event called the dependent event and event called the prerequisite event. An event dependency relationship, for example, could be created to represent the fact that a subscription cannot expire unless a subscription first exists. To accomplish this a dependent and prerequisite event are created. Referring now to FIG. 5 for example, event 501 is a prerequisite event called "current subscribers" and event 502 is a dependent event called "subscription expired." In this example event 502 cannot occur unless event 501 first occurs. Therefore, events 501 and 502 are representative of the fact that a subscription cannot expire unless a person is first a subscriber. Event Nodes In one embodiment of the invention each event is represented as an individual node. FIG. 3 illustrates how a set of events are grouped together. One way of representing one or more events is as nodes 301-308 in a directed graph 300. A directed graph 300, sometimes called a digraph, is a non-linear data structure. In a directed graph 300 each node 301-308 can have any number of links to any other node 301-308. For example, node 303 is linked to node 302, and node 307. This enables one event to depend on other events. The event nodes 301-308 contain a list of attributes 310-314n. The number of attributes 310-314n is determined by the person creating the event. There are a variety of different things an attribute can represent, for example, an attribute could represent an internal event state 310, data specific to a particular event 311, data shared by all events having the same event type 312, a way to decide when to try to generate a new internal state 313, and a way to generate a new internal state 314. More than one attribute can be created and an attributes can represent anything the programmer defines it to represent. The events 301-308 illustrated in FIG. 3 each have an event state 310. An event state 310 is defined by the developer and varies according to the event that is created. For example, if a set of events relating to credit card authorization system is modeled, then the developer might choose to create the following event states: "authorization approved", "authorization declined", "hardware error--cannot retry", "line is busy--retry later." In one embodiment of the invention a set of possible event states S is defined as S={0,1}. The number of events neighboring e which are in state 1 is defined as W(x)=.vertline.{e.epsilon..DELTA.(x):S.sub.e =1}.vertline.. The state function is then defined as: ##EQU4## The function .phi. says that an event is in state 1 if three or more of its neighboring events are in state1. When an event is in state 1 it is considered to be "alive". If an event is in state 0 it is considered to be "dead." Thus, function .phi. corresponds to the cell transition rules for John H. Conway's game of LIFE. Defining event states in this manner in combination with the dependency operator allows the developer to represent an event model M.sub.c. In one embodiment of the present invention each event also contains data or datum associated with it. The data or datum associated with an event is called event datum. Event datum is data that is specific to a single event instance. For example, if an event is created to send an electronic mail message to the winner of an online game the following data is associated with the event: a user identification number, the user's electronic mail address, the date the message is sent, and the text that comprises the message. Typically an event datum is not shared with another event, although in some instances it may be. A type datum, on the other hand, is shared by more than one event. A type datum is associated with an abstract type and provides a way to compactly represent a set of events. This is accomplished by storing all the data shared by more than one event as type datums. In one embodiment of the present invention an event can optionally have both a trigger function and a state function. A trigger function indicates whether an event has occurred or not. It does this by taking as input the set of events and their respective states upon which the event having the trigger function depends. If an event is "triggered" the trigger function returns a value of one. If the event is "not triggered" a value of zero is returned. The trigger function expresses the event model's dependency logic. That is it expresses the model's policy of when to continue processing events and when not to. The trigger function does this by implementing a stored procedure when the event is triggered. An event does not need to have a trigger function. A state function is utilized when an event is "triggered". An event's state function returns the event state. An event is not required to have a state function either. Event Metamodel In one embodiment of the present invention an event metamodel is created. An event metamodel is a model of one or more event models. Thus, it is a model of a model. An event metamodel can be instantiated to represent a number of different event models and the corresponding dependencies that interrelate them. The event metamodel is used, for example, to describe a set of modeled events. This is accomplished by maintaining values that represent the type of events the event metamodel describes. The event metamodel enables the model creator to control what happens to each and every event in the event metamodel without having to modify the underlying structure of the database. Instead of changing the structure of the database a new data type can be created in the event model. Once this new data type is created it can immediately be used. Thus, the event metamodel provides a way to add functionality to a database and immediately make that functionality available for use. All of this is done without having to create new tables or change the relationship that exists between tables. FIG. 6 illustrates how an event metamodel 600 describes a set of modeled events 601-605. The event metamodel 600 provides a framework in which multiple event models 601-605 can be instantiated, and it contains a built-in clock mechanism that drives an instantiated event model 601-605, thus turning it into an event processor. More than one metamodel 600 can be created. Each event metamodel 600 contains a list of entities 610 that represent various attributes of the event metamodel 600. In one embodiment of the invention the list of entities 610 contains the values event_instance 611, ev_type 612, ev_datum 613, event_datum 614, ev_type_datum 615, ev_type_containment 616, event_dependency 617, and event_state 618. Each value describes a different feature of the events the event metamodel represents. All the values that begin with ev_comprise the event metamodel, although other values may be added or subtracted at any time. The event_instance 611 value represents the entire set of modeled events. The ev_type 612 value represents a set of all the abstract types each event contains. An abstract type is a label supplied by the model developer that supplies the external semantics for elements of the event metamodel. Each abstract type also has a type called the supertype, or super-1-type. Thus, the set of all abstract types contains abstract types, super-types, and super-super-types. The ev_datum 613 value represents a set of all the data each event is associated with. The event_datum 614 value represents an ordered set of all elements of event-specific data associated with an particular event. The ev_type_datum 615 value represents an ordered set of all the elements of type-specific data associated with an abstract type. The ev_type_containment 616 value represents a type containment relationship. The details of a type containment relationship are discussed below. The event_dependency 617 value represents the event dependency relationship of each event defines. For example, the event_dependency 617 value describes the set of events that another event depends on. The event_state 618 value represents a set of all the possible event states each event within the event metamodel 600 has. The event metamodel may contain additional entities other than the ones illustrated in FIG. 6. For example, entities may be added that improve the performance and maintainability of the event metamodel 600. In one embodiment of the invention the values 611-618 that comprise the list of entities 610 is stored in a database. How each value 611-618 is interrelated is illustrated in FIG. 4. The values event_instance 611, ev_type 612, ev_datum 613, event_datum 614, ev_type_datum 615, ev_type_containment 616, event_dependency 617, and event_state 618 are shown. The ev_type 612 describes one or more ev_datums 613. Thus, an ev_type 612 is the parent entity for ev_datum 613. An ev_type 612 comprises an ev_type_id 904 and a description 905. The ev_type 612 represents an abstract object type. An abstract object type is itself a typed object. Thus, the set of abstract object types represented by this entity includes meta-types, meta-meta-types, meta-meta-meta-types, and meta-k-types where k is some natural number. The ev_type_id 904 is used to uniquely identify each abstract type. In one embodiment of the invention the ev_type_id 904 functions as a primary key for the ev_type 612. The description 905 contains a name or description which uniquely identifies the ev_type. The event model internal code uses this attribute to uniquely identify object types. Description 905 is also made available to external applications for the same use. In one embodiment of the invention ev_datum 613 is described by an ev_type 612. An ev_datum 613 stores one or more ev_type_datum(s) 615. An ev_datum 613 comprises an ev_datum_id 900, datum 901, and an ev_type id/datum_type_id 902. The ev_datum value 613 represents an abstract serializable typed data object whose string representation is no longer than the length of the data type "longest_varchar". An ev_datum 613 can be associated with event instances and with other abstract type objects. The ev_datum_id 900 held in ev_datum 611 is an attribute that uniquely identifies each stored datum. The ev_datum_id 900 is the primary key for ev_datum 613. The datum 901 is a serialized string representation of a data object. Each datum 901 is representative of one abstract type and its type identifier is contained in the attribute datum_type_id 902. The ev_type-id/datum_type_id 902 uniquely identifies each abstract type. An ev_type 612 has one or more ev_type_datum(s) 615. Thus the parent entity to an ev_type_datum 615 is an ev_type 612. This makes ev_type_datum 615 a child entity. An ev_type_datum 615 is stored by ev_datum 613. Entity ev_type_datum 615 associates one or more datum(s) with an abstract type. This is useful when a group of events or types share common data. The ev_type_datum 615 contains an ev_type datum_id 906, an ev_type_id (FK) 907, and an ev_datum_id (FK) 908. In one embodiment of the invention the ev_type_datum_id 906 functions as the primary key for ev_type_datum 615 by uniquely identifying each abstract type/datum relation. The ev_type_id (FK) 907 uniquely identifies each abstract type and the ev_datum_id (FK) 908 uniquely identifies each stored datum. An ev_datum 613 stores one or more event_datum(s) 614. An event_datum 614 associates one or more datum(s) with an event instance. This is useful when an event needs to store data not shared with other events or abstract types. For example, if the administrator of a database wants to send a form-letter to user number 144332 at 10 PM tomorrow night to congratulate the user for winning an on-line computer game called fantasy baseball then the following event_datums 614 are associated with an event that sends the e-mail: userid=144332, fantasy team name, id-number of e-mail form-letter template. To represent this information each event_datum 614 comprises an event_datum_id 909, an event_id (FK) 910, and an event_datum_id (FK) 911. The event_datum_id 909 uniquely identifies each event-instance/datum relation and thus serves as the primary key for an event_datum 614. The event_id 910 uniquely identifies each event_instance and the event_datum_id (FK) 911 uniquely identifies each stored datum. Each event_datum 614 belongs to an event_instance 611. An event_instance 611 has one or more event_datum(s) 614. An event_instance 611 represents an event E of some abstract type T, or event type. An event_instance 611 can depend upon past events, and it can be a past event of zero or more events. An event_instance 611 can also have an associated trigger function or a state function, or both. Neither a trigger function or a state function is necessary. Rather, both functions are optional. The semantics of the word depend are supplied by the trigger function datum associated with abstract type T. An event trigger function is a stored procedure which takes as input the set of events upon which E depends and their respective states, and which returns a value of one or zero indicating whether the event E is triggered or not triggered. An event associated with a null trigger function datum is defined to be triggered. In one embodiment of the invention the state of an event is computed only if the event is triggered. The semantics of the word state are supplied by the state function datum associated with the abstract type, event_type_id, of E. An event state function is a stored procedure which computes an event_state and event_state_id based on the outcome of the actions it attempts to perform. An event type associated with a null state function datum is equivalent to an event type associated with no state function datum. The ordered set of actions which the state function attempts to perform supply the semantics of the event type T. An event_instance 611 is comprised of a primary key and two foreign keys. The value event_id 912 is the primary key and the values event_state_id (FK) 913 and ev_type_id/event_type_id 914 are foreign keys. An event_id 912 uniquely identifies each event_instance 611. The event_state_id (FK) uniquely identifies each event state and the ev_type_id/event_type_id 914 uniquely identifies each abstract type. Each event_instance 611 depends upon one or more event_dependency(s) 617. An event_instance 611 is also a prerequisite for each event_dependency 617. An event_dependency 617 represents the dependency relationship (DR) between an event E, called this event, and past events D1, D2, . . . , Dk where k is some natural number. Event E depends upon the past events. The semantics of the word depend are supplied by the trigger function associated with the abstract type of E. The event dependency relationship is a mesh. That is, an event can depend upon zero to many events. An event_dependency 617 is comprised of an event_id/this_event_id 915 and event_id/past_event_id 916. The event_id/this_event_id 915 and the event_id/past_event_id 916 both uniquely identify each event_instance 611. Each event_instance 617 is also described by an event_state 618. An event_state 618 is comprised of an event_state_id 917, a description 918, and a ev_state_type id.ev_type_id (FK) 919. The event_state 618 represents an abstract state of an event instance. The definition of event states is application-specific and varies according to the set of events being modeled. For example, is a set of events relating to credit card authorization is modeled then a useful set of states for these events might include the following: "Authorization approved", "Authorization declined", "Hardware error--cannot retry", "Line is busy--retry later." Trigger functions for the events which depend upon this event express the application policy of when to continue processing events dependent upon this event and when not to. The event_state_id 917 in event_state 618 uniquely identifies each event state. The description 918 contains a name which uniquely identifies this event state. The event model internal code uses description 918 to identify event states. Description 918 is also made available to external applications for the same use. The ev_state_type_id.ev_type_id (FK) 919 value uniquely identifies each abstract type. In one embodiment of the present invention a hierarchical type containment relationship is created. A type containment relationship is a framework for organizing data associated with the event metamodel. The ev_type_containment 616 value represents the type containment relationship. An ev_type_containment 616 is comprised of an ev_supertype_id.ev_type_id (FK) 920, an ev_subtype_id.ev_type_id (FK) 921 and a containment_type_id.ev_type_id(FK) 922. The ev_supertype_id.ev_type_id (FK) 920, the ev_subtype_id.ev_type_id (FK) 921 and the containment_type_id.ev_type_id(FK) 922 are all used to uniquely identify each abstract type. The ev_type_containment 616 value represents the hierarchical type inclusion relationship (HTIR) by associating some type (sometimes called a subtype) with a meta- (or super-) type. A hierarchical relationship (or ordering) was chosen over the more general mesh topology to simplify searches of the ordered set. The set of abstract object types can include meta-types, meta-meta-types, meta-meta-meta-types, and meta-(k)-types where k is some natural number. If a type is called which is not associated with a meta-type, then expressed in the notation above, this entity represents the set of relationships between meta-(k)-types and meta-(k+1)-types for all whole numbers k. Because of the artificial restriction to hierarchical ordering, there can be more than one meaningful way to order a given set of abstract types in a type containment hierarchy. For this reason a new type called a type containment relationship is created called a containment type and associated with the ordering relation. The containment type enables a given set of abstract types to be ordered in any of a finite number of hierarchies. For example, a relation HA and a relation HB can both be represented by the containment type. All of the rows in the containment type corresponding to HA would have one value for containment_type_id. All of the rows corresponding to HB would have another, different value, for containment_type_id. The application locates in ev_type the type_id of the HTIR it wants to use, and then consider only those rows that have containment_type_ids that match the type_id. The data in a type containment relationship is organized into a hierarchical tree structure. The tree structure enables the developer to organize data so that the data can represent complex relationships. The type containment tree represents data that is related to, or a subtype of other data. Referring now to FIG. 7 for example, a tree 700 is shown. The tree contains a series of nodes. Each node in the tree 700 is called a type. Every type is connected to one or more other types by a branch. The branch represents the relationship one type has with another type and is therefore called a containment type. The tree 700 represents a number of related types 701-707. Type 701 resides at the top of the tree 700. The remaining types 702-705 are subtypes of type 701. The tree 700 has two subtypes 702 and 703 branching from it. The subtypes 702 and 703 are connected by a containment type 720. Subtype 702 has two subtypes 704 and 706 branching from it these subtypes are connected to subtype 702 by another containment type. The subtypes 704 and 706 are related to subtype 702. Subtype 703 has two subtypes 705 and 707 branching from it and is connected to subtype 703 by another containment type 720. The subtypes 705 and 707 are related to subtype 703. The organization of types into tree 700 enables the developer to create a framework that is capable of representing complex relationships between different types. If type 701, for example, represents an airplane then the subtypes 702-707 represent things related to an airplane. Subtypes 702 represents the parts of an airplane, for example, and subtype 703 represent the labor needed to maintain the airplane. The parts type, subtype 702, is further broken down into different kinds of parts. Subtype 704 and 706 represent those parts. Subtype 704 represents bolts and subtype 706 represents fabric. Bolts and fabric are both parts which an airplane contains. The labor type, subtype 703, is further broken down into the people that perform labor on the airplane. Subtype 705 and 707 represents those people. Subtype 705 represents Bob and subtype 707 represents Sue. The tree 700 enables provides the developer with a way to represent and organize complex relationships between types 701-707. More than one meaning can be given to the same data. Therefore, additional trees can be made to represent additional relationships. For example, the people who perform the labor on the airplane discussed above can also work on cars, boats, or any other object the developer defines. The bolts the airplane contains can be used in other things as well. Computerized Embodiment An embodiment of the invention can be implemented as computer software in the form of computer readable program code executed on a general purpose computer such as computer 200 illustrated in FIG. 2. A keyboard 210 and mouse 211 are coupled to a bi-directional system bus 218. The keyboard and mouse are for introducing user input to the computer system and communicating that user input to processor 213. Other suitable input devices may be used in addition to, or in place of, the mouse 211 and keyboard 210. I/O (input/output) unit 219 coupled to bi-directional system bus 218 represents such I/O elements as a printer, A/V (audio/video) I/O, etc. Computer 200 includes a video memory 214, main memory 215 and mass storage 212, all coupled to bi-directional system bus 218 along with keyboard 210, mouse 211 and processor 213. The mass storage 212 may include both fixed and removable media, such as magnetic, optical or magnetic optical storage systems or any other available mass storage technology. Bus 218 may contain, for example, thirty-two address lines for addressing video memory 214 or main memory 215. The system bus 218 also includes, for example, a 32-bit data bus for transferring data between and among the components, such as processor 213, main memory 215, video memory 214 and mass storage 212. Alternatively, multiplex data/address lines may be used instead of separate data and address lines. In one embodiment of the invention, the processor 213 is a microprocessor manufactured by Motorola, such as the 680X0 processor or a microprocessor manufactured by Intel, such as the 80X86, or Pentium processor, or a SPARC.TM. microprocessor from Sun Microsystems.TM.. However, any other suitable microprocessor or microcomputer may be utilized. Main memory 215 is comprised of dynamic random access memory (DRAM). Video memory 214 is a dual-ported video random access-memory. One port of the video memory 214 is coupled to video amplifier 216. The video amplifier 216 is used to drive the cathode ray tube (CRT) raster monitor 217. Video amplifier 216 is well known in the art and may be implemented by any suitable apparatus. This circuitry converts pixel data stored in video memory 214 to a raster signal suitable for use by monitor 217. Monitor 217 is a type of monitor suitable for displaying graphic images. Computer 200 may also include a communication interface 220 coupled to bus 218. Communication interface 220 provides a two-way data communication coupling via a network link 221 to a local network 222. For example, if communication interface 220 is an integrated services digital network (ISDN) card or a modem, communication interface 220 provides a data communication connection to the corresponding type of telephone line, which comprises part of network link 221. If communication interface 220 is a local area network (LAN) card, communication interface 220 provides a data communication connection via network link 221 to a compatible LAN. Wireless links are also possible. In any such implementation, communication interface 220 sends and receives electrical, electromagnetic or optical signals which carry digital data streams representing various types of information. Network link 221 typically provides data communication through one or more networks to other data devices. For example, network link 221 may provide a connection through local network 222 to host computer 223 or to data equipment operated by an Internet Service Provider (ISP) 224. ISP 224 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 225. Local network 222 and Internet 225 both use electrical, electromagnetic or optical signals which carry digital data streams. The signals through the various networks and the signals on network link 221 and through communication interface 220, which carry the digital data to and from computer 200, are exemplary forms of carrier waves transporting the information. Computer 200 can send messages and receive data, including program code, through the network(s), network link 221, and communication interface 220. In the Internet example, server 226 might transmit a requested code for an application program through Internet 225, ISP 224, local network 222 and communication interface 220. In accord with the invention, one such downloaded application is the method and apparatus for event modeling described herein. The received code may be executed by processor 213 as it is received, and/or stored in mass storage 212, or other non-volatile storage for later execution. In this manner, computer 200 may obtain application code by way of a carrier wave. Application code may be embodied in any form of computer program product. A computer program product comprises a medium configured to store or transport computer readable code, or in which computer readable code may be embedded. Some examples of computer program products are CD-ROM disks, ROM cards, floppy disks, magnetic tapes, computer hard drives, servers on a network, and carrier waves. The computer system described above is for purposes of example only. An embodiment of the invention may be implemented in any type of computer system or programming or processing environment including, but not limited to, an embedded system. Thus, a method and apparatus for method and apparatus for event modeling has been described. 4.3 Published API 4.3.1 ev_AddDateSingletonEvent Create a new event instance of type DATE SINGLETON EVENT. A date singleton event is the special ca of an interval singleton event with an interval of 1 day. 4.3.2 ev_Add Event Datum Create a new datum and associate it with an event instance. 4.3.3 ev_AddEventDependency Create a dependency relationship between two event instances. "This event" will depend on the "past event". Or put another way, "past event" is prerequisite to and is generally evaluated before "this event". 4.3.4 ev_AddEventInstanceByTypeDesc Create a new event instance of the type specified by .COPYRGT.event_type_desc. 4.3.5 ev_AddIntervalSingletonEvent Create a new interval singleton event, or ISE. An ISE is an active event exactly one of which occurs within the given chronological interval. If .COPYRGT.event_type_desc. is specified, an event of that type is created; otherwise a generic ISE is created. Upon return, .COPYRGT.new_event_id will continue the event_id of the ISE which already existed, or which was newly-created ISE if no existing ISE was found. 4.3.6 ev.sub.13 AddTestEvents Populate the schema with some test events. 4.3.7 ev_AddTypeDatum Create a new datum and associate it with the specified type. Type level data are used to store data elements which are shared by all instances of a given type. For example, a type called `Bob's email events` might all use the same mail server. So disk space is conserved by storing this datum at the type level rather than at the event_instance level. A good Java analogue would be static class variables. 4.3.8 ev_DeleteEventInstance Delete an event instance. Rows in table event_datum corresponding to this event_id are cascade-deleted by a delete trigger on table event_instance. 4.4 Internal functions 4.4.1 ev_add_datum Add a new datum and associate it with a table specified in part by one of the arguments. 4.4.2 ev_add_event_instance Add a new event instance. 4.4.3 ev_clock_tick This is the core of the event processing subsystem. It should be run periodically. 4.4.4. ev_event_compute_state Compute and return the state of a single event. This procedure is meant to be called only by the procedure ev_update_update _event_states. 4.4.5 ev_get_evtypeid_by_desc Translate a type description into a type id. 4.4.6 ev_get_state_id_by_desc Translate a state description into a states id. 4.4.7 ev_get_type_datum Retrieve a datum directly associated with or inherited by an abstract type. Inheritance is computed relative to the given containment type. 4.4.8 ev_init_metamodel Initialize the event model and metamodel data structures. 4.4.9 ev_log Handle a log message generated by the event processor. The more positive the message level, the more toward "noise" you get. The more negative the message level, the more "urgent" you get. A null .COPYRGT.squelch_threshold means no squelching. The variables .COPYRGT.indentwidth and .COPYRGT..COPYRGT.nestlevel are both used to compute and indentation offset for the descriptive part of the log message. Set .COPYRGT.indentwidth =0 to turn off indenting. The argument .COPYRGT.indentleveldelta lets the caller adjust indentation by (additive) fractions of .COPYRGT.indentwidth. Note that for large event meshes, performance may require the use of a less computationally intensive logging function. 4.4.10 ev_sf_date_passed This event state function will indicate whether a specified date has passed. It takes a single argument, which it expects to be convertable to the datetime MS SQL datatype. 4.4.12 ev_tf_all _complete This event trigger function indicates whether all prerequisite events to .COPYRGT.dep_event_id have happened, viz. their state type id's are that of the state type HAPPENED. Note that the cursor called nextprereq retrieves the set of events upon which .COPYRGT.dep_event_id is dependent. 4.4.13 ev_tf_date_passed This event trigger function will indicate whether a specified date has passed. It takes a single argument, which it expects to be convertable to the datetime MS SQL datatype. 4.4.14 ev_update_event_states Compute and update the state of events matching certain criteria which are incorporated into a view, the name of which view is passed-in as .COPYRGT.eventset_name. 5. Example model: TheStreet free trial email 5.1 Goal As a user's free trial subscription to TheStreet.com nears expiration, send mail to encourage the user to purchase a subscription. Send email on the seventh, thirteenth and sixteenth days after the start of the free trial subscription. 5.2 Event model 5.2.1 Types We define one event type t=THE STREET FREE TRIAL EMAIL, which is a subtype of type EVENT TYPE. 5.2.2 Events A set of three events E={e.sub.1, e.sub.2, e.sub.3 } is defined the elements of which correspond respectively to the first, second and third emails to the user. All three events are of type t. 5.2.3 Event datums Three datums are defined which are associated with each element of E: ed.sub.1 which stores the userid of the user, ed.sub.2 which stores the date after which the email should be sent, and ed.sub.3 which stores which of the three email form letters to send. 5.2.4 Event states Each event of type t will exist in one of two states: s.sub.1 =HAPPENED and s.sub.2 =YET TO HAPPEN. Upon creation an event is initialized to state s.sub.1 and the event transitions to state s.sub.2 only when it succeeds in sending its email message. The state function .phi.t is defined as ##EQU5## 5.2.5 Dependency operator For i i.di-elect cons. {1,2,3} the dependency operator is defined as ##EQU6## which expresses the requirement that an email event for a given user depend on the previous email event for that user, if one exists. The trigger function T.sub.t is defined as ##EQU7## The function T.sub.t expresses the requirement that the current event will execute, or compute its own state, only if (b 1) today's date is later than the desired email send date and (2) all events prerequisite to this one have "HAPPENED". 5.3 Implementation 5.3.1 Stored procedures AddEmailByTypeDescDate Adds a "TheStreet" email event of the specified type for the specified date. A bridge date singleton event precedes the email event to reduce computation when many emails happen on a given date. Computation is simplified because until the date singleton event happens, only the date singleton is checked for computability yielding savings which are superlinear in the number of email events scheduled per day. AddStreetEmailEventsForUser Creates a set of events which will send a sequence of emails to a "TheStreet free-trial" owner prior to the expiration of the free trial. SendStreetEmailToUser Implements .phi.t for "TheStreet" email events. This procedure retrieves an email form letter corresponding to ed.sub.3, addresses it to the email address of userid ed.sub.1 and submits the addressed letter to the commerce system's outgoing mail queue.
|
Same subclass Same class Consider this |
||||||||||