5.21.13.3 Accessing Extensions Using RMI

• Accessing Extensions Using RMI (from BE Server)

• Accessing Extensions Using RMI (from FE Server)

• Tool to generate the Proxy implementation for the ExtensionAPI

Accessing Extensions Using RMI (from BE Server)

The steps to access the provisioning extensions using RMI from BE Server are as follows :

• Specify the entry of the provisioning extensions in the file ProvisioningExtensions.xml in <Web NMS Home>/conf directory. This file contains the extension name and the corresponding implementation class. A sample entry is given below.

Syntax

<Extension>

name="<Name of the Extension>"

class="<fully qualified class name>"

</Extension>

Example Entry

<Extension

name="Generic"

class="com.adventnet.nms.provisioning.ext.GenericExtension" />

• Start the Web NMS Server. The BE server on startup creates the ExtensionAPI instance, by reading the above entries.

• Get the handle of the ProvisioningAPI and call the getExtensionAPI(apiName). Please refer the topic "Accessing ProvisioningAPI" for details.

• This will return the appropriate ExtensionAPI reference through RMI.

Accessing Extensions Using RMI (from FE Server)

Any ExtensionAPI request accessed using RMI from FE Server, is routed through the proxy implementation of the FE server. The advantage of accessing the ExtensionAPI reference through the proxy implementation of the FE server, is to provide the access for the remote objects even through applets.

The steps to access the ExtensionAPI reference using RMI from FE Server are as follows :

• Specify the entry of the Extension name and the implementation class in the file ProvisioningExtensions.xml in <Web NMS Home>/conf directory. The syntax and an example entry are given above. Please note that the ProvisioningExtensions.xmlfile is read by the BE server.

• Create the proxy implementation class corresponding to the ExtensionAPI reference to be accessed, using the tool provided. The steps to create the proxy implementation class using the tool is given in "Tool to Generate the Proxy Implementation for the ExtensionAPI".

• Compile the .java file representing the proxy implementation class and set the classpath in the StartnmsFE.bat/.sh file, if the generated .java file is placed elsewhere other than <Web NMS Home>/classes directory.

• Specify the entry of the generated proxyAPI class in the ProvisioningExtensionProxies.xml file in <Web NMS Home>/conf directory. Please note that the ProvisioningExtensionProxies.xml file is read by the FE server.

• Start the Web NMS Server. The BE server on startup creates the ExtensionAPI instance by reading the entries in ProvisioningExtensions.xml. The FE server creates the proxy implementation instance of the ExtensionAPI by reading the entries in ProvisioningExtensionProxies.xml.

• Get the handle of the ProvisioningAPI and call the getExtensionAPI(apiName). Please refer to the topic "Accessing Provisioning API" to know the details of accessing Provisioning API. This will return the appropriate ExtensionAPI reference through RMI.

Tool to generate the Proxy implementation for the ExtensionAPI

In the above steps, in order to create the exact mirror image proxy implementation for the BE Server's ExtensionAPI object, a tool is provided. This tool can be accessed by invoking the ExtensionProxyGenerator.bat/sh file in <Web NMS_Home>/bin/provisioning directory, which accepts the following inputs :

• Specify the name of the proxyAPI class to be generated.

• The proxy implementation class name of the "ExtensionAPI" interface or the proxy implementation class name of the interface extended by the user written extension. If the user- written extension extends "ExtensionAPI", then the proxy implementation class name is GenericExtensionProxy.

• The user written extension "ExampleExtensionAPI", for which the proxy implementation class is to be created.

• Destination directory where the generated Proxy implementation class, corresponding to the user-written extension "ExampleExtensionAPI" needs to be placed. This is optional. If not specified, places the proxy implementation class generated under <Web NMS Home> directory.

For example, let us assume that a new extension API "ExampleExtensionAPI" is written extending the already existing interface "ExtensionAPI". The new extension API defines additional methods over "ExtensionAPI". To create the proxy implemenation class for the user-written extension "ExampleExtensionAPI" reference that extends the definitions of "ExtensionAPI", invoke the tool with the following arguments from the command prompt :

ExtensionProxyGenerator -name com.adventnet.nms.extension.ExampleExtensionProxy -extends

com.adventnet.nms.fe.provisioning.GenericExtensionProxy -implements

com.adventnet.nms.provisioning.ext.ExampleExtensionAPI

(Or)

ExtensionProxyGenerator -name com.adventnet.nms.extension.ExampleExtensionProxy -extends

com.adventnet.nms.fe.provisioning.GenericExtensionProxy -implements

com.adventnet.nms.provisioning.ext.ExampleExtensionAPI -d [c:/mydir]

Here,

• com.adventnet.nms.extension.ExampleExtensionProxy is the fully qualified name of the proxy class to be generated using the tool.

• com.adventnet.nms.fe.provisioning.GenericExtensionProxy is the proxy implementation class for the "ExtensionAPI", since the "ExampleExtensionAPI" extends "ExtensionAPI".

• com.adventnet.nms.provisioning.ext.ExampleExtensionAPI is the user-written extension, for which the proxy implementation class is to be created.

• DestDirectory [c:/mydir] is the destination directory, where the generated proxy implementation class needs to be placed. If not specified, it is placed under <Web NMS Home> directory.