|
|
Any ExtensionAPI reference to be accessed by the Provisioning client using JMS is routed through the JMS Server. The advantage of accessing the ExtensionAPI reference using JMS is, the request passed from the client to the server is persistent and the data is not lost due to some unforeseen problems in the server-side. This topic explains the procedure for accessing the provisioning extensions using JMS/Session.
Accessing Extensions Using JMS/Session (from BE Server)
The steps to access the provisioning extensions using JMS/Session from BE Server are as follows :
Specify the entry of the Extension name and the class in ProvisioningExtensions.xml file in <Web NMS Home>/conf directory. This file contains the extension name and the corresponding implementation class. The syntax and an example 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" />
Create the JMS/Session stub file corresponding to the ExtensionAPI to be accessed, using the tool provided. The steps to create the JMS/Session stub file using the tool is given below.
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 to the topic "Accessing Provisioning API" to know the details of accessing Provisioning API. This will return the appropriate ExtensionAPI reference through JMS/Session.
Accessing Extensions using JMS/Session (from FE Server)
Any ExtensionAPI request accessed using JMS from a remote JVM, 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 that it provides the access for the remote objects through applets.
The steps to access the provisioning extensions using JMS/Session from FE Server are as follows :
Specify the entry of the Extension name and the class in ProvisioningExtensions.xml file in <Web NMS Home>/conf directory. The syntax and an example entry are given above. Please note that the ProvisioningExtensions.xml file 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 are explained in the topic "Accessing Extension Using RMI". Please refer to the same.
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.
Create the JMS/Session stub file corresponding to the ExtensionAPI to be accessed, using the tool provided. The steps to create the JMS/Session stub file using the tool is given in "Tool to generate the JMS/Session stub".
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 JMS/Session.
|
|
Note: Please note that the Extensions will be instantiated only once, when it is requested for the first time using ProvisioningAPI.getExtensionAPI() method. Further requests for the same Extension API, would return the same instance. |
Tool to generate the JMS/Session stub
The tool ExtensionStubGenerator.bat/.sh file provided in <Web NMS Home>/bin/provisioning directory can be invoked to generate the JMS/Session stub file corresponding to the ExtensionAPI reference to be accessed. To invoke the tool, run the ExtensionStubGenerator.bat/.sh file in <Web NMS Home>/bin/provisioning directory. The inputs to be passed to invoke the tool is as follows :
Specify the proxy implementation class of the ExtensionAPI to be accessed.
Specify the Extension Name.
Include the option -keep to retain the source file (optional)
Specify the path, where the generated JMS Message stub file needs to be placed with the -d option (optional, if not specified places the stub file under <Web NMS Home>/classes directory).
Specify the mode in which the ExtensionAPI reference is to be accessed.
This would generate and place the stub files corresponding to the ExtensionAPIs in the appropriate location.
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 stub file for the user-written extension "ExampleExtensionAPI" reference that extends the definitions of "ExtensionAPI", invoke the tool with the following arguments from the command prompt.
ExtensionStubGenerator -className com.adventnet.nms.extension.ExampleExtensionProxy -extensionName ExtensionAPI -mode JMS/Session (depending on the required mode to access the Provisioning extensions)
(Or)
ExtensionStubGenerator -className com.adventnet.nms.extension.ExampleExtensionProxy -extensionName ExtensionAPI -mode JMS/Session (depending on the required mode to access the Provisioning extensions) -d [c:/mydir]
Here,
com.adventnet.nms.extension.ExampleExtensionProxy is the fully qualified name of the proxy class, for which the stub file needs to be generated.
ExtensionAPI is the extension name, same as the one specified in ProvisioningExtensions.xml file in <Web NMS Home>/conf directory.
DestDirectory [c:/mydir] is the destination directory, where the generated stub file is placed. If not specified, by default it is placed under <Web NMS Home> directory.
Hence, for all the ExtensionAPI references to be accessed from the Web NMS client using JMS/Session, you need to generate a JMS/Session stub file using the tool provided. The same should be placed under the appropriate location.
|
|
Note: Using the tool provided, you can create JMS/Session stub files for any number of ExtensionAPI objects to be accessed from the Web NMS Client. |
|
|
