Bio Adrian Colyer is the leader of the AspectJ project and a well-known industry expert on AOP. He is a co-author of the book "Eclipse AspectJ : AOP in Eclipse with AspectJ and AJDT," and has also published numerous book chapters, articles and published papers. Adrian is Chief Scientist at Interface21, providers of the Spring Framework.
My name is Adrian Colyer and I'm probably best known for leading the AspectJ project, on eclipse.org, I was with IBM for many years as a senior technical stuff member but I recently moved and now I'm chief scientist at Interface21, best known as the company behind Spring.
I've evolved with Aspects for at least 5 years now. The research and the background go back probably another decade, although Aspects are appearing to many people in the industry a fairly new thing. Actually they've been growing for quite some time so it's not that new. We're now really starting to see a shift in the adoption (when I go and give talks people raise their hands). Relatively recently, like 2 years ago, we would get 20% or a third of the audience say "yes I've heard about AOP in some way or another", but now it is pretty much every hand all the time. Now, 20% of the people are saying "we're actually doing something with it". Depending on the way you phrase that question, you can get more or less hands raised.
I've gone to enterprises and I said "How do you get started with Aspect? What are the beginning steps?" We've got a road map and we basically said: "what you don't want to do is rush on day 1 with a new shiny toy Aspects everywhere, change all your tools, your processes, your organization. That might be exciting but it probably has a high risk of running into trouble. If you net out a few stages. In the first stage you don't use Aspects in your production system, but it turns out that it can do a lot of useful things for you in terms of design level assertion, which is just simply using aspects to make sure that certain properties you want to be true about design and architecture are really expressed in the code which you couldn't easily do before.
Aspects can help you with debugging and diagnosing problems with testing etc. A whole bunch of useless things you can do to help you learn the technology a little bit, but with very little risk. There are a lot of people getting on that rung of the adoption ladder at the moment and probably that's where the majority of folks are because most people coming in again started. As you move on from that stage use Aspects to help with what I call infrastructure type issues. People talk about Aspects, they come with this classic list and you get tracing, logging, transactions, security, cascing or polling or whatever, it is that list of the Java.util of the Aspects world; that's a good next place to go because it's not your core business logic it's important and often cross cutting Aspects can be a good fit there. Quite a number of people pushing into that stage of adoption, at IBM certainly there are a number of products shipping that level of adoption of Aspects in there.
A third stage is where you embrace Aspects as part of your business domain logic so let's call those domain aspects. There are less people pushing to that stage now but you start to see the signs to see the change on the AspectJ users' list a few publicised examples. Nick Aziki at VMS did some good stuff that talked about using Aspects for shopping baskets for example). Totally different from the kind of aspects people are talking about. While the infrastructure ones are like java.util of aspects, so just like in OO you have many many more domain specific objects than you do have Java libraries, so actually with Aspects there are many more domain specific aspects than the usual list we talk about. Those examples and people at that stage of adoption there's not so many there yet, but it starting to come, and automatically I think that's where it will end up.
Basically Aspects are about modularity, that's where I start most of my talks with. If I got some requirement (business or domain level requirement) that I can't express in one single modular place in the code, that's the candidate for an aspect. You tend to find things like business rules and policies and ramifications of those, for example, often a fairly and easy map into an aspect like solution. There's no dogma there. You might find an aspect that helps you to encapsulate and make the code clearer, it might not. There's no automatic thing that says business policy becomes an aspect, but at the same time I'd say there's an affinity there and an Aspect might help you. For example, in that case. Your re-pricing the shopping basket is another one. There are some rules about when to reprice the actually doing it is spread across many places. AJDT and AspectJ are both built using AspectJ and AJDT. We have a multipage wizard inside AJDT and you can change properties at any page, how do you know when to apply those property changes? That's all tracked with an aspect inside AJDT. Domain specific is quite narrow but when you need it it's very useful.
I haven't seen the system obviously, but I think the gist of it is the aspects is used in what I would call a controller role, which is a fairly commonly pattern. The aspect itself isn't responsible for the pricing strategy. What the aspect is responsible for is observing changes to the shopping basket that can happen through a number of different routes, and say "I detect that the changes happen to this" and according to my logic I now need to hand off to a pricing component to reprice. I like to think of that as - There a model, the shopping basket, stuff happens to affect the model which is observed by the aspect that's the pointcuts matching the joinpoints in the AO terminology. Then it acts as controller saying "I've observed this change in the model, this now needs to happen" and it delegates to something else. That's the common design and structure.
That's a great question, many people have looked at that pattern and at other patterns in the design patterns catalogue and said: "What do aspects buy us here?" If you think of something classic like Observer/Observable and in fact at the whole slew of design patterns that we have, why do they exist? They exist because what's happening is, there are common problems that recur in object oriented or java based systems and that straight out of the box OO isn't natural at capturing or resolving; that's why we have to have patterns that teach people work arounds, so there's not an easy and straightforward way to encapsulate that in the language. I think observer observable really becomes very natural in an aspect oriented language.
So if you you've got a language such as AspectJ in which Aspects are first class citizens, which I think is pre-req for doing that kind of thing because it needs to be for that sort of thing, then Observer/Observable will become almost not a pattern because it's just straight there in the language as the first class construct Like you would call a method you wouldn't really call that not pattern and in AO Observer/Observable isn't a pattern. If you look through many of the other design patterns a tremendous amount of academic work, research and analysis What you find is that the aspect oriented approach has benefits in probably 2/3 of those patterns, so you can solve the same problem using Aspects and under some criteria you choose to measure it by, you can objectively assess that yes this is better. Than there's set that tends to be the more structural ones which Aspects don't buy you so much. But it's a really good set of common observed problems in which Aspects help with this, is it a good test? In Observer/Observable it really does. If you've embraced the language like AspectJ that's just natural thing to express.
I've moved to Interface21 from IBM I'm still very much leading the AspectJ project associated with that; I have protected time in my contract to ensure that I'll continue to do that. I'm looking at Spring AOP, at what it offers there, at how we get the integration between AspectJ and Spring AOP right??? That was one of the things that really excited me about going there and its proving true; what happens when you think about the spectrum of use cases you could apply AOP to, you've got some very runtime, more dynamic instance-based requirements through to the more fine grained performance centric things and that spectrum maps very nice from Spring AOP to AspectJ. There's some blurring in the middle. What we are able to do is to open up bits of AspectJ, for example a point-cut parsing and matching piece, maybe one of the most critical bits of an aspect oriented language. That's opened up.
Now as we're working in Spring 1.3 and AspectJ 5, Spring AOP can actually use AspectJ point-cut expressions. And it hands off to AspectJ to parse those and to match them. You can use the self-same point-cut language from Spring as you use in AspectJ and it just works across seamlessly. In fact it works so well that you can build a point-cut library in AspectJ aspects using the code style compile it AJDT into a jar file and you can then refer to those point-cuts from your xml texts in a Spring config file. You get the referencing pointcuts and the composition abstraction and all that works and is integrated. That's the first step on the journey, but there's more coming. For example AspectJ 5 also has what we call the @AspectJ style; for those familiar to AspectJ is basically a programming language with key words.
In some adoption scenarios , the fact that there are new key words is an inhibitor. Something we got from merging with aspectworks was a style where you can use Java 5 annotations @aspect @pointcut and @before, etc. It turns out those annotations can also be consumed and understood by Spring and used to configure Spring AOP proxies, so you get the ability to use AspectJ 5 pointcuts and their semantics with all the generic support, the annotation support etc, and then you get the ability to use @AspectJ Aspects in Spring configurations. What we are doing is just blurring the lines not in a confusing way, but in a way that means what you learn when you start off probably in Spring world - where lots of people use transaction and security aspects - you carry with you when you start to want to bring in a bit more power bring in some AspectJ it's a natural step and less of a jolt. That's some of what we're doing.
Using domain aspects
Re: Using domain aspects
When was the interview?
Re: When was the interview?
Re: Using domain aspects
So the interceptors are usually very specific in terms of methods that they apply to, but those methods/mixins can then be reused quite a lot in a number of different classes.
The way I think about aspects changed quite a bit when I started using mixins in our domain model extensively, since as in the above case it allows the interceptor aspects to be very specific to a particular mixin, but the mixins are usually highly reusable.