This post originated from an RSS feed registered with Java Buzz
by Talip Ozturk.
Original Post: AOP... go figure!
Feed Title: Shared Memory
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: about java, jini, javaspaces, programming, aop and a little bit of me and life.
Jon Tirsen's AOP manifesto is quite right in my opinion. I found it very descriptive, well formulized.
I am also using my own Dynamic Proxy based AOP framework in JPower. One thing that I found very important is the need for declaring control flow checks. Let me explain a little bit. An object in AOP is composition of aspects (= advices + introductions). Aspects are supposed to be as much independent, pluggable or unpluggable at any time as possible. Just like JMX mbeans. It is perfectly OK to have dependency among aspects and framework can/should take care of this. This leads to more flexible design and development. While we are trying to decouple the aspects, we should make sure that the framework is control-flow aware. lets say my aspected object has A, B, C, D aspects and aspect C needs to be running in the control of aspect A meaning; A is controlling the behaviour of C. This is such a nice feature that is easily achievable with AOP. It is even better if framework would double check the control flows. Meaning If I mark C as an aspect that has to run in the control of aspect A then the AOP framework can check on this. Even when writing the aspect C, in the code, I should be able to say something like
if (AOPFramework.isThisInTheControlFlowOf(aspectIDofA)) doThis(); // pick a better method name though :)
else doThat();
You may let AOP framework to manage the control flows in a way that ,for example, If aspect C is added then AOP framework may check if the controller aspect A is added, if not then the framework adds it. Framework says 'if you want to use aspect C then I will add the aspect A if not there, because A has to control C.
One other thing is that framework should be able to deal with dependencies between advise and introduction. Because in most of the frameworks (I might miss one or two), you add advices and introductions independently. This might sound like a good thing but I think framework should be able to tell you something like 'hey, you cannot add advise A without adding introduction X and Y because advice A operates on the state that X and Y introductions hold.' A good framework should sometime limit what you can do; it should not let you do something wrong/error-prone.
The biggest difficulty I am having regarding AOP is not being able visualize a very complex system being aspected. It is hard to divide the system into aspects and figure out how the aspected object hierarchy should look like. It is hard to define the horizontal and vertical links between aspected objects in a manageable, clean way. horizontal links are easier than vertical ones. I heard/read many component level examples and talks but I wish to hear more design strategies/patterns/hints on entire system. I wish people who managed to write fairly large applications with AOP could share their experience and discuss their framework/design at system/architecture level rather than component/aspect level. We should talk more on AOPfied architectural diagrams, aspect diagrams and such to get the big picture.
Previous Topic
