Software development was by far the least time consuming of the above tasks, since it was under the complete control of the management team. Each participating component of the distributed telephony system sends information to the management server (system administration tool) via provided stubs. Below is a description of the architecture, including all features that might have been implemented. The terms ``management client'' and ``stub'' are used interchangeably.
When a participating component is started, its first initializes a provided stub that sets up a full duplex communication link (using RMI) between that client and our server. When the component invokes a function that would alter the state of the telephony system (for example, accept_a_call(), send_a_fax(), or look_up_a_user_address()), it makes calls to the provided functions, manageFunctionInvocation() and manageFunctionTermination(). The arguments for these functions are three strings that contain information about how and why the component is modifying the system state. Hence, the management code can monitor function-level execution information regarding participating components of the distributed system.
The management functions either return immediately (and spawn a thread to communicate with the management server) or throw an exception. Which behavior they exhibit can be controlled by the management server at runtime, because the management client spawns an RMI server that exports control functions to the management server. In particular, the management server can cause the management functions to return normally, or to throw one of two exceptions, and can cause the management client to alter the size of the buffer it keeps locally (and sends when full) for the information it collects. Hence, the management code can provide function-level control of the execution of participating components of the distributed system, with little overhead being imposed on the system.
The management client and the management server communicate exclusively using RMI. This means that security can be had for free. In the latest version of Java, it is possible to specify the SocketFactory that is used by RMI implementations to create their socket connections. Third party implementations already exist, and potentially a Sun implementation will become available, of a SocketFactory that creates SSL connections. Hence, with little or no modification of management code, a new SocketFactory can be "dropped in" to a recent JDK distribution, with the effect of automatically securing all management communications, and any other system communications that rely on RMI. SSL provides integrity, confidentiality, and authentication.