http://www.eventgnosis.com/wiki/ 2010-11-14T09:34:28-05:00 http://www.eventgnosis.com/wiki/ http://www.eventgnosis.com/wiki/lib/images/favicon.ico text/html 2007-02-06T14:48:54-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:architectural_considerations&rev=1170791334&do=diff Architectural Considerations 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. text/html 2007-02-06T14:49:58-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:conclusion&rev=1170791398&do=diff Conclusion The ECS event-management architecture offers high perfomance, is pluggable and is judicious with respect to resource consumption. It will provide a solid platform for solving complex system and correction problems in the Event Management Space. text/html 2007-02-09T14:00:03-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:configuration_system&rev=1171047603&do=diff Configuration System 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. text/html 2007-02-09T14:02:30-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:debugging_system_problems&rev=1171047750&do=diff Debugging System Problems The ECS is started with an ECA which specifies its configuration. Inside this ECA are uses and specific instances of the various SourceType, DestinationType and FilterType EMML definitions. It may be easier to build, maintain & view ECA’s from the standard GUI, but knowing that this configuration file is a simple XML file allows independence from the GUI, which is valuable for isolating certain types of problems. If you are familiar with XML you can open any of the XM… text/html 2007-02-09T13:53:36-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:event_engine_architecture&rev=1171047216&do=diff Event Engine Architecture Typical event flow through the ECS is from a threaded source, through an implicit threaded adapter (which is unseen on the GUI or in the ECA, but which provides an additional event buffering layer between sources and filter stacks), into a threaded filter stack(s) to an output destination, which is threaded and able to handle communication delays with external devices because of its contained queue. text/html 2007-02-09T13:55:38-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:event_notification_and_blocking_architecture&rev=1171047338&do=diff Event Notification and Blocking Architecture Since a typical ECA contains a complex graph of interconnected event-processing SystemObjects, there are bound to be times when a receiving object cannot accept a new event. Reasons include some of the following: text/html 2007-02-09T13:54:11-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:event_queue_architecture&rev=1171047251&do=diff Event Queue Architecture Queues are intimately related to event processing and are an essential part of the architecture, since input sources and output destinations are usually asynchronous and bursty in nature. Therefore, FIFO (First-In, First-Out) queues at the front (contained by) ThreadedEventProcessors serve to smooth out bursty traffic patterns and provide event-receiving SystemObjects with a consistent workload. In fact, the relationship between sending and receiving objects is that of… text/html 2007-02-09T13:56:03-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:how_to_add_atype_definition_to_an_eca&rev=1171047363&do=diff How to Add aType Definition to an ECA To add a new type definition and its functionality to an existing ECA, edit that ECA’s xml file and add the type there. It will then be accessible through the GUI. To add a new type definition and its functionality and create a new ECA with that new type definition, add the type definition to EV_HOME/config/extra/emptyECA.xml. It will then be accessible in all new ECAs that you create with the GUI. text/html 2010-07-19T10:32:09-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:how_to_write_a_destination&rev=1279549929&do=diff How to Write a Destination Destination SystemObjects send events out of the ECS, often in an asynchronous manner due to the nature of both the ECS and the nature of the receiving protocol. Because of the unpredictable arrival of events to the destination from within the source as well as the unpredictable rate of consumption of events via the external receiver, a Destination must be threaded. This is done by specifying the right parameter for the setEventProcessor() call in the local setVars()… text/html 2007-02-09T15:14:47-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:how_to_write_a_filter&rev=1171052087&do=diff How to Write a Filter A Filter System Object is a cohesive unit of functionality that performs a well-defined task on XML events flowing through the system. Filters are chained together inside Filter Stacks to solve specific parts of application problems. These filter stacks can then be replicated, reconfigured and reused to perform similar tasks inside Event Correlation Applications (ECA’s). text/html 2007-02-09T13:49:16-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:how_to_write_a_source&rev=1171046956&do=diff How to Write a Source Source SystemObjects receive events external to the system, often in an asynchronous manner. Due to the unpredictable arrival rate of events, a source must be threaded, depending on the input parameter for the setEventProcessor() call you make in the SystemObject’s setVars() method. A source is responsible for converting a given protocol to EventGnosis’ proprietary, normalized Event format (basically a small XML document or property sheet). This document is then routed su… text/html 2007-02-06T14:54:38-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:object_taxonomy&rev=1170791678&do=diff Object Taxonomy In a running ECS, most major objects are a part of a single object hierarchy, extending the class com.eventgnosis.system.SystemObject. Specializations of SystemObject fall into one of the following four basic categories: * Event Sources: convert events from a given input protocol into an internal, proprietary EventGnosis information schema. Generally on the edge of the system, pulling events into the ECS. * Event Destinations: convert from the internal, proprietary EventG… text/html 2007-02-06T14:54:58-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:purpose_audience&rev=1170791698&do=diff Purpose/Audience The purpose of this document is to provide a quick overview of EventGnosis’ Event Correlation Server (ECS) for technical personnel, providing a foundation for development of EventGnosis System Objects. A special focus is the object hierarchy and thread architecture. text/html 2007-02-06T14:55:20-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:soap_api&rev=1170791720&do=diff SOAP API SOAP is currently a leading protocol for communicating over loosly coupled systems independent of platform hardware and operating system. Since SOAP uses generic XML over HTTP, it is platform and network topology independent, allowing firewall tunneling and avoiding typical security problems. It is also easy to decode what is flowing over the wire, should it be necessary to troubleshoot problems. text/html 2007-02-06T14:48:05-05:00 http://www.eventgnosis.com/wiki/doku.php?id=ecs_tec:technical_introduction&rev=1170791285&do=diff Developers Guide * Purpose/Audience * Object Taxonomy * Architectural Considerations * Event Engine Architecture * Event Queue Architecture * Event Notification and Blocking Architecture * How to Write a Source * How to Write a Destination * How to Write a Filter * Configuration System * How to Add aType Definition to an ECA * SOAP API * Debugging System Problems * Conclusion