Women in Technology

Hear us Roar



Article:
  Aspect-Oriented Programming and JBoss
Subject:   Answering your well-founded skeptism
Date:   2003-05-30 07:22:47
From:   patriot1burke
Response to: Answering your well-founded skeptism

""Will you be able to determine what is actually going on?" - I can see it right now. A couple of months into the the project everyone is happy. AOP is running cool and snappy. Then at crunch time when the bugs are flying around like mad people will be banging their heads into walls trying to figure out "what is actually going on", and ripping out aspects left and right to get back to "real code"."


We've written a GUI management console so that you can see what aspects have been applied to any given class at runtime. Many of the aspects we're writing for JB4 are triggered by metatags declared using XDoclet tags right in the source. GUI + declarative XDoclet tags bring aspects out right in the open.


"I just looked up "Apsect Oriented Programming" on the MSDN, "No Topics Found"."


You didn't look hard enough. http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx


"* Maintenance programmers won't know AOP from ASP and will reak havoc.
* Engineers will forget the aspects because they aren't right in their face, and will spend days searching for bugs in one class when they are really in an aspect in some other distant corner of the program.
* You can be working on a system without robust unit tests (like 99% of the systems in production) change an aspect and break pieces of the code you didn't even know about.
* I can imagine having to impose and 'aspect lockdown' well in advance of a code freeze so that system wide changes are not made close to release."


PLEASE! Replace aspect or AOP with your favorite methodology (OOP etc..), acronym (EJB, CORBA), or language (C++, Python, Java) and you can apply the generalized statements you make above really to anything in software development.


But other statements, I will address.


"* You can have hairy aspect ordering problems."


Yes this is an issue. JBoss AOP provides some mechanisms for this, other AOP frameworks do the same. Go to our website or another AOP frameworks' website.


"* There are issues getting aspects to talk between each other."


Not a problem with JBoss AOP at least with a single full remote or local invocation which is why we have an Invocation and InvocationResponse object in the first place. ThreadLocals are also useful as well.


"* Aspects can cross component boundaries freely, with adverse effect."


Then don't use a regular expression to apply your aspects and/or rely on pointcuts triggered by metatags. Apply aspects declaratively on a per-class basis.


Although this is non-documented, in JBoss AOP we are also experimenting with the idea of an abstract AOP container so that pointcuts can be applied across groups of different instances rather than forcing pointcuts at the class level.


One of the things I wanted to drive JBoss AOP is real-world requirements. I want all functionality of JBoss AOP to be driven by use cases, not some academic ivory tower phd thesis. JBoss 4 implements a bunch of powerful aspects that have actually driven the underlying framework itself. We are currently using it also to implement EJB caching and optimized HTTP session replication. In other words, we are eating our own lunch.


I'm sorry the article did not meet your expectations. Personally, I need to see some simple examples in action before I can really understand how something can be used. When opening a tech book, I usually skip the BS in the first few chapters and go directly to the meat, but that's just me. Spare me the "blah blah blah", just show me the damn code!


On a side note, its funny. Recently, we were talking to an AOP expert who generally writes articles and papers on AOP about reviewing and making suggestions on our codebase, his response was "I'm allergic to code." I'll leave the "conceptual and architecture article"s to those allergic to code.


All and all, thanks for the exercise. Its good practice and helps me refine the message.


Bill

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • Answering your well-founded skeptism
    2003-05-30 10:48:53  anonymous2 [View]

    I'll have some specific comments, but I'd like to center my response around the educational aspects of your response.

    First, let me again prove my case that you have an education problem with AOP. Once again, my own informal poll, the only information that I have, on knowledge about AOP tells me that ZERO percent of engineers around me understand AOP. ZERO.

    And in the time since we have started this conversation the sun has risen and set on Japan, Australia and India, and nobody in any of those places chose to respond to your article.

    Must I make my case any more plain? You have an adoption and education problem with AOP. If you want AOP to take off it's your job as a member of the AOP community to be an advocate for the technology. Statements such as: 'Spare me the "blah blah blah", just show me the damn code!' betray a lack of understanding about your audience. You cannot assume knowledge of AOP. Period.

    The article you mention (which is not on the CD version of the MSDN):

    http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx

    Is interesting because it spends six paragraphs and a graphic explaining AOP and giving links before it "show(s) me the damn code!"

    Is there no place for a pragmatist, like yourself, to write articles on pragmatic, but high level, approaches to actually using AOP in production? Why must all of the AOP articles either be ridiculously abstract, or nose deep in th code?

    Comments or your other comments:

    Your assertion that I can "apply the generalized statements you make above really to anything in software development" is both right and wrong. These problems occur in other environments but they are more acute in AOP because nobody knows AOP. Let's look at them again, so that you can understand them before you brush them off:

    * Maintenance programmers won't know AOP from ASP and will reak havoc.

    This has a real world case in point. When the first qsort algorithm was implemented it was ripped out by maintenance engineers that didn't know what it was or how it worked. I have proven that nobody knows AOP or how it works. Thus it will be ripped out by maintenance engineers with bugs to fix.

    * Engineers will forget the aspects because they aren't right in their face, and will spend days searching for bugs in one class when they are really in an aspect in some other distant corner of the program.

    You missed the point. Aspects can INVISIBLY insert code from other areas of the program into your code. This is disconcerting at best. It's also a pain to debug as you invoke a method in one place then attempt to trace into that method invocation and crash before you get there. Why? Because an aspect has patched the method invocation in the byte code.

    * You can be working on a system without robust unit tests (like 99% of the systems in production) change an aspect and break pieces of the code you didn't even know about.
    * I can imagine having to impose and 'aspect lockdown' well in advance of a code freeze so that system wide changes are not made close to release.

    These two address the system-wide changing nature of AOP which is unique to AOP. When you change a base class in OOP you can understand readily the number of test cases you are having an impact on. The same is not so clear on wide-spread aspects.

    "One of the things I wanted to drive JBoss AOP is real-world requirements. I want all functionality of JBoss AOP to be driven by use cases, not some academic ivory tower phd thesis." - This is a good sign. Perhaps we as customers of JBoss would like to know just what those use cases are so that when can ensure that our architectures match the design that you are creating.

    "Its good practice and helps me refine the message." - Ok, but what is the message? "Here is some code?" Read it and be in awe? Messaging and articles are supposed to inform and educate. The important part is the Times New Roman bits stuck between the code fragments. The code is meant to be an illustration!