WO2000060455A2

WO2000060455A2 - Systems, methods and computer program products for event and action management in data processing systems using event handler intermediaries

Info

Publication number: WO2000060455A2
Application number: PCT/US2000/008509
Authority: WO
Inventors: Jack W. Curtin, Jr.; Vincent A. George; John Michael Anthony; Roger Lee Banner
Original assignee: Powerware Corporation
Priority date: 1999-04-02
Filing date: 2000-03-28
Publication date: 2000-10-12
Also published as: WO2000060455A8; WO2000060455A3; AU4183900A

Abstract

An Event Source object and an Event Listener object are identified to an Event Handler object, and a target event definition associated with the Event Listener object is provided to the Event Handler object. An event description is communicated from the Event Source object to the Event Handler object responsive to an occurrence of an event. The event description is communicated from the Event Handler object to the Event Listener object if the event description satisfies the target event definition. The Event Handler, Event Source and Event Listener objects may include objects or processes implementing respective Event Handler, Event Source and Event Listener interfaces, and the event descriptions passed among the Event Source, Event Handler and Event Listener objects preferably include Event objects that encapsulate event descriptions. The target event definition may specify, for example, an event from a specific Event Source object, a specific class of events, and/or a specific event. According to another aspect, the Event Listener object includes an Event/Action Processor object that links an event to a corresponding action.

Description

SYSTEMS, METHODS AND COMPUTER PROGRAM PRODUCTS

FOR EVENT AND ACTION MANAGEMENT IN DATA PROCESSING SYSTEMS

USING EVENT HANDLER INTERMEDIARIES

Cross-Reference to Related Application

This application is related to Application Serial No. 09/285,523 (Attorney Docket No. 9060-168) filed concurrently herewith, entitled Apparatus, Methods and Computer Program Products for Secure Distributed Data Processing Using User-Specific Service Access Managers and Propagated Security Identification to Lowery et al, assigned to the assignee of the present application, the disclosure of which is hereby incorporated herein by reference.

Field of the Invention

The present invention relates to data processing systems, methods and computer products, and more particularly, to systems, methods and computer program products for managing events and actions in a data processing systems.

Background of the Invention

Distributed computation and control are widely used in information processing systems and in such applications as power distribution, industrial control and telephone network control. As illustrated in Fig. 1, a typical distributed computing environment 100 includes a plurality of computers 110 or computer-controlled devices 120, a respective one of which executes a respective control program 130 designed according to a procedural prograrriming paradigm, e.g., a sequential series of steps performed by the computer 110 or device 120. The programs 130 typically interact with one another over communications links forming a network 150.

The increasing capability and decreasing cost of computing hardware has generally led to an increase in the demands on and complexity of software. The size and scope of software applications have generally increased and, consequently, increased interoperability is generally desirable, as interoperability can facilitate collaborative development of software applications. Typically, this means the development of standardized software elements that can ease the work involved in building and modifying applications. Standardization can also enable programmers to reuse existing code in new applications, reducing time to market. The object paradigm has become the dominant paradigm for software standardization. According to the object-oriented computing paradigm, applications are organized as collections of interacting objects. Each object typically is an encapsulated, self-contained code entity that provides one or more services upon a request received from a client, such as another object, via an "interface." An object typically is an instance of a "class," an object template that defines the data and methods of objects. The internal operations and data of the object are typically inaccessible to the requesting client apart from the "methods" defined for the object. Consequently, the internal data and operations of an object can be modified without affecting other objects. Objects typically exhibit the characteristic of "inheritance," meaning that a new object class can be created as "extensions" of an old object class, inheriting the methods and data of the old object to which new methods and data can be added. The result is a powerful, modular structure that allows for rationale segmentation of application tasks and reuse of existing code.

A distributed control application, such as a computer network management application, may include a variety of hardware and software monitoring and control functions. A typical computer network includes a variety of different hardware components, such as servers, workstations, mass storage units, hubs, routers and other communications devices, as well as uninterruptible power supplies (UPSs) and other power control elements that provide active and/or standby power to these devices. In addition to these hardware elements, the network will also typically include a variety of software elements, such as server programs accessible from client workstations and applications programs such as word processors or spreadsheets that are resident on individual workstations. Many of these software programs may be implemented in an object-oriented fashion.

Comprehensive monitoring and control of these hardware and software elements typically requires the ability to monitor events occurring around the network, as well as the ability to respond to such events with the appropriate actions. The types of events and responses needed in a network can widely vary and can change over time. Objects or processes that desire to receive notification of particular events may be instantiated or otherwise created before the object or process that monitors the event actually exists, and thus may have to wait to register to receive events. Conventional event processing techniques may not be able to provide advance registration for events, and may have fixed structures for event recognition and routing that may be difficult to reconfigure at run time. Accordingly, there is an ongoing need for flexible event and action management capabilities for networks and other data processing systems. Summary of the Invention

In light of the foregoing, it is an object of the present invention to provide systems, methods and computer program products for improved event and action management in data processing systems.

It is another object of the present invention to provide flexible systems, methods and computer program products for event and action management in data processing systems.

It is yet another object of the present invention to provide systems, methods and computer program products for event management that are compatible with distributed obj ect-oriented computing environment.

These and other objects, features and advantages are provided according to the present invention by systems, methods and computer program products in which an event description, e.g., an Event object encapsulating a description of an event, is communicated from an Event Source object to an Event Handler object, which then selectively conveys the event description to an Event Listener object based on a target event definition provided to the Event Handler object by the Event Listener object. The Event Source object, the Event Handler object and the Event Listener objects may include objects or similar computing processes that are operative to implement respective Event Source, Event Handler and Event Listener interfaces. The Event Source object preferably is configurable, e.g., is operative to receive configuration information via a method call from an Event Configuration Client, the configuration information specifying the conditions under which event descriptions are generated in response to events.

An Event Handler object can be viewed as a liaison between Event Source objects and Event Listener objects, relieving Event Source objects from having to manage listeners and associated event notification requests. A variety of target event definitions may be provided to an Event Handler object. For example, an Event Listener object may request event descriptions generated by a specific event source or an event source implementing a specific interface, as well as event descriptions associated with specific events, specific classes of events, specific events with a specified severity, or a class of events with a specified severity. The specified Event Source objects do not have to exist when the target event definition is provided to the Event Handler object. This pre-registration of Event Listener objects allows listeners to sign up for event sources and events that may exist in the future. Security constraints can be imposed such that, for example, Event Listener objects are only notified of events from Event Source objects for which they possess security rights, or only Event Source objects residing on computers listed as "trusted hosts" can send event descriptions to an Event Handler object. Event Source objects preferably are configurable, such that generation of event descriptions by the Event Source objects can be dynamically altered. According to an aspect of the present invention, the Event Listener object includes a special type of Event Listener object, an Event/ Action Processor object that is operative to link an event description to a particular action request that is supplied to an Action Server that performs the requested action. As with the Event Source object, the Event/Action Processor and Action Server objects may be configurable via method calls, thus providing a flexible, object-oriented event/action model. Events and actions handled by the Event/ Action

Processor object may be extensible; in fact, the Event/ Action Processor object need not have any detailed knowledge of the nature of the specific events, Event Source objects, actions, or Action Server objects for which it implements event/action pairings.

In particular, according to an aspect of the present invention, an Event Source object and an Event Listener object are identified to an Event Handler object, and a target event definition associated with the Event Listener object is provided to the Event Handler object, e.g., by an event notification request from the Event Listener object. An event description is communicated from the Event Source object to the Event Handler object responsive to an occurrence of an event. The event description is then communicated from Event Handler object to the Event Listener if the event description satisfies the target event definition. The Event Handler, Event Source and Event Listener objects may include objects or processes implementing respective Event Handler, Event Source and Event Listener interfaces, and the event descriptions passed among the Event Source, Event Handler and Event Listener objects preferably include Event objects that encapsulate event descriptions. In embodiments of the present invention, an Event Source object is identified to an

Event Handler object by performing a method call from the Event Source object to the Event Handler object, the method call conveying an identification for the Event Source object to the Event Handler object. An Event Listener object is identified and a target event definition provided by performing a method call from the Event Listener object to the Event Handler object, the method call conveying and identification for the Event Listener object and the target event definition. The target event definition may specify, for example, an event from a specific Event Source object, a specific class of events, and/or a specific event.

According to another aspect of the present invention, the Event Listener object includes an Event/ Action Processor object that links an event to a corresponding action. In response to receipt of an event description, the Event/ Action Processor object may communicate an action request requesting the action corresponding to the event described by the event description from the Event/ Action processor object to an Action Server object in response to communication of the event description to the Event/Action Processor object. In turn, the Action Server object may perform the requested action.

According to yet another aspect of the present invention, data processing systems are provided that include an Event Handler object that is operatively associated with an Event Source object and an Event Listener object, and is operative to selectively route event descriptions, e.g., Event objects, from the Event Source object to the Event Listener object. According to another aspect of the present invention, related computer program products are also provided.

Brief Description of the Drawings

Fig. 1 is a schematic diagram illustrating an exemplary distributed computation and control environment.

Fig. 2 is a schematic diagram illustrating an exemplary computer network in which the present invention may be implemented.

Fig. 3 is a schematic diagram illustrating an object architecture according to an embodiment of the present invention. Fig. 4 is a flow chart illustrating exemplary event processing operations for the object architecture of Fig. 3.

Figs. 5-14 are schematic diagrams illustrating exemplary object architectures and operations according to various aspects of the present invention.

Detailed Description of Embodiments

The present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

As will be appreciated by one of skill in the art, the present invention may be embodied as a method, data processing system, or computer program product. Accordingly, the present invention may take the form of hardware, software, or a combination of software and hardware. Furthermore, the present invention may take the form of a computer program product including a computer-usable storage medium having computer-usable program code means embodied in the medium. Any suitable computer readable medium may be utilized including, but not limited to, hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

Fig. 2 illustrates an exemplary distributed computing environment in which the present invention may be practiced, more particularly, a computer network 200 including a distributed plurality of computing nodes. The illustrated network includes network segments 210, linked by networking components such as hubs 220 and routers 230. The network is illustrated as including servers 240 and workstations 250, and peripheral devices such as printers 260 and mass storage devices 270. Also included in the network 200 are networked support devices such as uninterruptible power supplies 280 that provide power to devices such as servers 240, workstations 250 or other electrical devices. Generally, each of the components 220, 230, 240, 250, 260, 280 of the network 200 may be viewed as a

"computers", i.e., a locus at which computational operations may be performed. Basic operations of each of these components are well known to those skilled in the art, and need not be discussed in detail to understand the nature of the methods, apparatus and computer program products according to the present invention. It will be readily understood that the network 200 is provided as an example only, and that the methods, apparatus and computer program products according to the present invention are applicable to a variety of other computing environments and network configurations, and to a variety of other types of computer devices.

Fig. 2 also illustrates an exemplary application for the apparatus, methods and computer program products according to the present invention, namely, event and action management in a distributed computing environment such as the network 200. It may be desirable, for example, for a user to monitor events at UPSs 280 from a workstation 250 of the computer network 200, and to perform actions in response to these events at a server 240. Events associated with the UPS 280 may include events related to the status of batteries included in the UPS 280 and of AC line power supplied to the UPS, such as events relating to changes between AC and battery power mode, events relating to voltage levels of battery or AC power sources, and the like. In response to such events, it may be desirable to perform actions such as e-mailing or paging maintenance personnel via an e-mail or paging service resident at a server 240, gracefully shutting down application programs running at a server 240 or a workstation 250, or similar actions. In exemplary embodiments described herein, such event and action management may be achieved using a flexible architecture employing configurable Event source objects that generate event descriptions, that is selectively routed to Event Listener objects via Event Handler objects.

Object-Oriented Computing

It will be appreciated that the distributed control applications described herein may be described in terms of object-oriented computing architectures and processes. As is well known to those having skill in the art, object oriented programs are composed of various types of "objects". An object typically includes two parts, a data structure, also referred to as a "frame", and a set of operations or functions, also referred to as "methods", for accessing and manipulating the data structure. Objects having identical data structures and common behavior can be grouped together into, and collectively identified as a "class." Objects are typically instances created from a particular class, and typically do not exist until run-time. Classes, however, are typically fixed at build-time. Each object inherits the data structure and methods of the particular class from which it was instantiated. A hierarchical inheritance relationship exists between multiple classes. For example, one class may be considered a "parent" of another class (the "child" of the parent class). The child class is "derived" from the parent class and inherits all of the attributes and methods of the parent class. An object typically implements an interface (or protocol) that defines the manner in which data and methods of the object can be accessed by entities, e.g., other objects, outside the object. An interface defines a set of methods but does not implement them. A class that implements the interface agrees to implement all of the methods defined in the interface, thereby agreeing to certain behavior. The interface essentially renders the internal operations of the object transparent to outside entities, which allows objects to be altered without changing the object's interaction with outside entities. In a classic object-oriented environment, a first or "client" object may send request messages to a second or "server" object to invoke operations performed by the server object. Such operations may include, for example, mathematical computations, behavioral modeling, initiation of operating system procedure, or the creation of other objects. The typical request is often referred to as a "method call," i.e., a message invoking a defined method of the target object and, possibly, including parameters associated with the invoked method. Early object-oriented programming environments were typically limited to operation within a single machine, i.e., the data and methods of objects instantiated within a program space created at the machine could be accessed by other objects instantiated on the same machine, but typically could not be accessed from outside of the machine. As such, the power of object-oriented programming tended to be limited in distributed applications spread across multiple computers or other computing devices, as communications between objects in different program spaces generally could not utilize standard object communication techniques.

However, modern systems have extended the object paradigm beyond the individual computer. Distributed object computing architectures have been developed that enable objects resident on one computer of a network to access the data and methods of objects resident on other computers of the network as if they were local objects, in some cases, even if the objects on the different computers were written in different programming languages. For example, the Common Object Request Broker Architecture (CORBA) standard, a software standard maintained by the Object Management Group (OMG), defines specialized interfaces or "Object Request Brokers" (ORBs) that provide translation of an object call made by a first object at a first computer to a second object at a second computer such that, from that standpoint of the objects, the call appears as a normal "local" object call. A first ORB at the first computer translates the object call into an appropriate data stream, which is communicated between the first and second computers. A second ORB at the second computer translates the received data stream into an equivalent object call suitable for the second object. The ORBs typically are pieces of software developed to create a standardized object call interface on a specific platform. Specifications for CORBA are provided by OMG at http://www.omg.com. Similar remote object functionality is provided in other distributed component architectures, such as the Distributed Component Object Model (DCOM) described in the white paper entitled "DCOM Architecture " published by Microsoft Corporation (1998), and available at http://www.microsoft.com, and the JAVA® Remote Method Invocation (RMI) system, an extension of the JAVA® language produced by Sun Microsystems, Inc., and described in the "The Java TutoriaF maintained by Sun Microsystems at http://java.sun.com.

There are many different types of computer languages for creating object-oriented environments, such as JAVA®, Smalltalk or C++. Preferably, all or portions of the present invention are implemented in a JAVA® environment, in particular, in a distributed JAVA® environment that makes use of the Remote Method Invocation (RMI) extension to JAVA®. JAVA® is an object-oriented programming language developed by Sun Microsystems, Mountain View, California. JAVA® is a portable and architecturally neutral language. JAVA® source code is compiled into a machine-independent format that can be run on any machine with a JAVA® runtime system known as a JAVA® Virtual Machine (JVM). A JVM is implemented in a computer using platform-specific software that runs on the computer. The use of the JVM provides portability, allowing machines with diverse operating systems, including UNIX®, Windows 95®, Windows NT®, and Macintosh®, to execute the same JAVA® programs. It will be appreciated by those skilled in the art, that computer program code for creating processes that provide functional equivalents to the object architectures described herein may also be written in conventional procedural programming languages, such as the "C" programming language, or in a functional (or fourth generation) programming language such as Lisp, SML, or Forth.

Exemplary "computers" in which the present invention may be utilized may include, for example, Sun Microsystems®, Apple®, IBM®, and IBM®-compatible personal computers, servers and workstations, as well as computer-controlled peripheral devices such as disk arrays, printers and plotters, as well as computer-controlled devices such as "intelligent appliances" developed in compliance with the JAVA® standard. However, it is to be understood that various other computing devices and processors may be utilized to carry out the present invention without being limited to those enumerated herein. Exemplary operating systems within which the present invention may be utilized include, but are not limited to, UNIX®, Windows 95®, Windows 98®, and Windows NT®.

Event and Action Management in an Object-Oriented Environment

With reference to Figs. 3-14, the following discussion will describe apparatus and methods for providing secure operations in an object-oriented environment. In particular, Figs. 3-14 provide object architecture diagrams and a flow diagrams that illustrate exemplary object architectures and operations for securely managing computer operations in an object- oriented environment. The architectures and operations illustrated in Figs. 3-14 are implemented in the Talon distributed object system developed by Powerware Corporation (formerly Exide Electronics, Inc.), the assignee of the present invention. Talon is a JAVA® - based software system and architecture operative to implement monitoring and control functions for network elements such as uninterruptible power supplies (UPSs). Talon makes use of the distributed-object JAVA® RMI system that is provided by Sun Microsystems as an extension to the basis JAVA® language, as described in the aforementioned "The Java Tutorial." Talon may be used to implement a variety of monitoring and control functions, such as monitoring of software processes that may be power-dependent, generation of alarms, printouts, wireless paging and the like, as well as simulation of "what if scenarios and other functions related strategic network power management. It will be understood that although the following description is oriented to strategic network power management, systems, methods and computer program products according to the present invention are applicable to a variety of other data processing applications.

It will be understood that each block of Figs. 3-14, and combinations of blocks in these illustrations, can be implemented by computer program instructions. These computer program instructions may be provided to a processor or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the processor or other programmable data processing apparatus create means for implementing the functions specified in the block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a processor or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the functions specified in the block or blocks. The computer program instructions may also be executed by a processor or other programmable data processing apparatus to cause a series of operational steps to be performed by the processor or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the block or blocks. Accordingly, blocks of Figs. 3-14 support apparatus for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions.

Referring to Fig. 3, an exemplary object architecture 300 according to an embodiment of the present invention includes an Event Source object 310, an Event Handler object 320 and an Event Listener object 330. The Event Source object 310 is operative to identify itself to the Event Handler object 320 via an AddEventSource method call that passes an event source identification, e.g., a reference, to the Event Handler object 320. Similarly, the Event Listener object 330 is operative to provide the Event Handler object 320 with a reference and a target event definition via an AddEventListener method call. The Event Source object 310 is operative to provide the Event Handler object 320 with an event description responsive to occurrence of an event via a Notify method call. The Event Handler object 320 is operative to selectively convey the event description to the Event Listener object 330 via another Notify call, dependent on whether the event description meets the target event definition provided by the Event Listener object 330. Communication of event descriptions from the Event Source object 310 to the Event

Handler object 320 may be preceded by the Event Handler object 320 registering to receive event descriptions from the Event Source object 310, e.g., via a Register method call (not shown) that identifies the types of events for which the Event Handler object 320 desires to receive event descriptions. This registration preferably occurs in response to receipt of the target event definition from an Event Listener object 330, such that the Event Source object 310 does not provide event descriptions to the Event Handler object 320 that are not requested by Event Listener objects, thus reducing unnecessary communication of event descriptions. This registration process may be preceded by and conditioned upon a validation process wherein the Event Handler object 320 queries the Event Source object 310, e.g., via an IsNotificationAvailable method call (not shown), as to whether the Event Source object 310 is capable of providing event descriptions meeting the target event definition supplied by the Event Listener object 330.

Preferably, the Event Source object 310, the Event Handler object 320 and the Event Listener object 330 include objects that implement respective Event Source, Event Handler and Event Listener interfaces. As described above, an interface represents a protocol or agreed upon external behavior that is implemented by an object class. Thus, it will be understood that generally, in addition to implementing the Event Source, Event Handler and Event Listener interfaces above, the above-described objects may implement other functions and protocols. For example, an Event Listener object may, in addition to implementing an Event Listener interface, may also perform methods that initiate actions responsive to event descriptions provided to the Event Listener object, such as in the case of the Event/Action Processor objects described in greater detail herein.

Fig. 4 illustrates exemplary operations 400 for managing events according to an embodiment of the present invention. An Event Source object is identified to an Event Handler object (Block 410) using, for example, the AddEventSource method call illustrated in Fig. 3. An Event Listener object is also identified to the Event Handler object (Block 420), and an associated target event definition is provided to the Event Handler object (Block 430) using, for example, the AddEventListener method call illustrated in Fig. 3. An event description is communicated from the Event Source object to the Event Handler object in response to the occurrence of an event (Block 440). The event description is then passed on to the Event Listener object if the event description meets the target event definition provided to the Event Handler object (Block 450).

An advantageous feature of the object architecture and operations illustrated in Figs. 3 and 4 is that the Event Handler object is capable of "storing' event descriptions and target event definitions for subsequent use. For example, an Event Source object may be spawned when a related event-generating device or process is started. However, an Event Listener object can sign up to receive event descriptions meeting its target event definition, even if no Event Source operative to generate such event descriptions is currently online. Preferably, the Event Source object 310, the Event Handler object 320, and the Event

Listener object 330 are implemented in JAVA®, and the event description includes an Event object that is passed among the Event Source object 310, the Event Handler object 320 and the Event Listener object 330 using the object-passing capabilities of JAVA® RMI. Object passing capabilities under JAVA® RMI are known to those skilled in the art and are described in detail in the aforementioned Java Tutorial.

Using Event objects allows for the development of an Event object hierarchy to describe different types of events, such that the target event definitions supplied to Event Handler objects can use the characteristics of the Event object hierarchy to selectively return Event objects to Event Listener objects. An exemplary Event object hierarchy 500 is illustrated in Fig. 5. A base Event class 502 may include attributes or parameters that are "generic" to events, such as a time an event occurred, an event "severity" and a source identification for the Source Event object generating an instance of the Event class 502. Subclasses may extend from the generic Event class 502. For example, a Device Event subclass 510 may be defined at the head of a branch of "device" Event classes including such classes as a UPS Event class 512 and a Router Event class 516 (e.g., classes corresponding to actual physical devices), or a Communication Failure Event class 514 that represents an abstraction of multiple device functions. These classes may be further extended to such subclasses as a UPS On Battery Event class 522, a UPS Battery Low Event class 524 and a Router Overloaded Event class 526. A similar hierarchy may be applied to Event Source objects. For example, the exemplary Event Source object hierarchy 600 illustrated in Fig. 6 includes a base Event Source class 602, which may include generic attributes or parameters, such as an event source identification. Subclasses may extend from the base Event Source class 602, such as a Device Event Source class 612 or a Software Application Event Source class 614. The Event and Event Source object hierarchies provide a powerful tool for routing events. For example, a target event definition supplied to an Event Handler object by an Event Listener object may specify an event class, such as a Router Event class 516 or a UPS On Battery Event 522 class, thus commanding the Event Handler to return all Event objects meeting this class specification (which may include all subclasses extending therefrom). A target event definition may specify event descriptions generated by a specific type of event source, e.g., objects implementing a specific event source interface. Thus, an Event Handler object may return all or specific classes of Event objects generated by a particular Event Source class; for example, a target event definition may command that an Event Handler object return all Event objects generated by instances of the Device Event Source class 612 In addition, a target event definition may specify Event objects having. specific attribute or parameter values, such as all Event objects having a specific time of occurrence and/or specified level of severity. Other possible target event definitions include: any event description associated with a specific Event object class (or class derived therefrom) from any Event Source object; any event description associated with a specific Event object class (or class derived therefrom) from any Event Source object implementing a specific JAVA® interface; any event description associated with a specific Event object class (and classes derived therefrom) from a specific Event Source object; any event description associated with a specific Event object from a specific Event Source object; and any event description having a specific parameter or attribute value, such as a time of occurrence, severity or the like. It will be appreciated that a target event definition generally may combine such criteria, providing a powerful and flexible mechanism for routing Event objects from Event Source objects to Event Listener objects. Those skilled in the art also will appreciate that the object hierarchies 500 and 600 are exemplary, and that other architectures may be employed with the present invention.

Fig. 7 illustrates one example of an event management system 700 according to the present invention, as might arise in the aforementioned Talon environment. A Event Source object 310, specifically, an instance of a UPS Event Source class, is resident on a Java Virtual Machine (JVM) 711 running on a first computer 710. An Event Handler object 320 is responsive to the Event Source object 310', receiving events, e.g., UPS Event objects, therefrom. The UPS Event objects may be generated, for example, in response to actual physical events occurring in an UPS 730 operatively associated with the computer 810 and communicating with the Event Source object 310' via the operating system (not shown) and physical layer communication infrastructure (not shown) of the computer 710 and the UPS 730. Such an interface may be implemented in a number of different ways, such as by a software driver or similar mechanism. The nature of such interfaces is well known to those skilled in the art, and need not be described in further detail to understand the nature of the present invention. As illustrated, the Event Source object 310' and the Event Handler object 320 form part of a first Service Engine 712 (in Talon parlance, a "Talon Engine") that represents a conglomeration of service objects providing a particular set of registered services. An Event Listener object 330 may be resident at a second JVM 721 on a second computer 720, and may form part of a second Service Engine 722 (however, as explained below, the Event Listener object 330 need not be part of a Service Engine). The Event Listener object 330 is identified to the Event Handler object 320, to which the Event Listener object 330 has provided a target event definition. The, identification of the Event Listener object 330 and its associated target event definition preferably occurs via a method call to the Event Handler object 320, such as the AddEventListener method call described with reference to Fig. 3. Such an inter-machine method call may be accomplished, for example, through the aforementioned JAVA® RMI system, as described in detail in the aforementioned Java Tutorial. Similar distributed object communication capabilities are also provide by CORBA an DCOM.

As illustrated in Fig. 8, an Event Handler object 320 may be viewed as having a one- to-many relationship with Event Source objects 310a-c and Event Listener objects 330a-c. In this manner, the Event Handler object 320 may serve as a "middleman" between the Event Source objects 310a-c and the Event Listener objects 330a-c, receiving Event objects generated by the Event Source objects 310a-c, and selectively routing them to the Event Listener objects 330a-c based on target event definitions supplied to the Event Handler object 320 by the Event Listener objects 330a-c.

As illustrated in Fig. 9, Event Source objects 310a-c and Event Listener objects 330a- c may be distributed on different machines, and may be resident in both Service Engine and non-Service Engine environments. As shown, first and second Event Source objects 310a, 310b are operatively associated with an Event Handler object 320 which, along with a first Event Listener object 330a, form part of a first Service Engine 912 running on a first JVM 911 running on a first computer 910. The Event Handler object 320 is also operatively associated with a second Event Listener object 330b that is part of a second Service Engine 922 running on a second JVM 921 at a second computer 920. The Event Handler object 320 is also operatively associated with a third Event Listener object 330c and a third Event Source object 310c, non-Service Engine objects resident at respective third and fourth computers 930, 940.

Security may be imposed on Event Source objects and Event Listener objects. For example, as illustrated in Fig. 10, in a JVM 1010, Event Source objects 310a, 310b and Event Listener objects 330 may be associated with unique instances 320a, 320b, 320c of an Event Handler class. A respective one of the instances 320a, 320b, 320c includes a respective security identification 321a, 321b, 321c that is specific to the corresponding Event Source object 310a, 310b or Event Listener object 320c. The instances 320a, 320b, 320c also share static data 322 that is used by the Event Handler instances 320a, 320b to route Event objects. As illustrated, the Event Handler instance 320c associated with the Event Listener 320 may be destroyed once shared static data associated with the Event Listener object 330 is created and thus conveyed to the other Event Handler instances 320, 320b, which persist as long as the JVM 1010 exists.

The security identifications 321a, 321b, 321c may be used by the Event Handler objects 320a, 320b, 320c, for example, to validate transfers of Event objects via a Security Manager object 1020 using a validateSecurityAccess method call that passes a security identification and rights required to perform a Notify method. The Security Manager object 1020 may check the communicated security identification and rights against access control lists it maintains, and responsively return an indication of the whether the entity identified by the security identification has the required rights. In this manner, an Event Listener object can be prevented from gaining unauthorized access to an event description. Operations of such security-enabled object instances are described in detail in the aforementioned United States Patent Application entitled "Apparatus, Methods and Computer Program Products for Secure Distributed Data Processing Using User-Specific Service Access Managers and Propagated Security Identifications" (Attorney/Docket No. 9060-168), filed concurrently herewith and incorporated herein by reference in its entirety.

Fig. 11 illustrates yet another aspect of the present invention, namely, the ability to dynamically configure Event Source objects. For example, as illustrated, an Event Source object 310 resident at a computer 1110 and associated with a device 1130 may receive configuration information from an Event Configuration Client 340, e.g., an object or other process resident at another computer 1120. Preferably, the event configuration information includes configuration information, such as the number of times to communicate Event objects in response to a particular event, or a threshold value for triggering generation of an Event object. According to yet another aspect of the present invention, a special type of Event Listener object may be implemented that pairs a specific target event definition to one or more specific actions to be performed. As illustrated in Fig. 12, an Event/ Action Processor object 330' is an object that implements the Event Listener interface, and thus is operative to receive Event objects from an Event Handler object 320 to which it has supplied a target event definition. The Event/ Action Processor object 330' is also operative to communicate action request to an Action Server object 350, i.e., an object operative to perform the requested action in response to a received Event object. The Event/Action Processor 330' is operative to receive configuration information specifying a target event definition/action pairing from an Event/Action Client 360.

In a manner similar to an Event Source object, an Action Server object 350 may be operative to receive action configuration information from an Action Configuration Client 370, the action configuration information specifying how a particular action is performed. Preferably, the action configuration information is "dynamic" or "runtime" information that is subject to change. For example, the Action Server object 350 may include an electronic mail server that is operative to send an e-mail in response to an action request from an Event/ Action Processor 330'. Action configuration information conveyed to the Action Server object 350 by the Action Configuration Client 370 may include, for example, an e- mail address and/or a predetermined content for an email sent in response to the action request. This type of information may be distinguished, for example, from "static" configuration information associated with the Action Server object 350, such as the address of a communications port used by the Action Service object 350 to transmit an email message.

An exemplary application of an Event/ Action Processor object is illustrated in Fig. 13. A UPS Event Source object 310' resident at a computer 1310 and associated with a UPS 1360 is operatively associated with an Event Handler object 320, also resident at the computer 1310. The UPS Event Source object 310' is also operative to receive UPS event configuration information from an Event Configuration Client 340, e.g., an object at another computer 1340, and communicates Event objects to the Event Handler object 320 based on the event configuration information.

An Event/Action Processor object 330' is also operatively associated with the Event Handler object 320, receiving Event objects therefrom based on a target event definition supplied to the Event Handler object 320. The Event/ Action Processor object 330' sends action requests to a Page Action Server object 350 resident at yet another computer 1320, based on an event/action pairing supplied by an Event/ Action Client 360 at another computer 1330. The Page Action Server object 350 is operative to send a page message in response to a page action request via a Modem 1350 operatively associated with the Page Action Server 350, based on action configuration information received from a Page Action Configuration Client 370.

The exemplary embodiment of Fig. 13 demonstrates how actions may be triggered in response to events in a distributed data processing environment according to aspects of the present invention. For example, a UPS Low Battery Event class may be defined for the UPS Event Source object 310', such that an instance of this event class is generated and communicated to the Event Handler object 320 when a battery voltage of the UPS 1360 reaches a predetermined level. If the Event/ Action Processor object 330' has targeted such an event, the Event Handler object 320 conveys the generated event class instance to the Event/Action Processor object 330'. Assuming that the UPS Low Battery instance coincides with a page action request, the Event/ Action Processor object 330' communicates a page action request to the Page Action Server object 350, which initiates transmission of an appropriate paging message.

Fig. 14 illustrates exemplary operations 1400 among a client 390, i.e., and object or other process implementing functions of the Event/ Action Client 360 of Fig. 12, and an Event/ Action Processor object 330', an Event Handler object 320, and Action Server object 350 and an Event Source object 310. ListAvailableEventSources and ListAvailableAction

Servers method calls return respective references to Event Source objects and Action Servers. GetDeliverableEvents and GetExecutableActions method calls return respective types of events and actions associated with the Event Source object 310 and the Action Server object 350. Based on this returned information, the Client 390 makes a RegisterEventActions method call that provides an event/action pairing to the Event/Action Processor object 330' In response, the Event Action Processor object 330' makes an AddEventListener call to the Event Handler object 320, notifying the Event Handler object 320 of its presence and providing a target event definition based on the event/action pairings. The Event Handler object 320 makes an IsNotificationAvailable method call to the Event Source object 310 to verify that the Event source object 310 is capable of returning event descriptions meeting the target event definition. If the Event Source object 310 is capable of returning the appropriate event descriptions, the Event Handler object 320 registers for receipt of such event descriptions by performing a Register method call to the Event Source object 310. In response to the occurrence of an event, the Event Source object 310 provides an event description to the Event Handler object 320 via a Notify method call. If the event description meets the target event definition supplied to the Event Handler object 320 by the Event/Action Processor object 330', the Event Hander object 320 passes on the event description to the Event/ Action Processor object 330' via another Notify method call. In response, the Event/ Action Processor object 330' initiates one or more actions that are paired with the event description, by performing an appropriate PerformAction method call to the Action Server object 350.

Those skilled in the art will appreciate that the above-described embodiments are provided for purposes of illustration, and that the present invention is not limited to the embodiments shown. For example, numerous other object classes may be use the event/action framework illustrated. In the drawings and specification, there have been disclosed typical preferred embodiments of the invention and, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being set forth in the following claims.

Claims

THAT WHICH IS CLAIMED IS:

1. A method of managing events in a data processing system, the method comprising the steps of: identifying an Event Source object to an Event Handler object; identifying an Event Listener object to the Event Handler object; providing a target event definition associated with the Event Listener object to the

Event Handler object; communicating an event description from the Event Source object to the Event Handler object responsive to an occurrence of an event; and communicating the event description from the Event Handler object to the Event Listener object if the event description satisfies the target event definition.

2. A method according to Claim 1 : wherein the Event Handler object implements an Event Handler interface; wherein the Event Source object implements an Event Source interface; and wherein the Event Listener object implements an Event Listener interface.

3. A method according to Claim 1 , wherein said step of communicating an event description from the Event Source object is preceded by the step of registering the Event Handler object to receive event descriptions from the Event Source object, and wherein said step of communicating an event description from the Event Source object comprises the step of communicating an event description from the Event Source object if the Event Handler object has registered to receive the event description from the Event Source object.

4. A method according to Claim 3, wherein said step of registering is performed responsive to said step of providing a target event definition.

5. A method according to Claim 1, wherein said steps of identifying an Event Listener object and providing a target event definition precede said step of identifying an Event Source object.

6. A method according to Claim 1 : wherein said step of communicating an event description from the Event Source object to the Event Handler object comprises the step of communicating an Event object that encapsulates the event description; and wherein said step of communicating an event description from the Event Handler object to the Event Listener object comprises the step of communicating the Event object from the Event Handler object to the Event Listener object.

7. A method according to Claim 1 : wherein said step of identifying an Event Source object comprises the step of performing a method call from the Event Source object to the Event Handler object, the method call conveying an identification for Event Source object to the Event Handler object; and wherein said steps of identifying an Event Listener object and providing a target event definition comprise the step of performing a method call from the Event Listener object to the Event Handler object, the method call conveying and identification for the Event Listener object and the target event definition.

8. A method according to Claim 1, wherein the target event definition specifies an event from a specific Event Source object.

9. A method according to Claim 1 , wherein the target event definition specifies a specific class of events.

10. A method according to Claim 1 , wherein the target event definition specifies a specific event.

11. A method according to Claim 1 , wherein the target event definition specifies an event from an object of a specific Event Source class.

12. A method according to Claim 1 , wherein the target event definition specifies an event having specific attribute associated therewith.

13. A method according to Claim 1 , wherein said step of communicating an event description is preceded by the step of configuring the Event Source object.

14. A method according to Claim 13, wherein said step of configuring comprises the step of conveying event configuration information to the Event Source object from an Event Configuration Client, the event configuration information specifying a condition for communicating an event description from the Event Source object.

15. A method according to Claim 1, wherein the Event Source object and the Event Handler object are resident at different computers.

16. A method according to Claim 1 , wherein the Event Listener object and the Event Handler object are resident at different computers.

17. A method according to Claim 1 , wherein said step of identifying an Event object comprises the step of instantiating an instance of an Event Handler class, the instance specific to the Event Source object.

18. A method according to Claim 17 : wherein said step of identifying an Event Source object is preceded by the step of instantiating the Event Source object; wherein said step of identifying an Event Source object comprises the step of instantiating a first Event Handler object, the first Event Handler object specific to the Event Source object; wherein said steps of identifying an Event Listener object and providing a target event definition are preceded by the step of instantiating an Event Listener object; wherein said steps of identifying an Event Listener object and providing a target event definition comprise the step of instantiating a second Event Handler object specific to the Event Listener object, the second Event Handler object and the first Event Handler object sharing data that links the Event Listener object and the target event definition; wherein said step of communicating an event description from the Event Source object to the Event Handler object comprises the step of communicating the event description to the first Event Handler object; and wherein said step of communicating the event description from the Event Handler object to the Event Listener object comprises the step of communicating the event description from the first Event Handler object to the Event Listener object if the event described by the event description meets the target event definition linked to the Event Listener object in the shared data

19. A method according to Claim 17, wherein the instance of the Event Handler class specific to the Event Source object includes a security identification, and wherein at least one of said steps of communicating are conditioned upon a security validation of an entity identified by the security identification.

20. A method according to Claim 1 : wherein said step of identifying an Event Listener object comprises the step of identifying an Event/ Action Processor object that links an event to a corresponding action; wherein said step of communicating the event description from the Event Handler object to the Event Listener object comprises the step of communicating the event description the Event/ Action Processor object; and wherein said step of communicating the event description from the Event Handler object to the Event Listener object is followed by the steps of: communicating an action request requesting the action corresponding to the event described by the event description from the Event/ Action processor object to an

Action Server object in response to communication of the event description to the Event/ Action Processor object; and performing the requested action in response to communication of the action request to the Action Server object.

21. A method according to Claim 20, wherein the Action Server object implements an Action Server interface.

22. A method according to Claim 20, wherein said step of communicating an action request is preceded by the step of identifying the event and corresponding action to the Event/ Action processor.

23. A method according to Claim 22, wherein said step of identifying the event and corresponding action comprises the step of communicating information identifying the event and corresponding action to the Event/ Action Processor object from an Event/ Action Configuration Client.

24. A method according to Claim 20, wherein said step of performing the requested action is preceded by the step of configuring the Action Server object.

25. A method according to Claim 24, wherein said step of configuring comprises the step of conveying configuration information to the Action Server object from an Action Configuration Client.

26. A data processing system, comprising: an Event Handler object operative to receive event descriptions and to communicate the event descriptions based on a target event definition.

27. A system according to Claim 26, wherein said Event Handler object implements an Event Handler interface.

28. A system according to Claim 26, further comprising: an Event Listener object identified to the Event Handler object and for which the Event Handler possesses an associated target event definition, said Event Listener object operative to receive an event description from the Event Handler object, wherein said Event Handler object is operative to selectively convey an event description to the Event Listener based on the target event definition associated with the Event Listener object.

29. A system according to Claim 28, further comprising an Event Source object identified to said Event Handler object and operative to generate an event description and to communicate the event description to the Event Handler object in response to occurrence of an event, and wherein the Event Handler object is operative to selectively convey the event description to the Event Listener object based on the target event definition.

30. A system according to Claim 29: wherein the Event Source object implements an Event Source interface; and wherein the Event Listener object implements an Event Listener interface.

31. A system according to Claim 29, wherein said Event Handler object is operative to register with said Event Source object to receive event descriptions, and wherein said Event Source object is operative to communicate an event description to the Event Handler object if the Event Handler object has registered to receive the event description.

32. A system according to Claim 31, wherein said Event Handler object is operative to registering with said Event Source object responsive to receipt of a target event definition from said Event Listener object.

33. A system according to Claim 29: wherein said Event Source object is operative to communicate an Event object to the Event Handler object, the Event object encapsulating an event description; and wherein said Event Handler object is operative to communicate the Event object to the Event Listener object.

34. A system according to Claim 29: wherein said Event Source object is operative to perform a method call that conveys an identification for the Event Source object to the Event Handler object; and wherein said Event Listener object is operative to perform a method call that conveys an identification for the Event Listener object and the target event definition.

35. A system according to Claim 29, wherein the target event definition specifies at least one of an event from a specific Event Source object, an event from an object of a specific Event Source class, a specific class of events, a specific event, and an event having a specific attribute.

36. A system according to Claim 29, wherein said Event Source object is operative to receive event configuration information specifying a condition for communicating an event description from the Event Source object.

37. A system according to Claim 29, wherein the Event Source object and the Event Handler object are resident at different computers.

38. A system according to Claim 29, wherein the Event Listener object and the Event Handler object are resident at different computers.

39. A system according to Claim 29, wherein said Event Handler object comprises an instance of an Event Handler class specific to the Event Source object.

40. A system according to Claim 39: wherein said Event Handler object comprises a first Event Handler object specific to the Event Source object and a second Event Handler object specific to the.Event Listener object, the first and second Event Handler object sharing data that links the Event Listener object and the target event definition; and wherein said first Event Handler object is operative to communicate an event description to the Event Listener object if the event description meets the target event definition linked to the Event Listener object in the shared data.

41. A system according to Claim 39, wherein the instance of the Event Handler class specific to the Event Source object includes a security identification, and wherein at least one of said steps of communicating are conditioned upon a security validation of an entity identified by the security identification.

42. A system according to Claim 29, wherein said Event Listener object comprises an Event/ Action Processor object that is operative to request an action from an Action Service object in response to a received event description.

43. A system according to Claim 42, further comprising an Action Server object operative to receive an action request from the Event/ Action Processor object and operative to perform the requested action responsively thereto.

44. A system according to Claim 43, wherein the Action Server object implements an Action Server interface.

45. A system according to Claim 42, wherein said Event/ Action Processor object is operative to receive configuration information that pairs an event description to an action request.

46. A computer program product for managing events in a data processing system, the computer program product comprising: a computer-readable storage medium configured to instruct a computer to perform the steps of: identifying an Event Source object to an Event Handler object; identifying an Event Listener object to the Event Handler object; providing a target event definition associated with the Event Listener object to the Event Handler object; communicating an event description from the Event Source object to the Event Handler object responsive to an occurrence of an event; and communicating the event description from the Event Handler object to the Event Listener if the event description satisfies the target event definition.

47. A computer program product according to Claim 46: wherein the Event Handler object implements an Event Handler interface; wherein the Event Source object implements an Event Source interface; and wherein the Event Listener object implements an Event Listener interface.

48. A computer program product according to Claim 46, wherein said computer readable storage medium is configured to instruct that computer to register the Event Handler object to receive event descriptions from the Event Source object before said step of communicating an event description from the Event Source object, and wherein said step of communicating an event description from the Event Source object comprises the step of communicating an event description from the Event Source object if the Event Handler object has registered to receive the event description from the Event Source object.

49. A computer program product according to Claim 48, wherein said step of registering is performed responsive to said step of providing a target event definition.

50. A computer program product according to Claim 46, wherein said steps of identifying an Event Listener object and providing a target event definition precede said step of identifying an Event Source object.

51. A computer program product according to Claim 46: wherein said step of communicating an event description from the Event Source object to the Event Handler object comprises the step of communicating an Event object that encapsulates the event description; and wherein said step of communicating an event description from the Event Handler object to the Event Listener object comprises the step of communicating the Event object from the Event Handler object to the Event Listener object.

52. A computer program product according to Claim 46: wherein said step of identifying an Event Source object comprises the step of performing a method call from the Event Source object to the Event Handler object, the method call conveying an identification for Event Source object to the Event Handler object; and wherein said steps of identifying an Event Listener object and providing a target event definition comprise the step of performing a method call from the Event Listener object to the Event Handler object, the method call conveying and identification for the Event Listener object and the target event definition. .

53. A computer program product according to Claim 46, wherein the target event definition specifies at least one of an event from a specific Event Source object, an event from an object of a specific Event Source class, a specific class of events, a specific event, and an event having a specific attribute.

54. A computer program product according to Claim 46, wherein the Event Source object is configurable by a method call from an Event Configuration Client.

55. A computer program product according to Claim 46, wherein said computer- readable storage medium is configured to instruct a computer to instantiate an instance of an Event Handler class specific to the Event Source object

56. A computer program product according to Claim 55, wherein the instance of the Event Handler class specific to the Event Source object includes a security identification, and wherein at least one of said steps of communicating are conditioned upon a security validation of an entity identified by the security identification.

57. A computer program product according to Claim 46: wherein said step of identifying an Event Listener object comprises the step of identifying an Event/ Action Processor object that links an event to a corresponding action; wherein said step of communicating the event description from the Event Handler object to the Event Listener object comprises the step of communicating the event description the Event/Action Processor object; and wherein said computer readable storage medium is further configured to instruct the computer to perform the steps of: communicating an action request requesting the action corresponding to the event described by the event description from the Event/ Action processor object to an

Action Server object in response to communication of the event description to the Event/Action Processor object; and performing the requested action in response to communication of the action request to the Action Server object.

58. A computer program product according to Claim 57, wherein the Action Server object implements an Action Server interface.

59. A computer program product according to Claim 57, wherein the Event/ Action Processor object is configurable by a method call from an Event/Action Configuration Client.

60. A computer program product according to Claim 57, wherein the Action Server object is configurable by a method call from an Action Configuration Client.

61. A computer program product according to Claim 46, wherein the computer comprises a plurality of computers.