Documentum Aspects

Documentum 6 adds a new framework for modifying and extending object attributes and behaviors, independant of object type.

What are the best practices that take advantage of the new capabilities?
How do you use (or intend to use) Aspects in your Documentum applications?
What tips do you have for others who are starting to explore Aspects?
What would make using Aspects easier?

This is all pretty new, so this is a great community collaboration opportunity!

Find more posts tagged with

Comments

leecsmithcap

Interesting post.

I see Aspects are used as the basis for the Records Manager implementation, and in particular. Someone in EMC must have made a decision that aspects were the right approach for this. Would like to know the rational for this.

Zakusov

I'm interested too!

Does somebody use it in practice?

Chaithanya

Yaa people use aspects in practice, but I dont how wide the usage Im just putting my understanding around this. Aspects are used used dynamicall attach state(attribute) and behavior(functionality) and detach the same when the corresponding functionality, or attached attribute is no more required to object instances. An aspect module created once with state and behavior can be reused where ever required.A single persistent object can have more than one aspects attached with or without an attribute. It is an attempt to eliminate the classical problem of type explosion that comes with traditional inheritance and which leads to unmanagable type hirerarchy after a while, it eliminates need for creating a custom type for each and every requirement. Let's take a simple example you have an custom type of invoice which is used by different departments in your organization, and you have an requirement for instance of invoice to hold different set of attributes when it is in different states(if it has been attached to workflow and can be different states such as watingforapproval, approved) and which varies on department using he invoice type. Then normally we go ahead create a custom type extending base type custom invoice like invoice_marketing, invoice_management etc, if we keep on creating custom types for each and every small requirement then you end up in a large hierarchy. Also you may create a TBO for functionality associated with custom type.

Using aspects you can live with the same base type invoice_type and attach attribute and behavior to instances based on requirements of the departments, even lets part of behavior is common between two departments you can reuse the same aspect modules created for both. Even if the department needs an attribute to be dropped or requires new attributes to be added there is no need to create custom types you can go ahead create ascpects..attach the new and detach the old which are not required.

It comes with lot of flexibility.

venkas6

Hi,

Since the question about Aspects, I thought of putting this broader description Of how Aspects work as was detailed to me from one of the Architects:

Aspects are like "traits" in academic OO (traits in Scala, modules in Ruby etc). You can statically associate aspects with types using alter type
statement. In this case every instance of the type will have the aspect attached. This technique is useful for type composition.

You can also dynamically attach aspects to individual instances of any type (almost) using the code defined below. This allows for partitions of objects
within the same type or across types. You might use this capability to add retention to a specific object, eg.

If you define behavior for an aspect it will be treated like a TBO of sorts. Actually, any aspects on an object will have their behavior appear as if
they were successive subclasses of the relevant TBO (this happens through byte code manipulation).

Aspects can have state as well as behavior. You define aspect state pretty much as you would for types, except there is an extra attribute metaproperty
called "qualifiable". A qualifiable attribute exists in the actual tables and is therefore selectable. Non-qualifiable aspect attributes exist in the
hosting object's property bag only and are not selectable. Aspect attributes are referenced using a qualified attribute name of the form
<aspect>.<attribute> using all the normal attribute access mechanisms. If you define state for an aspect then the aspect name should follow type
naming rules.

There is some trickiness if you attach or detach an aspect during a save operation in a TBO or aspect (basically don't). Otherwise, aspect state
should operate fine with saves.

To create an aspect you use Composer. You *must* have an aspect module artifact, although it doesn't need any code. You can optionally have an
aspect type artifact if you want state. The alter type facilities require the presence of an aspect module in the docbase to work - you can't skip
this step.

I have added some detail about dynamic attachment from an earlier email exchange. You might find it helpful.

Dynamic Attachment
------------------
If you are a regular client just use the sequence ..

(IDfAspects) obj).attachAspect(³foo², null);
IFoo = (IFoo) session.getObject(object.getObjectId());

The reason you have to do the getObject is that the aspect magic causes the actual Java object (obj) to become ³stale² in a special way (we don¹t have
time;-), and the object id, along with all its related state is reconstituted in a new Java object (which alone has the new interface).
getObject recovers a reference to this new Java object, you are happy, and the old one just fades away.

However, if you are executing in the context of a TBO or aspect method on obj itself when you try to attach the aspect, then you are executing on the
³old² object that is about to become stale, and the new object has not been built yet, so getObject just returns the same old disappointing Java object.
You then have to use callbacks. Callbacks are invoked just before the original entry point to the outermost TBO or aspect method invocation
returns and have a kind of implicit getObject associated with them. You can think of them as delayed client code. Do not do getObject within a callback
the object reference your callback is given is the new, beautiful, predictable Java object.

Those are the only two situations you should have to consider.

Aspects are black magic, so you pay a little price in complexity, but they are super-powerful in return. You don¹t really want to know what¹s going on
- it¹s kind of like making sausage.

Thanks,

Sekhar