Since the beginning, the integration part of Grid Computing products was a sore point. APIs are complex, non-intuitive and vendor generally assumed that people writing grid-enabled software would be willing to spend a significant time on grid-enabling process (changing their applications, learning complex grid APIs, etc.).
When we set to tackle this problem in GridGain we quickly realized that AOP can be a ticket here. Now, I've had experience with AOP a number of years ago (when AspectJ just came out) and having studied and used it back then quite intensively I came away rather disappointment by how little applicability it brings. I still believe that AOP is a niche technique but when you find such niche it usually fits like a glove.
I think AOP makes an almost perfect fit in our product and that's why:
- Grid-enabling (at least in Java) most often comes down to grid-enabling a method call. No matter whether you are grid-enabling an existing code or developing a new - you will most likely deal with one method. Java5 annotations and AOP pointcut model provide perfect tooling for defining all necessary information to grid enable a specific method.
- AOP allows us to grid-enable not only the application for which you have source code, but also for applications for which you don't have a source code (or even documentation). For non-splitting scenarios (like in on-demand computing) you don't even have to know anything about the method - even a signature.
Think about it: using GridGain with AOP integration you can grid-enable your current application, someone else's framework, your favorite app server or even a standard JDK. In simple cases you don't even have to write a single line of code as you can apply aspects via external XML definition - and in the same time you have full power of AOP's pointcut model at your disposal.