Re: [aspectj-users] Drawbacks of AOP

[Arno Schmidmeier <A@xxxxxxxxxxxxxxx>]

On Monday 21 April 2003 18:17, John Rayburn wrote:
> > But the problem here is that the deployment descriptor/ejb container
> > approach to transactions is very specific and binds my transaction
>
> service
>
> > to a very specific specification. What if I want to produce a
>
> container that
>
> > can use different "plug-in" declarative services? Ask anyone that
>
> works with
>
> > HIPPA in security or web services with transactions as to why.
>
> However, this is not always a requirement for a project, so both ways
> (descriptor/container vs AspectJ) scale differently, and per project
> this would be a decision that would be made by the team.  

Here is the first big difference. Assuming you have a container approach, all 
this decisions have to be done quite early in the design phase and you have 
to live with all the policies/constraints of the container. Changing one is 
pretty hard if even possible.
In the aspect solution it is pretty easy. Just changing one simple aspect.

> They both
> provide solutions to implementing aspect oriented cross-cutting
> concerns...

That is wrong. Correct is:
They both provide solutions to implementing THE CONCERN TRANSACTIONHANDLING, 
PERSITENCY, ... .

>
> From: "Marc Tremblay" <marc@xxxxxxxxxxxxx>
>
> >Reply-To: aspectj-users@xxxxxxxxxxx
> >To: <aspectj-users@xxxxxxxxxxx>
> >Subject: RE: [aspectj-users] Drawbacks of AOP
> >Date: Thu, 17 Apr 2003 14:54:36 -0600
> >
> > > > 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.
>
> >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
>
> _________________________________________________________________
> Add photos to your messages with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
> _______________________________________________
> 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.