Persistence of framework related information

As described in Section 4.1, every filter client maintains a list of plugged filters and every filter maintains mappings from client method to upfilter/downfilter methods and status of each of its methods. Any CORBA object providing a service may deactivate itself to save resources if it anticipates period of inactivity. Deactivation involves stopping the service and freeing all resources. The object will be reactivated whenever the service it offers is requested. Since filter clients and filters are CORBA objects, they can also choose to be deactivated. If the framework related information mentioned above is not saved while deactivation, it will be lost making the framework ineffective. In this section, we discuss the strategy adopted by us to make the framework related information persistent.

A CORBA object requests its deactivation by calling shutdown() on BOA. The shutdown procedure in BOA involves deactivating object implementations. Before deactivation actually takes place an object is given a chance to save its data by save_object() method in BOA. This method calls _save_object() on every object, which does actual work of storing object data, usually in a file. On reactivation, object initializes itself using the stored data.

In our approach for making the framework information persistent, we have modified the save_object() method of BOA. Before giving an object a chance to save its data, framework specific information in filter client and filter object is stored in files as appropriate. The information is stored in two files, one contains client specific data whereas other contains filter specific data. Note that creation of these files is not mutually exclusive since a filter client can itself be a filter e.g. in case of multi-level filtering.

On reactivation of the object, saved framework information is not immediately restored since it is required only when a method is to be invoked on that object. The method invocation request is represented at server-side by FilterServerRequest. Hence, the framework information is restored only while creation of this server-side request. File names, where the framework information is stored, are made unique for every object by using _ident() method of Object.