[Reprinted] Rod Johnson's text on AOP transaction

[Original author] Rod Johnson
[LINK] http://www.theserverside.com/news/thread.tss? Thread_id = 27208 #129224
[Comment] Rod Johnson, the Founder, leader, and one of the major developers of springframework, naturally has some weight to say. Although this passage is just a response to others' questions, but it contains a lot of information, as follows:

• Spring's AOP for the transaction management, as currently seen in aspectj's transaction implementation;
• The support for aspectj will be integrated in spring 1.1, which is great!
  
• Spring 1.1 RC1 will be released soon, and it is likely to be available on the weekend of next week.

[Original]

Jacob

I recently read aspectj in action from manning press. it discusses transactions too, but through aspectj and the resulting efforts are not container dependent. I think that spring as an IOC container is great, but if people want aspect oriented features, just do yourself a favor and learn aspectj in eclipse with the ajdt plugin. none of this runtime proxy of invocationhandler stuff to slow down your application.

Rod's answer:
Aspectj is a great language: no argument there. I also like laddad's book. but aspectj is not the perfect solution to all AOP problems, and often simpler, lower-Tech, solutions are compelling.

Transaction Management is a case in point. for a lot of middleware aspects, which typically require only method interception, aspectj's full power doesn't come into play, and it has no greadvantage over Spring AOP, dynaop or another Proxy based framework. for example, laddad's book is excellent, but the transaction examples are just that -- examples of how you might start work on Transaction Management in aspectj. spring's transaction interception is way more powerful than anything I 've seen implemented using aspectj. of course you can implement whatever sophisticated of transaction interception you like with aspectj -- it's just that what really matters is how you abstract the underlying transaction infrastructure, not what AOP framework you use. the performance overhead of a proxy-based approach is insigificant in such cases.

So there is a valid case for the subset of AOP that proxy-based solutions provide. (Also they can do one or two things that are hard to do with "full-blown AOP," such as maintain different advice for different objects of the same class .)

Having said that, I believe that aspectj is going to become increasingly important as we come to understand the full implications of AOP. so one of the major features in spring 1.1 is aspectj integration. this will allow aspectj aspects to be configured by the Spring IoC Container Using dependency injection, which brings similar benefits to applying DI for classes. both Adrian Colyer and I are very excited about this, and both spring and aspectj teams are working together. support for the core aspectj integration is already in spring CVs and will be released with spring 1.1 RC1 (probably end of next week ). i'm also working on some samples, which will probably be released separately slightly later. the spring/aspectj integration opens up some interesting possibilities.

Beyond that, we're looking at using aspectj pointcuts to target Spring AOP advice. This relies on aspectj changes -- they are going to expose an API for spring and other tools to use at runtime.

Another interesting area is implementing spring services as "native" aspectj aspects. Thus we'll provide a transaction aspect, probably in the spring 1.2 timeframe, although I might release it with the samples.

RGDS
Rod