XML over HTTP/S communications protocol
The protocol used by the Java API for communications between the API client and the Netcool Configuration Manager - Base presentation uses XML over HTTP/S, server starting with Netcool Configuration Manager version 6.2. One of the primary reasons for using this communication mechanism is to avoid dependencies on any particular vendor's J2EE libraries as is usually the case when using RMI.
While the underlying details are not exposed to the user and are subject to change without notice, the high level details of the current version ofNetcool Configuration Manager communications are provided here as background information:
- The client and server implementations both use a proprietary mechanism to serialize and de-serialize Java objects to and from XML format. Direct creation or use of the XML data outside of the API interface is not supported.
- The data in XML format is exchanged between the client and the server over HTTP/S. Using HTTPS requires installing a server certificate on the underlying WebSphere Application Server.
- The server side implementation includes a servlet that the API client connects to. Direct use of the servlet outside of the API interface is not supported.
- The server side acts as a proxy for client requests, de-serializing the XML data, carrying out the API calls on the server, and then serializing the return data and returning it to the client.
All the Java classes that are serialized or de-serialized by the client or server implementation must be in the CLASSPATH for that component. In particular, if you observe serialization errors from your API client application, you should check the CLASSPATH you are using for the API client runtime environment. Additional classes may be required beyond what is required to compile the Java code for your client application, since additional classes may be returned as part of the response data from the server. In general, if you are using the recommended CLASSPATH this is only likely to occur when EJBExceptions are returned as part of the embedded stack trace in the case of server side errors when performing the API call. If you wish to see the EJBException data instead of a serialization error, you will need to include a jar file in your CLASSPATH that contains EJBException. In this case, if you are running the API client from a J2EE environment, you will need to use a jar file that is compatible with your J2EE environment.