Object caching does result in some changes that need to be exposed to the application level. These changes affect the way objects are programmed, created and used. First, we allow class implementors to specify the desired level of consistency by having the user defined class explicitly inherit (directly or indirectly) from the appropriate class in the consistency framework shown as part of the caching framework in figure 2.
The second aspect of the API that affects the application program is the following. Since memory pointers do not make sense across address spaces, there needs to be an address-space independent way of accessing a shared object. We call this an object-id and it consists of a host name, a process id, and a process-unique identifier. For example, if the object-id of an object is < hname, pid, nid >, then this object was created by process with pid as its process-id on a host named hname and nid uniquely identifies the object within the process. A client creates a distributed object on a particular node by specifying the hostname and the process-id while specifying the third component to be zero. When the object is created, its process-unique id is assigned by Flex. Thus, the constructor for the object's class takes an additional argument - the object-id. For example, a client obtains a reference to an existing object by executing new className (oid, <arguments>) instead of new className (<arguments>), where oid is the object-id of the shared object that the client wishes to access.