Electrical computers and digital processing systems: interprogra – Event handling or event notification
Reexamination Certificate
1999-05-28
2004-08-24
Bullock, Jr., Lewis A. (Department: 2126)
Electrical computers and digital processing systems: interprogra
Event handling or event notification
C719S315000
Reexamination Certificate
active
06782541
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
The present invention relates to systems for, and methods of, exchanging information between software modules. More particularly, the present invention relates to systems for, and methods, of exchanging information between software modules, wherein a brokering service is provided to manage callback interfaces between notifiers and observers.
2. Description of the Related Art
Object-oriented computer programming (“OOP”) deconstructs a high-level operation performed by a computer application into discrete modules known in the art as “objects” or “components.” Prior to OOP, computer applications typically contained program code for each task which may be executed during the application's high-level operation. However, OOP allows a computer application to contain only the program code which is minimally necessary for the operative structure or framework of the application's high-level operation. Each specific task to be performed during the computer application's high-level operation, then, is provided as a component which is itself “called” into the framework of the computer application on an as-needed basis. Component-based programming platforms known to those of ordinary skill in the art, such as Component Object Model (“COM”), distributed by Microsoft Corporation of Seattle, Wash., or Common Object Request Broker Architecture (“CORBA”), promulgated by Object Management Group of Framingham, Mass., were developed for the purpose of designing modular computer applications.
Generally, objects may be considered to be either “observers” or “notifiers” or both which commonly reside within discrete addressable locations of a computer's memory. An observer is responsible for performing some predefined operation in response to detection by a notifier of a predetermined triggering event. For example, in a telecommunications network, the observer may be an automated voicemail application which is responsible for playing a prerecorded message and recording an incoming message when an incoming telephone call is routed to voicemail. The notifier may be connected to a telephone line to detect an incoming call which is reported to the observer thus triggering the voicemail application. It is therefore desirable to provide a system for, and method of, transmitting a message from a notifier component to an observer component upon the happening of a predetermined triggering event.
One known method for an observer to be advised of the happening of a triggering event involves having the observer periodically poll the notifier to determine the status of the notifier. For example, the notifier may contain a memory flag which is in a logical “up” position when it detects an incoming call on the line and which is in a logical “down” position at all other times. Upon polling the notifier, if the observer detects that the flag is in the “up” position, it thereby detects the happening of the triggering event and initiates the automated voicemail application. According to this method, however, the observer must poll the notifier at frequent, predetermined intervals to determine the position of the flag. Such repeated polling consumes substantial operating time and can create operating problems, for example, when the notifier is removed from the system. Moreover, polling the notifier is a totally useless operation most of the time since the status of the flag does not change frequently. Thus, polling reduces overall system performance and efficiency. Accordingly, it is desirable to provide a system for, and method of, exchanging information between software modules, wherein unnecessary polling or querying of a notifier by an observer is minimized or altogether eliminated.
Another known method of notifying an observer of the happening of a triggering event is for the notifier to spontaneously transmit a message to the observer when a triggering event occurs. For example, an object-based platform, such as COM, can establish a “callback interface” between the observer and the notifier, whereby the observer has beforehand registered with the notifier the observer's interest in being notified upon the happening of a triggering event. Typically, the observer initiates the procedure of establishing the callback interface by locating the notifier, querying the notifier to determine whether the notifier is adapted to detect the happening of the triggering event which is of interest to the observer, and if so, determining if the notifier is adapted to advise the observer of the happening of the triggering event. If so, the observer registers with the notifier the observer's interest in being notified when the triggering event occurs.
Unfortunately, the process by which the callback interface is established according to known methods requires several queries and messages to be exchanged between the observer and the notifier. Moreover, an observer may not know whether, or where, a notifier resides on the server which may detect triggering events of interest to the observer. As such, an observer may operate completely ignorant of the fact that it could take advantage of the notification services of a notifier existing in the system, but fails to do so only because it is unaware of the notifier's existence. To find notifiers offering notification services of interest to the observer with which the observer desires to establish a callback interface, then, requires the observer to search the entire system looking for notifiers which monitor events of interest to the observer and to contact all notifiers in the process, many of which may not monitor events of interest to the observer. It is obvious that the search for and querying of each notifier found on the system significantly reduces overall system performance and efficiency. It is therefore desirable to provide a system for, and method of, establishing a callback interface between an observer and a notifier, wherein minimal searching and querying is required for observers to establish callback interfaces with notifiers.
To this end, a directory service is sometimes provided on a system with a look-up table containing the locations of any notifiers on the system and the class of events the notifiers respectively monitor. For example, as each notifier is created, an entry is created in the directory service look-up table for that notifier having the location of the notifier and the class of events it monitors. Rather than searching the system at large for a notifier which monitors a particular class of events, an observer, when it becomes interested in receiving notification from a notifier, consults the directory service look-up table to find those notifiers registered therein which monitor a class of events of interest to the observer. For example, upon its creation the line-monitoring notifier of the above example would register its location alongside a reference to its monitoring the unanswered status of a telephone line. The voicemail observer, then, upon consulting the directory service, would determine that the line-monitoring notifier monitors an event class of interest to it and would directly initiate a callback relationship with the line-monitoring notifier. Because the directory service points the observer directly to the notifier, the observer is not required to search the system for it, thereby improving overall system performance and efficiency. However, it is not always desirable for an observer to be pointed directly to a notifier. For example, disclosing the location of the notifier to other objects, such as the observer, may present security issues. Moreover, while a directory service reduces the searching and querying required for observers to establish callback interfaces with notifiers, observers need to poll the service to determine whether new notifiers have been created.
An event service is sometimes provided as an alternative to a directory service, whereby messaging is routed through the event service such that, as notifiers and observers are cr
Cohen Marc A.
Long John David
Avaya Technology Corp.
Bullock, Jr. Lewis A.
LandOfFree
System and method of exchanging information between software... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method of exchanging information between software..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method of exchanging information between software... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3283284