Object-Oriented Programming Using SOM and DSOM/Making Your Objects Persistent

The Persistence SOM (PSOM) Framework allows you to make all or part of a SOM object persistent. This means you can p1·eserve the state of an object, ever after the process that creates the object terminates. The Framework provides services that allow you to store an object to a file system or another form of per sistent store. It also provides services that permit you restore objects from the persistent storage.

Most applications already use some form of persistence. For example, a spreadsheet or a word processor stores user data in a file. The implementation of a spreadsheet typically contains logic that converts the data in the cells into some format that can be written to a file for storage. When an existing spread sheet is loaded, the reverse takes place. The logic converts the external data back to the cell format so the user can work with it.

The PSOM Framework simplifies these operations by providing a uniform interface to storage. A cell in a spreadsheet can be implemented as a persistent object, and its data can be stored and restored, using the services in the PSOM Framework. Any flattening and unflattening of data can be eliminated. Applications can also avoid writing low level I/O routines and therefore become more portable.

PSOM OVERVIEW??

To use the PSOM Framework, both the object and the client program that accesses the object must be PSOM aware. What doest.his mean? From the object perspective, it must be derived from a special persistent class and the persistent data must be specified explicitly. This is different from the DSOM approach where an object does not have to know in advance whether it is going to be distributed. The PSOM client is typically responsible for managing persistence by controlling when the persistent data is stored or restored.

The PSOM Framework can store and restore objects that are arbitrarily complex. This means that if an object contains pointers to other objects, the PSOM Framework can save and restore those referenced objects as well. In a hierarchy of objects, the client can control whether or not an object should be stored or restored with its children.

It should be noted that OMG is in the process of releasing a Persistence Service Specification. The goal of the Persistence Service Specification is to provide common interfaces to the mechanisms used for retaining and managing the persistent state of objects. It is expected that the next release of PSOM will comply with the OMG Persistence Service Specification. It is quite likely that the interfaces described in this chapter will change with the next release. However, the concepts behind them should remain the same. More on this can be found in Chapter 10.

The development of a PSOM application involves the following steps.

1. Define the interface for your persistent objects, and write code to implement your objects.
2. Create a client program that accesses and manages the objects.
3. Build your classes and register them with the Interface Repository.
4. Run the client program.

The following sections provide details on each of the above steps.

DEFINE AND IMPLEMENT A PERSISTENT OBJECT

To create a persistent object, we must first create a class that is derived from the SOMPPersistentObject class. The parent class for SOMPPersistentObject class is SOMObject. Therefore, your persistent object is still a SOM object, only it can potentially become persistent because it is dervied from the SOMPPersistentObject class.

All data that is to be stored persistently must be declared as an attribute of CORBA type. The persistent modifier must be set for each of these attributes in the implementation section of the IDL.

The following Person class is potentially persistent and contains two persistent and one non-persistent attributes.

#include <po.idl>
interface Person: SOMPPersistentObject
{
   attribute string name ;
   attribute string birthdate: 
   attribute short age;

   #ifdef _SOMIDL_
   implementation
   {
      releaseorder : _get_name , _set_ name.
                     _get_birthdate, _set_birthdate,
                     _get_age, _set_age;

      somplsDirty:override;

      name: persistent;
      birthdate: persistent ;
    };
    #end if
} ;
#end if

The SOMPPersistentObject class provides the somplsDirty method, which is called by the PSOM Framework, to determine if an object has been changed. The PSOM Framework is optimized so it will only write out changed objects. Since the defauJt implementation of sompl sDirty always returns TROE, it is typically redefined by subclasses so that they can indicate whether an object has been changed. The implementation can invoke the s ompGe tDirty method to deter mine if the object h as been changed. An example of overriding this method is given in the Persistent Calendar application in Section 6.6 on page 148.