An Aspect of My Disappointment

I found EMC’s webinar, Leveraging Composer and Aspects, informative given the format and one hour time limit. Composer is the Eclipse plug-in and looks good overall. An aspect is a software design technique which could revolutionize Documentum data architecture. How EMC implemented aspects, however, repeats their architectural mistake with DBOF. Oh well.

Composer looks competently-enough done to be a welcome replacement to the persnickety Documentum Application Builder (DAB). The look and feel (and clutter) is pure Eclipse–no sexy Apple minimalist influence here. The win here is one-stop shopping: Developers won’t split their attention (nor workstations their resources) across two programs. That’s definitely a Good Thing.

Aspects in theory are great. They allow per-instance extension of both state and behavior, so objects get what they need when they need it. The reduction in type bloat alone is worth it. There’s no need for all those “optional attributes” just in case a particular instance becomes a document of record or gets included in a submission. Fabulous. In happy wonderful fantasy land, I’d scrap dm_document completely for a true lightweight object, then staple on versioning, lifecycles, web content, retention, and whatever as needed.

Aspects bring some real architectural benefits, too. Adding an aspect at runtime doesn’t require ALTER TYPE activity which can crap out the database on some really big (or really underpowered) docbases. Older docbases will also benefit from this easy way to add and remove new functionality without the potential dangers of hacking around the existing type hierarchy. Documentum architects now have a built-in way to do composition, a technique that is largely replacing inheritance in OOP design theory because it keeps the design open and adaptable.

Aspects in practice aren’t so great. My fear that aspects would use the DBOF model of requiring Java code client-side has been confirmed, although they made an effort to minimally support DQL since attributes are involved. (No word on DQL limitations imposed by aspects yet.) Turning the docbase into a JAR pusher has improved the deployment situation, but it’s still pushing functionality too far up the stack for my liking. More moving parts mean more things can fail, get out of sync, or confound.

This design flaw will persist for as long as EMC is swinging their Java hammer, even on screws like scripting. Perhaps EMC catching onto jython a few months back means they’re reaching back into the toolbox. Funny how they had to make a simple script look so big with all the extraneous print statements–very Java of them. If only there were another way to pass messages from a client to Documentum without the DFC. Hmmm.

Here’s what I’m thinking: All custom client applications and integrations should use DFS going forwrd–assuming it doesn’t have its own issues. DFC programming should be restricted to the uber-server, that big box drawn around the real docbase servers, webtop servers, DFC servers, full-text indexing servers, site caching servers, etcetera. Only push DARs–yes, they had to go there–to Documentum application servers. What goes on in the uber-server stays in the uber-server–including every single line of DFC code.

Aspects are too useful to discount for a few architectural missteps–as long as you’re careful where you walk.

Tech Deep Dive: Exploring Documentum Architecture — Leveraging Composer and Aspects
Available soon on EMC Events On Demand (developer access may be required)