techno.blog("Dion")

• Realise that Thinking in Aspects is a mind-shift
• Spend some time exploring… and embrace the mind-shift
• Start small: explore with AO in your own personal code, and then follow the adoption curve: starting with testing/tracing/non-production, capture simple policies, low risk / high reward aspects, and on-wards
• Favour OO interfaces (just a check, to make sure you aren’t going to AO for fun :)
• Make your first AO project be a small one, and expect to learn from mistakes
• Understand the power of aspects, and that with power you have to be more responsible.

It is so interesting to watch up we take input, and somewhere in the process it gets munged up in the brain.

I do this all the time. When I look at something I just typed, such as a piece of code, I don’t see what I typed at all. Nope. I see what I thought, wanted, and should have typed.

I was talking to another kind soul today about AOP. I happen to be a fan, an advocate, or whatever you want to call it. Does this mean that I believe that if we all start to use AOP that software will suddenly become simple? Suddenly we will not make anymore mistakes in our design? Of course not. This is just a tool folks. A tool that can help with the complexity of cross cutting concerns.

How many cross concerns are out there? A bunch… Is everything a cross cutting concern? Not even close.

I was told that the AOP guys are touting that it is the best thing since sliced bread, that it is a saviour, and that this is going to bring on a nightmare as people abuse it. I asked the fellow to show me ONE example of a thought leader (using the term just to piss of Hani) in the AOP space saying this. Of course he couldn’t. The real thought leaders rarely do!

AOP is a great tool, but just like we have learned to favour compositionin OO, we should favour OO interfaces compared to AO. What does this really mean? It means… when you start…. REALLY think about if it makes sense to use AO. Don’t just run into it…. think really hard, what are the implications? Write some test first code that has a few use cases to make sure it still makes sense.

So, listen to the AOP mentors (of which I am not one by the way!), not the people who jump on the bandwagon!

Of course, my little blog entry won’t stop anything.

As Mike Spille wrote:

When a novel technology just starts to come into common practice, there seems to inevitably be a cycle that has been repeated from time immemorial:

• Early adopters experimenting all over the map
• Said early adopters writing optimistic and enthusiastic articles about it
• “The masses” start to adopt based on the early adopter’s enthusiasm
• Early results are good, because people always start small and they benefit from the “low hanging fruit”.
• Over time, usage grows, complexity in usage grows, people start to see the downsides
• As more time goes by, people will write books like “Bitter AOP” and “Pragmatic AOP” and “AOP Sucks – The Case for Procedural Programming” :-)
• A few people will note that the gist of these books are issues that were obvious early on to the early adopters, but were suppressed and/or ignored due to undue enthusiasm or an unconscious need to suppress negative comments

Now I would temper one thing said. Said early adopters writing optimistic and enthusiastic articles about it. We have to listen to the folk who are really using it versus any ole early adopter.

I hope the mistakes are tamed a little this time around, and we don’t all start writing everything as an aspect.

Obviously it depends on your project, your thoughts on AO etc… however some have said that:

90% of code will be handled via OO. 10% of it can be more cleanly designed with aspects

NOTE: Again, just to make sure… when I talk about the AOP mentors I am thinking along the lines of these guys

I enjoyed the article Implementing the Null Object Pattern using AOP, by Dale Asberry.

It is another example of how you can take something that is “annoying” in your development, and having an elegant solution with AOP.

NullPointerException’s are such a pain. Whenever you get a NPE in your app as a developer you sit back and *sigh*. “Time for the debugger”, and you know that it could be awhile.

With a simple aspect, and the right pointcuts, we get real information about the ugly NPEs.

I somehow missed the developerWorks article: Use AOP to maintain legacy Java applications.

What is more interesting to me than the tech in the article itself, is that fact that these articles are coming out.

Developers are starting to read about AOP and its various uses. This article discusses a use case which is simple to get your feet wet. You can play with aspects in development to mine your code, and it never touches the more dangerous grounds of production.

Every time I hear an AOP expert discuss the ramp-up of AOP they show “the curve”. The curve talks about how you can start dinking around in development (tracing and such) and slowly move up the stack as you become more familiar with AOP. Learning to think in AOP isn’t trivial so this approach is very much needed…. to ramp up your brain. You will make mistakes at first (as with any new tech) and you don’t want your first mistakes to cross-cut on every piece of code in your running production system.

I am really excited about the marriage of AOP with the new JSR 175 annotations. As I have mentioned before, I am a little worried that they will be taken too far, and we will run into @ hell.

Having annotations in classes are cross-cutting concerns themselves, and so we have a chance to deal with them in some cases via AOP.

This will naturally happen anyway. Tools that have up until now said “A method that is set*() is a setter” will probably start to use:

“A method that is set*() AND doesn’t have a @nowrite annotation
OR
A method that has a @write attribute

This is just due to some legacy rules that we have lying around.

Some scenarios will be ripe for us to just slap on some annotations manually. These will be for the types of metadata that don’t tend to be slapped on a huge amount of methods all over the shop.

The other side of the house has cross-cutting concerns that can applied to a heap of methods. The exteme would be something like having to put @log on every method that you wanted to log!

For this scenario we can mix AOP with annotations. AOP will be responsible for weaving annotations into our code.

Right now we use AOP to put marker interfaces on certain classes… e.g:

declare parents: org.atrack.ui..controller..Edit* && Action+ implements StartsApplicationTransactions;

With metadata we will be able to do something like:

declare annotation: org.atrack.ui..controller..Edit* && Action+ annotates @Transaction(type=”Requres”)

I had a nice chat with Jon Tirs

People were bubbling at AOSD after the IBM keynote. It has been quite widely known that quite a few large companies are using AOP, but keep it hush hush. Now the time is coming where it is actually “cool” to differentiate yourself by aligning with the technology, and many companies are seeing how it is helping their lives.

I think it says quite a lot when a company as large as IBM can get a new technology as different as AOP into their large bureacratic departments. They do have the most to gain, but it still a big effort. Adrian’s life is going to get even more crazy in the coming year (Adrian is the lead on AspectJ, and great guy).

Getting developers to think in aspects is no mean task, but we will get there. Gregor uses an interesting story when introducing AOP:

In AspectJ there is an example used which is a GUI figure editor. If you ask today’s developers to think about how they would solve this problem they will probably come up with:

We will need a Point class, a Line, an abstract Shape, etc etc. Basically they are trained to think in objects now.

However if we asked this same question 20 years ago what would those programmers have said? They would have talked about creating a table of X, Y co-ordinates and drawing functions. The idea of thinking in objects would be foreign for them.

This is where we are at now. One of the beautiful aspects of AOP (pun intended) is that a team can use it incrementally…. and in fact this is what the leaders in this space PREACH. Don’t go out and start building a full AOP production project. Start small. Use it to do some analysis (such as IBM doing this to find a bunch of policy breakages in their products). Use it to enforce certain policies. Then strap it into development to enable tracing and exploration of code. By the time that you are here…. you will be familiar with AOP and will be ready to keep moving up the stack slowly. It is very easy to do the wrong thing with AOP, and this incremental approach minimizes this risk as you cut your teeth on non-mission critical areas.

Let’s continue the slow but steady march of AOP!

IBM endorses AOP: “It is vital for our survival”

While in a session at AOSD there was talk of a Diagnostic Exception Handler. In my experience, developers are (in general) pretty crap about dealing with exceptions. If you don’t have a process to follow it is bloody hard to do the right thing all the time (and isn’t always easy when you do have a plan to follow).

I wonder if a Diagnostic Exception Handling engine would help. In the AOP world is would be cross-cutting advice, so in your code you wouldn’t have to do anything differently (just try/catch/throw). A handler would apply advice at the right time and could put it through an engine that could work out what to do with it.

Depending on how advanced you got this could involve:

• Simple: Just taking care of your logging needs
• Do certain retries
• Simple logic: e.g. commit() if app exception, rollback() if system exception
• Run the exception through workflow logic that could try to really do The Right Thing

We will always have to think (god forbid!) about what to do wrt exceptions in our code, but it would be interesting to see if a nice system could help us out….. or it could just be total overkill ;)

I fly back to my native London this weekend. It is great to be back, and I will enjoy my time here (have already had a great curry!).

Tomorrow I meet up with Ron Bodkin, and head up to Lancaster, for the AOSD 2004 conference.

I am looking to see this years Aspect Oriented show, as AOP is growing slowly but surely, and this year sees a mix of academia and the private sector. I am also looking forward to putting some faces to the names!

I hope to see you at the conference!

Ramesh Loganathan asked AOP & EJB/J2EE- any synergies?.

I personally think there are some obvious synergies, but the main point that I want to respond to comes from this paragraph:

Regardless, the fact simply remains that AOP cannot be a panacea for Systems Design issues. It is at some level, (even if I risk a sweeping conclusion here) not too different from say using a logging framework. Albeit, it can do a little (;-)) more than just logging. It can only “extend” an existing complete biz application to perform some additional plumbing. But cannot be used to build complete end-applications!

• AOP is not a silver bullet
• AOP does not mean you don’t do OOP anymore
• AOP makes sense as a solution for CROSS CUTTING CONCERNS

I have to keep saying this, as I don’t want people to go down the same route as we did with OOP (and others) and think that everything should be an object. That is not the case. We need to use common sense, and move slowly.

Ron Bodkins, Ramnivas Laddad, myself, and others are working on an open source project that shows AOP in practice. We have some really nifty ways to handle:

• Persistence: The user doesn’t have to worry about Hibernate sessions, you just use your POJOs
• Security: The policy is external. One place to set it all up
• Virtual Mock Objects: AOP can really help out here
• … and many more …

We of course have a solution for logging, but I don’t want to mention that as people get SO distracted by AOP logging examples.

In our project there is PLENTY of OOP going on, with a sprinkling of AOP to help out where needed. We don’t go the extreme and do the following:

class Person { }

… aspects use mixins and other advice to plug everything in …

Don’t use aspects unless it makes sense. Do use them when it DOES make sense. With polymorthism in OOP we now favor composition. We can do the same in AOP… to keep us on track.

I am excited to be heading to the AOSD 2004 in the UK (Lancaster? weird). I think this will be a good year for AOP… so lets see where it leads us :)