A program can obtain a proxy for its
admin object by calling the
getAdmin operation on a communicator:
This operation returns a null proxy if the administrative facility is disabled or the application has not created the admin object with
createAdmin. The proxy returned by
getAdmin cannot be used for invoking operations because it refers to the default facet and, as we mentioned previously, the
admin object does not support a default facet. A program must first obtain a new version of the proxy that is configured with the name of a particular administrative facet before invoking operations on it. Although it cannot be used for invocations, the original proxy is still useful because it contains the endpoints of the object adapter where the admin object is hosted, and therefore the program may elect to export that proxy to a remote client.
To administer a program remotely, somehow you must obtain a proxy for the program's
admin object. There are several ways for the administrative client to accomplish this:
- Construct the proxy itself, assuming that it knows the admin object's identity, facets, and endpoints. The format of the stringified proxy is as follows:
adminId -f admin-facet:admin-endpoints
The identity, represented here by adminId, is instance-name/admin for admin objects created during communicator initialization or with
getAdmin, where instance-name is the value of the
Ice.Admin.InstanceNameproperty or a UUID if that property is not defined. (Clearly, the use of a UUID makes the proxy much more difficult for a client to construct on its own.) The name of the administrative facet is supplied as the value of the -f option, and the endpoints of the object adapter that hosts the admin object appear last in the proxy.
- Invoke an application-specific interface for retrieving the
- Use the
getServerAdminoperation on the
IceGrid::Admininterface, if the remote program was activated by IceGrid (see IceGrid Server Activation).
Having obtained the proxy, the administrative client must select a facet before invoking any operations. For example, the code below shows how to obtain the configuration properties of the remote program:
Here we used an overloaded version of
checkedCast to supply the facet name of interest (
Properties). We could have selected the facet using the proxy method
ice_facet instead, as shown below:
This code is functionally equivalent to the first example.
A remote client must also know (or be able to determine) which facets are available in the target server. Typically this information is statically configured in the client, since the client must also know the interface types of any facets that it uses. If an invocation on a facet raises
FacetNotExistException, the client may have used an incorrect facet name, or the server may have disabled the facet in question.