The two local methods in the client management application available to component programmers are
manageFunctionInvocation() and
manageFunctionTermination().
For specified functions written in the component, the component programmers will be required to call manageFunctionInvocation() in the first line after the function declaration, and to call manageFunctionTermination() on any line immediately preceding a call to exit() or return() within the function.
manageFunctionInvocation() returns an int, which the programmers should check before proceeding. The int will tell the programmer that the function call may proceed, that an error occurred, or that the function call is not allowed to proceed. Both manage functions will probably be overloaded, but the basic C/C++ prototype will be
int manageFunctionInvocation(char * ComponentName,
char * FunctionName,
char * KeyFunctionArg);
The linkable object file provided to C/C++ programmers will provide a function with this or a similar signature, invoking a JVM using JNI_createJavaVM() (if one has not already been created). The C/C++ function will convert each char * to a String, and call the equivalent Java function. When the JVM is invoked, it spawns a thread to provide an RMI interface to the local client management application.
When manageFunctionInvocation() is called, the management client application logs the fact that the calling component function was invoked; when manageFunctionTermination() is called, the management client application logs the fact that the calling component function returned. Every so often, the management server application makes an RMI call to the management client application, telling it to send its log to the server. Alternatively, if the client log is full, the client may make an RMI call to the server to flush its log. Because the purpose of specific functions in specific components is well-known (and well-documented) the server can use the information in the logs it receives to update a status report of the system. With the use of the parameter KeyFunctionArg (or something like it, depending on the component function in question), the server can also compile usage statistics.
For example, a directory service component might report that its lookup function was invoked for John Doe; the management server application might then increment a counter displaying how often a lookup of John Doe has been performed. As another example, the management server could monitor the number of active users by keeping track of how many invocations of handleUser() (or some such function) are in progress on the appropriate component(s).
Optionally, the management server application could make an RMI call to a management client application telling it to reject certain component function invocations. For example, the server application could take the directory service component offline by telling its management client to use a specified return value on all invocations of the lookup function. Depending on which return value is used, the directory service component might shut down, or wait for a while and retry the function. As another example, the management server might take similar action towards any component(s) invoking handleUser() if the system load is too high, or if the system is shutting down.
