How does DFC work?

September 17, 2007 at 8:56 pm | Posted in Architecture | 4 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.

About these ads

4 Comments »

RSS feed for comments on this post. TrackBack URI

  1. Robin – Very useful post. Although we know (at least think we know) how it works, effort like this validates our understanding.

    Cheers,
    Sumanth

  2. Robin,

    I will gladly update the book when the documentation is updated.

    For now, I will let the choice be with the readers when they are taking the exam. I will happily point them to your insightful articles along with the Documentum reference documentation.

    Thanks again for taking such a keen interest in this topic.

    Regards,
    Pawan

  3. xe sang audi a8

    How does DFC work? | Inside Documentum

  4. tim mua oto cu gia re tai ha noi

    How does DFC work? | Inside Documentum


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com. | The Pool Theme.
Entries and comments feeds.

Follow

Get every new post delivered to your Inbox.

Join 345 other followers

%d bloggers like this: