United States Patent (19)
`Lawson et al.
`
`III USOO5721825A
`
`Patent Number:
`11
`45 Date of Patent:
`
`5,721,825
`Feb. 24, 1998
`
`54)
`
`75)
`
`(73)
`
`21
`22
`
`(60)
`(51)
`(52)
`58
`
`SYSTEMAND METHOD FOR GLOBAL
`EVENT NOTFCATION AND DELVERY IN
`A DISTRIBUTED COMPUTING
`ENVIRONMENT
`
`Inventors: Todd C. Lawson, Lindon; Warren D.
`Cave, Orem; Dean L. Schmidt,
`Lindon, all of Utah
`Assignee: NetVision, Inc., Orem, Utah
`
`Appl. No.: 725,393
`Filed:
`Oct. 3, 1996
`Related U.S. Application Data
`Provisional application No. 60/013,471, Mar. 15, 1996.
`Int. Cl. ......... G06F 9/44; G06F 13/38
`U.S. Cl. ................
`... 395/20033; 395/200.54
`Field of Search ......................... 395/200.33, 200.54
`
`56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`5,005,122 4/1991 Griffin et al. ...................... 395/200.33
`5,247,664 9/1993 Thompson et al. ..................... 395/610
`
`... 395/200.56
`5,341,477 8/1994 Pitkin et al. ......
`5,355,484 10/1994 Record et al. .......................... 395/704
`5,421,015 5/1995 Khoyi et al. ............................ 395/677
`5.430,875 7/1995 Ma .......................................... 395/682
`5,592,664
`1/1997 Starkey ................................... 395/601
`5,621,892 4/1997 Cook .................................. 395/200.54
`
`Primary Examiner-Krisna Lim
`Attorney, Agent, or Firmi-Workman. Nydegger & Seeley
`57
`ABSTRACT
`A system in method for global event notification in a
`distributed computer environment is presented. The system
`and method of the present invention utilizes a local event
`registry to identify local event consumers that should be
`notified when an event occurs. The system and method also
`utilizes a global event registry which identifies other servers
`which need notification when an event occurs. These other
`servers will then, in turn, notify their local event consumers
`of the event. The system and method of the present invention
`incorporates multiple levels of filtering to allow event con
`sumers to remove notification of events having little or no
`interest. The system and method of the present invention
`also ensures that duplicate event notifications are not
`received for the same event.
`
`52 Claims, 7 Drawing Sheets
`
`
`
`LOCAL
`
`REMOTE
`>. >
`
`INCOMING
`EVENT
`PROCESSING - -
`
`REDUNDANT
`EVENT
`FILTERING
`
`d
`
`C
`O
`N
`N
`E
`C
`
`O
`N
`
`GLOBAL
`REGISTRY
`
`RENOTE
`EVENT
`
`REMOTE
`EVENT
`PROCESSING
`
`LOCAL
`EVENT
`PROCESSING
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 1 of 27
`
`

`

`U.S. Patent
`
`Feb. 24, 1998
`
`Sheet 1 of 7
`
`5,721,825
`
`
`
`TWOOTTW001Z? G &=[3]
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 2 of 27
`
`

`

`U.S. Patent
`
`Feb. 24, 1998
`
`Sheet 2 of 7
`
`5,721,825
`
`0%
`
`
`
`ÅN18|03}}
`TWOOT
`
`??
`
`<??????????????????????????????????>
`
`|\}|$|0}}
`TW8010
`
`87
`
`}}
`
`=--->
`
`\\||$1938
`TWOOT
`
`%==--->
`
`$$
`
`TW001
`
`$$\\||$103|}}Š?
`
`Z?
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 3 of 27
`
`

`

`U.S. Patent
`
`Feb. 24, 1998
`
`Sheet 3 of 7
`
`5,721,825
`
`2 LL H S Co Oa Na
`
`Cld O 22 LLCO Han
`
`Co 2
`
`}|
`
`91
`
`TWOOI
`
`}}
`
`- -a
`
`99
`
`
`
`
`
`
`
`ce O 22 LL Co - Oe
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 4 of 27
`
`

`

`U.S. Patent
`
`Feb. 24, 1998
`
`Sheet 4 of 7
`
`5,721,825
`
`
`
`
`
`
`
`EVENT
`TO BE
`PROCESSE
`
`an amb die m - - -
`
`-
`
`- - - - P. r.
`
`P
`
`-
`
`op-
`
`-
`
`- - - - - -
`
`- REDUNDANT
`
`REMOVE
`EVENT
`
`
`
`84
`S EVENT
`REDUNDAN'
`
`EVENT
`;FILTERING
`
`
`
`
`
`
`
`
`
`
`
`CREATE
`NEW EVENT
`TPE
`
`REGISTER
`FOR
`EVENT
`
`
`
`EVENT
`TO BE
`QUEVED
`
`
`
`
`
`
`
`92
`
`
`
`94
`
`
`
`HAVE PROPER
`RIGHTS?
`
`HAVE PROPER
`RIGHTS?
`
`DOES
`EVENT PRODUCER
`HAVE PROPER
`RIGHTS
`
`
`
`EVENT
`ALREADY
`CRETED
`
`
`
`
`
`ALREADY
`REGISTERE
`
`CREATE EVENT
`TYPE IN GLOBAL.
`REGISTRY
`
`
`
`REGISTER FOR
`EVENT IN LOCAL
`& GLOBAL REGISTRES
`
`
`
`FIG, 4
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 5 of 27
`
`

`

`U.S. Patent
`
`Feb. 24, 1998
`
`Sheet 5 of 7
`
`5,721,825
`
`EYES,
`AVAILABLE FOR
`REMOTE
`sERYERs
`
`S EVENT
`
`REyat
`
`REDUNDANT
`EVENT
`FILTERING
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`TEAR DOWN
`CONNECTION TO
`REMOTE SERVER
`
`
`
`
`
`
`
`SEND EVENT PACKET
`TO REMOTE SERVER
`
`AL EVENTS
`RANSERE)
`
`RECEIVE EVENT PACKET
`AND SEND TO ANCOMING
`EVENT PROCESSING
`
`ALL EVENTS
`RECEYE)
`FG, 5
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 6 of 27
`
`

`

`U.S. Patent
`
`Feb. 24, 1998
`
`Sheet 6 of 7
`
`5,721,825
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`EVENT
`POLLING
`REQUEST FROM
`CONsyME
`
`TRANSFER HOLD
`EVENT PACKETS
`TO CONSUMER
`
`
`
`S.
`CONSUMER
`N QyEy;
`
`DOES
`EVENTiSEENO
`ES
`CRITERA
`
`
`
`
`
`OSCARD
`EVENT
`
`ASYNCHRONOUS
`RAFE
`
`SEND EVENT PACKET
`TO CONSUMER(S)
`
`AL EVENTS
`ANSERE
`
`POLLING
`TRANSFE
`R
`
`
`
`150
`
`OSCONNEC
`TRAFE
`ty."
`
`WRITE EVENT PACKETS
`TO EVENT STORE
`
`FIG. 6
`
`HOLD EVENT
`PACKETS) FOR
`SG
`
`YES
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 7 of 27
`
`

`

`U.S. Patent
`
`Feb. 24, 1998
`
`Sheet 7 of 7
`
`5,721,825
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 8 of 27
`
`

`

`5,721.825
`
`1
`SYSTEMAND METHOD FOR GLOBAL
`EVENT NOT FICATION AND DELVERY IN
`A DSTRIBUTE) COMPUTNG
`ENVIRONMENT
`
`10
`
`15
`
`20
`
`BACKGROUND OF THE INVENTION
`1. Related Application
`This Application claims the benefit of now abandoned
`U.S. Provisional Application Ser. No. 60/013471. entitled
`“Global Event Delivery Method," filed on Mar. 15, 1996,
`and is incorporated herein by reference.
`2. Field of the Invention
`This invention relates to event notification and distribu
`tion between computer systems, and more specifically to
`global event notification in a distributed computing
`environment, such as a computer network.
`3. Prior State of the Art
`Distributed computing environments are typically made
`up of several systems and resources. For example, Local
`Area Networks (LAN), Wide Area Networks (WAN), and
`other types of computer networks typically involve many
`computer systems connected together via physical commu
`nication links. Many networks comprise two or more inter
`25
`connected servers. User or client systems then attach to one
`or more of these servers. In addition, servers may have
`attached peripherals which are available to users of the
`network. For example, many office networks have various
`devices which are available to all users of the network, such
`as printers, fax machines, modems, and the like.
`In order to share information and resources among the
`various systems in a computer network, systems must be
`able to discover the status of other systems or devices in the
`network. For example, when a file is to be printed by a
`network printer, the file must be transferred to the server
`which is responsible for printing; typically the server physi
`cally attached to the printer. Before such a transfer takes
`place, it may be desirable to discover or ascertain the status
`of the network printer. For example, if the networkprinter is
`off-line or otherwise unavailable, there would be little ben
`efit to transferring a file to the printer for printing. As another
`example, after a file is finished printing, it may also be
`desirable to inform the user that the print job is completed.
`Thus, in a distributed computing environment there is a need
`for systems to be able to discover when certain events
`happen on other systems. Although such a mechanism was
`once accomplished by polling (requesting the status of other
`systems), today's modem architectures utilize an event noti
`fication procedure.
`In an event notification procedure, when an event occurs
`that should be known by other systems, the system where the
`event occurs sends a message to the other systems to notify
`them of the event. This notification can be called "event
`notification” and is typically accompanied by a message
`packet containing data associated with the event. In a
`computer network, systems or processes which produce
`events can be referred to as "event producers" and systems
`or processes which should be notified of the event can be
`called "event consumers.”
`When an event consumer receives notification that a
`certain event happened on an event producer, the event
`consumer can take appropriate action. In the case of one
`example given above, if the network was set up to notify a
`user when a file had finished printing, after the file had been
`printed, the server responsible for printing the file would
`generate an event notification that printing had finished. This
`
`2
`event notification would then be passed to the user to notify
`the user that printing had concluded.
`By its very nature, event notification is a local phenom
`enon. In other words, an event producer notifies event
`consumers of events which happen locally to the event
`producer. Event consumers which desire to receive notifi
`cation of certain events "register" with the event producing
`system. When an event occurs, notification is sent to all
`registered event consumers.
`Although such an event notification system provides
`many benefits and advantages, it also has many shortcom
`ings and drawbacks. For example, event notification pro
`cesses are typically single-thread execution processes. This
`means that when an event occurs, a process begins running
`on the event producing system which contacts each regis
`tered event consumer and notifies them of the event. The
`registered event consumers are contacted, one after the
`other, until all event consumers have been notified. This
`tends to create a situation where the event producing system
`is prevented from performing other tasks until all event
`consumers have been notified.
`Because a connection must be established between the
`event producer and the event consumers, a situation can
`arise where a large amount of message traffic is created on
`the computer network. Thus, it is important to minimize the
`time it takes to contact each event consumer and minimize
`the amount of message traffic generated on the network.
`Another problem with current event notification systems
`is the inability to generate global event notification. As
`previously discussed, by its very nature, event notification is
`a localized phenomenon. In other words, an event producer
`notifies all event consumers that are registered for a par
`ticular event. Thus, an event consumer that desired notifi
`cation of all events of a particular type must register for the
`event at each server. For example, consider a situation where
`a network comprises three servers, server A, server B, and
`server C. Server A and server B each have a network printer
`attached thereto. A user on server C desires to know when
`any file he prints from either printer is completed. In such a
`situation, the user must register for a print job finished type
`event at both server A and server B. Failure to register for
`events on both servers will create the possibility of missing
`a desired event. In large networks with many events of
`interest, registering for events on each and every server can
`be a time consuming and cumbersome process. It would
`therefore, be an advancement in the art to provide global
`event notification across an entire network without the need
`to register at each server.
`Another problem with prior art event notification systems
`is that events tend to be broadcast events. This results in
`sending a large number of event notifications that are of little
`or no interest to the event consumer. As previously
`described, an event producer will contact all registered event
`consumers and notify them of the event. Many events.
`however, are of little or no interest to many registered users.
`For example, suppose a system had a create object event.
`Now suppose an event consumer wished to be notified when
`a directory object on a certain system disk was created.
`Under prior art event notification systems, this event con
`sumer would register for the create object event. This would
`have the effect of not only notifying the event consumer of
`a directory object created on the particular disk of interest,
`but also of every other object created on any disk. Thus, this
`event consumer would receive many notifications that were
`of no interest. It would, therefore, be advantageous to be
`able to register only for events meeting certain criteria.
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 9 of 27
`
`

`

`5,721,825
`
`5
`
`10
`
`15
`
`3
`A still further problem with prior art notification systems
`can be identified by considering the following example.
`Many network environments contain a large database of
`shared data. Such a database can contain, for example, the
`log-in names and passwords of all users who are authorized
`to connect to the network. A wide array of other information
`may also be associated with such user account information.
`Such information can include a user's full name, an address,
`billing numbers, department, or any other type of informa
`tion. In order to allow all servers on the network to know
`which resources are available on the network, such a data
`base also often contains network device information such as
`a listing of the computer servers in the network and attached
`peripherals such as mass storage devices, printers, modems,
`and the like.
`Experience has shown that as networks grow to hundreds,
`thousands, or tens of thousands of systems and users, the
`size of such a database becomes larger than any one system
`can store and maintain. In such a situation, the database is
`often broken up and scattered among various servers in the
`network. Thus, server A may contain part 1 of the database,
`server B may contain part 2 of the database, and server C
`may contain part 3 of the database.
`Sometimes, in order to provide redundancy and prevent
`loss of the database, portions of the database are replicated
`on different systems. For example, server A may contain
`parts 1 and 3 of the database. Server B may contain parts 2
`and 1 of the database, and server C may contain parts 3 and
`2 of the database. In such a configuration, if any single
`system is lost, the remaining systems still have an entire
`copy of the database.
`While breaking the database up among systems helps to
`provide robustness and eliminates the problem of having a
`single database on one system, it also creates several prob
`lems for event notification systems. Because event notifica
`tion is a local phenomenon, if an event consumer wishes to
`be notified when a user is added to the system, the event
`consumer must be registered with enough servers to ensure
`connections to all parts of the database. This is because if the
`event consumer only registers with Server A, then in the
`example given above, the event consumer will only be
`notified if parts 1 and 3 are changed. If, in this example, part
`2 of the database was changed, then an event would not be
`generated by Server A and the event consumer would not be
`notified. Prior art systems therefore require registration with
`a plurality of servers in order to effect notification if any
`portion of the database is changed. This results in multiple
`or redundant notifications for a single event. This can be
`illustrated by the following example.
`Suppose part 1 of the database was changed. Further
`suppose that an event consumer who wished to be notified
`of changes in the database registered with Server A
`(containing parts 1 and 3 of the database) and Server B
`(containing parts 2 and 1 of the database). When Server A
`modifies part 1 of the database, Server A will send notifi
`55
`cation of this event to the event consumer registered for the
`database modification event. In order to synchronize part 1
`of the database on server A with part 1 of the database on
`server B. server A will send a message to server B so that
`server B can update its copy of part 1 of the database. When
`server B updates its part 1 of the database, however, it will
`realize that an event consumer has registered for the data
`base modification event and send notification to the event
`consumer of the modification of part 1 of the database
`located on server B. Thus, the event consumer receives two
`notifications for a single modification, one from server A and
`one from server B. It would, therefore, be advantageous to
`
`65
`
`4
`have an event notification system which could eliminate
`duplicate events so that only a single notification is sent to
`registered event consumers.
`Finally, prior art event notification systems lack certain
`functionality that is highly desirable. For example, current
`event notification systems do not provide a mechanism for
`an event producer who is also a user to trigger a customized
`event. Thus, it would be desirable to allow event producers.
`including event producers that are also users, to trigger
`custom events that can be globalized to all event consumers
`in the network.
`In addition to the ability to trigger custom events, it would
`also be desirable to provide events that are directed. As
`previously described, prior art event notification systems
`notify all registered users of a particular event. Thus, there
`is currently no mechanism to allow an event to be directed
`to a specific event consumer to the exclusion of all other
`event consumers, even though the other event consumers
`have registered for a particular event. It would be an
`advancement in the art to provide this capability.
`BRIEF SUMMARY AND OBJECTS OF THE
`INVENTION
`The foregoing problems in the prior state of the art have
`been successfully overcome by the present invention, which
`is directed to a system and method for globalizing event
`notifications in a distributed computing environment. The
`current system and method can be used with virtually any
`underlying event notification system. In one preferred
`embodiment, the present invention is designed to work in
`conjunction with current event notification systems to
`achieve the desired functionality.
`The present invention presumes an underlying event
`notification system which: (1) allows local event consumers
`to register for notification of an event; and (2) sends noti
`fication of events that occur to registered local event con
`sumers. In addition, it is desirable for some embodiments of
`the present invention to allow registration of custom event
`types. If an underlying event notification system does not
`provide the ability to register locally for an event, does not
`send even notifications to locally registered event
`consumers, or does not allow registration of custom event
`types, then this functionality can be provided as part of the
`present invention.
`The present invention achieves global event notification
`by storing a global event registry comprising a list of events
`and a corresponding list of servers which need notification
`when the corresponding event occurs. In addition to the
`global registry, each server stores a local event registry
`comprising a list of events and a corresponding list of local
`event consumers that need notification when an event
`occurs. The basic event globalization process utilized these
`two registries to globalize events as follows:
`Each server has running thereon a local event globaliza
`tion process that registers for events desired by local event
`consumers. When an event consumer registers for an event,
`the event globalization process of the event consumer's local
`server places an entry into the local event registry for the
`local server. An entry is also placed into the global event
`registry for the local server where the event consumer is
`located. Thus, the global event registry is updated to contain
`an entry identifying the server where the event consumer is
`located and the desired event and the local event registry of
`that server is updated to identify the event consumer and the
`desired event.
`When a local event globalization process receives notifi
`cation of an event that has occurred locally, the local process
`
`25
`
`30
`
`35
`
`45
`
`50
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 10 of 27
`
`

`

`5,721,825
`
`10.
`
`S
`
`25
`
`30
`
`20
`
`5
`looks in the local registry in order to identify local event
`consumers that need notification of the event. This process
`then transfers the event to any identified local event con
`sumers. In addition, the process checks the global event
`registry to identify any additional servers which also need
`notification of the event. This process then sends the event
`to the corresponding event globalization process running on
`the identified servers. These corresponding event globaliza
`tion processes, in ram, check their local event registries and
`provide the event to any event consumers identified therein.
`In this way, local events can be routed to any event consumer
`in the network without the need to register at each server.
`The present invention handles the problem of duplicate
`event notifications by utilizing an indicator field or infor
`mation field in the event. In other words, when an event
`occurs on a server because the event originated there, the
`eventis marked with an indicator identifying it as an original
`event. When an event occurs on a server because of another
`event which occurred on a different server, the event is
`marked with an indicator identifying it as a duplicate event.
`Thus, this identifier allows the event globalization process to
`distinguish between original events and duplicate events.
`Duplicate events are removed without forwarding notifica
`tion to registered event consumers or servers. This elimi
`nates the problem of receiving duplicate notifications.
`The present invention also provides for filtering mecha
`nisms that allow an event consumer to prevent notifications
`of irrelevant events. When an event occurs, several pieces of
`information will be available about the event. Filtering can
`occur on any of these pieces of information. For example, if
`a create object event is triggered whenever an object is
`created in the system, an event consumer may submit
`filtering which further restricts the type of objects that the
`event consumer is interested in receiving notification of. A
`35
`user may, for instance, submit filtering information that only
`allows the user to receive notification when directory objects
`are created.
`The present invention supports a plurality of different
`filtering options. In one option no filtering is used. Filtering
`may also be based on the target or event consumer. Such a
`filtering allows only notification of directed events. Another
`type of filtering supported by the present invention is
`location-based filtering. In this filtering mechanism, notifi
`cation is sent of events meeting a certain location criteria.
`Another type offiltering supported by the present invention
`is class-based filtering. In this type of filtering, notification
`of events affecting a certain class of objects or category of
`objects is sent. The present invention also supports attribute
`level filtering. Attribute level filtering sends notification of
`events affecting designated attributes of objects. Finally, the
`present invention implements object-based filtering. This
`level of filtering sends notification of events affecting a
`certain specific instance of an object or class. Various levels
`of filtering can be combined in any combination in order to
`limit the event notifications received to those events affect
`ing any or all of the items of interest.
`Filters on any level or type may either be inclusionary or
`exclusionary. Inclusionary filters send notification when
`events meeting the specified criteria happen. Exclusionary
`filters send notification when events occur that do not meet
`the specified criteria. In other words, exclusionary filters
`exclude notification of events meeting the specified criteria.
`Inclusionary and exclusionary filters can be combined in any
`combination in order to include or exclude certain events.
`The present invention also provides a mechanism for
`allowing a user to create a custom event type. A custom
`
`6
`event type is created by placing appropriate entries in the
`global and local event registries. In addition, an associated
`process may have to be initiated which receives the custom
`event and takes appropriate action. For example, if a user
`wished to initiate automatic running of a virus scan program
`on multiple user computers in a network, the user would
`create a launch program event type and register the event
`type in the global registry. Each of the user computers would
`then register for the launch program event type using the
`procedure previously described. One user could then initiate
`or trigger the run program event. The global event notifica
`tion process previously described would then notify each of
`the user computers that the event had occurred. A process
`running on each of the user computers would then receive
`the notification and in response run a virus scan program.
`Accordingly, it is a primary object of this invention to
`provide systems and methods for global event notification
`and distribution.
`Another primary object of the present invention is to
`provide systems and methods for global event notification
`that allow a local event consumer to receive notification of
`events without registering with each individual server in the
`network.
`Another object of the present invention is to provide
`systems and methods for global event notification and
`distribution that eliminate duplicate event notifications.
`A further important object of the present invention is to
`provide systems and methods for global event notification
`and distributions that allow a user to register and trigger a
`custom event type.
`Additional objects and advantages will be set forth in the
`description which follows, and in part will be obvious from
`the description, or may be learned by practice of the inven
`tion. The objects and advantages of the invention may be
`realized and obtained by means of the instruments and
`combinations particularly pointed out in the appended
`claims. These and other objects and features of the present
`invention will become more fully apparent from the follow
`ing description and appended claims, or may be learned by
`the practice of the invention as set forth hereinafter.
`BRIEF DESCRIPTION OF THE DRAWINGS
`In order that the manner in which the above-recited and
`other advantages and objects of the present invention are
`obtained, a more particular description of the invention
`briefly described above will be rendered by reference to a
`specific embodiment thereof which is illustrated in the
`appended drawings. Understanding that these drawings
`depict only a typical embodiment of the invention and are
`not therefore considered to be limiting of its scope, the
`invention will be described and explained with additional
`specificity and detail through the use of the accompanying
`drawings in which:
`FIG. 1 represents a network view of one embodiment of
`the present invention;
`FIG. 2 represents another network view of one embodi
`ment of the present invention;
`FIG. 3 is a data flow diagram of one embodiment of an
`event globalization process of the present invention located
`on a single server;
`FIG. 4 is a flow diagram illustrating the details of one
`embodiment of the incoming event processing block of FIG.
`3;
`FIG. S is a flow diagram illustrating the details of one
`embodiment of the remote event processing block of FIG. 3;
`
`45
`
`50
`
`55
`
`65
`
`PETITIONERS - AMERICAN/SOUTHWEST, Exhibit 1005
`Page 11 of 27
`
`

`

`5,721,825
`
`7
`FIG. 6 is a flow diagram illustrating the details of one
`embodiment of the local event processing block of FIG. 3;
`FIG. 7 is an example of how an "add user" event is
`processed in one preferred embodiment of the present inven
`tion.
`
`8
`networks. Furthermore, network 10 may be a homogenous
`network where servers 12 all utilize common networking
`means or maybe a heterogenous network where servers 12
`use a variety of networking means.
`The present invention may comprise means for storing a
`global event registry. In FIG. 1, such means is illustrated by
`global event registry 16. Global event registry 16 comprises
`a list of events and a corresponding list of servers that should
`be notified when an event occurs. Global event registry 16
`may be stored in any manner or format that is accessible by
`servers 12 in network 10. For example, if network 10 is a
`homogenous network where all servers use Novel
`NetwareTM, then global registry 16 can be stored as part of
`the Netware Network Directory Services (NDS). If,
`however, network 10 is a heterogenous network then,
`perhaps, global event registry 16 will be stored as a database
`file in a format that is accessible by all servers 12.
`Furthermore, global event registry 16 may be stored as a
`single registry or may be broken up and distributed among
`a plurality of servers. All that is required of global event
`registry 16 is that the information contained therein is
`accessible by servers 12. As explained below, the informa
`tion in global event registry 16 may also be cached locally
`on each server so that each server can gain access to desired
`information without the need to read from a global file stored
`somewhere else on the network.
`Embodiments within the scope of this invention can
`comprise means for storing a local event registry. In FIG. 1,
`such means is illustrated by local event registries 18. As
`illustrated in FIG. 1, servers 12 each have associated there
`with local event registry 18. Local event registry 18 com
`prises a list of events and a corresponding list of local event
`consumers. Thus, local event registry 18 allows a particular
`server 12 to identify which local event consumers need to be
`notified when a particular event occurs.
`A local event registry 18 is shown in FIG. 1 as being
`associated with each server 12. Typically, local event reg
`istry 18 will be stored on local program storage means
`accessible by a particular server. Thus, server A will store its
`local event registry on a local disk or other program storage
`means. Other servers will store their local event registries on
`their local storage means. Such an arrangement, however, is
`simply an implementation detail and should not be limiting
`of the scope of this invention. Other mechanisms may be
`utilized to store local event registries for each server. For
`example, local event registries may be stored on a com
`monly accessible mass storage device. Each server could
`then access its own local event registry from the common
`mass storage device.
`Although the present invention speaks in terms of a global
`event registry and a plurality of local event registries, those
`skilled in the art will recognize that the information con
`tained in the global event registry and local event registry
`may be stored in a common file or in some otherformat that
`achieves the essential functionality described in this inven
`tion. For purposes of the present invention, all that is
`important is that all servers be able to access a list of servers
`that should receive an event that occurs. Local servers
`should be able to access a list of local event consumers that
`should receive an event that occurs. By breaking down this
`information into two separate lists an advantage is achieved
`in that the server where the event occurs need not know how
`to transfer the event to a remote event consumer (an event
`consumer located at a different server). All a server needs to
`know is which servers need notification of which events.
`The individual servers are then responsible for notifying
`their local event consumers,
`
`10
`
`15
`
`O
`
`DETALED DESCRIPTION OF THE
`PREFERRED EMBODMENTS
`The following description of the present invention is
`described by using flow diagrams and data flow diagrams to
`either describe the structure or the processing of one pre
`ferred embodiment implementing the systems and methods
`of the present invention. Using the diagrams in this manner
`to present the invention should not be construed as limiting
`of its scope. The present invention contemplates both sys
`tems and methods for global event notification and delivery.
`The presently preferred embodiment of a system for global
`event notification and distribution comprises a general pur
`pose computer. The present invention, however, can also be
`used with any special purpose computer or other hardware
`system and all should be included within its scope.
`The preferred general purpose computer comprises tradi
`tional computer elements such