Thesis Weblog

I just quickly glanced over the conclusion to your thesis which confirmed a few of the assumptions that I had made about JBoss AOP several months ago.

Currently I am in the middle of finishing the implementation portion of my thesis in Software Engineering. I am using AspectJ to weave a very specialized security Model into enterprise applications. I am using plain vanilla J2EE with Sun’s J2EE Application Server that you can download for free from their website. I had to make a decision back in October as to which container I would be using for my project and I decided to avoid JBoss for several reasons. The first reason was that it wasn’t integrated with a web container and was only an EJB container so I had to worry about getting it to talk to Tomcat or some other web container. The other issue that I had was documentation, I had heard that JBoss documentation tends to be lacking and I wasn’t willing to pay for the subscription to their documentation service. Sun had a nice packaged tutorial that I could use free of charge. I also had to buy a couple of books on J2EE but that was going to happen regardless of the container that I had chosen. The final 2 reasons for avoiding JBoss AOP was that I suspected it to be considerably slower than other AOP technologies and I didn’t like the idea of using XML to store all the AOP references. I preferred (and still do) the use of code to denote JoinPoints as it is done in AspectJ.

In your conclusion you make mention of the extra complexity that is required to learn JBoss AOP. This is a bit of an on going discussion that I have been having with one of the faculty members in my department; basically wondering if the extra complications involved with learning AOP semantics are offset by the supposed reduction in complexity in the system design. AspectJ is fairly complicated, but manageable. From the brief description that I read in your thesis I get the impression that JBoss AOP is worse. IMHO I think that the complexity issue and the static JoinPoint declarations (XML declaration instead of code declaration) will inhibit the growth and deployment of JBoss AOP. There is also the performance problem, with AspectJ I have found (informally with JUnit) that my base code with the Aspects woven in, executes, on average, at about 1/4th the speed of the non-woven code.

Currently in the stage of my project I have built up a distributed Web Services example to implement my example. I am using SOAP message to effect Remote Procedure calls and transfer files between J2EE servers. In the next week or so I hope to use AspectJ to weave the necessary security fields into the SOAP messages so that the security concern is isolated from the base functionality as much as possible.

I too am a believer in AOSD/AOP and think that it is the programming model of the future. I have high hopes for IBM and their Concern Manipulation Environment that Peri Tarr and Harold Ossher are working on. The ability the combine the benefits of JPI (JoinPoint Interception) with Hyperspaces (method and field introduction) will make for a powerful set of tools. I also think that with AOSD you need a very robust set of tools because of the extra complications that undisciplined weaving can bring to a project. For AOSD/AOP to succeed the tool support is critical which is why I think that Eclipse and AJDT (AspectJ Development Team) are going in the right direction.

If you don’t mind I might reference some very small parts of you thesis in mine as there is some overlap in what we are researching. Thank you for sharing you findings with the rest of the community.

Just my $.02(CDN).

Cheers,

Captain Jason Furlong
Royal Military College of Canada
jason.furlong@rmc.ca

Hi Jason.

Feel free to reference all you want. :-) Thanks for your comments. In regards to your comment about complexities in AspectJ and JBoss AOP, it is my belief that the complexities in JBoss AOP and AspectJ as well mainly stem from the fact that it is difficult to maintain the untangling and retangling of code in your head. This is true for any AOP system. Whenever aspects need to be woven into code, there is the problem of being able to comprehend what will happen to the resulting code. It is my feeling that this can be rather difficult. In JBoss AOP this is even more difficult because JBoss AOP is designed to run in a complex container environment that allows for aspects to be weaved into code pr. JVM, pr. Thread, pr. instance etc. The cognitive burden is quite high. I don't know a great deal about AspectJ but I don't think the pr. JVM etc. is an issue that can affect it because AspectJ is so general. Applying aspects to instances and threads and the like would require the application to at least run in a container and the bytecode weaver to be aware of it, I think. At least if the code is to be woven runtime.

Now that was a long something;-) We are glad you could use our Master's thesis for something:-)

Kind regards
Eske Sort

Great thesis guys. The usability portions of the thesis were quite excellent. Hopefully I can address a lot of your concerns before the 1.0 release.

Just to let everybody know. JBoss AOP 1.0 Beta went out March 16th. Some things added to it that may be of interest:

1. AspectJ like pointcut expressions
2. annotation, cflow, full caller side for constructors all supported with expression languageto expression language
2. Separatation of pointcut and advice/interceptor bindings
4. Aspect classes. Ability to encapsulate multiple advices in one class.
5. Precompiler so that you don't have to use LoadTime and you can run easier in standalone, outside of JBoss
6. Expanded management console and a standalone XML dump so that you can find out where bindings are bound, and what bindings are unbound (if you did a typo or something.
6. massive overall performance increases.

See more info and links here:
http://www.jboss.org/releases/aopbeta

Regards,

Bill Burke

One thing I wanted to add. Currently, if you are running JBoss AOP within the application server, you can get a runtime view of classes that have advices attached to them, and what annotations that have attached as well. You can also see unbound advice bindings. Both are very good at debugging eroneous pointcut expressions.

Bill

Jason,

JBoss IS integrated with multiple web containers and comes bundled with Tomcat when you download it. JBoss Inc. actually employs the lead developer of Tomcat.

Although our advanced documentation is for-sale, we have a number of free getting started guides. One that goes along with O'Reilly's EJB 3rd edition, the other which we contracted somebody to write. We also have a WIKI now and are expanding it as we have time. Documentation sales currently support the salaries of two engineers and the revenue from the sales supports the costs for maintaining professional documentation. Documentation for open-source is always lacking and it costs money to pay somebody to professionally do it which is what we do.

As far as JBoss-AOP goes, the documentation is free on our wiki.

It is very disappointing that you have chosen Sun One as your application server. JBoss has a number of "separation of concerns" features (interceptors) that you can plug into without the need of AOP frameworks like AspectJ or JBoss-AOP. Our customers that have evaluated Sun ONE have also told us that we are far superior in quality and performance to Sun ONE as well.

Bill

Yeah we were a bit tough on you all right, but we stressed that most of the issues most likely will go away in a final release.
We knew it was going to be a RAW thing ;-)

We have been looking through the new stuff (on the surface only) and it looks really nice. Overall it seems as if the concepts have been tied better together -- both as "idea" and on the implementation level.

I really like the more explicit separation of dynamic vs. "static" precompiled aop, as it simplifies things alot.

Will unadvised methods in 'advisable' classes still do 10+ method calls ending up in a reflective call, or is that part of the performance makeover?

Good luck with your work, Bill -- the competetion is getting rougher every day on this field, it seems...

Bill,

I just read your comment to me about Sun vs. JBoss. I made the (somewhat uninformed) decision to go with the Sun One server mostly because I figured it had the least number of features and would be the easiest one to learn how to use.

I can't say that is the most depedable product; I've crashed it numerous times and one bug in their deploytool wasted a full day.

It was only after I had committed myself to Sun's server when I found out about how good JBoss. Sun was good to learn on but I figured out quickly that it wasn't industrial grade.

Jason