Hi all,
coming from JavaZone in Oslo, I got very inspired by the talk that Rickard Öberg was
giving on his AOP thoughts and his own AOP framework.
Basically, he has removed all methods and interfaces from Objects and introduces all
logic with Introduction Aspects on the objects at runtime.
The objects are just dumb things that only provide a placeholder for the attachement
of Aspects that take over the implementation of all the interfaces that might be used
from other objects.
Any group of functionality is defined by an interface, much like in Avalon/Merlin. But
the implementaion is not provided in the ojbect but in Aspects, so even the
implementation becomes reusable over different classes needing that funcitonality.
There are different scenarios:
1) the Object declares the function groups compile time:
public abstract Person implements Nameable
{
}
and the aspect will be attached that implements NameableService with getName() via a
query language (point cuts etc.).
2) at runtime, the Person object wants to act like a Startable, so the aspect is
introduced first then (kind of lazy loading).
As I see it, Merlin has or could have all the elements that would allow a similar
functionality to work on Containers/Components. I guess the instrumented elements
would be containers that in the future act exacly like components (as Stephen
suggested) with Container configuration, container context, parameters etc.
I'm thinking of such scenarios as:
- the declaration of (non-overlapping of course) multiple services at Container level
that could either be routed to another component/container or inserted at
assembly/runtime via a query language on the Dpeloyment model or resolved
automatically as it is now via automatic insertion of dependencies
- adding/changing of new functionality on Containers via the same mechanism (basically
changing the dependencies of a component at runtime)
- In addition to the class-level AOP, container-based AOP could even route
functionality on a aper-method level to other components with the same approach.
- the introduction of a query language for the Deployment model (a la
OGNL/SQL/OQL/AspectJ etc) for the traversal, selection of models and:
- change of their dpendencies
- load/unload
- route dependencies etc. etc.
I could think of a model like:
<container name="Dynamic">
<service type="Nameable">
<getName source="persistenceService">
<setname source="setNameStore2">
</service>
<service type="Startable" source="StartStopComponent">
<service type="Executable"/> //will be looked up via static AOP at assembly
time, see below, or simply as a container-dep via the dependency resolution
<service type="AnotherService"> //will be resolved at dynamically at
assembly/runtime
<container name="pesistenceService">
<service type="Nameable" source="nameStore1">
<component name="nameStore1"..../>
</container>
<component name="StartStopComponent"..../>
<component name="ExecutableComponent"..../>
<component name="NameStore2"..../>
<staticAOP>
<cuttingInstruction>
<cut>
<path="/Dynamic.Exceutable.*"
source="ExcecutableComponent" serviceLifecycle="transient">
</cut>
</cuttingInstruction>
</staticAOP>
</container>
Rickard was suggsting that the full migration to AOP-based programming can replace the
OO-approach. Of course, the tooling is not there and there are no patterns/practices
etc. for the granularity of concerns (e.g. the granularity of the interfaces), but
that's a thing that the avalon community has delt with for a long time.
What that would mean is that all Merlin will have an approach to AOP or at least SoC
that is Component-based, has at least the same strength as AOP and a few advantages:
- the smallest parts ar Components, e.g. stackable, distributable, self describing,
repository-awareness, Ioc etc., so alal Merlin benefits kick in.
- no bytecode/JVM/mixin magic required
- coming closer to taking the whole programming model for complex applications one
step up from classes to Components by providing suport for the two major modern
programming paradigms at component level: OOP and AOP/SOC
Im not quite sure what more the implications/benefits are, but it souded cool to be
able to at least balance the programming logic between OOP and AOP.
Just some random thoughts.
Wdyt?
/peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
