Patent Application
20080148293
Various computer hardware devices, such as PCs, printers, telephones, etc., receive various types of events, such as SNMP traps, Syslog messages, application events, etc., and act on the events in some manner. Generally, the events are received by the device on different ports, which requires a separate event receiver at each port. The events may include critical information needed by software applications running in the particular device. Particularly, various software applications within the device, such as network browsers, Microsoft Outlookâ˘, etc., may perform some function in response to the event received by the device.
The various events received by the device are typically coded or formatted in some manner, where different types of events are typically formatted in a different manner and the same type of events may also be formatted in a different manner. Therefore, the software applications must decode or parse the events to extract the information therefrom. Thus, it is necessary to provide software that is able to decode multiple events from many sources, and is extensible to decode updated or new types of events.
One solution to this problem is to only allow the particular application or device to receive events that are formatted or coded in a particular manner. However, this solution provides limitations as to the ability of the particular device to receive information from multiple sources.
Another solution to the problem is to have a plurality of event receivers in the device, where each event receiver decodes events formatted in a particular manner. For example, a particular event receiver may be responsible for only receiving and decoding SNMP traps, and then passing the decoded event to a particular software application. Therefore, each receiver is required to have its own separate decoder processor. However, providing a decoder processor in each receiver adds cost to the system. Further, there is an efficiency issue because as a particular event receiver receives a string of events, the decoding process may prevent events from being immediately passed on to the software application as a result of the time it takes to decode the events.
In another known technique, the event is immediately passed from the event receiver to the parent software application, which may store the event in a memory device. When a particular child software application of the parent software application needs the information in the event, it will access the memory, and then decode the event for its use. However, this requires that each of the various child software applications in the parent software application needs to be able to decode many different types of event formats where the decoding ability would be provided in many different child software applications. This requirement has significant implications for the maintainability and extensibility for adding future event formats to the software applications. Therefore, it would be desirable to provide a better software application for decoding events as they are received in a particular device.
Each event receiver 14 passes the event to an event driver loader 16 that is also a piece of software running in the event broker software application. Based on an unique identification (ID) number in the event that identifies its particular coding format, the event driver loader 16 will load the applicable event driver 20 from a plurality of event drivers 20 stored in a memory 18. When the system 10 is started, the event driver loader 16 generates a map of the location of each of the event drivers 20 based on the unique ID that identifies what type of event format the event drivers 20 will be able to decode. The event drivers 20 are separate pieces of software that decode a particular type of event into a common language format. Particularly, each event driver 20 formats the particular event into a particular output, generates a dictionary for the particular event using predetermined common words know to all of the software applications, and then returns a generic formatted event to the event driver loader 16. The event driver 20 knows how to extract and map the event values to the dictionary names. Therefore, the particular event will be in a format where all of the various software applications running in the system 10 will be able to use the event by extracting pertinent data from the events dictionary that was previously encoded. In this manner, the event broker 12 is extensible because it allows additional event drivers 20 to be stored in the memory 18. Also, if a particular event driver 20 needs to be upgraded, a suitable file can be downloaded to the system 10 to perform that function.
When the event driver 20 decodes all of the relevant information, it builds a dictionary by mapping well-known names to the decoded information. The dictionary is necessary because the various child software applications running in a particular parent software system may need to know that an event has been received, and the information that it contains. For example, the software system may be a network management software system that includes various types of child software applications. The event broker software would be one of the child software applications running in the parent software system. When the event broker 12 generates the dictionary for the particular event, it passes that dictionary to the parent software system. The parent software system would then notify all of the child software applications that may need to know the information in the particular event.
By decoding the information in an event to common terms in a dictionary format, each particular child software application that needs to know that information can readily access it directly through the generic event. Particularly, when the event driver 20 decodes the original event it creates the generic event and the dictionary for that event. The dictionary is attached to the generic event so that access to an events dictionary is gained by first accessing the event. Thus, all of the various software applications will know the particular meaning of the well-known names established in the dictionary. Each software application is able to access a list of well-known names from particular information that are entries in the event dictionary. For example, when a port down event is received by a software application it may want to automatically turn that port back on. The child software application can then access the events dictionary, retrieve the port number, and turn it back on.
Once the event driver 20 decodes the event, the event broker 12 transfers the generic event to an event storage system 24 in the parent software system at box 50. Additionally, the generic event can be sent to an event distribution system 26 inside the parent software system to be distributed to the many internal software modules 28 that represent the child software applications. Alternately, the event broker 12 can do both things, particularly, send the generic event to the event storage system 24 and distribute the generic event using the event distribution system 26. Therefore, the internal software modules 28 may receive the generic events immediately as they are decoded by the event broker 12, or the internal software modules 28 may later access the generic event from the data base in the event storage system 24. The internal software modules 28 can generally be software applications that need to know about the events in real time, need to know about events later after they are received, or do not need to know about the events. Therefore, the generic events are stored in the storage system 24 or distributed to the applicable software modules 28 by the event distribution center 26.
The event broker 12 offers a number of advantages. Particularly, when the event broker 12 is configured to accept a new type of event, it builds the same dictionary as the other events that were previously known by the various software applications. The internal software modules 28 don't know and don't care about the source or type of event. Further, the event broker 12 facilitates development of a software system that involves event processing. Only the event broker 12 has to be told about a new event, thus making the amount of code changes minor. Thus, the event broker 12 also allows child software modules to uniformly get potentially crucial data that was previously encoded in a format unknown to the child software modules. This sets the stage for event driven actions, that is, having events trigger actions and allowing actions to have a way to uniformly extract any pertinent data.
The foregoing discussion discloses and describes merely exemplary embodiments. One skilled in the art will readily recognize from such discussion, and from the accompanying drawings and claims, that various changes, modifications or variations can be made therein without departing from the spirit and scope of the embodiments as defined in the following claims.
