AOP anyone?

[Nilesh Pereira]

These days the latest buzz word seems to be Aspect Oriented Programming (AOP), with everyone from Marc Fleury (of JBoss) to Grady Booch (of the three Amigos) touting it as the future of programming. AOP is supposed to complement Object Oriented Programming, not replace it. I still haven't seen any job postings requiring AOP, but I'm curious to know if there are any real world projects out there already using AOP. If so, I'd be interested to know about the challenges that were faced, and the success that were had using AOP. Thanks!

[Lasse Koskela]

I'm afraid you'll have to wait for a looong time...
I am convinced that AOP has solid aspects going for it but I am also convinced that it'll take a couple of years before AOP gets attention in bigger, "real-world" projects. Sun adopting, say, AspectJ syntax and vocabulary as a Java standard extension for AOP would make a big difference.

[Tim Holloway]

It's been puzzling to me why I haven't been seeing position postings saying must have 5 years AOP along with all the other drivel. I've been watching AOP for close to 2 years now and, while there appears to be good support in Emacs and Eclipse (also Borland, I think) for AOP, there just hasn't been anything on it it the software development magazines and other places of public exposure.
I haven't decided whether AOP is a "silver bullet", but there are certainly some things where an Aspect-Oriented approach is a good idea - and here I refer to more things than just AOP coding. One of the few things I liked about OS/2 was that you could create "folders" that displayed aspects (though they didn't call them that). They were collections of objects having a useful commonality that might not all be closely related in the filesystem. I've heard rumours of other desktop systems looking to go that route as well, but so far I don't think anything's hit the mainstream.

[Nilesh Pereira]

Lasse, maybe that's why nobody has responded to this thread, eh?
Tom, LOL, yeah, 10 years of java, 5 years of EJB, 5 years of AOP...
I don't think that AOP will ever be a "silver bullet", because it doesn't attempt to solve all your problems, just those problems that cross cut across several unrelated classes. I would think that Inheritance and Polymorphism are still better ways of adding features to classes that are related to each other.
I've read that the EJB component model could be considered to be Aspect Oriented? Declaring Transactionality, Security, etc. of an EJB is equivalent to defining an Aspect, even though it does it declaritively and without using any special language constructs. The EJB compiler adds the required EJB functionality to the classes, much like an Aspect compiler would add any Aspects.
Any thoughts on that?

[Gopi Balaji]

Originally posted by Nilesh Pereira:
<snip> but I'm curious to know if there are any real world projects out there already using AOP. If so, I'd be interested to know about the challenges that were faced, and the success that were had using AOP. Thanks!

I have used AOP in a small production application, for logging and tracing purposes. The biggest challenge I faced was political - acceptance. Although this wasn't a spectacular success (no critical functions were modelled as apects. So, removing the AOP/aspects would not damage the functionality at all), it was kinda proof-of-concept.
I am encouraged to use it in the next (bigger) application.
-GB.

[Gopi Balaji]

Originally posted by Nilesh Pereira:
[Snipped]
I've read that the EJB component model could be considered to be Aspect Oriented? Declaring Transactionality, Security, etc. of an EJB is equivalent to defining an Aspect, even though it does it declaritively and without using any special language constructs. The EJB compiler adds the required EJB functionality to the classes, much like an Aspect compiler would add any Aspects.
Any thoughts on that?

There is an interesting conversation going on in AspectJ's user mailing list along the same lines..
My thoughts are: -
1. AOP adds more benefits in some cases of EJB-environment-like cross-cutting concerns. It can be used beneficially in such cases. For general cases, no special value is added by AOP.
2. It has been successfully used by JBoss to implement these same concerns. Although JBoss allows you to extend these, I suspect not many people use it. Its more of an AppServer developer aid than a business application developer aid.
[Thoughts broken.. have to go now]
-GB.

[Ilja Preuss]

IMHO, AspectJ is a somewhat "dangerous" implementation of AOP - as aspects are woven into the code by pattern matching of class- and method names, you can change the behaviour of a method by changing its name! I really dislike this idea...
Regarding AOP in general, I think it is an interesting concept, but we probably need to wait some more years to see what usage patterns prove to be usefull.
Personally, I still strive to handle the art of OOP, so I don't yet need another dimension of complexity...

[Nilesh Pereira]

The reason I'm asking these questions about AOP is because I'm still trying to figure out if learning AOP in detail is worth my time.
AOP represents a radical paradigm shift for me - I'm still recovering from the shift in thinking from procedural to OOP! But the benefits from moving to OOP definitely made it worth the effort.
I think a major challenge for me would be in figuring out how I would incorporate AOP in my designs. Right now, I can only find information on how to code using AOP.
Also, wouldn't using AOP make debugging really really difficult?
Any insights would be very much appreciated.

[Gopi Balaji]

Originally posted by Ilja Preuss:
IMHO, AspectJ is a somewhat "dangerous" implementation of AOP - as aspects are woven into the code by pattern matching of class- and method names, you can change the behaviour of a method by changing its name! I really dislike this idea...[snipped]

The more accessible the method is, the more wider the impact of changing its signature.
If you change a method's name, you also have to change the name in all places where it is being called/invoked. And, the aspect(s) advicing a joinpoint involving that method is one such place.
To aid in such changes, we have to have good tool support - as provided for plain Java in Eclipse (has anyone in the forum used Smalltalk and would care to share their experience on refactoring support?).
It is entirely possible that the tool support is extended to change the PCD declaration of an advice in AspectJ, to reflect changes in method signatures. I think an effort is being made by the AJDE team in this direction.
IMHO, I think it is "dangerous" to change method signatures without excellent tool support - AspectJ or no AspectJ.
-GB.

[Gopi Balaji]

Originally posted by Nilesh Pereira:
[snipped..]
The reason I'm asking these questions about AOP is because I'm still trying to figure out if learning AOP in detail is worth my time.
I think a major challenge for me would be in figuring out how I would incorporate AOP in my designs. Right now, I can only find information on how to code using AOP.
Also, wouldn't using AOP make debugging really really difficult?

My humble opinion, it is worth any developer's time.
There are several papers in the academic world which deals with designing using aspects/AspectJ. [Throwing away my laziness, I could've provided some links, but you can very well do it better by doing what I will do - googling]
Good tool support for an aspect, and testing-debugging strategies will definitely help in aiding debugging of aspected code.
In fact, aspects themselves can be considered as an aid for debugging.
Also, this (difficult to debug) is nothing new - think of debugging EJBs, MTS components, CICS transactions etc.. - you get the drift.. any code which runs in a managed environment is difficult (meaning here as not straight forward) to debug. Aspected code can be thought of plain code running under a managed environment. What do you say?
-GB.

[Gopi Balaji]

Originally posted by Ilja Preuss:
[ snipped.. ]
Regarding AOP in general, I think it is an interesting concept, but we probably need to wait some more years to see what usage patterns prove to be usefull.
[snipped .. ]

Agreed. But, this is just a matter of how much comfortable one is with new and sunrise technologies/methodologies/paradigms.
On one hand, we can wait and see what patterns prove useful. Or, on the other hand, we can start using aspects and we might dictate what these patterns look like. (Romantic thought, eh?)
-GB.

[Nilesh Pereira]

Does that mean I have to stop coding in vi???
Thanks Gopi, Ilja for your insightful comments. I think I'm ready to get my feet wet now
If anyone wants to post their thoughts or experiences using AOP, please continue to post on this thread. Thanks.

[Jon Dornback]

can anyone post a link to a good explanation of what AOP is/how to use it? The definition on the asod.org website is pretty vague.
Thanks!

[Nilesh Pereira]

I found http://www.voelter.de/data/articles/aop/aop.html to be a good starting point.
There is a pretty extensive listing of AOP links at http://www.iturls.com/English/TechHotspot/TH_e.asp.
[ April 25, 2003: Message edited by: Nilesh Pereira ]