Some notes about UCF

A really interesting article on UCF has been posted on the dm_notes blog:

Role of UCF in Documentum Clients « dm_notes: Documentum Notes

Here is some additional info I’ve discovered over the last couple of years:

• UCF does not run in the context of the browser and it is not an applet. It is a standalone (headless) java application that is launched by the browser. There is some pretty tricky stuff that the launcher does (like installing a private copy of java if you don’t already have java) in order to get an execution environment for UCF setup.
• With the advent of ACS/BOCS, the UCF client application is able to transfer files from/to(as of D6) the ACS servlet that runs in the Java Method Server servlet container on the Content Server. This can eliminate a network hop, but also requires users to have at least one network path open to the Docbase which could be considered a security vulerability.
• UCF provides services to the User Profile component in Webtop, allowing for filetypes to be mapped to specific view/edit programs on a users PC.
• DFS can utilize UCF for file transfers, This desirable when you are dealing with Virtual Documents and/or xml content managed by XML Applications
• UCF is capable of transferring all nodes in a virtual document in a single operation.
• UCF is capable of pulling down supporting documents (DTDs, Schemas, Entities, Modules, XML Editor customizations, etc) for xml content that is managed by an XML Application. Also UCF will perform DOCTYPE fixup so that the xml content points to the local filesystem location for the DTD/Schema
• Similar to DFC, the UCF runtime can interact with the client registry. This information can then be used by UCF to streamline certain transfer operations.
• At least as of 5.3, UCF would attempt to use HTTP 1.1 Chunked Encoding to send data. This reduces the amount of HTTP header information that has to be sent in band with large transfers. Unfortunately there is an issue where the HTTP header is split in such a way that certain firewalls (CheckPoint with SmartDefense enabled) will block UCF traffic. It is possible to turn off chunked encoding via the UCF config files.
• UCF has issues traversing an HTTP proxy that requires authentication. This can be tweaked to some degree via UCF config, but there are some situations where UCF will simply fail to get through a proxy that requires auth.
• Prior to D6, the UCF runtime would terminate when the launching browser closed. As of D6 this is no longer true. Instead the UCF client times out after a configurable period of inactivity (15 minutes by default.) I assume that Documentum is intending to re-bind to an existing UCF client when a browser is closed and re-opened in order to reduce the spin-up time associated with loading a JVM. However this re-binding does not appear to work as of D6SP1. This is especially noticeable when you use DFS as a stateless transport (i.e. you reconnect for each interaction.) In this case, you can end up with many UCF runtime instances all running concurrently taking CPU and Memory resources. Also it seems that if the UCF runtime timesout while you are in Webtop and you then attempt a UCF operation. There can be some failure in re-binding that results in your browser freezing up and/or a failed transfer.

Some of the above info is rather negative. I do think that UCF is a great concept to provide clients with a light-weight enhanced transfer mechanism, but there are quite a lot of issues with it as well. I have been told that a get-well program is underway for UCF so am expecting big improvements sometime soon.