Package com.mindtree.techworks.insight.reporting.verifiers

Provides a framework of Verifiers to be attached to any action being executed on the LogEventModel.

See:
Description

Interface Summary

DefaultImplDeserializable	Marks a Verifier to be deserializable by the default VerifierDeserializer implementation - VerifierDeserializerImpl.
Verifier	A 'Verifier' as the name suggests is used to evaluate criterias on the filtered (or unfiltered) log event model.
VerifierDeserializer	Implementations of this class would deserialize a serialized Verifier.

Class Summary

AbstractVerifier	An abstract implementation of the Verifier interface.
VerifierDeserializerImpl	This is the default implementation of the VerifierDeserializer interface in the Verifier framework.

Exception Summary

VerifierInitializationException

An exception that indicates a failure to initialize or deserialize a Verifier.

Package com.mindtree.techworks.insight.reporting.verifiers Description

Provides a framework of Verifiers to be attached to any action being executed on the LogEventModel.

A Verifier is a monitor with a set of configurable criterions which monitors the execution of an action (usually mutating) on the LogEventModel. For more details on the structure of a Verifier, see the documentation for Verifier.

Verifiers Design.

The UML Diagram below describes the design on the Verifiers.


Click on any of the classes above to see a detailed documentation of the class.

The above diagram refers to Job and JobMessage which are used in the execution of Verifiers, but their working is explained in more detail in the documentation of the com.mindtree.techworks.insight.reporting.jobs package.

Using Verifiers

The Verifiers are unaware of any action (mutating or otherwise) in Insight. Any action which wishes to make itself verifiable has to be aware of the Verifier, it has to provide mechanisms to register Verifiers and also has to call the appropriate methods in the Verifier.

Before any action begins on the LogEventModel, the action class must call the notifyStartAction(LogEventModel) method of all Verifiers registered with it.
While processing each LogEvent, the action class should call the verify(LogEvent, FilterCriteria, boolean) method, where the boolean value would indicate the success or failure of the action on the particular LogEvent. The current implementation takes in a FilterCriteria as a parameter in this method, but this could be changed in the future if more actions are anticipated to use the Verifiers. Then a superclass of FilterCriteria may be created.
When the action class is done with processing all the LogEvents in the LogEventModel, it should call the notifyEndAction(LogEventModel) method of all the registerd Verifiers.

Trigerring Jobs

A Verifier implementation would track the progress of the action as notified by the three methods mentioned in the previous section, and would hence be aware when criterions set in them are reached. A Verifier may trigger the Job(s) associated with it immediately or might wait for the entire LogEventModel to be processed. When the Job(s) would be triggered would depend on the particular implementation of the Verifier and also the criterion(s) set in them.

Verifiers use the language of JobMessages to talk to a Job, but there might be multiple JobMessage types. A Verifier would hence have to check with the Job for all possible JobMessage types supported by the Job known to it. To avoid the situation that no such common format be available, it is required for all Verifier and Job implementations to support the DefaultJobMessage type.
See the documentation for Job for more details on invocation and execution of Jobs.

Verifier Serialization and Deserialization

Verifiers are meant to be Serializable (not java.io.Serializable), so that they can be stored and invoked later. Like FilterCriteria the serialization format used for Verifiers is XML. The details of the format are described in the class VerifierDeserializer.

Verifier implementations need to decide the fields that they need to be serialized if they are extending the AbstractVerifier. The fields need to be returned on calling the getFieldMap() method. All fields that need to be serialized have to implement the toString() method, or they can be Arrays or Collections.
Alternately, Verifiers can provide their own serialization implementation by overriding / implementing the serialize() method.

Each Verifier needs to return an instance of VerifierDeserializer that Insight would use to deserialize the Verifier. A default implementation has been provided for the same - VerifierDeserializerImpl. To be able to use the default implementation, the serialized form of the Verifier needs to have exact conformity to the format in VerifierDeserializer, and they need to implement the DefaultImplDeserializable interface.

Extending Verifiers

Someone intending to support a new type of Verifier should need to implement the Verifier interface or extend the AbstractVerifier.

The AbstractVerifier

AbstractVerifier is a class provided for easy implementation of a new Verifier. It has the following functionality (of the Verifier interface) implemented in it:

• Implements a Jobstore and the registerJob(Job) method. The jobs are made available to the extending classes as a protected field.
• Provides a serialize() implementation that generates a serialized form with full conformation to the format suggested in the VerifierDeserializer class. To use this facility, the extending classes need to implement the getFieldMap() method.
• Provides an implementation for the getDisplayName() method. This requires the extending class to set the display name in the constructor or using the setDisplayName(String) method.
• Implements the getUID() method.
• Provides a default implementation of the getDeserializer() method which returns the VerifierDeserializerImpl class instance.
• Implements the DefaultImplDeserializable interface.

Ofcourse, extending classes have the freedom to override one or more of the implementations provided here, and provide implementations of their own.

Serialization requirements of extending Verifiers

If the extending class provides for its own Serialization mechanism, it should atleast adhere to the minimum serialized form requirements specified in the documentation for the VerifierDeserializer class.
Unless the new class is providing its deserialization implementation or using a deserializer other than VerifierDeserializerImpl, it should implement the DefaultImplDeserializable interface. In this case, if it is providing its own serialization mechanism, the serialized form generated off that should exactly match the format specified in the documentation for VerifierDeserializer.

Since:

Insight 1.5

Version:

$Revision: 28 $ $Date: 2007-12-16 05:06:46 -0700 (Sun, 16 Dec 2007) $

Author:

Bindul Bhowmik

See Also:

com.mindtree.techworks.insight.reporting.jobs, com.mindtree.techworks.insight.reporting.jobs.message