This post originated from an RSS feed registered with Java Buzz
by Carlos Perez.
Original Post: Ideas on How to Build Reusable Aspects
Feed Title: .:Manageability:.
Feed URL: http://www.manageability.org/blog/stuff/rssDisabled?portal_status_message=Syndication+is+Disabled
Feed Description: Random thoughts on the manageability of complex software.
One of the unresolved issues of Aspect Oriented Programming (AOP) is the issue of reusable aspects. Reusability can come in many forms, one is "can an aspect be reused in a different context?" another kind is "can aspects be composed?".
To get a feel of reusable aspects of the first kind study "Aspect-Oriented Design Pattern Implementations". You'll can also find a quick summary on this blog entry from Merrick Schincariol. In short you can apply the Template design pattern, resusing either pointcuts or methods, or as Merrick illustrates exploiting interfaces.
AspectJ's implementation however is in the static sense. For the dynamic kind, take a look at how AspectWerkz does it. The author was clever enough to recognize its utility and added the ability to hot deploy and reconfigure aspects dynamically. There are a few more items in my wish list though, but based on the speed of his progress, I'm confident he'll reach that milestone before anyone else recognizes its utility.
However for the second kind, that is for composable aspects, it appears to remain an unresolved issue. This was best illustrated by Cedric Beust's "AOP Caching Challenge". However, there seems to be this fallacy going around in the .NET world that AOP requires aspects to be orthogonal. ( Of course, what the .NET folks terms as AOP is attribute based interception kind, the sad part of it all is that JBoss Group accepts the same definition! Its simply unfortunate that the term has been hijacked in this way. )
Now of course someone else recognizes the flaw and says "services are not generally orthogonal". Rather than using a code generation approach, as recommended by the former author, he chooses a dynamic approach. Clemens Vasters is contemplating some kind of coordination mechanism based on two phase commit protocol:
A promising approach is to make aspects/interceptors act like resource managers and coordinate their work using a very lightweight 2PC protocol ("AC" guarantee only; no "ID"). Using 2PC for this approach allows interceptors/aspects to coordinate their work and know about each other before any work actually gets done. I have discussed these issues with a couple of people in depth we put some code together that essentially implements a little, in-memory "DTC" for that purpose. We call it a "WorkSet" instead of a transaction.
So it's something like this, all applicable aspects in a joinpoint are asked to consider if they can apply themselves, all return a confirmation or rejected and possibly based on some voting scheme perform the actions required of each individual aspect. Of course, I don't know if the details have been worked, however it's a promising perspective.
In the same blog entry someone else makes the remark:
We have a separate 'Problem Resolution' service which is also enrolled in the context, and, in the event of failure, the context gets passed to the resolution service to deal with whatever issues were raised by the orchestrated services.
So in general people are thinking of different kinds of coordination mechanisms. Either some variant of 2PC or a kind of "conflict resolution" that we've previously found in optimistic locking protocols. Only time can tell which approach may work best, however I'm curious to ask, just like we have ACID for transaction management, what properties are essential for dynamic composability of aspects?
Previous Topic
