Documentum Foundation Services – What Happened?

Unveiled with D6 in 2007, Documentum Foundation Services (DFS) was the service-oriented  replacement for the Documentum Foundation Class (DFC) and the Microsoft specific Primary Interop Assembly (PIA) including lingering components of the original Documentum API still embedded within the DFC.  With the announcement at EMC World that the new development environment will be a REST based API built on the DFC, Documentum customers might be wondering about the future of DFS.  This post will discuss the different web services approaches and present some TSG thoughts on the subject of the DFS as well as the upcoming REST API. 

The Need for DFS

Long-time developers with the DFC will understand that some of the underlying code that powers the DFC is the long-time (90’s vintage) API created by the original Documentum developers.  The original API was not Web-based, but instead powered more of a client/server architecture, complete with RPC messaging from the client to the server.  As such, the DFC  wasn’t designed to meet the needs of  a multi-threaded API appropriate for web applications.  We had always heard certain rumors that remaining C-code was sometimes preventing the DFC from threading appropriately.  The DFS was created with D6 to provide a true web-services layer from Documentum while removing these last, non-Java, components.

Complexity of replacing the DFC

 Readers should understand that the DFC, when built, leveraged the original Documentum Client Library (DMCL) API.  To build the DFS, Documentum chose to replace both the DFC and DMCL API components from scratch.  In Documentum release 6.5, the DMCL was removed and replaced with an emulator for backwards compatibility. The current limited functionality of DFS and the need to keep the DMCL API in some form speaks to the complexity and effort required to build a fully functional web services API. The depth and control the DFC provides the developers is labor intensive to recreate and  the need for stability and performance makes the task even more difficult. 

Funding of the Effort

Like the upcoming Unified Web Interface, DFS development is not an activity funded by licensing.  This is different from Webtop, CenterStage or xCP where the development can be justified by the sales of the product.  DFS is an API replacement/enhancement  development effort and like other infrastructure efforts, like current D7 release, it doesn’t necessarily drive revenue.

What happened to xCP on DFS?

At 2010 EMC World, EMC announced that the upcoming release of xCP was going to be ported to DFS.  At the time, TSG recommended waiting until the release was complete as we saw this effort as a major reworking of the xCP platform (currently based on a combination of WDK/DFC/DFS).  From the announcement at this year’s EMC World that xCP will be built on new REST API sometime late 2012, it seems that the full DFS effort for xCP was either never started or aborted midway. 

OpenContent Experience – The application drives the web service

As long-time readers might know, TSG developed our own Open Source web services starting in 2005.  We originally developed that layer based on multiple client experience (mostly financial services), that were building their own web service layer.  We chose to develop OpenContent based on our client experience and our thoughts for other clients’ needs.  While our development efforts with OpenContent are similar to DFS, TSG decided to only build a sub-set of  functionality based on our client needs.  Some differences between OpenContent development and DFS included:

• OpenContent is built on the DFC due to timing as well as the need to work with D5 versions of Documentum.  DFS was mostly built to work only on D6 and above.
• OpenContent was enhanced client by client based on new needs and interface components from our HPI interface.  DFS was built as a developer tool only.
• OpenContent was built to access a variety of repositories (Alfresco, Documentum, SharePoint…) and had to remove all Documentum specific components (ex: DQL).

For comparison to the DFS, our work differentiated due to:

• We didn’t have the complexity of getting rid of the DFC.  We were confident that the DFC was stable and could perform based on a wide variety of experience with clients.
• We had each client pushing us for stability and performance.
• We had an interface (mostly HPI, but Active Wizard later) pushing us for enhancements to OpenContent. 
• We needed the web services to work with a variety of ECM platforms, not just Documentum.

Interface Development pushing DFS

Currently, only the MyDocumentum suite is fully based on the DFS.  CenterStage was to be based on the DFS but had issues with certain requirements that the DFS was not meeting causing the CenterStage team to develop their own web services.  It is our understanding (this is more rumor mill than any announcement) is that the CenterStage experience was one of the factors that led internally to develop the REST API on the DFC.

One issue of concern for long-term DFS usage is that lack of an interface to push out existing functionality outside of the MyDocumentum suite.  With the Unified Client Interface moving to the new REST API, we are concerned that DFS will not be enhanced or updated based on a Documentum interface, but rather, just based on user custom development, whether that be clients or Documentum consulting with the SharePoint thing (add name and link). 

DFS Thoughts going Forward

Similar to our thoughts on the other announcements at EMC World 2011, we would recommend a “wait and see” attitude in regards to figuring out what to do in regards to the DFS.  With CMIS and REST coming, it is hard to commit to DFS as it appears Documentum’s new development effort will be focused in other directions.

We still recommend something like OpenContent for clients looking for Web Services for Documentum or other repositories for clients that understand the benefits of an Open Source layer between their application and underlying ECM repository.