Aspect-Oriented Programming with AspectJ 496
| Aspect-Oriented Programming with AspectJ | |
| author | Ivan Kiselev |
| pages | 274 |
| publisher | SAMS |
| rating | Excellent |
| reviewer | Verity Stob |
| ISBN | 0672324105 |
| summary | Introduction to a new programming technique using an extension to Java |
He has divided the book into four parts. Part I provides a brief sketch of AOP and introduces its concepts. AOP builds on OOP, asserting that we need a new programming entity called, wait for it, an aspect. Mr Kiselev's explanation of aspects reminded me of that bit in The Hitchhiker's Guide to the Galaxy when the planet Golgafrincham divided its population into A types (who were the leaders, the scientists and the great artists), the C types (who were the people who did all the actual making of things and doing of things), and the B types, who comprised everybody left over: telephone sanitizers, advertising account executives and hairdressers. As I understand Mr Kiselev, the AOP view of things is that objects and classes (A type thinkers) and low-level procedures and APIs (C type doers) can be nicely encapsulated using traditional components. But aspects, software's little hairdressers, get their fingers into everything, and until now there has been no way to encapsulate them. This of course is what AOP in general and specifically the AspectJ superset of the Java language set out to do.
AspectJ's eponymous aspects are constructs not unlike ordinary classes. Mr Kiselev has not resisted the temptation to make an aspect Hello World example, and it looks reassuringly so-whatish:
package intro;
import java.io.*;
public aspect HelloWorldA
{
public static void main(String args[])
{
System.out.println(Hello, world!);
}
}
Mr Kiselev then lays out his stall of New Things. A join point is any point in execution flow that AspectJ can identify and -- to get slightly ahead of ourselves -- execute some extra code. The most frequently used kind of join point being the call to a method. Pointcuts specify collections of join points; as a regular expression is to an instance of matched text, so a pointcut is to a matching join point. An advice (with horrid plural 'advices') is the code to be executed when a given pointcut is matched. If you are familiar with Eiffel's pre- and post-conditions, then you'll understand if I say that it is common for advices to run in the same way, topping and/or tailing the execution of a method. The differences are that aspects are specified from outside the method without touching the method or its class's code, and that aspects can be applied to multiple methods in one go. Mr Kiselev concludes this section of the book with a few simplistic examples of 'here is class A, here is class B' kind.
In Part II Mr Kiselev rolls up his sleeves and takes us through an extended, realistic example. I did wonder if perhaps it weren't a wee bit too realistic, as it is a miniature website application for news story submission and reading -- sort of Slashdot Ultralite -- all done using JSP and a MySQL database. Just explaining this setup, without even using any AspectJ, consumes a 15-page chapter. Since I am a C++ programmer who has not had any contact with JSP, I was initially anxious that I might not be able to follow this. However, recalling that www.[name withheld].com, the clumsiest, ugliest corporate website on the Internet, is programmed in JSP, I reasoned that if the dolts that programmed that site could understand JSP then it couldn't be very hard. So it proved.
The first example comprises adding password protection to the application. This is achieved by adding an advice that intercepts calls to doStartTag() methods. The advice can test if the user is logged in and, if he isn't, throw an exception that will dump him back at the login page. (Who says exceptions aren't 21st century gotos?) At this point Mr Kiselev admits that the cute 10-line implementation that he initially shows is in reality a non-starter; for one thing not all pages that must be secured define doStartTag() methods, for another the aspect can't reach an instance variable it needs to read because it is declared in protected scope. The second problem is easily overcome. AOP offers a mechanism by which extra classes can be bodged ('introduced' is the preferred verb in the AOP community) into the hierarchy as parents of existing classes. He uses this to add an accessor method for the field in question. The other problem is not so neatly smothered, and it is somewhat ruefully that Mr Kiselev produces his final, two-page solution. But I think that it is greatly to Mr K's credit that he does this - it tastes like programming in the real world as I have experienced it.
For the rest of Part II, Mr K demonstrates other applications of AOP using the AspectNews code. This includes Eiffelish design-by-contract stuff, improved exception handling, various debugging and tuning techniques (specifically logging, tracing and profiling) and a chapter on runtime improvements - stream buffering, database connection pooling and result caching - which show the AOP way to do things, usually where I would expect to be putting in proxy classes.
In part III we get down and dirty with the AspectJ language. This is the part where the book explains the obscure stuff: how to make a pointcut that picks up object preinitialization, or make an advice that goes off only when you are exiting a method on the back of an exception. I skimmed this bit - I guess it will become vital when I start using AspectJ in earnest. It looked good and clear on a flick through. A brief part IV contains some patterns, to give one a start when engaging AspectJ in earnest. Apparently it is horribly easy to create infinitely recursive situations, so if you here a faint popping sound from your machine it will be the stack colliding with the heap. There are seven appendices, supplying such things as a summary of the API in AspectJ's packages and hints on obtaining and using the Open Source supplementary tools mentioned in the book (Tomcat JSP container, MySQL database and Ant make replacement). AspectJ itself, now escaped from Xerox PARC, can be downloaded from the Eclipse website.
Complaints? None really. Oh all right, here's a nitpicklette because it's you: at page 75 Mr Kiselev adopts the irritating Internet habit of writing 'loosing' when he means 'losing'. Note to publisher SAMS proofreaders: do I win 25 cents?
For the rest, this is a lucid and readable book that describes the Next Big Methodology. I'm a bit alarmed at the prospect of squeezing new actions into the cracks of existing code, but I dare say I'll grow to love it.
A word of warning to the eager: since this technology is currently implemented as a species of preprocessor that relies on having all the source code available at once, so it is rather slow and probably isn't going into production shops for a while. There again, I seem to remember the comparable Cfront C++ compiler doing rather well, before we had platform-native C++ compilers.
And to the sceptics: if you think you can ignore AOP, don't forget the fate of the A and C type inhabitants of Golgafrincham, who having sent their B type telephone sanitizers into exile were all wiped out by a germ caught from a particularly dirty telephone.
You can purchase Aspect-Oriented Programming with AspectJ from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
So, what is this? (Score:2, Interesting)
Where's this useful? (Score:1, Interesting)
I honestly don't understand the applications for this. Maybe it's just because I'm reading the review rather than the actual book, but it does'nt feel all that useful.
I can understand the benefits of OOP over standard top-down programming, but I'm failing to see where this coding methology gives you any gains.
Re:Where's this useful? (Score:2, Interesting)
I have a bad feeling about this (Score:1, Interesting)
Sounds like a code maintenance nightmare if there ever was one. And I don't even want to think about all the "But I thought Joe put that safety check into the advice so I didn't worry about it in the main class" problems.
Re:Where's this useful? (Score:2, Interesting)
Re:Where's this useful? (Score:3, Interesting)
AOP is a very interesting notion in that it allows you to separate your concerns. Application logic, security, logging, transaction maintenance, etc, etc, etc. All of these things can be written separately but are then woven together at specific critical points. The result of good AOP programming is that your code is cleaner, and the guy writing application logic thinks only about application logic, not about persistence, caching, security, etc, which are all implemented as separate conerns and woven together later.
The real power is the ability to define this at runtime instead of compile-time, though. Imagine this- you write a generic caching and persistence layer for an application. You write this once. Then, at runtime, any time you want to apply this persistence layer's functions to an object, you just instruct the application (through a config file or some other means) to weave the persistence layer in with a specific object. Boom. Instant persistence. You could do this with any feature really, as long as you wrote each aspect generically.
This is a pretty extreme boon for certain classes of applications. Specifically, take any application that's modular or componentized. Each component can now have additional services dynamically bound to it. You can apply code as a policy over any activity...field modifications, method calls, constructors...etc. As a result, you can apply special policies to modules or compnents in your application without having to actually code them in to the component.
Other possiblities include applying advice to the constructor of Thread objects that checks threads into a registry on their creation. Now, every thread in the VM has a handle in this registry. If a thread flies off into an infinite loop, you can see the stacktraces of all the threads easily and have a better point to investigate from.
It's worth noting that the applications that really will benefit from this methodology...applications servers...are taking note of it. The JBoss 3.x series was written with a limited form of AOP that can only apply policies in limited ways to objects that implement certain interfaces. The next major version of JBoss promises the opportunity to leverage runtime AOP so that any Java object can have server services bound to it regardless of whether it implements an EJB interface or not.
Again, though, the power comes in in the ability to make these pointcuts at runtime. AspectJ, as far as I know, still doesn't offer this, so you can't dynamically change the aspect policies in your application dynamically. That makes AspectJ pretty useless for AOP in my book.
Then again...I could be talking arse. Here come the flames!
Re:Where's this useful? (Score:3, Interesting)
The nice thing, then, would be a smart editor which is aware of aspects, and can draw flags on top of the source code you're reading so that the programmer is warned that an Aspect will be sticking it's nose in.
Even better, you could click those flags to apparently expand the aspect's code inline, revealing exactly what statements will execute when the function runs. Of course, this can't be reliably done in all cases, if the Aspects are something that can be toggled on/off as the program runs.
In that case, the editor might have to be pessimistic, and assume "an Aspect might apply here...". But that might not work well either. In the end, you need smart programmers, both writing the aspects, and using them.
Re:So, what is this? (Score:5, Interesting)
It's my opinion that, if you have to ask that question, then you and everyone else on your team are doing AOP in a bad way. The entire function of AOP is to separate disjoint concerns so that you don't think about them when you're programming. You write application logic. Your fellow team member maintains your security aspect. You don't ask "When I call this method, will it trigger the security aspect?". Especially in a world of runtime AOP, it's not possible for you to really have a reliable answer.
Long story short- if two separated concerns in AOP have such a sufficient dependency that you have to ask yourself a question like that, then they should not be separate concerns at all. At least, in my opinion.
Re:This is not good (Score:3, Interesting)
This attitude is already pretty common. "Oh, we can't understand what this library does, so we'll write a transparent wrapper which instruments all function calls, so we can gain a clear picture of what's going on"
If AOP was used, then at least when a programmer decides he's got to throw a wrapper on something, he can do it with a few lines of code (define an aspect on the classname, using wildcards), rather than spending all day to copy & paste every single function in the class and add his 3 lines of "instrumentation".
And then when his foolish adventure is done, and the extra code is nothing more than a drag on performance, it can be removed (or just disabled) from a single place, rather than once again scrolling through all of a class's source code to touch each and every method.
Hasn't CLOS had this sort of thing (15 years ago) (Score:3, Interesting)
If I remember correctly, in CLOS you can specify a method "foo", and then another method "foo" with the ":before" modifier that would be executed before the normal "foo" method. There is also an ":after" specifier.
Re:So, what is this? (Score:1, Interesting)
Game and simulation programming lends itself perfectly to aspect oriented design because it's full of objects and events which must be responded to. For example a "banana" object might have a "before eating" action which checks that the banana has been peeled and an "after eating" action in which it removes itself from the player's possessions and places a "banana peel" object there instead. A "monkey" object, might have an "after player enters room" action in which it attempts to steal the banana from the player. Since there are an unlimited number of possible events, it is impractical have a virtual function for each of them, so aspect-oriented programming is the only viable solution (especially if you want to create extensible libraries).
Re:So, what is this? (Score:3, Interesting)
There's quite a bit of repetitive code created (copied & pasted, then search & replaced) when you make a delegator. Hopefully, Aspect-Oriented would let you skip the mechanical work of writing a delegator, and just get on to using it.
You might describe it as the programming language compiler becoming aware of a pattern, and learning to implement it when told.
Re:Hasn't CLOS had this sort of thing (15 years ag (Score:3, Interesting)
I did see a project on sourceforge to add explicit AOP to Ruby, perhapss making code more understandable, but of course one can hook methods without it
Books (Score:4, Interesting)
What, like The Art of the Meta-Object Protocol [mit.edu] by the very same Gregor Kiczales et al, pub. MIT Press, 1991?
Like most things, AOP is only new if you don't know LISP.
AOP is useful, but not well suited to Java (Score:3, Interesting)
I think the reason there are so many 'huh? why do I want to do all this?' responses is that Java is not a language that lends itself to AOP, and that AspectJ therefore has to build this scary layer of 'pointcuts' and so on on top of it.
With a language that lets you assembly types dynamically, like Ruby or Perl, AOP is much simpler and more natural, so it's easier to get a feel for the benefits.
In particular I think Ruby is well-suited, although you do lose some type safety. There is a package called AspectR available, although you *could* do it all youself with mixins and the like.
Re:So, what is this? (Score:3, Interesting)
I bought it - its worthless! (Score:4, Interesting)
So I bought it, and I was excited when I began reading. Then I found out it was just a bunch of JSP and other then the first 25 pages, very little content. Now I admit I put it down a good 25 or so pages later and skimmed through the rest, but I was extremely disapointed in it. Instead I've been grabbing all of the ECOOP workshop documentation.
In the end, it was worth the money. No, not for the book, god no! But by getting me excited and reading the ACM Communication articles and then talking to my adviser about it. It turns out the editor for the AOP material in the ACM communications is a professor at my school, and even better is happy to let me help her out next semester (I'm extremely swamped now). So now I'm considering doing the thesis option on my masters. I'll spend the summer reading REAL material.
My opinion: AOP is awesome but the book is a waste of money. Here are a few good readings:
Alternatives to AOP [lancs.ac.uk]
Generitive Programming chapter [tu-ilmenau.de]
AOP publication [parc.com]
AOD 2002 workshop [iit.edu]
ECOOP97 [uni-trier.de]
Re:So, what is this? (Score:1, Interesting)
if the purpose of AOP is to remove the actual logging calls from the data module you wouldn't be doing any logging i suspect. unless the calls were stealthily inserted by a preprocessor or some other tool. which isn't good either because then you can't tell whats really going on.
pick a methodology and stick with it, not for a few months, try a decade. if its really that good its worth hanging onto.
Re:So, what is this? (Score:3, Interesting)
Bounded and large would be worse enough. Let me rather cite:
My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.
AOP, like operator overloading in C++, can introduce amazing surprises to a programmer. A small innocent source code file in the collection of hundreds of source code files can change the behaviour of a program in an unpleasant way.
Regards,
Marc
Breaking encapsulation (Score:2, Interesting)
Aspect Oriented Programming claims to support a new kind of modularity, but what it really does is break encapsulation.
Imagine you're responsible for a module in a big system. Over the years, well meaning aspect oriented programmers stick more and more little hooks into your code. Eventually like Gulliver, when you try to move, e.g. fix or improve your code, you simply can't without breaking the hooks that tie you down.
If they had used your published interface and you designed a good interface, you would have been ok, but no! They reached into your code and created dependences on your implementation. If it's production code and you break someone else's code, you'll be seen as the bad guy.
Many years ago I used Xerox Lisp machines and worked near the inventors of Aspect Oriented Programming. I used two precursors of AOP. I used the advice mechanism in InterlispD and later Active Values in it's object oriented extension Loops.
When used very sparingly, advice was useful, especially for debugging and working around bugs. The advise function allowed you to add wrappers to functions that would replace, preceed or follow the invocation of the function. You could further restrict the advice to apply only when a function was called from within another function.
Active Values, on the other hand, were an advice mechanism applied to object field access. People quickly realized that the facility was a mess because there was rarely any hope that you could get your advice to run *only* when you wanted it to and rarely any hope that you could avoid a unreadable tangled mess. There were new getter and setter functions that didn't trigger the active values, but this just added even more complexity.
It would be much easier to design an explict hooks than to worry about what happens if someone sticks an active value in any and every object field. Especially when the field may already have an active value.
It's vital to be able to assume that when you read a line of code, you know what it means and if not, you know where to look up what it means. Rather than enabling hacks like aspect oriented programming, we need better tools for making clean changes that sweep across the source code and thereby do away with the urge for this perilous patching stratgy.
Re:Where's this useful? (Score:2, Interesting)
Every example of AOP I've seen uses the "logging example" (is AOP actually useful for anything else?)
In this example some sysout is printed after certain method calls.
methodFoo();
methodBar();
both trigger message();
so what? Can't this be done with java style event handlers and triggers? Are there benefits of AOP beyond oberserver/oberserved type relationships?
Why LISP is not mainstream... (Score:2, Interesting)
(tail (make (get (blah (foo()), bar())))))
In the end, this lang vs. that lang is "fundamentally superior" is all bullshit since practically all languages are Turing equivalent, so practical acceptance comes down to ease of learning, readability, API and platform support, speed, and sensible amounts of syntactic sugar.
Java does all those things pretty well. LISP had 50 years to gain acceptance, and it hasn't. It has had numerous evangelizers, even whole tech startups, and all for naught.
Oriented Programming (Score:2, Interesting)
Table-Oriented Programming (TOP): http://www.geocities.com/tablizer/index.html
(I found this very good)
Subject-oriented programming:
http://www.research.ibm.com/sop/
There are one or two other ideas and paradigms out there as well. I personally hope that TOP finds its way into more major languages. But then again, I also want more APL operators in Perl
Re:Yet another reason to switch to Lisp (Score:3, Interesting)
Re:So, what is this? (Score:3, Interesting)
That's a true statement about any program. Just try tossing in a random uninitialized pointer or runtime exception here or there in any utility function, rebuild, and see what happens.
I've written "aspect"-like code before... a system that I worked on not too long ago (hey, Honus!) made use of a pretty nice set of functions and macros in order to:
This involved manually adding the appropriate macro at the start and end of each function. A pain in the butt, and the inevitable tyop came back to bite you hard :-/ IMHO, this is the type of problem that aspect oriented programming is intended to solve.
Yah, improperly coding an aspect could cause all sorts of heartache and difficult to solve problems. But... when we did the same thing by hand, it still caused heartache and difficult to solve problems. I'll take AOP (supported by an AOP-aware debugger) over doing this sort of thing by hand any day of the week.
Re:Verity Stob (Score:3, Interesting)
Nicely written, informative book review, too, by the way. Hope we see more of her here!
Speaking of weird things to like about Dr. Dobbs, does anyone else look forward to the PC-Lint advert/riddles every month? -- Asking that feels strangely embarassing, similar to asking "Does anyone else ever find that they've been talking to themselves for the last hour with the office door open?"
Re:Hasn't CLOS had this sort of thing (15 years ag (Score:3, Interesting)
Yes, and relational databases have had trigger methods before and after different SQL operations. You can define 12 triggers on a table in Oracle, made out of combinations of (before, after) (insert, update, delete) (for each row, for each statement). You code them in PL/SQL which is a fairly comprehensive language similar to Ada. Is AOP merely triggers for Java methods? Because you could do that already, by subclassing, overriding the method, and calling the superclass method within your own code.