As previously discussed, a running ECS is a directed graph of SystemObjects through which events flow as they are processed. The job of the ECS Configuration system is to take a static set of definitions from a set of XML files and create a running, configurable system that solves the problem at hand.

EventGnosis has defined the first specific derivative of XML specifically for the Event Management market space. It is called “EMML” (Event Management Markup Language). It conforms to XML standards, introducing specific keywords and attributes that allow the specification of ECA’s (Event Correlation Applications). A user typically will not see raw EMML files since the ECS GUI provides a much friendlier interface, shielding him from very particular EMML details.

A typical ECA consists of a set of type definitions (parameter’s, sourceType’s, destinationType’s, filterType’s), and then instances of sources, destinations, stacks and contained filters which are instances of these types, each with their own configuration.

On power-up, the ECS Configuration Manager reads the set of ECA’s specified in a file suffixed with .ecs. Currently both this ECS and ECA files are stored in the EV_HOME/config directory.
The ECS attempts to parse each ECA into a DOM document
(see com.eventgnosis.config.ConfigurationManager:initDomDocument()). If there are any validation or reference errors (possible with manual editing) the errors are logged and the ECA parsing process is aborted. Otherwise, processing proceeds by adding each type of parameter, source, destination and filter, and each instance of source, destination, filter stack and filter. This operation is somewhat order dependent because types are needed before actual instances. As each EMML type or instance is processed, it is converted to an intermediate form (com.eventgnosis.config.EmmlConfig) that can be queried by the setVar() methods of each event-processing SystemObject.

Finally, once all the types and instances are entered into their appropriate data structures and processed into a queryable form, the system is started and each SystemObject is constructed using its EMML names and types. It is specifically configured inside its setVars() method according to its specified parameter values by the passed EmmlConfig variable. The EmmlConfig object provides a convenient query interface that is used to pull the appropriate configuration parameter values into that particular SystemObject. Each configuration parameter can then be verified for correctness and applied in its local SystemObject context.

Typically, you will not have to deal with configuration details to this level of detail, and should only have to correctly utilize the EmmlConfig variable to set up your object.

Another final, behind-the-scenes feature is that of EMML variables: they have scope, are essentially associative arrays, and their individual elements can automatically expire after a preset timeout. They are ideal for holding state inside SystemObjects, ECA’s or on the ECS global level for dynamic lookups.