How event classes are structured
An event class defines the types of events that the cell accepts and classifies source event data for processing. For example, one class of event might be Microsoft Windows operating system events. That event class has several subclasses: application events, security events, and system events. Each event subclass represents a common type of event that occurs, such as a network logon, that contains varying data values, such as a time stamp and the name of the host on which the logon occurred. The varying data values from a source event are stored in data fields called slots (attributes). An actual event is an instance of an event class.
By using the BAROC language, you define each event class and its slots. Each slot has a data type and can have specific attributes, called facets, that can control the values that the slot can have or control aspects of the event's processing. Slot enumerations specify acceptable values for a particular slot.
You can think of a class definition as an empty form with its input fields representing slots, and a class instance as a completed form. A valid instance must respect slot types, and if some slot values are not specified, they are implicitly set to their default values, which are inherited from the parent class.
The following example illustrates the event class structure for Windows Event Log classes:
Class: EVENT
Class: MC_ADAPTER_BASE
Class: WIN_EVENTLOG
Class: WIN_EL_APPLICATION
Class: WIN_EL_SECURITY
Class: WIN_EL_SYSTEM
The following example shows the same example with some of the slots defined for these classes:
Slot: mc_client_address - Type: STRING - Flags: rkpdh - Def:
Class: EVENT
Class: MC_ADAPTER_BASE
Class: WIN_EVENTLOG
Slot: mc_tool_class - Type: STRING - Flags: rkPDh - Def: WINEventLog
Class: WIN_EL_APPLICATION
Slot: mc_tool - Type: STRING - Flags: rkPdh - Def: Application
Class: WIN_EL_SECURITY
Slot: mc_tool - Type: STRING - Flags: rkPdh - Def: Security
Class: WIN_EL_SYSTEM
Slot: mc_tool - Type: STRING - Flags: rkPdh - Def: System
In this example, a WIN_EL_APPLICATION event defines mc_tool as Application. Because WIN_EL_APPLICATION is a subclass of WIN_EVENTLOG, it inherits the mc_tool_class slot definition of WINEventLog. WIN_EL_APPLICATION also inherits mc_client_address from the CORE_EVENT class. mc_client_address contains the network address of the host of the adapter that sent the event.
By comparison, a WIN_EL_SECURITY event defines mc_tool as security; however, it inherits the same values for mc_tool_class and mc_client_address as a WIN_EL_APPLICATION event.
Event classes and their syntax are described in Event-and-data-classes.
Class inheritance
BAROC class definitions are organized in a hierarchical system where existing classes (superclasses) can be assigned subclasses so that the subclasses automatically inherit definitions from these superclasses. This behavior is called inheritance.
While a subclass inherits all the slot definitions of the superclass, it can also contain additional new slot definitions of its own, and even slot definitions that override a superclass slot definition. However, when a subclass slot overrides a superclass slot definition, it cannot have a different data type from the inherited slot, only different facet values.
Also, a rule defined for a class applies to all instances of its subclasses. For example, a rule defined for the base event class, EVENT, applies to all events because all event classes are subclasses of EVENT.
To summarize, subclasses:
- Inherit slots from superclasses
- Inherit rules from superclasses
- Can have their own slots
- Can override superclass slots (but must contain the same data type)
- Can be a subclass of only one class