With system designers, developers, and IT managers becoming more familiar with both Object Request Brokers (ORBs) and Object-Oriented Database Management Systems (ODBMS), many are looking for help differentiating the two. Should I use an ORB or an ODBMS? I hear this question over and over again. I usually begin by saying that the two technologies are different but highly complementary. I feel the question is not “Which technology should I use?” but “How can I use these two technologies together successfully?” While working for Expersoft, I have been involved with many leading edge technologists who have successfully combined the two technologies to create a highly competitive applications.
In most cases, combining both technologies is more powerful and flexible than using either technology alone. I like what John Rymer said in the May 1995 Seybold SnapShots, in an editorial about using databases with distributed object technology. “In a distributed object architecture, a database server plays a vital, but limited role, It provides a service to store and retrieve data… The distribution service is usually an object request broker (ORB). An ORB is a communications backbone.” Below I will discuss several application problems, and how the combination of an ORB with an ODBMS can do the trick.
Using an ODBMS within an Object Server or Object Implementation
Is your application Object Oriented? Would you like native database support to store and retrieve object states? Would you like services to be transparently accessible over a heterogeneous network? Embedding ODBMS access within a distributed object server or object implementation will solve this problem for you.
An ORB allows a particular process, an object server, to instantiate objects at the request of client applications. An object server might also explicitly instantiate objects itself and allow clients to connect their local object surrogate or stub to the previously instantiated object. The object server will then invoke methods on instantiated objects transparently when a client invokes a method on the local object surrogate or stub. An object server should be able to service instances of different classes. The actions that occur when a method is invoked on an object are defined within the implementation of that object not within the object server.
Both the object server process and the actual object implementations can utilize an ODBMS to their benefit. An object implementation could utilize an ODBMS as a persistent store for that objects internal or private information objects. For example, in a derivative trading application, a derivative object might be accessed remotely through an ORB. The ORB would allow calculations on the derivative object to be distributed to a calculation server. The implementation of the derivative object might utilize an ODBMS to persist a contained object which represents its current positions. The ODBMS ensures integrity, archiving, and recovery of this complex information. The developer would make extensive use of the ODBMS API when implementing the derivative object. The derivative object implementation would be considered an ODBMS client. Applications accessing the derivative object via the ORB would not need to access the ODBMS directly. This minimizes ODBMS access and isolates client applications from the underlying persistence mechanism.
Remote Object Faulting
Does your application require many distributed objects? In an object oriented application, all services are provided through objects. An object server could have instantiated several thousands of objects, over a heterogeneous network. With this many objects, your application might require too much memory for a particular machine configuration. An ODBMS could be used to fault in and out instantiated objects based on their actual runtime usage. An object server could access an ODBMS to retrieve an object which hasn’t been used recently. If a method call occurs, the object server would check if that object is in memory, if not, it could retrieve the object from the ODBMS and then invoke the method for the client application. This functionality could be transparent to the developer depending on the ORB implementation or it could be developed into the object server explicitly by using the ODBMS API.
A Unified Object Model
Would your application require an ORB to provide the transparent location of object services, and a database to provide the reliable storage and retrieval of objects? One option is to write an object server yourself, using both the ORB API and the ODBMS API to provide a seamless service which will access the associated underlying persistence mechanism. Another option is to have this persistence mechanism provided as part of the ORB. Expersoft provides this transparent service with ObjectStore, a leading Object database.
Expersoft’s XShell product supports the transmission of objects by value. Full fledged objects can be passed as parameters and return values to remote method calls. This can be thought of as a network deep copy. When would you want to pass an object by value? If a client application constructs a large matrix object through client interaction and wants to pass the particular matrix to a remote calculator object, it makes sense to pass the object by value. By modeling the object as an XShell ADT instead of as a regular C++ class, the XShell preprocessor is able to generate all the code required to stream the object by value across the network. The remote calculator object might want to store the matrix into an ODBMS so that in the future, it doesn’t have to be sent across the network again.
The ObjectStore integration from Expersoft allows any ADT to be written/read from standard memory or ObjectStore’s persistent memory. This allows a single object model to be used, whether it be between ORB clients and ORB servers or ODBMS clients and ODBMS servers. For example, let us assume that a remote matrix server has been developed. A client can instantiate a local matrix server surrogate and connect it to the remote matrix server. It could then invoke the retrieve method. The retrieve method might take a name as a parameter and return a matrix object by value. The implementation of the remote matrix retrieval object could read the matrix object out of ObjectStore’s persistent memory, and return it directly by value to the client via the retrieve call. A unified object model makes it easy to use both technologies without having to map an ODBMS object to an ORB object.
COSS I – Persistence
Does your application require object states to be saved between invocations of your program? As part of the COSS 1 specifications, every ORB should provide a persistence object service. Could an ODBMS be used to support the COSS Persistence Service? Yes. An application might access the COSS Persistence Service through a product provided by an ODBMS. Several vendors contributed to the actual specification. These include Objectivity, Ontos, Persistence Software and Versant. An application might use an vendor’s Persistence Service and an ORB vendors ORB implementation. It is likely that many ORB vendors will provide implementations of the COSS Persistence Service. It is possible that some of these will interface to a commercial ODBMS. Some ORB vendors will provide native implementations of the COSS Persistence Service without interfacing to an ODBMS.
Why would an application use an ODBMS once implementations of the COSS Persistence Service become available? The COSS Persistence Service does provide object storage and retrieval but does not support querying to the same extent as a true ODBMS. Additionally the COSS Persistence Service is defined simply by its API. No where in the specification are implementation details specified. These details are left up the vendor implementing the service. An implementations of the COSS Persistence Service is not required to provide archival or restore facilities. This type of functionality known as an implementation detail.
Embedding an ODBMS within an ORB Implementation
An ORB can utilize an ODBMS to implement CORBA services. In this case, the use of the ODBMS is completely hidden from all ORB clients and exists for the convenience/benefit of the actual ORB implementation. This architecture is discussed for the sake of completeness.
An ORB Implementation provides many services to ORB clients. Providing these services to clients often requires the management of complex data. The ORB could utilize an ODBMS for this complex data management. For example, the ORB needs to keep track of numerous client processes, numerous server processes, and possibly, a very large number of specific connection identifiers. The ORB could be implemented to track this information via standard C structures, C++ objects or ODBMS aware objects. By utilizing an ODBMS, the ORB itself might reduce its memory requirements or provide better fault recovery. The ORB must also keep track of named objects. The ORB could use an internal, proprietary mechanism for storing naming information persistently, or it could utilize an ODBMS. Considering the simplicity of the Naming information, a RDBMS could potentially be used for this as well.
If an ORB has been implemented using an ODBMS, it will probably not expose the ODBMS to its users. The ODBMS would be hidden from ORB developers via the ORBs API. The benefits obtained by using an ODBMS within the ORB Implementation, can also be obtained by using an ODBMS within a remote object server or implementation.
Summary
In this article, I have investigated several different ways to take advantage of both ORB and ODBMS technology within a single distributed application. Most distributed applications can make use of ORB technology as the underlying communications infrastructure. ODBMS technology can be used to store important object state information. With this combination, your application can neatly: store objects, minimize resources, and execute remote methods. In addition, the integration between XShell and ObjectStore provides a unified object model which can be used across the ORB and the ODBMS. This can drastically reduce your development time.
Bibliography
“Heart of the Matter” by John R. Rymer, SnapShots: May 1995, Patricia Seybold Group. Pages 6-7.