|
The data associated with the various modules present in Web NMS are referred to as framework data. This data is transferred from the Central to Distributed Mediation Server and vice versa as a result of client requests and response. The data that is transferred can be customized based on the user-specific requirements. The following sections explains how the customization of the framework data is possible.
The ModuleDataCustomizer interface implementation detail is provided in DataCustomization.xml located in <Central Home>/conf and <DMS Home>/conf directories respectively.
On initialization, both these servers read this configuration file to initiate customization.
The modules for which customization can be performed and the corresponding nodes in the XML file are
|
Module Name |
Node Name |
|
Event/Alert |
Event |
|
Topology |
Topology |
|
Performance |
Performance |
To customize the data
Implement the ModuleDataCustomizer
interface
both in Central server and
Distributed Mediation Server
Specify the user defined classes which implement the ModuleDataCustomizer interface in the DataCustomization.xml file at the Central Server and Distributed Mediation Server.
The Distributed Mediation Server and Central server read the DataCustomization.xml file, present in the conf directory, on initialization and identify the customization implementation class for each module.
If the DataCustomization.xml is not configured for any customization, the Central server and the Distributed Mediation Server assume that no customization is needed.
The getCustomizedData() method in ModuleDataCustomizer interface is invoked before the data is transferred to the counterpart.
The user implementation processes the data and the modified data is returned.
If the data need to be dropped, NULL should be returned.
The getCustomizedData()
method of ModuleDataCustomizer interface has the following
signature,
DataObject getCustomizedData(String moduleName, DataObject dataObject, boolean isFromDMS);
The parameters are
moduleName - This parameter gives the name of the module to which the data belong.
dataObject - This parameter contains the data that need to be processed.
isFromDMS - This parameter is to identify the source of the data. It helps in determining whether the data is coming from the Distributed Mediation Server or the Central server . The value is set to True if the data is being transferred from Distributed Mediation Server to the Central server and set to False if the data is being transferred from the Central server to the Distributed Mediation Server.
The getCustomizedData() method returns the modified Data Object. The method implementation should contain the logic for customizing the data that is to be transferred to the counterpart. The implementation of the ModuleDataCustomizer interface can be done in two ways, a single implementation for handling all modules or different implementations handling different modules. The entry in the DataCustomization.xml file present in the conf directory depends on the type of implementation and is explained as follows:
For a single implementation, there needs to be a single entry enclosed within the
<default_customizer> ..</default_customizer> tags.
At the Central server, the DataCustomization.xml file should contain the entry for the implementation for the Central server; and on the Distributed Mediation Server, the DataCustomization.xml file should contain the entry for the implementation for the Distributed Mediation Server.
Example: Let Central server customization be UserImplCentral and Distributed Mediation Server customization be UserImplDMS. In this case, the entry in the DataCustomization.xml file will be as follows:
|
Central server : <default_customizer>com.test.UserImplCentral</default_customizer>
Distributed Mediation Server : <default_customizer>com.test.UserImplDMS</default_customizer> |
For separate implementations, each module implementation will have an entry enclosed within the
<Module>
<name> ...</name>
<customizer> ...</customizer>
</Module>
Example: Let the Central server customization for handling Events and Topology be UserEventImplCentral and UserTopoImplCentral, respectively. Let the Distributed Mediation Server customization for handling Events and Topology be UserEventImplDMS and UserTopoImplDMS. In this case, the entry in the DataCustomization.xml file will be as follows:
|
Central server : <Module> <name> Event </name> <customizer> com.test.UserEventImplCentral </customizer> </Module> <Module> <name> Topology </name> <customizer> com.test.UserTopoImplCentral </customizer> </Module>
Distributed Mediation Server : <Module> <name> Event </name> <customizer> com.test.UserEventImplDMS </customizer> </Module> <Module> <name> Topology </name> <customizer> com.test.UserTopoImplDMS </customizer> </Module> |
|
|
Note: In Central Server, there is no provision to have Distributed Mediation Server-specific implementations. There can be only one implementation in the Central server for all the Distributed Mediation servers present. |
Scenario One: Data is being transferred from the Distributed Mediation Server to the Central server. The order of events is as follows:
Distributed Mediation Server
During initialization of Distributed Mediation Server, the user-defined implementation class name is read from DataCustomization.xml.
Distributed Mediation Server modules receives data either from the devices or from the database; and before transferring the data to the Central Server, the user-defined implementations is invoked.
The value of isFromDMS is true, so the user Implementation is invoked to modify the data. After the necessary customization is achieved, the modified DataObject is returned. If the data need to be dropped, NULL should be returned.
The Modified DataObject element is sent to the Central server through the Communication framework.
Central Server
During initialization of Central server, the user-defined implementation class name is read from DataCustomization.xml.
The Communication framework invokes the user implementation with the Modified DataObject element.
The value of isFromDMS is true, so the user implementation is invoked to extract the required properties and only the DataObject element which will be sent to the module(s) is returned. If the data needs to be dropped, NULL should be returned.
The module/modules analyze the data and update the data in the Central server Database if required.
Scenario Two: Data is being transferred from the Central server to the Distributed Mediation Server. The order of events is as follows:
Central server
During initialization of the Central server, the user-defined implementation class name is read from DataCustomization.xml.
Central server modules need to transfer the data to the Distributed Mediation Server through the Communication framework as DataObject elements.
The value of isFromDMS is false, so the user implementation is invoked to modify the data. After the necessary customization is achieved, the modified DataObject is returned. If the data need to be dropped, NULL should be returned.
The Modified DataObject element is sent to the Central server through the communication framework.
Distributed Mediation Server
During initialization of Distributed Mediation Server, the user-defined implementation class name is read from DataCustomization.xml.
The communication framework invokes the user implementation with the Modified DataObject element.
The value of isFromDMS is false, so the user implementation is invoked to extract the required properties and only the DataObject element which will be sent to the module(s) is returned. If the data need to be dropped, NULL should be returned.
|
Server |
Data from Distributed Mediation Server to Central Server |
Data from Central Server to Distributed Mediation Server |
|
Distributed Mediation Server |
Will convert DataObject to Modified DataObject |
Will extract DataObject from Modified DataObject |
|
Central server |
Will extract DataObject from Modified DataObject |
Will convert DataObject to Modified DataObject |
|
|
Warning:
|
|