techno.blog("Dion")

Is it sad that the mentions of AOP these days relate to code like:

String.prototype.capitalize = String.prototype.capitalize.wrap(
function(proceed, eachWord) {
if (eachWord && this.include(” “)) {
// capitalize each word in the string
return this.split(” “).invoke(”capitalize”).join(” “);
} else {
// proceed using the original function
return proceed();
}
});

“hello world”.capitalize() // “Hello world”
“hello world”.capitalize(true) // “Hello World”

Ron Bodkin has written about Performance monitoring with AspectJ: A look inside the Glassbox Inspector with AspectJ and JMX, which is part of the AOP@Work series.

Say goodbye to scattered and tangled monitoring code, as Ron Bodkin shows you how to combine AspectJ and JMX for a flexible, modular approach to performance monitoring. In this first of two parts, Ron uses source code and ideas from the Glassbox Inspector open source project to help you build a monitoring system that provides correlated information to identify specific problems, but with low enough overhead to be used in production environments.

The article gets into some serious code, and discusses:

• An aspect for capturing time and counts of servlets
• Managing overhead
• Thread safety
• Exposing performance data
• Exposing beans for JMX management
• Database request monitoring
• Servlet request tracking
• JDBC monitoring
• Tracking JDBC information

Not only is this a great example of seeing *real* AOP at work, but it also let’s us see the work being done in Glassbox, which wil hopefully end up with us being able to find problems in our software a LOT faster!

It has been a big couple of weeks for the stars of AOP and AspectJ 5.

Firstly,

Jonas Boner, the founder of AspectWerkz (and now AspectJ 5) has moved on from his post with the JRockit VM team at BEA, to join Terracota… the AO caching folks.

I guess that most people have not missed that I am leaving BEA. Yesterday was actually my last day as an BEA employee.

I have had two great years at BEA. It has been a great experience to work at the Java Runtime Products Group (JRPG), (JRPG is the group that implements the JRockit JVM), not everyone gets the opportunity to work among so many extremely talented and smart people, and that is something that I am very grateful for. I have learned more in these two years that I had in my whole career.

I am also grateful for that JRPG has believed in AOP and my vision, so much and that they have allowed me to work full-time for two years to materialize them.

Then, Adrian Colyer, the AspectJ lead who worked at IBM announed that he is joining Interface 21 as the Chief Scientist. This is great for Interface 21…. I don’t know many people as bright as Adrian. It is also great for Spring users, as we are going to see some impressive things in the Spring framework coming up!

I’m pleased to announce plans for much closer integration between the Spring and AspectJ projects in the near future. Spring and AspectJ already fit well together: Spring can be used to configure aspects, aspects can be used to drive Spring configuration, and we are working on opening up the AspectJ pointcut language so that external tools can create pointcuts at runtime, and then perform matching. This facility will be used by Spring to support AspectJ pointcut expressions in its AOP proxy framework.

As of October, this relationship will move onto a new level as I have resigned from my current post at IBM to take up the post of Chief Scientist at Interface21. I will continue to work on and lead the AspectJ project (no change there), and will also be working on some of the Spring core and AOP support to make the integration with AspectJ as seamless as possible and to take the AOP message to as broad an audience as we can. I’m leaving behind a fantastic IBM team who have worked with me on AspectJ and AJDT these past few years, and they will carry right on working on these projects when I leave. Rest assured that I’m still working flat out on completing AspectJ 5 too.

Congrats to both Adrian and Jonas. I look forward to seeing the great work that comes from you in your new posts, and via AspectJ 5 in general (which they are both still going to be actively working on!)

It was nice to read Jonas Boner talk about the session at JavaOne 2005 on AOP in the JVM.

This will be the first time ever to show an enterprise JVM – BEA JRockit – with native AOP support. Alex Vasseur and myself have been pushing for this idea since the early days of AspectWerkz when we joined the JRockit group, and it’s finally taking shape, with now support for AspectJ 5, the de-facto standard for AOP in Java.

Credit should also go to Joakim Dahlstedt, the CTO of JRockit, who has been playing a leading role in the design and implementation.

We will talk about the current problems with bytecode based weaving (multiple agents, double bookkeeping, performance etc.) and then discuss how these problems can be solved through native JVM support. We will show a prototype of our implementation, go through the programming model and run a live demo.

Having native AO support in the VM will be very cool indeed. Microsoft has some features itself in their research VM called “Phoenix”.

Technorati peaked my interest when it found the same entry regarding AOP and Ajax.

AOP and Caching

I was recently developing a new AJAX based system for picking a drugs from a long potential list. Specifically, there are two drop down lists – picking an element from the first select list makes the page look up the entry from the server.

In itself, this is rather unexciting, but i got a chance to code is in what is IMHO a rather elegant manner:

I used JSON for the javascript-server client communication, and spring+hibernate for all server side interaction. Now, at this point, we are still talking a decent implementation, the part that I really liked was using AOP for method level caching.

I had to have a little Friday chortle when reading that the WS-* stack are aspect oriented protocols.

Personally, I would agree that they are AO, but not AOP :)

A group of people were talking at No Fluff Just Stuff, and Richard Monson-Haefel brought up using AOP to manage multiple products from one code base.

It can actually make a lot of sense. Imagine having a software product that has:

• Express: A bunch of enterprise features are disabled
• Standard: fully featured, but none of the hard core enterprise features
• Enterprise: Enhanced enterprise features

Then there could be trail editions of the various products.

30 day aspect

To handle a trial period, an aspect could be woven into the code to handle all of the crippling.

For example, WebLogic used to let a few IP addresses to hit the server only. An aspect could track the incoming IPs and block after the allowed number come in (of course, some people just put WLS behind a proxy to trick it! Lots of 127.0.0.1 comes in ;).

This could be reused among all editions of the product.

Throttling aspect

Let’s say the Express edition only allows X concurrent uses of feature Y. A simple set of aspects could throttle the features.

Additional behaviour

Additional enhanced behaviour could get weaved into the core.

IBM Cloudscape vs. Apache Derby

There are rumours that IBM uses this technique already. With this, they can add in the enhanced transaction support and other features that make Cloudscape from Derby.

I had a double take when I saw the following show up:

Aspect-Oriented Analysis and Design at 30% off

Register – London,England,UK

Site offer Aspect-oriented programming (AOP) is a revolutionary new way to think about software engineering. AOP was introduced …

I want to get 30% off of my time spend on AO Analysis and Design!

Then I followed the link to find that this was for 30% off the BOOK on the topic ;)

Cedric has responded to the article on TheServerSide, Implementing Object Caching with AOP.

He discusses the coupling issues that are intrinsic to any of these crosscutting problems.

The nice thing about AOP, is that it gives you the tools to add to the balance.

You can choose to:

• Use a marker based approach (@annotation / marker interface / naming convention in methods [normally bad])
• Have a more complicated policy defining a pointcut in code (e.g. List around(String productGroup) : getInterestRates(productGroup) {)
• Define a DSL in some form to handle the configuration

At the end of the day, these are all the same in more ways than they are different. Cedric says:

It should be configurable externally. You don’t need AOP to branch conditionally and disable (or alter) your caching logic at runtime. Most of the EJB and web containers that I know have been providing this kind of functionality in XML files for quite a while.

This is an example of a DSL. In this case, there is a very formal way to specify SOME form of caching for EJBs. It is very limited, but it is well specified.

A lot of the time people want a lot more control (and not be forced to use EJB ;), and that is where the other options come in. You could create your own XML definition which powers the caching configuration (an Aspect could grok that), you can use annotations if you think it makes sense to declare the configurability of the caching IN the area of the code, or you can modularize it completely by NOT having this, and having it all in an external aspect. At this point your code doesn’t know about the caching cross cutting concern.

In my opinion, there is no RIGHT answer for all of your needs. As with all these things, depending on your use cases, you will find the right balance.

We added Tangosol Coherence to the TSS code way back, and we only needed caching in the form of DATA caching. Thus, we could add it to our persistence layer, in one simple place, and the AOP approach may well have been overkill here.

But there are many other types of caching, and I think an AOP modularization of this concern makes a lot of sense.

Alex Vasseur (of AspectWerkz/AspectJ 5) has written a thorough piece on EJB 3 and AOP: the EJB interceptor dilemna.

He delves into issues with the EJB 3 specification of interceptors (wrt AOP), for example, having to specify interception via:

@javax.ejb.Interceptor(”test.ejb3.MyInterceptor”)

He also complains a little about current preview implementations:

After having a look at JBoss EJB 3 and OracleAS EJB 3 previews, I was even more disapointed. Both of them are using a reflective based approach to invoke the interceptors. This means that the performance of the interceptor will be bad, and that a Heisenberg effect will be inevitable and actually fairly big (no wonder that ones will use interceptor to gather performance metrics and thus as soon as you observe the bean, you are observing a different things than what actually happens).

Ones may say this is a microscopic view. It is. But when thinking about EJB 2 stories in the past a sound idea would be to make sure we don’t waste resources where we can avoid it. And thinking about JBoss history around AOP, that’s rather suprising that the EJB 3 interceptors are not cleanly integrated in their AOP framework. I personnaly consider that we have enough technology around to make it far better, and far more consistent with AOP. Given the impact that AOP will continue to have, ones would better figuring out how to do that now with EJB 3 – assuming that EJB 3 succeeds.

He then spent 1 hour IMPLEMENTING the spec itself using the AspectWerkz AOP container, which is pretty damn impressive IMO.

Alex is even kind enough to put in some thoughts on the spec:

There are some odd things in the 3.5 section of the JSR-220 that I have spot:

• (sect. 3.5.1) an interceptor class or EJB can only have one single @AroundInvoke method (advice) in it, and its signature is (sect. 3.5.4) “@AroundInvoke Object someNameOfYourChoice(InvocationContext ctx) throws Exception”. Why limitating that to having one single method in the interceptor class or EJB (sect. 3.5.1). My guess is that it is tied to the fact that precedence between advice would then be harder to define in the spec without new semantics. Then one might wonder why an interceptor is not defined as an interface with one single method “intercept(…)” that the EJB could implement as well. Having this interface would suppress the need for @AroundInvoke which sounds like an annotation overuse (unless it is a door open for vendor extension as I will do below..). I’ll be interested in EG feedback on that topic, especially in regards of the first limitation.
• interceptor components life cycle is unspecified but stateless. That sounds like a very important and powerfull concept of AOP (especially AspectJ) that has been left aside. It is probably an interesting door to provide vendor specific extension ie thread safe interceptor, per bean class interceptor, per bean instance interceptor, per application interceptor etc (but then interceptor component may not be stateless anymore.)
• (3.5) an interceptor intercepts all business method (or MessageListener methods for MDB). This means that every interceptor will be poluted with a code snip like “if (invocationContext.getMethod().getName().equals(”doSomething”)) …” ie ones will have to write sort of a pointcut in a very loosy way while AOP allow us to write that in a neat way (and further, a way that tools can easy understand to spot which method is intercepted by what).
• javax.ejb.InvocationContext is tied to EJB. What will happen when interceptors will end up somewhere else ?

Fortunately, the implementation exposed in this article addresses those issues nicely from a vendor specific extension perspective.

Awesome stuff Alex.