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)

2 thoughts on “An Aspect of My Disappointment”

  1. AFAIK the example Jython script was not developed by EMC but by a partner (I could be wrong on this). It was somewhat verbose but it would be straightforward to refactor that code to make it more concise and less Java-esque. In the discussion thread for that Jython article I mentioned that by using scripting languages you could end up with code like this -> Although you could knock up DFC wrapper libraries in Jython, Scala, Groovy, JSR-168, etc and make it available as Open Source, what I would really like to see is EMC investing the time in this. It’s high time that DocBasic was replaced anyway – let EMC push a JVM-based scripting solution that they will support.

    Being a Documentum developer I am quite envious of Alfresco and their implementation of Aspects, Web Scripts, Scripting, etc.

Leave a Reply