I didn’t know what to expect, but the appearance of Rickard Öberg – a renowned programmer on the Java world scene – surprised me.
Apart from having written a book on RMI, he has been one of the core programmers behind JBoss. He instigated the XDoclet tool. WebWork, winning Java programming competitions, lectures and other achievements are also on his CV. Moreover, he’s not your average online personality, or perhaps he is? Anyone who remembers the Pet Store debacle*?
* Microsoft vs. Sun over the J2EE blueprint called PetStore. It resulted in a hot debate with many arguments.
I was sort of waiting to meet someone, well, far out. Instead this wholesome dude with a four-day beard greets me with a smile. I can’t help but to think of a strong caffe latte smooth milk blended with mind-altering caffeine.
Q: SiteVision is the content management system (CMS) sold by the company you work for, SenseLogic. Ok, without any prenuptial agreement, let’s get at the first question why?
Why do you use aspect oriented programming in SiteVision? After all, there isn’t that many product grade systems using aspects as a core design choice.
A: There are several reasons. When we began writing SiteVision we soon realized that we had to encapsulate reusable code in a number of places, especially features that were side effects of method calls. Object had to be saved on setter calls, events had to be sent, logging had to be done, transactions should be managed, and so on. We couldn’t figure out a way to do it using standard technology, e.g. EJB, so the only solution was to use AOP.
We were also on a very tight schedule. In just a couple of months we had to build a commercially viable CMS-tool using only five developers, and after that we had to maintain and develop it at such a rate as to catch up, and pass, our competition. It really should be impossible, and it would be with standard technology. The solution was to avoid writing code by using AOP. AOP allows an extreme degree of reuse of code, and because of this we managed to write lots of features with a minimal effort, and since we avoided writing unnecessary code to a large extent it also became easier to maintain. In addition, since AOP makes it easy to add functionality incrementally we were also able to enhance the architecture and implementation as we went along without having to change much of what was already written.
Q: Why roll your own aspect engine? Why didn’t you decide to use AspectJ or some other aspect-inspired tool?
A: After the decision to use AOP was made I researched the available tools on the market, and compared their feature sets with our requirements, especially with regard to code maintenance, performance, scalability. None of the tools, including AspectJ, had been written with such requirements in mind, so we had no alternative but to write our own tools. My background in EJB made it possible for me to combine the principles of AOP with our requirements in a good way.
In hindsight I can conclude that it was the right decision, and if I were to make the same decision today I would still do the same. There is, in my opinion, still a lack of good AOP-tools that support the demands of a complex server side application. The awareness of the importance of such tools is on the increase however, so I would be surprised if this has not changed by next year.
Q: AOP being a true paradigm shift what are the biggest changes when going aspect?
A: There are two things that stand out, from a design and implementation point of view. First of all it takes some time to learn to recognize “cross-cuttting concerns”, that is, code that can be extracted into an aspect. Second, the use of static introductions as a design tool gives one a whole new set of posssibilities with regard to domain model design. Instead of using inheritance as the main building block for reuse of code one would use design by composition, which gives you many more possibilities for combining existing components. It takes a while to get used to this new freedom, but once you do that everything is fine.
Q: SiteVision is soon to go version 2. Has your view on AOP changed during the trip?
A: In the beginning I was, as most others seem to be now, fascinated with the concept of interception. What difffers now, almost two years later, is partly a realization of the importance of static introduction, and partly the understanding of how important it is to have a powerful pointcut model. AOP has so much more to offer than just method call side effects.
As for AOP in general it is great to see that more developers are beginnning to see the advantages of it, even though the examples often are so trivial that it’s hard to see the point of it. I’m also waiting for more people to realize just how powerful static introductions are as a design tool, and the consequences this has for design pattterns and such issues.
It’s going to be quite a revolution, and several tools that exist today in order to avoid the problems of current system design techniques are going to get a tough time.
Q: Do you dare to mention tools, or types, that will have problems?
A: I suppose XDoclet is the most obvious one. We are not using any code generation at all in SiteVision, and that is solely because we have been able to avoid all the problem of standard design principles by using AOP.
Q: Let’s pull out the tarot cards. What’s in the future for AOP?
A: The theoretical part of AOP seems to be stabilizing, but we will probably see more tools in the AOP space. Some people ask, “Why not only use AspectJ?” but I think that’s like saying, “Why not just drive BMW?”. There’s nothing wrong with a BMW, but sometimes a Volkswagen works better, and sometimes a Porsche is the only choice.
As usual it’s about choosing the tool that best matches your requirements, and I can’t see AspectJ being able to match all different kinds of requirements at the same time.
Apart from the AOP frameworks it will also be very important to have good support tools, especially with regard to visualization of AOP systems. Since AOP to a large extent is about fragmentizing and componentizing code it can sometimes be difficult to see what a component does just by reading code. A visualization tool for AOP can put together all the different pieces that make up the whole, and present them as one unit even though they have been developed separately. Access to this kind of tools is, of course, crucial.
We have built such a tool ourselves for our own system, and it has been very helpful when we are expanding the system and when we are looking for bugs.
The step after that, I guess, is the possibility to build packaged aspects that can be reusable in your own projects. However, predicting component markets have proven to be a notoriously difficult task so I’m not going to bet on it.
Q: …and the future for SiteVision?
A: Without revealing too much we can see that our framework and way of building systems gives us interesting opportunities to build application using AOP which run in SiteVision as portlets. Our next version expands the product into the portal segment, and the next logical step after that is to include document management features. We are also looking into how to provide scalability through clustering, and have some rather unique ideas there. But, one thing at a time.
Q: For the finale What are your top five advices for the wannabe aspect programmer?
A:
- Read “Design Patterns” (the GoFbook)
- Read the documentation for AspectJ
- Find a medium size example application and implement it fully using AOP. Pick the framework which best suits your needs. I would start looking at AspectJ for client side development and AspectWerkz for the server side.
- Apply design patterns using AOP as far as possible.
- Read the AOP-entries in my blog 🙂
It is somewhere around here, at the end of the interview, that I start to long for a good cup of coffee, some Java and lots of aspects 🙂
Resources SenseLogic: http:// www.senselogic.se Rickard's blog: http://www.jroller.com/page/rickard
Originally published in JayView.
Tumblelight 
Leave a Reply