Adrian Colyer on Domain Specific Aspects

Interview with Adrian Colyer on Apr 09, 2007 Length 00:08:20

Sections

Development,

Architecture & Design

Topics

Java ,

AOP

Tags

Spring ,

AspectJ

Share |

Problems watching video?

Summary
AspectJ lead and AOP expert Adrian Colyer briefly talks about Domain Specific Aspects, where business rules and policies and can map to an aspect like solution. Adrian also discusses using AOP to implement design patterns such as Observer/Observable, and AOP adoption.

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.

Can you tell us a bit about yourself and what you're involved in?

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.

Where are we now in the option cycle for Aspects?

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.

What kind of requirements can map to domain specific aspects?

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.

Can you talk more about the e-commerce example? How are the Aspects used for pricing and what objects could they be intercepting?

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.

What about using Aspects for complex event processing? Could Aspects replace the Observer/Observable pattern?

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.

You've moved to Interface21, the company that puts out Spring. What are you doing there and how does that impact on your role in the Aspect world?

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.

 

1. Back to top

   Using domain aspects

   by Rickard Öberg

   Great interview, and it's good to hear that there is more discussion around domain aspects. We've been using AOP and domain aspects since 2002, and have nothing but good experiences with it. Also, I must say that doing the opposite of what Adrian talks about, i.e. plunging into using AOP all-out instead of just using the "simple" parts, allowed us to exploit the advantages of it more fully, and in a less schizofrenic way. So there are certainly benefits to going "all in". But, at the same time it *IS* important to consider if a team have the skillz and experience needed to do so. With great advantages comes great risk, so it's (as usual) a tradeoff.

   Reply

2. Back to top

   Re: Using domain aspects

   by Floyd Marinescu

   Rickard, Adrian mentioned business policies that apply in a number of places as an example use of Aspects for domain logic. What were some of yours?

   Reply

3. Back to top

   When was the interview?

   by Twice Tshwenyane

   When was this interview carried out? Most of the things in the last paragraph seem dated.

   Reply

4. Back to top

   Re: When was the interview?

   by Floyd Marinescu

   It was about a year ago, we tried to edit out anything dated, sorry if we missed anything.

   Reply

5. Back to top

   Re: Using domain aspects

   by Rickard Öberg

   The majority of our interceptor aspects apply only to one "place" (=mixin), BUT the vast majority if mixins are reused in a number of places, which means that the interceptor aspects are then consequently ALSO reused in many objects. E.g. if I add a child to a container there's an interceptor which ensures that the child->container is properly set. The interceptor applies to only one place (=the Container.addChild method), but the Container mixin applies to some twenty places in our domain model. This allows for highly focused and specific aspects which are still highly reusable, when combined with mixins.
   
   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.

   Reply

• Older >