The ECS is designed for maximum throughput, plugability, and scalability. Great care was taken to create a logical, concise object hierarchy, choose efficient processing algorithms and simple interfaces to conserve system resources (memory, threads & file handles), and to be able to interact seamlessly with other systems and varied protocols across the network.
Most objects of a given classification (source, filter and destination) follow a fairly standard pattern. Occasionally, an odd exception will deviate from the “standard” implementation, but solid reference implementations for each of the System Object Categories are more usual and can be used as examples:
com.eventgnosis.sources.FromLogListener.java. Pulls lines from a log file and converts them into EventGnosis’ internal event format.com.eventgnosis.sources.XmlTCPIPSocketDestination. Pushes EventGnosis’ in XML format to an external TCP-IP socket.com.eventgnosis.filters.RoutingFilter.com.eventgnosis.filters.AddFieldFilter.com.eventgnosis.filters.CountUniqueEventsFilter.
Due to the nature of Event Management, one of the critical architectural requirements of the ECS was to seamlessly integrate synchronous and asynchronous SystemObjects, since event flows into and out of the system are both synchronous and asynchronous. For any SystemObject that handles event flow (pretty much all except for Managers) a simple, clean interface is utilized for both types of connected objects to interact. Some objects are necessarily threaded, such as sources or destinations, which interact with unpredictable event inflow/outflow rates and delays. Filter stacks are also threaded, but child filters are mostly synchronous, utilizing the parent thread to execute through the complete set of filters in the stack and into the last filter’s destination, thus saving system thread resources.