A program can obtain a proxy for its admin object by calling the getAdmin operation on a communicator:
module Ice
{
local interface Communicator
{
// ...
Object* getAdmin();
}
}
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 withgetAdmin, where instance-name is the value of theIce.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
adminobject's proxy. - Use the
getServerAdminoperation on theIceGrid::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:
std::shared_ptr<Ice::ObjectPrx> adminObj = ...;
auto propAdmin = Ice::checkedCast<PropertiesAdminPrx>(adminObj, "Properties");
auto props = propAdmin->getPropertiesForPrefix("");
Ice::ObjectPrx adminObj = ...;
Ice::PropertiesAdminPrx propAdmin = Ice::PropertiesAdminPrx::checkedCast(adminObj, "Properties");
Ice::PropertyDict props = propAdmin->getPropertiesForPrefix("");
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:
std::shared_ptr<Ice::ObjectPrx> adminObj = ...;
auto propAdmin = Ice::checkedCast<PropertiesAdminPrx>(adminObj->ice_facet("Properties"));
auto props = propAdmin->getPropertiesForPrefix("");
Ice::ObjectPrx adminObj = ...;
Ice::PropertiesAdminPrx propAdmin = Ice::PropertiesAdminPrx::checkedCast(adminObj->ice_facet("Properties"));
Ice::PropertyDict props = propAdmin->getPropertiesForPrefix("");
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.