How does DFC work?

September 17, 2007 at 8:56 pm | Posted in Architecture | 5 Comments

In my review of Documentum Content Fundamentals I made the comment that the section describing how a DFC-based client communicates with the Content Server was wrong. It turns out that that passage of the book was based on a section in the Documentum System Development Guide, in fact Pawan Kumar has helpfully posted the relevant passage on his website. I thought I would use this post to expand on what I think is wrong with both the explanation given in the System Development Guide and in Pawan’s book.

First of all I think it would be helpful to define exactly what I mean when I am referring to the DMCL (Documentum Client Library) and the DFC (Documentum Foundation Classes). The DMCL consists of a DLL (windows) or shared library (Unix) plus a configuration file dmcl.ini. The DLL is called dmcl40.dll and the shared library has a number of names depending on the OS but usually something like libdmcl40.so.

The DFC is a set of JAR files, principally dfc.jar but also a number of others contained in c:\Program Files\Documentum\shared (windows) or DOCUMENTUM_SHARED (Unix). In addition there are a number of configuration files such as dfc.properties and dbor.properties. Documentum hasn’t had a separate release of the DMCL files for quite a while now and it will only be installed as part of the DFC installation. Just to complicate matters Documentum 6 no longer has a native code implementation of the dmcl, it is all implemented in Java, and DFC and DMCL are all bundled together.

No Server-side DMCL

If you look at the description of the communication process given in the System Development Guide you will see it talks about there being a DMCL receiving communications on the server-side. This is not correct. It is pretty easy to see that no DMCL code is loaded or invoked in the Content Server process so it can’t be that DMCL is receiving communications. Of course there may be another process running as an intermediary on the server-side that is running a ‘server-side’ DMCL. However it is again easy to see that the communications are direct client to server by using netstat to view the network endpoint connections.

If you look at the functions involved in stack traces both on the client and in the content server it can be seen that Documentum uses a fairly standard RPC mechanism to present Content Server functionality to the outside world (ie anything outside of the Content Server process). The DMCL implements the official Content Server API, a set of 150 or so functions that utilise the RPC functions implemented by the Content Server.

No server-side DFC

The description in the System Development Guide only talks about a server-side DMCL but the accompanying diagram shows a server-side DFC component. The server-side DFC is not shown as taking part in the communication process but it may have been the catalyst for Pawan to extrapolate the description of the communication process to include a server-side DFC. In his description the communication is client-DFC -> client-DMCL -> server-DMCL -> server-DFC. Again this does not seem to be an accurate model of what happens. DFC was conceived as an object-oriented wrapper around the DMCL and it doesn’t really make sense for there to be a server-side DFC component to the communication.

Why worry?

So the description in the System Development Guide is not quite accurate. But does it matter? There are a couple of reasons I think it does.

1. It is essential when troubleshooting systems to understand what components are involved and how they communicate. The idea that dmcl is involved as part of the server-side processing can and has mislead some people into believing that changing dmcl.ini parameters on the server can influence and change Content Server processing. Methods and other processes running on the server but external to the content server process act as client programs using the DMCL but Content Server code does not appear to use the DMCL library or the dmcl.ini configuration parameters
2. Architecting systems for performance and performance tuning relies on understanding the pattern of communication

I hope that EMC Documentum will look at revising the section in the System Development Guide to avoid the confusion it causes.