This document discusses the history and evolution of the Documentum content management system. It outlines the various versions released between 1990-2003 and the changing technologies and approaches recommended by Documentum over time. For systems today, it suggests considering the Webtop and WDK for new efforts, while older systems could potentially be kept unchanged or migrated to the API, DFC, or WDK based on factors like performance needs, client control, and development expertise.

1. Documentum:
Where Do We Go
From Here?
Frank Jacquette, Jacquette
Consulting

2. A Brief History of
Documentum
• Company founded in 1990 by ex-Ingres
engineers
• Funded by Xerox
• First version of software shipped in
1993
– Documentum Server 1.0
– DocuWorks 1.0

3. 1995
• WorkSpace replaces the fairly useless
DocuWorks
– Server 2.0
– WorkSpace 2.0

4. 1996
• Accelera – first web product, read only
• UnaLink – Lotus Notes interface
• Server 3.0 – ACLs, other
enhancements
• WorkSpace 3.0 – GUI improvements

5. 1997
• Server renamed as “DocPage Server”
• RightSite I (aka “the fiasco”)
– ViewSpace (read-only web browsing)
– SiteSpace (anonymous web browsing)
– SmartSpace (read/write web client)
• SmartSpace Client/Server (aka
“WorkSpace Light)

6. 1998
• Server 3.2, renamed as “EDMS 98”
• RightSite II
– Complete rebuild, shares nothing but the
name and parts of the WebQL engine with
RightSite I
• See ya later, Macintosh users

7. 1999
• Desktop Client
– Windows only
– Provides file explorer interface to
Documentum
– Breaks all previous WorkSpace
customizations

8. 2000
• New name for version 4, Documentum
4i
• Documentum Foundation Classes
– Java wrappers around server APIs
– Documentum pushes developers to use
DFC rather than straight API calls

9. 2001
• Server 4.1 (still under the 4i name)
• Web Development Kit (WDK)
– Tools for building Java components on top
of the DFC
• Documentum quietly plans to kill
WorkSpace and RightSite

10. 2002
• Documentum 5 scheduled for 3Q02
• Includes WDK 5, DFC 5
• New features focused on digital asset
management, some usability enhancement
• Pledging RightSite support…for now
• No upgrade path from RightSite to WDK –
start over!

11. 2003
• WDK 5.1, 5.2 announced, roadmap to
WDK 6
• Server 5.2.5 ships, Webtop becomes
preferred client (built on WDK)
• Products all get renamed (again)

12. Today – What should we use?
• Documentum says: use the WDK to build
J2EE components (starting from Webtop)
• Great idea, but…
– Need a separate application server (WebLogic,
WebSphere, etc.) to serve the J2EE components
– All WorkSpace and RightSite customizations are
lost
– WDK, DFC, Desktop Client still being thrashed out
– Performance and usability weaknesses

13. Discussion
• Talk about the problems/solutions you
have or foresee

14. Options
• Keep older technologies
• Port customizations to new clients
• Build your own client application
– Using the API
– Using the DFC
– Using the WDK

15. API
• Fastest option • Lowest level option
• API is the most • Platform-dependent
stable of all client implementation (but
targets API calls are
• Full access to all common across all
server functions platforms)

16. DFC
• Platform • Slower than API calls
independent • Long initialization of
• Provides full access client side JVM required
to API • Future of Java support
• In theory, can on Windows is
improve uncertain
performance by • Just starting to
virtue of abstraction stabilize/get useful

17. WDK
• Clearly Documentum’s • Performance: full round
direction trip for almost all
• All the benefits of Java component events
and relevant standards • No migration path
• Good • JVM compatibility
business/presentation issues
logic separation • WebTop has huge
usability issues

18. Recommendations(?)
• Consider WebTop and WDK for new efforts
where:
– Performance is not key
– Client platform is under tight control
– Expected product life cycle is not very long
– In-house Java expertise is solid
• Similar considerations for DFC, but DFC may
work better when you want no Java on the
client side

19. Recommendations(?)
• Use C or Visual Basic against the API (or
against a DFC-API wrapper) if the WDK
conditions aren’t true
• For older systems, keep them if they aren’t
changing until Documentum forces an
underlying server upgrade
• For critical, still-evolving systems, start
planning a migration to WDK, DFC, or API