Home > DOCUMENTUM > Documentum Business Objects Registry

Documentum Business Objects Registry

May 4, 2010

When creating a new document of document type ‘dm_document’ using WebTop application, internally DFC system will create instance of DFC classes DfSysObject, DfDocument and so on, thus limiting the functionality to that provided by DFC standard classes.

When using business objects, classes mapped to an existing object type (or custom object type) can be extended to provide our own business logic; this is done while developing TBO. Through object oriented mechanism called polymorphism, methods of these new classes gets called in bottom up order, i.e., methods in the parent class can be overridden in the new classes written. These new methods will be called automatically by DFC system.

The object factory guarantees that the correct object will be instantiated at runtime. This applies to TBO but not necessarily to SBO. When a TBO is developed and deployed on application server or content server, the framework guarantees that the new object gets called automatically. Two things make this happen. One is Documentum Business Object Repository (DBOR) . The other is that use of registry is now an integral part of DFC. Whenever someone attempts to access a custom-type Docbase object, DFC first checks the registry for a mapping to a custom Java class, then loads and instantiates that class.

DBOF provides the following mapping at runtime:

1. Docbase Type name to Java Class mapping: When the DFC core loads a Docbase object, its type name is looked up in the registry. If the name is found, its corresponding Java class is loaded and instantiated.

2. Service Interface name to Java Class mapping: When requesting the client to load a service, the service is identified by its published interface name, such as com.documentum.IInbox. If DFC finds the interface name in the registry, the corresponding service class is loaded and instantiated and returned to the caller.

Session Manager: Whenever an application requires access to a DocBase, authentication is required. Session Manager encapsulates the DFC session object and automatically manages the session pool. To get session in SBO java class, one has to acquire it using Session Manager and release it when not needed. Whereas in TBO’s, a reference to TBO’s session is embedded inside the object by default.

Session Pooling: Session Pooling provides for an application to connect and disconnect from DocBase session many times without incurring the overhead of real sessions with the server. Session Manager puts back the session into the pool when the client releases it, free to be used by other requests for sessions.

The concept of TBO and SBO is similar to the EJB in J2EE, TBO represent entity beans
and SBO represent stateless session beans

%d bloggers like this: