Well-known Objects

Table 35.1. Well-known objects and their proxies.
Identity	Proxy
Object1	Object1:tcp -p 10001
Object2	Object2@TheAdapter
Object3	Object3

For Object2, the registry notices the adapter id and checks to see whether it knows about an adapter identified as TheAdapter. If it does, it attempts to obtain the endpoints of that adapter, which may cause its server to be started. If the registry is successfully able to determine the adapter’s endpoints, it returns a direct proxy containing those endpoints to the client. If the registry does not recognize TheAdapter or cannot obtain its endpoints, it returns the indirect proxy Object2@TheAdapter to the client. Upon receipt of another indirect proxy, the Ice run time in the client will try once more to resolve the proxy, but generally this will not succeed and the Ice run time in the client will raise a NoEndpointException as a result.

Finally, Object3 represents a hopeless situation: how can the registry resolve Object3 when its associated proxy refers to itself? In this case, the registry returns the proxy Object3 to the client, which causes the client to raise NoEndpointException. Clearly, you should avoid this situation.

35.6.1 Object Types

The registry’s database not only associates an identity with a proxy, but also a type. Technically, the "type" is an arbitrary string but, by convention, that string represents the most-derived Slice type of the object. For example, the Slice type of the encoder factory in our ripper application is ::Ripper::MP3EncoderFactory.

35.6.2 Object Descriptors

During deployment, the registry associates the identity EncoderFactory with the indirect proxy EncoderFactory@EncoderAdapter. If the adapter descriptor had omitted the adapter id, the registry would have generated a unique identifier using the server id and the adapter name.

35.6.3 Adding Objects in a Program

module IceGrid {
interface Admin {
    ...
    void addObject(Object* obj)
        throws ObjectExistsException,
               DeploymentException;
    void updateObject(Object* obj)
        throws ObjectNotRegisteredException,
               DeploymentException;
    void addObjectWithType(Object* obj, string type)
        throws ObjectExistsException,
               DeploymentException;
    void removeObject(Ice::Identity id)
        throws ObjectNotRegisteredException,
               DeploymentException;
    ...
};
};

The addObject operation adds a new object to the database. The proxy argument supplies the identity of the well-known object. If an object with the same identity has already been registered, the operation raises ObjectExistsException. Since this operation does not accept an argument supplying the object’s type, the registry invokes ice_id on the given proxy to determine its most-derived type. The implication here is that the object must be available in order for the registry to obtain its type. If the object is not available, addObject raises DeploymentException.

The updateObject operation supplies a new proxy for the well-known object whose identity is encapsulated by the proxy. If no object with the given identity is registered, the operation raises ObjectNotRegisteredException. The object’s type is not modified by this operation.

The addObjectWithType operation behaves like addObject, except the object’s type is specified explicitly and therefore the registry does not attempt to invoke ice_id on the given proxy (even if the type is an empty string).

The removeObject operation removes the well-known object with the given identity from the database. If no object with the given identity is registered, the operation raises ObjectNotRegisteredException.

Ice::ObjectAdapterPtr adapter =
    communicator‑>createObjectAdapter("EncoderAdapter");
Ice::Identity ident =
    communicator‑>stringToIdentity("EncoderFactory");
FactoryPtr f= new FactoryI;
Ice::ObjectPrx factory = adapter‑>add(f, ident);
IceGrid::AdminPrx admin = // ...
try {
    admin‑>addObject(factory); // OOPS!
} catch (const IceGrid::ObjectExistsException &) {
    admin‑>updateObject(factory);
}

After obtaining a proxy for the IceGrid::Admin interface (see Section 35.14), the code invokes addObject. Notice that the code traps ObjectExistsException and calls updateObject instead when the object is already registered.

There is one subtle problem in this code: calling addObject causes the registry to invoke ice_id on our factory object, but we have not yet activated the object adapter. As a result, our program will hang indefinitely at the call to addObject. One solution is to activate the adapter prior to the invocation of addObject; another solution is to use addObjectWithType as shown below:

Ice::ObjectAdapterPtr adapter =
    communicator‑>createObjectAdapter("EncoderAdapter");
Ice::Identity ident =
    communicator‑>stringToIdentity("EncoderFactory");
FactoryPtr f = new FactoryI;
Ice::ObjectPrx factory = adapter‑>add(f, ident);
IceGrid::AdminPrx admin = // ...
try {
    admin‑>addObjectWithType(factory, factory‑>ice_id());
} catch (const IceGrid::ObjectExistsException &) {
    admin‑>updateObject(factory);
}

35.6.4 Adding Objects with icegridadmin

The icegridadmin utility (see Section 35.23.1) provides commands that are the functional equivalents of the Slice operations shown in Section 35.6.3. We can use the utility to manually register the EncoderFactory object from Section 35.6.2:

$ icegridadmin --Ice.Config=/opt/ripper/config
>>> object add "EncoderFactory@EncoderAdapter"

>>> object list
EncoderFactory
IceGrid/Query
IceGrid/Locator
IceGrid/Registry
IceGrid/InternalRegistry-Master

>>> object add "EncoderFactory@EncoderAdapter" \
"::Ripper::MP3EncoderFactory"

>>> object remove "EncoderFactory"

35.6.5 Queries

The registry’s database of well-known objects is not used solely for resolving indirect proxies. The database can also be queried interactively to find objects in a variety of ways. The IceGrid::Query interface supplies this functionality:

module IceGrid {
enum LoadSample {
    LoadSample1,
    LoadSample5,
    LoadSample15
};

interface Query {
    idempotent Object* findObjectById(Ice::Identity id);
    idempotent Object* findObjectByType(string type);
    idempotent Object* findObjectByTypeOnLeastLoadedNode(
            string type, LoadSample sample);
    idempotent Ice::ObjectProxySeq findAllObjectsByType(
            string type);
    idempotent Ice::ObjectProxySeq findAllReplicas(Object* proxy);
};
};

The findObjectByType operation returns a proxy for an object registered with the given type. If more than one object has the same type, the registry selects one at random. The operation returns a null proxy if no match was found.

The findObjectByTypeOnLeastLoadedNode operation considers the system load when selecting one of the objects with the given type. If the registry is unable to determine which node hosts an object (for example, because the object was registered with a direct proxy and not an adapter id), the object is considered to have a load value of 1 for the purposes of this operation. The sample argument determines the interval over which the loads are averaged (one, five, or fifteen minutes). The operation returns a null proxy if no match was found.

The findAllObjectsByType operation returns a sequence of proxies representing the well-known objects having the given type. The operation returns an empty sequence if no match was found.

Given an indirect proxy for a replicated object, the findAllReplicas operation returns a sequence of proxies representing the individual replicas. An application can use this operation when it is necessary to communicate directly with one or more replicas.

Be aware that the operations accepting a type parameter are not equivalent to invoking ice_isA on each object to determine whether it supports the given type, a technique that would not scale well as the for a large number of registered objects. Rather, the operations simply compare the given type to the object’s registered type or, if the object was registered without a type, to the object’s most-derived Slice type as determined by the registry (see Section 35.6.1).

35.6.6 Application Changes

Descriptors

At first glance, the addition of the well-known objects does not appear to simplify our client very much. Rather than selecting which of the two adapters receives the next task, we now need to select one of the well-known objects.

Querying with findAllObjectsByType

The IceGrid::Query interface provides a way to eliminate the client’s dependency on object adapter identifiers and object identities. Since our factories are registered with the same type, we can search for all objects of that type:

Ice::ObjectPrx proxy =
    communicator‑>stringToProxy("IceGrid/Query");
IceGrid::QueryPrx query = IceGrid::QueryPrx::checkedCast(proxy);
Ice::ObjectProxySeq seq;
string type = Ripper::MP3EncoderFactory::ice_staticId();
seq = query‑>findAllObjectsByType(type);
if (seq.empty()) {
    // no match
}
Ice::ObjectProxySeq::size_type index = ... // random number
Ripper::MP3EncoderFactoryPrx factory =
    Ripper::MP3EncoderFactoryPrx::checkedCast(seq[index]);
Ripper::MP3EncoderPrx encoder = factory‑>createEncoder();

Querying with findObjectByType

Ice::ObjectPrx proxy =
    communicator‑>stringToProxy("IceGrid/Query");
IceGrid::QueryPrx query = IceGrid::QueryPrx::checkedCast(proxy);
Ice::ObjectPrx obj;
string type = Ripper::MP3EncoderFactory::ice_staticId();
obj = query‑>findObjectByType(type);
if (!obj) {
    // no match
}
Ripper::MP3EncoderFactoryPrx factory =
    Ripper::MP3EncoderFactoryPrx::checkedCast(obj);
Ripper::MP3EncoderPrx encoder = factory‑>createEncoder();

Querying with findObjectByTypeOnLeastLoadedNode

So far the use of IceGrid::Query has allowed us to simplify our client, but we have not gained any functionality. If we replace the call to findObjectByType with findObjectByTypeOnLeastLoadedNode, we can improve the client by distributing the encoding tasks more intelligently. The change to the client’s code is trivial:

Ice::ObjectPrx proxy =
    communicator‑>stringToProxy("IceGrid/Query");
IceGrid::QueryPrx query = IceGrid::QueryPrx::checkedCast(proxy);
Ice::ObjectPrx obj;
string type = Ripper::MP3EncoderFactory::ice_staticId();
obj = query‑>findObjectByTypeOnLeastLoadedNode(type,
    IceGrid::LoadSample1);
if (!obj) {
    // no match
}
Ripper::MP3EncoderFactoryPrx factory =
    Ripper::MP3EncoderFactoryPrx::checkedCast(obj);
Ripper::MP3EncoderPrx encoder = factory‑>createEncoder();

Review

Incorporating intelligent load distribution is a worthwhile enhancement and is a capability that would be time consuming to implement ourselves. However, our current design uses only well-known objects in order to make queries possible. We do not really need the encoder factory object on each compute server to be individually addressable as a well-known object, a fact that seems clear when we examine the identities we assigned to them: EncoderFactory1, EncoderFactory2, and so on. IceGrid’s replication features, discussed in Section 35.9, give us the tools we need to improve our design.

35.6 Well-known Objects