Re: [aspectj-users] Drawbacks of AOP

[Arno Schmidmeier <A@xxxxxxxxxxxxxxx>]

On Thursday 17 April 2003 22:54, Marc Tremblay wrote:
> > > To me this is the kind of thing that should be handled declaratively in
> > > a deployment descriptor and applied by some sort of runtime container
> > > (not nesc. EJB, but along those lines).  To me, implementing things
> > > like transaction management, security, etc. as an aspect leads to
> > > hidden complexity and thereby can render the code unmaintainable.
> >
> > ...
> >
> > > I certainly agree with you that these crosscutting concerns don't
> > > belong in the code itself, but I just think the deployment descriptor
> > > approach is a better one than using aspects.  Just because we can solve
> > > these problems with aspects, doesn't mean aspects are the best way to
> > > solve these problems.  These concerns are the kind that should be
> > > handled in a container or runtime framework in my opinion.
> >
> > That's identical, though. One could write an aspect that parses that
> > exact same deployment descriptor and accomplish the same thing with an
> > aspect.
> >
> > It's simply a matter of syntax for maintenance.
>
> It's identical with respect to the effect to be achieved.  However, it's
> very different with respect to on the one hand I'm writing aspects to
> manage these concerns, and on the other I'm relying on some 3rd party
> container/framework provider to take care of it for me.  With the later I
> really don't care how they handle these concerns so long as they do.
>
> I guess what I'm getting at is that I see the problems of transactions,
> security, etc. as already being solved well enough that I'm not interested
> in finding other solutions for them.

Where is the difference, between an aspect solution and an EJB or "container" 
solution, when you simply use an aspect library (maybe from a third party)? 
You simply have to write your "deploymentdescriptor" in an aspect-form and 
you are done.
However the aspect approach has some big advantages. 
1. You can simply reuse the pointcut definitions for other aspects. (As I 
pointed out in my speech at AOSD 2002, infrastructure aspects tend to reuse 
the same pointcuts.) 
e.g. you could reuse the transaction-pointcuts for auditing or access control.
2. If you can not life with the transaction policy, persistence policy, etc. 
you can simply switch the relevant aspect. You are not bound by a take it or 
leave it decision as you are by current "container"-architectures.

>
> Logging, resource pooling, and enforcing design by contract ideas have not,
> to my knowledge, been solved in an adequate manner in the Java environment.
>
> -- Marc
>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users

-- 

******************************************************************************
Arno Schmidmeier
+49/9151/90 50 30
or A@xxxxxxxxxxxxxxx
******************************************************************************
Yes, I have realized several projects with AspectJ.
Yes, I do provide consulting for AspectJ.