DFC has Junk (DNA) in the Trunk

In a webex with EMC engineering about DFS and UCF, I asked if D6.5 would bring full coverage of DFC functionality to DFS. The answer was yes and no.

The first cut of DFS was a little minimal even for my tastes. Anything beyond basic object-related operations was either barely implemented or completely ignored, like workflow and lifecycles respectively. D6.5 promises more than a dozen new services that will fill out much of the missing functionality and add some application-specific services for things like formal records management and content transformation. EMC is clearly committed to DFS as the primary API for application development and system integration.

The only big chunk of functionality missing in D6.5 will be administration-related. There’s still no way to write your own Documentum Administrator (DA) in DFS. I can’t think of an application more in need of a make-over than DA, but we’ll have to wait until D7 or beyond to write our own in DFS.

If I were the DFC, I’d be feeling a little uncomfortable about now. Documentum is like the Zsa Zsa Gabor of APIs and client interfaces; just as an interface matures, they dump it and move onto the next pretty face or fat checkbook. EMC’s already been seen around town with party boy Magellan even though Webtop still wears a ring. The same goes for DFS and DFC. With DFS 6.5 meeting all of EMC’s needs, I hope DFC’s hiring a good divorce attorney. DMCL didn’t, and look what happened to him!

No more wire hangers!The “yes and no” answer I got stems from my previous observation about Documentum’s junk DNA. That idea resonates with people, including Pie who provoked me into posting this with his own latest post. EMC sees the DFC as littered with failed ideas, obsolete patterns, and deprecated methods. When I pressed, EMC said that the DFS will contain everything an application developer would require. Parts of the DFC that qualify as junk in its trunk will not find their way into the DFS closet. No more wire hangers DFC classes!

Fear not, DFC fanboys! The DFC will still be the primary interface for writing things that go into docapps or service providers–methods, (S|T)BOs, custom DFS services and my bad boyfriend of the day, aspects.

While I understand EMC’s constraints and the issues of compatibility versus new development, I have to say my feelings here are mixed. Are we going SOA as a choice to solve particular kinds of problems or because it’s too hard for people to treat Documentum objects as java objects? My relationship with the DFC hasn’t been a smooth one, but I do feel that it has come to express the underlying model fairly well. By saying “DFS for applications, DFC for the back end”, my read between the lines is that the average application developer just can’t handle Documentum as OOP. I wish I could disagree.

Leave a Reply