This section shows an example of how to provide a server class implementation for persistent SOM objects. (The Persistence Framework of the full-capability SOMobjects Developer Toolkit can be used to write a persistent object s erver; an example of that type is given in the SOMobjects Developer Toolkit Users Guide.) All of the persistent object management is contained in the server class; this class can be used with the DSOM "generic" server program, somdsvr.
The following example describes a user-supplied server class "MyPServer"
that is derived from SOMDServer. The "MyPServer" class introduces
five new methods:
and overrides four SOMDServer methods:
somdDeleteObj
somdRefFromSOMObj
somdSOMObjFromRef.
The example shows how a server class might use and manage Reference Data in object references to find and activate persistent objects.
The IDL specification for "MyPServer" follows:
interface MyPServer : SOMDServer { boolean isPObj (in SOMObject obj); void assignRefDataToPObj(in SOMObject pobj); void deletePObj(in SOMObject pobj); ReferenceData getRefDataFromPObj(in SOMObject pobj); SOMObject activatePObjFromRefData(in ReferenceData rd); #ifdef __SOMIDL__ implementation { somdCreateObj : override; somdDeleteObj : override; somdRefFromSOMObj : override; somdSOMObjFromRef : override: }; #endif };
The "isPObj" method returns TRUE if the object passed to it is a persistent object. It is implemented as follows:
SOM_Scope boolean SOMLINK isPObj(MyPServer somSelf, Environment *ev, SOMObject obj) { return(obj && _somIsA(obj, MyPersistentObjectNewClass(0, 0)); }
The following two procedures override SOMDServer's implementations of somdCreateObj and somdDeleteObj.
SOM_Scope SOMObject SOMLINK somdCreateObj(MyPServer somSelf, Environment *ev, Identifier objclass, string hints) { /* create the object as usual */ SOMObject obj = parent_somdCreateObj(somSelf, ev, objclass, hints); /* if obj is persistent, assign Ref Data to it */ if (_isPObj(somSelf, ev, obj))) { _assignRefDataToPObj(somSelf, ev, obj) } return(obj); }The implementation of somdCreateObj first creates the object as usual by employing the implementation of SOMDServer (MyPServer's parent). If the newly created object is persistent, the job of "assignRefDataToPObj" is to associate with the object a piece of data that (1) identifies the object, (2) is retrievable from the object, and (3) can be coerced into ReferenceData so that it can be used to create a SOMDObject (an object reference).
SOM_Scope void SOMLINK somdDeleteObj(MyPServer somSelf, Environment *ev, SOMObject obj) { /* is obj persistent, have the persistence framework delete it */ if (_isPObj(somSelf, ev, obj)) { _deletePObj(somSelf, ev, obj); } else /* obj is not persistent, so delete as usual */ parent_somdDeleteObj(somSelf, ev, obj); }
The somdDeleteObj implementation, when the object to be deleted is persistent, invokes "deletePObj" to delete the object. When the object is not persistent, the SOMDServer implementation of somdDeleteObj deletes the object.
The following two procedures override SOMDServer's implementations of the methods somdRefFromSOMObj and somdSOMObjFromRef:
SOM_Scope SOMDObject SOMLINK somdRefFromSOMObj(MyPServer somSelf, Environment *ev, SOMObject obj) { SOMDObject objref; /* is obj persistent */ if (_isPObj(somSelf, ev, obj { /* Create an object reference based on identifying data. */ ReferenceData rd = _getRefDataFromPObj(somSelf, ev, obj); InterfaceDef intf = _lookup_id(SOM_InterfaceRepository,ev,somGetClassName(obj)); objref = _create_constant(SOMD_SOMOAObject, ev, &rd, intf SOMD_ImplDefObject); _somFree(intf); SOMFree(rd._buffer); } else /* obj is not persistent, so get Ref in usual way */ objref = parent_somdRefFromSOMObj(somSelf, ev, obj); return(objref); }
Method somdRefFromSOMObj is responsible for producing a SOMDObject (the"Ref" in somdRefFromSOMObj) from a SOMObject. As mentioned earlier, SOMOA exports two methods for creating SOMDObjects: create and create_constant. This implementation uses create_constant because it does not want to store the ReferenceData in the ReferenceData Table. If it did use create and store the ReferenceData in the persistent table, the server object would either (1) have to keep a persistent table that maps SOMObjects to SOMDObjects so that it didn't call create twice with the same arguments (recall that create always returns a new SOMDObject even when called twice with the same arguments), or (2) fill up the ReferenceData table with SOMDObjects that contain the same ReferenceData.
The prerequisites for asking SOMOA to create a SOMDObject are (1) some ReferenceData to be associated with the SOMDObject, (2) an InterfaceDef that describes the interface of the object, and (3) an ImplementationDef that describes te object's implementation. The InterfaceDef is retrieved from the SOM Interface Repository using the object's class name as key. The ImplementationDef is held in the variable SOMD_ImplDefObject that is set when the server process is initialized. The "MyPServer" method "getRefDataFromPObj" is used to retrieve the identifying data from the object and coerce it into ReferenceData. With these three arguments, SOMOA's create_constant is called to create the SOMDObject.
SOM_Scope SOMObject SOMLINK somdSOMObjFromRef(MyPServer somSelf, Environment *ev, SOMDObject objref) { SOMObject obj; /* test if objref is mine */ if (_is_constant(objref, ev)) { /* objref was mine, activate persistent object myself */ ReferenceData rd = _get_id(SOMD_SOMOAObject, ev, objref) obj = _activatePObjFromRefData(somSelf, ev, &rd); SOMFree(rd._buffer); } else /* it's not one of mine, let parent activate object */ obj = parent_somdSOMObjFromRef(somSelf, ev, objref); return obj; }This implementation of somdSOMObjFromRef is a little different from the others in that the server object must determine whether the SOMDObject is one that it created (that is, one that represents a persistent object), or is just a SOMDObject that was created by the SOMDServer code (its parent). This is done by asking the SOMDObject if it is a "constant" object reference (that is, one created by create_constant). If the SOMDObject says that it is a "constant", then the "MyPServer" may safely assume that the SOMDObject represents a persisten object that it created. If the SOMDObject is determined to represent a persistent object, then its ReferenceData is used to locate/activate the object it represents (via the method "activatePObjFromRefData").