|
|
This chapter describes the CORBA Client Data Caching design pattern. The purpose of this design pattern is to make persistent state information from the server available locally to the client for data-intensive processing. This way, the CORBA client application does not need to make repeated invocations to the server application to retrieve data.
This design pattern addresses the scalability and performance of distributed client/server applications. The overhead associated with remote invocations to retrieve attributes of a CORBA object may be quite high, depending on system load and other factors. Also, exposing persistent data records as CORBA objects tends to create applications that do not scale well because of the potentially large number of simultaneously active objects that must be managed by the system. Client application processing that is either data-intensive or that requires user input (for example, editing fields) can slow down both the client application and the system if multiple remote invocations must be made to retrieve data.
This design pattern is appropriate in situations where the CORBA process object needs to pass a large amount of data to the client application for its use. The local language object on the client application becomes a container for the data, and its constructor is used to populate the local object state.
You implement this design pattern in the client application, which creates a local language object, referred to in this chapter as the DataObject. The server application implements a CORBA process object that interacts with entities in persistent storage. This CORBA object is referred to in this chapter as the DataManager object.
The OMG IDL for the DataManager CORBA object defines a data structure that is used for transferring data between the client and server applications. (This design pattern assumes "optimistic locking," meaning that the data managed by the server application is not locked for update, and that it is hoped that no other server processes modify the data while the client application uses its local copy.)
When the client application instantiates the local DataObject, that object's constructor invokes an operation on the DataManager CORBA object, which passes a data structure back to the DataObject. The DataObject populates its class variables with the passed data.
If the client application needs to pass modified state back to the server machine, the client application invokes the DataObject::writeData() method, which, in turn, invokes the writeRecord() operation on the DataManager CORBA object. In this invocation, the data structure is passed as a parameter to the writeRecord() operation. The DataManager CORBA object makes the appropriate updates to durable storage.
The following figure illustrates how the CORBA Client Data Caching design pattern works.
DataObject constructor invokes the readRecord() operation on the DataManager CORBA object, and uses the returned data structure to initialize its local state.DataObject instance.DataManager CORBA object, the client application invokes the DataObject::writeData() operation, passing a data structure containing the modified data.
The DataObject methods read and write data by invoking operations on the DataManager CORBA object.
The data structure passed to the client application should be designed to provide the minimal set of data required for an operation. If a large amount of data is involved, it may be more efficient to provide multiple data structures with a subset of fields required for each operation. Operations on the CORBA process object should be designed to involve only the subset of data needed for each operation; this helps reduce network traffic.
|