"Aspects" in the (terminated) Avalon

Niclas Hedhman niclas at hedhman.org
Tue Nov 30 04:58:36 EST 2004


On Tuesday 30 November 2004 17:17, El Quijote wrote:

> As I still have to finish my work I hope that you guys maybe can help me
> out.

Will try.

> The text is perhaps not entirely well stated. Avalon needed cross-cutting
> concerns across components. Instead of going aspect orientation with a new
> language, or other declaration + heavy reflection, Avalon chose to keep it
> fairly simple. It is not AOP, it is a solution that is less complex than
> AOP that fulfill most of the need.
>
> The interfaces referenced in the text are the Avalon Framework classes.
> ------------------------------------------------------------
>
> I don't understand the last statement. It seems to conflict with the
> following
> Summary: this is the next logical step ofter Separation of
> Concerns. Many concerns cannot be centrally addressed using the standard
> OOP mechanisms.

It is somewhat difficult to unnest the thinking of someone else (who wrote the 
passages you are quoting).

To make the story even more complex, there have been many discussions within 
Avalon previously to create a more proper AOP at various levels ( btw, is 
that what you are quoting?), including the ability to create components that 
could be injected into the call chain of all the other components.

So,
1. Avalon Framework in its original form is SoC and IoC in its essence.

2. Some containers (like Merlin) allows for aspects by having a proxy injected 
between the component and its clients. It is also possible to define for 
instance LifeCycle extensions, which will be applied to components that 
implements the life cycle extension interface in question. This is also a 
kind-of AOP at the container level.

3. Custom aspects were discussed but never implemented. Whether these will be 
implemented in Metro is yet to be determined.

The 1. is not really AOP, but it has enforced (good or bad) the same handling 
of logging, parameterization and configuration onto all AF components.


The 3. is about allowing the injection of an aspect (which would be a 
component) into the call chain of one or many other components.

 +--------+     +------------------+     +-----------+
 | client |---->| Metro Activation |---->| component |
 |        |     | Component Proxy  |     | method    |
 +--------+     +------------------+     +-----------+
                   |             ^
                   |             |
 +-----------------+             +------------------------+
 |                                                        |
 |  +---------+    +---------+    +--------    --------+  |
 +->| aspect1 |--->| aspect2 |--->| aspect ... aspectN |--+
    +---------+    +---------+    +--------    --------+

where each aspect is basically a normal component, with a lifecycle and so 
forth, but implements an interceptor interface, which deals with the call, 
return and exception handling.


In my personal opinion this seems like fun, but I have not yet seen any good 
use-cases for it, and that is probably the main reason why it is not yet 
implemented in Merlin nor Metro.


Cheers
Niclas

P.S. For any further quotes, please state the source, so I can check the 
surrounding context from which the quote is extracted.



-- 
   +------//-------------------+
  / http://www.dpml.net       /
 / http://niclas.hedhman.org / 
+------//-------------------+




More information about the support-dpml mailing list