AOP: revolutionary, evolutionary or rudimentary?

Discussions

News: AOP: revolutionary, evolutionary or rudimentary?

  1. In recent months there were several AOP related discussions on TSS and other Java forums (not counting many discussions that turned into AOP in the middle). Upcoming products with pronounced AOP functionality, such as JBoss 4, will definitely magnify all the issues surrounding AOP.

    However, judging by the many replies and countless conversations that I had, the fundamental ideas behind AOP is far from being widely accepted by the software engineering community.

    Following is the list of some of the most frequent topics (in no specific order) about viability of AOP I have come across recently:

    1. Read-write (mutating) aspects break the fundamental basics of OOP by requiring the knowledge of the internal implementation details for advised code.
    2. Even read-only (non-mutating) aspects applied to non-public constructs may require knowledge of internal details for advised code.
    3. AspectJ is a whole new language (i.e. couple of dozens new keywords on top of the Java) and it is a way too much to pay for a new programming technique. OOP-language based AOP framework should give better value.
    4. Besides the venerable logging and security check examples that are popping up in every AOP discussion, is there any real-life applications of AOP (i.e. using AOP-based frameworks) large enough for good statistical analyses (excluding Rickard Oberg’s CMS)?
    5. As far as security check example (or in general): where is the proof that AOP-based implementation for security check is anyhow better than a traditional one implemented using normal OOP practices? Is it not just an alternate way which can be judged only on the case-by-case basis?
    6. Free-defined, unrestricted pointcuts promote spaghetti-like coding and ad-hoc design.
    7. AOP may introduce excessively tight coupling between aspect and advised code. Advised code cannot be freely changed if there is a mutating aspect attached to it (see p.8 for further complication).
    8. Since aspects are defined in a different language (or XML), the logic gets split into two semantically different places further complicating coupling.

    I personally have an opinion on each of these issues and not always share the skepticism of some of them. Yet I am leaning towards using AOP with pre-defined pointcuts and read-only aspects as probably the best implementation for exposed cross-cutting functionality in the enterprise systems.

    It will be interesting to see what other TSS members think on this topic and the issues listed in the paragraph above.

    Regards,
    Nikita Ivanov.
    Fitech Labs., Inc.

    Threaded Messages (100)

  2. In recent months there were several AOP related discussions on TSS and other Java forums (not counting many discussions that turned into AOP in the middle). Upcoming products with pronounced AOP functionality, such as JBoss 4, will definitely magnify all the issues surrounding AOP.

    >
    > However, judging by the many replies and countless conversations that I had, the fundamental ideas behind AOP is far from being widely accepted by the software engineering community.

    It may not be if you mean TSS as the software engineering community. The universities and papers at major conferences such as OOPSLA have been on almost nothing but AOP for the last 4 or 5 years.

    > 3. AspectJ is a whole new language (i.e. couple of dozens new keywords on top of the Java) and it is a way too much to pay for a new programming technique. OOP-language based AOP framework should give better value.

    Hmmm. The EXACT same thing was said about OO languages by C programmers. C++ is a whole new language with keywords etc. I think you may be right and it is time for a native AOP language. That would be cleaner most likely but you wouldn't get all of the "Java is the only programming language around" crowd to go for it at all. So shhhh on that whole new language stuff. I don't want people to not use it because they don't see it as Java.
    > 4. Besides the venerable logging and security check examples that are popping up in every AOP discussion, is there any real-life applications of AOP (i.e. using AOP-based frameworks) large enough for good statistical analyses (excluding Rickard Oberg’s CMS)?
    There are many companies using AspectJ in production right now. I know of a few anyway.

    > 5. As far as security check example (or in general): where is the proof that AOP-based implementation for security check is anyhow better than a traditional one implemented using normal OOP practices? Is it not just an alternate way which can be judged only on the case-by-case basis?

    OK this is the heart of the matter. If we perceive it as an addition to our OO vocabulary - a more powerful kind of object that allows us to put all of the crosscutting code in one spot - it seems like you could get improvements. If you use aspects everywhere it will be like if you use patterns everywhere or EJB everywhere etc. It absolutely can be only judged on a case by case basis.

    > 6. Free-defined, unrestricted point cuts promote spaghetti-like coding and ad-hoc design.

    No doubt about that.

    BTW IMHO frameworks generally are a way of dealing with crosscutting concerns. EJB containers are essentially providing aspect like services for all classes of a certain type. It would be interesting to see if we can solve our modularity problems better with aspects than frameworks.

    Thanks for the start to the discussion.
  3. ...to my knowledge the first mentioning of the cross-cutting functionality dates back to 1979 so in the post I was clearly referring to a number of the discussion I personally have had lately... Sorry for confusion.

    As for the point of AspectJ (as a new language), I think you are implicitly making an assumption that AOP brings the same added value over the OOP, as OOP brought once over the structured programming concept. I think this assumption could be widely disputed.

    And it will be nice to hear from people who are using AOP in production (but not as developers of AOP development frameworks).

    And finally, N.6 and N.7 (free-defined, unrestricted pointcuts & excessive coupling) highlight one of the major problems with AOP in my opinion. Moreover, the AspectJ aims to such usage which is another problem all together.
     
    Regards,
    Nikita Ivanov
    Fitech Labs., Inc.
  4. There is a very interesting comparison of GoF patterns in Java vs AspectJ.
    Have a look at http://www.cs.ubc.ca/~jan/AODPs/

    Narayanan
  5. I hope not..[ Go to top ]

    It may not be if you mean TSS as the software engineering community. The

    > universities and papers at major conferences such as OOPSLA have been on
    > almost nothing but AOP for the last 4 or 5 years.

    I just hope this isn't true. If you are saying that the most brilliant minds in computer science from Bangalore, Stanford, Oxford, Heidelberg etc. have been only thinking about AOP the last 5 years and still didn't come up with a quality textbook, a decent operation environment (at least like, say, Oberon) let alone a satisfactory defintion...now that scares me.
  6. For JBoss 4 reference see Better Reuse than OO
    and JBoss AOP.
    no time to discuss now.

    tx

    Matt
  7. OK, I'll take the bashing[ Go to top ]

    2. Even read-only (non-mutating) aspects applied to non-public constructs may require knowledge of internal details for advised code.


    They absolutely do. And they must, because the so called business logic is hardly 100% orthogonal to the aspect. Trivial example: Role based authorization with internal functional aggregation.

    > 3. AspectJ is a whole new language (i.e. couple of dozens new keywords on top of the Java) and it is a way too much to pay for a new programming technique. OOP-language based AOP framework should give better value.

    Interesting point. I'd rather put it differently. AspectJ is some extension language built on top of Java. If AOP is a principle in its own right: How about an AOP language?


    > 5. As far as security check example (or in general): where is the proof that AOP-based implementation for security check is anyhow better than a traditional one implemented using normal OOP practices?
    > 6. Free-defined, unrestricted pointcuts promote spaghetti-like coding and ad-hoc design.

    I am pretty sure that AOP can be considered very powerful plumbing if handled by a good developer. It leads to a clear reduction in terms of lines of code if handled well. So it is a powerful tool. So is C++ macros (which you can use to handcraft your own AOP like behaviour). The question is: Do you want it loose in the company. Hard to judge, IMHO.

    Yet, the most interesting question is: "What is AOP?". There is no definition, no first class textbook. There is not even a real reference implementation. Are "interception on steroids (pointcut)" and "messing around with the class structure (static crosscutting)" really part of the same conceptual idea (other than: reduce lines of code). I find this somewhat doubtful. What *is* a join point. This is a somewhat interesting question, because (AspectJ-) AOP is coupled to the coding decisions rather than the logical decisions in a program flow. I think this is strange. What *is* an Aspect? There is no clear definition. Some people answered with "A facette of a concern". Cool, if they can not really tell you what a concern is, isn't it? Also, I think it is a bit strange that most implementations go the AspectJ way, while the HyperJ way was - i think - conceptually cleaner (unfortunately impractical to use :-().
  8. Despite all of the hype associated with AOP, there does appear to be a valid problem to be solved: the design intent of our applications (the business logic) is being buried by other concerns. Are we deploying into a multi-threaded environment? What about distributed networking? Etc, etc. I think this is the heart of AOP - concerns unrelated to the core logic of a class should be dealt with in a different way.

    Careful object design can mitigate many of these issues, but implementation pressures often get in the way. So, is there an alternative? The recent trend has been to create a tool for everything. Indeed, it's not uncommon to find a project that incorporates half a dozen tools and has highly complex build chains. This adds its own level of complexity.

    I've been experimenting with AspectJ, and I can definately see some potential applications. Moving away from the "design" aspects that everyone seems to spend to much time on, AspectJ makes it easy to deal with concurrency issues, optimization (caching), selected design patterns (Observer, in particular), etc.

    That being said, I'm still not sure that I would make it a fundamental part of the logic of my application. There is a disconnect between classes and aspects that complicates dependency checking. If I refactor a class, there is no telling what aspects may be impacted until compile time (or run time in the worst case). Hopefully tool support will improve to make this less of an issue. Until then, I don't think I would want to use AOP in the large, so to speak.

    I'm also a little skeptical about the many Java AOP libraries. Java reflection is limited to method joint points and the boiler plate code required by libraries such as Nanning realy distracts from the task at hand. The JBoss approach supports a better range of joint points but requires both Java implementation classes and XML descriptors (enough with XML descriptors already). Even with the new syntax, AspectJ is much more straight forward.

    I suspect at some point that at least some of the AOP ideas are going to hit mainstream. The question is how we deal with them. Is it simply a matter of more rigorous design, or is a new language the answer? We'll have to wait and see.

    Merrick
  9. From all i see, AOP is nothing but a hack to try and fix the mess created by extreme programming. THe key to OO is to design and understand your project BEFORE you code a single line. The Extreme Programming methodology of code first, gather requirements later, leads you to want AOP as you need to hack around to try and make your poorly designed application work.
  10. From all i see, AOP is nothing but a hack to try and fix the mess created by extreme programming. THe key to OO is to design and understand your project BEFORE you code a single line. The Extreme Programming methodology of code first, gather requirements later, leads you to want AOP as you need to hack around to try and make your poorly designed application work.


    I could not agree with you more about your observation about the key to OO. However, I do think there are some very sound concepts in XP, which ultimately are designed to alleviate the very mess you speak about. Maybe a topic for a separate thread.
  11. From all i see, AOP is nothing but a hack to try and fix the mess created by extreme programming. THe key to OO is to design and understand your project BEFORE you code a single line. The Extreme Programming methodology of code first, gather requirements later, leads you to want AOP as you need to hack around to try and make your poorly designed application work.


    Designing the entire application BEFORE you code a single line is just a project doomed to failure. I've lived this failure and it was not a pretty sight. People get fired over this kind of stuff.

    Iterative development is the one true path IMHO. Small iterations at first with distinct reachable milestones, with larger longer iterations as the application becomes more mature. The key to iterative development is the testsuite. The testsuite must grow and grow with each iteration. With a mature testsuite, you can totally redesign whole sections of your code because you'll be assured your testsuite will pick up the new flaws.

    Waterfall design died years ago, didn't it?

    IMNSHO, AOP makes the iterative process much more fluid because architectural decisions like transaction demarcation, security, caching, remoting and optimization can be made later on the development process rather than upfront as new requirements pop up (and they always do). As Robert Devi says, we need structured AOP. As Nikita says, we need pre-packaged aspects. I say let's leverage the good work of J2EE, slice it up, and provide J2EE a la carte to plain Java objects. AOP and system components were made for each other.

    Bill
  12. "A two year study reported in the MIT Sloan Management Review of successful software projects identified four common factors for success; iterative development, rather than a waterfall process, was first on the list"

    "The others were: 2) at least daily incorporation of new code into a complete system build, and rapid feedback on design changes (via testing); 3) a team experienced in shipping multiple products; and 4) an early focus on building and proving a cohesive architecture."

    - page 25 in Applying UML and Patterns by Craig Larman (International Edition).

    How is one to design a complete system before writing a single line of code? Although it "may" result in a better design, it is rather difficult as the requirements will not be fully understood until the user uses the end system. Additionally, requirements change and so the design should be able to accomdate for these changes. The issues of OO design and handling change is discussed in detail at http://www.geocities.com/tablizer/oopbad.htm . I don't agree with everything there, but many of the comments I find well thought out and raise some concerns that I have experienced with software development.
     
    AOP aims to solve cross-cutting concerns. Wether it helps or not, is not something I can not comment on.
  13. "A two year study reported in the MIT Sloan Management Review of successful software projects identified four common factors for success; iterative development, rather than a waterfall process, was first on the list"
    "The others were: 2) at least daily incorporation of new code into a complete system build, and rapid feedback on design changes (via testing); 3) a team experienced in shipping multiple products; and 4) an early focus on building and proving a cohesive architecture."


    An obvious validation of eXtreme Programming. Continuous integration rocks!
  14. \Miller \
     Continuous integration rocks!
    \Miller\

    Indeed, but I guess you only got up to #2. The last were:

    "3) a team experienced in shipping multiple products; and 4) an early focus on building and proving a cohesive architecture."

    In its Zen like way XP seems to teach that past experience is futile e.g. you can never anticipate, only build for the now, which is a very neat way of saying experience is useless. And of course XP's focus is not on a cohesive architecture, but of addressing features as they come up and refactoring code to meet new things.

    The full quote in fact is in direct contradiction to XP. It says agility is certainly good, but you also need experience and a good design as a solid foundation on which to base your agility.

    Continuous integration is not unique to XP, and continuous integration alone won't get you very far :-/

       -Mike
  15. From all i see, AOP is nothing but a hack to try and fix the mess created by extreme programming. THe key to OO is to design and understand your project BEFORE you code a single line. The Extreme Programming methodology of code first, gather requirements later, leads you to want AOP as you need to hack around to try and make your poorly designed application work.


    Either this is a naive comment or this is flame-bait. Either way, I think it is quite misguided. Poor design has nothing to do with XP. You can have crap design without XP and you can have great design with XP. I thought the notion of having to know *everything* about your project before you code has been debunked a while ago. Plus, what happens when you *can't* know everything. What happens when the "customer" wants to add features midstream? A year later? Do you start from scratch? If you do, I would say you have not worked much in the real world. But I digress...

    From what I have seen so far, aspects are wonderful as you can "inject" functionality into your application at any point in the development process. This is quite powerful. Aspects are not hacks to patch design wholes. They are another type of abstraction that OO does not provide is the same way.

    As AOP hits critical mass (are has it already?) and matures, more support will be added for auditing to reduce that "spaghetti code" fears that some people currently had. I would imagine that tools will come along that will allow developers to more easily see what aspects will impact their code at run time.

    Of the three choices the title of this thread offered, I would say AOP is definitely "evolution" just like OO.

    Ryan
  16. \Breidenbach\
    Either this is a naive comment or this is flame-bait. Either way, I think it is quite misguided. Poor design has nothing to do with XP. You can have crap design without XP and you can have great design with XP.
    \Breidenbach\

    I believe that this statement doesn't take into account that _every_ methodology out there has a philosophical (and practical) leaning built into it. In fact, expanding your statement and saying you can have a crap design or good one in any methodology is a semantically null statement - it conveys no information.

    The fact is that an XP approach tends to produce certain design approaches - and they're different approaches than another methodology would produce. You may disagree with this, but IMHO doing so would be tantamount to saying that every methodology is ultimately the same :-)

    With the above in mind, it's my own experience and thought that XP projects lean towards designs which are more ad hoc and, for lack of a better word, "looser". This has many positive aspects that have been well detailed elsewhere, but it has negative ones as well. And one of those is that if you fail to constantly refactor not just code pieces but the design as well, an XP project can start to fall apart more easily than it might in other projects. And this can happen, and tends _to_ happen, at the worst possible moments - towards the end of a development cycle when deadline pressure begins to come to bear.

    Tying this back into AOP - I think there's some value in what the previous poster said. An XP project can get out of hand more rapidly than other approaches if all project members aren't firing on all cylinders, refactoring constantly, and constantly communicating. And in that environment, developers (perhaps "desperate" developers under deadline pressure) might turn to something like AOP as a quick fix to turn things around.

    \Breidenbach\
    From what I have seen so far, aspects are wonderful as you can "inject" functionality into your application at any point in the development process. This is quite powerful. Aspects are not hacks to patch design wholes. They are another type of abstraction that OO does not provide is the same way.
    \Breidenbach\

    I think some approaches are fairly indisputable, other than for performance reasons. For example, Java as it exists now has a powerfully attractive balance between simplicity and power, and most criticisms levelled at it (and OO in general) have been performance related. But something like AOP is a horse of a different color - it's like considering operator overloading a la C++. There, the arguments are not about performance, but more about the added power of the construct coming at the cost of a more complex language, and harder to understand programs.

    I see AOP in the same way. The question isn't in how much power you can get out of it. The question is whether the benefits of that that power outweigh the complexity cost. Hell, there's an infinite number of things you could bolt onto Java to increase its power - throw in some operator overloading, maybe a Prolog inference engine, Perl regexp syntax, and maybe closures and a few other things as well. All of those would undoubtedly increase the expressiveness of the language and reduce code counts. But, as always, the question is - at what cost?

    My own feeling is that AOP adds too much "magic" to a language. With magic defined as "the code just magically _does it_, but figuring out exactly how it does may take a few brain surgeons with a rocket scientist thrown in to supervise them". In my experience, the more magic you throw in - the more difficult it is to figure out what code does from its calling context - the harder its going to be to maintain. Now Java obviously has some magic of its own - with reflection, and magic string concatenation, and even polymorphism, it can be a little tricky to nail down what a line of code is doing. But the benefits of these constructs are small, and they're small in number, so the benefits outweigh the complexity cost.

    But AOP is codifying and encouraging the idea to inject "magic" all over a code base on a regular basis. From my point of view, that is saying "let's make it as easy as possible to write impossible to understand systems as we can". Personally, if I'm faced with a problem that AOP may seem well suited to solve, I'll solve it either explicitly via OO design, or I'll break out a code generator to solve it. Either way, it's clear to everyone what's going on, and even code generator "magic" is obviously tagged as such, and in the end you can always see the source when debugging.

    Tying back again to XP - in my experience AOP is _exactly_ the sort of thing that XPers love. Indeed - it dovetails nicely with XP's Smalltalk roots and its ability to do things like instrument classes outside of the class code itself. It appears to be a powerful and elegant mechanism, with alot of bang for the buck, that exactly matches XP's minimalism and need-for-speed. But, IMHO, what seems rockin' and cool and elgant in early stages of a project, and particularly an XP project, will rapidly evolve into a complex, impossible to understand tangle of interdepencies and behaviors - precisely in the same way that Smalltalker's ability to tack things onto the root Object class after the fact can lead to bizarre dependencies and twisty-curvy code paths.

    It's my belief that AOP and XP reinforce each other in a very elegant fashion - and with the worst possible results over the full lifetime of a project.

         -Mike
  17. \Breidenbach\

    > Either this is a naive comment or this is flame-bait. Either way, I think it is quite misguided. Poor design has nothing to do with XP. You can have crap design without XP and you can have great design with XP.
    > \Breidenbach\
    >
    > I believe that this statement doesn't take into account that _every_ methodology out there has a philosophical (and practical) leaning built into it. In fact, expanding your statement and saying you can have a crap design or good one in any methodology is a semantically null statement - it conveys no information.

    I agree. I was merely pointy out the absurdity of the previous poster who suggests that AOP is a stop gap created to patch XP's shortcomings. That is a foolish statement.

    > With the above in mind, it's my own experience and thought that XP projects lean towards designs which are more ad hoc and, for lack of a better word, "looser". This has many positive aspects that have been well detailed elsewhere, but it has negative ones as well. And one of those is that if you fail to constantly refactor not just code pieces but the design as well, an XP project can start to fall apart more easily than it might in other projects. And this can happen, and tends _to_ happen, at the worst possible moments - towards the end of a development cycle when deadline pressure begins to come to bear.

    Duh. That is why you constantly refactor based on the direction of the design. In my experience, nearly all designs have a life span - there is no such theing as the "perfect" framework. Either they do not evolve and become woefully outdated/cumbersome or they constantly evolve based on new/changing application requirements. To take constant refactoring away from the XP process is taking away a critical piece. Of course this will lead to problems.

    > Tying this back into AOP - I think there's some value in what the previous poster said. An XP project can get out of hand more rapidly than other approaches if all project members aren't firing on all cylinders, refactoring constantly, and constantly communicating. And in that environment, developers (perhaps "desperate" developers under deadline pressure) might turn to something like AOP as a quick fix to turn things around.

    If you turn to AOP at the last minute to solve critical design flaws, you are just asking for trouble. Come to think of it, when you discover design flaws at the last minute in any project, you are going to have problems. This can and does happen is software development. This is not unique (or caused by) XP.

    > But AOP is codifying and encouraging the idea to inject "magic" all over a code base on a regular basis. From my point of view, that is saying "let's make it as easy as possible to write impossible to understand systems as we can". Personally, if I'm faced with a problem that AOP may seem well suited to solve, I'll solve it either explicitly via OO design, or I'll break out a code generator to solve it. Either way, it's clear to everyone what's going on, and even code generator "magic" is obviously tagged as such, and in the end you can always see the source when debugging.

    I can see how AOP can be a slippery slope. I am not suggesting using it where good OO design would solve the same problem. Whenever I refactor significant portions of an application, it is because there is something repeated. An algorith, a process, whatever. I think, "How can I add an abstraction so that this (fill in the blank) can be written exactly once. Nine times out of ten it can be addressed with a well-known OO design pattern (Strategy, Template Method). There are those occasions where the problem "cross cuts" many areas of the application, and an aspect would fit much nicer - handling system-level exceptions (SQLException, IOException) come to mind.

    That said, I agree with you to some degree. AOP could be tempting for a quick fix. However, injecting to much "magic" into your code can lead to more problems than it solved. And as I said before, this the area (clarifying what magic is happening under the covers) that I think AOP tools should and will adress in the future.

    Enjoying the dialogue.

    Ryan
  18. \Breidenbach\
    I agree. I was merely pointy out the absurdity of the previous poster who suggests that AOP is a stop gap created to patch XP's shortcomings. That is a foolish statement.
    \Breidenbach\

    There certainly was more than enough baiting in the statement, but there was a small kernel of truth in there.

    \Breidenbach\
    Duh. That is why you constantly refactor based on the direction of the design. In my experience, nearly all designs have a life span - there is no such theing as the "perfect" framework. Either they do not evolve and become woefully outdated/cumbersome or they constantly evolve based on new/changing application requirements. To take constant refactoring away from the XP process is taking away a critical piece. Of course this will lead to problems.
    \Breidenbach\

    The difference for me is one of degree. I agree with the fundamentals of what you've said above, but I also believe the particular spin that XP puts on a project design wise can have some serious complications compared to other methods. Certainly every design does have a finite life span - but some are more longer lived than others :-) XP explicitly encourages a design which is reactionary to the current conditions as they exist right now, and also explicitly warns practitioners against anticipating the future. To me, that means that _by definition_ an XP design is going to be rather short lived.

    This may not be a big surprise to some, and their response is "constant refactorings!". The problem I have here is two fold:

       - Constant refactoring in my experience isn't realistic over the long haul. Too much change happening constantly wears everybody down, and real life biz requirements all too often add more pressure on top of the constant change. Couple the idea that refactoring may begin to decline over the life of a project, along with a reactionary design based on short term goals, and you've got a formula for trouble 12 months down the road (or less).

       - There's a built in arrogance (term used very purposely :-) in XP that developers cannot anticipate future needs, and that reactionary designs for the now are the best we can do. I fundamentally reject that idea, and believe experienced developers can rack up quite a track record of successfully anticipating future needs and designing for it now. If you open yourself up to that possibility for just a moment, and consider that it might be true, it blows a big giant hole into one of XP's cornerstones.

    \Breidenbach\
    If you turn to AOP at the last minute to solve critical design flaws, you are just asking for trouble. Come to think of it, when you discover design flaws at the last minute in any project, you are going to have problems. This can and does happen is software development. This is not unique (or caused by) XP.
    \Breidenbach\

    Too true. But at the same time I'd say that XP is predisposed towards this sort of scenario in the long run.

    \Breidenbach\
    I can see how AOP can be a slippery slope. I am not suggesting using it where good OO design would solve the same problem. Whenever I refactor significant portions of an application, it is because there is something repeated. An algorith, a process, whatever. I think, "How can I add an abstraction so that this (fill in the blank) can be written exactly once. Nine times out of ten it can be addressed with a well-known OO design pattern (Strategy, Template Method). There are those occasions where the problem "cross cuts" many areas of the application, and an aspect would fit much nicer - handling system-level exceptions (SQLException, IOException) come to mind.
    \Breidenbach\

    Certainly outstanding developers can create staggering works of software art, and their accomplishments are often even greater and more impressive when they have extremely powerful language constructs to work with. I've seen some C++ code from truly gifted people that uses a wide array of the language's available power to do some really great stuff, and in an understandable way.

    But I'm not worried about the gifted. I'm worried about the merely good, and also the not so good. From what I've seen, when you start considering truly powerful and complex language constructs, the "proper" use of such constructs are far outweighed by the bizarre usages. To use an example, for every elegant use of operating overloading, there'll be 10 strange, backwards, and almost indecipherable systems put together by people who went a bit too hog wild with the tools available to them.

    That's what I fear with something like AOP. Undoubtedly some really great stuff will be written using it. But every great system, there'll be 10 hideous monster systems created by people who just didn't know any better, and used it mainly because it was cool and it was there. And my fear is there because I all too often end up working on such systems and dealing with the consequences after the fact.

    To paraphrase Stroustrup, C made it easy to shoot yourself in the foot, but C++ can blow your whole leg off. I see AOP that way - gifted practitioners may play it like a violin, but far too many ordinary people will cut bloody strips off themselves and their co-workers trying to use it.

       -Mike
  19. i agree[ Go to top ]

    i came from a background in c, and it took many years for me to become proficient in oo. even though it was difficult, you could see the benefits - you just had to learn how to use it properly. no doubt the same thing will happen with aop. but to me, even accepting many of the legitimate issues above, it does offer real promise, and deserves to be looked at - and what's wrong with that? i think jboss4 will be a great testbed for aop. i still think it'll be a while before a 'gang of four' type book on aop comes out, though - and that book came about only after a lot of people pooled their collective wisdom together to share what did and did not work in oo - from bitter experience.
  20. i agree[ Go to top ]

    \Strong\
    i came from a background in c, and it took many years for me to become proficient in oo. even though it was difficult, you could see the benefits - you just had to learn how to use it properly. no doubt the same thing will happen with aop.
    \Strong\

    It's an entirely different situation to me. I also went from C (among other languages) into OO, and the reasons were extremely compelling. C makes it trivial (and SOP in many cases) to circumvent the static type system, and has no runtime typing. It's most powerful language constructs are function calls, data pointers, and function pointers.

    If we ignore C++ for a moment and look at just about any other OO language, you can see that there are much more powerful constructs than in C, that despite their power that are pretty easy to understand, and you get alot more typesafety (and high runtime safety too for languages like Java). The benefits of jumping from, say, C to Java are extremely clear cut, and the only criticisms are generally performance related or "I can't get to the hardware".

    But going from OO to AOP is an entirely different beasty altogether. Whatever you may consider the abuse or misuse potential of OO in Java is, it's nothing compared to that potential in AOP.

    As JBoss being a great AOP test bed - personally, I doubt it.

       -Mike
  21. <
    From all i see, AOP is nothing but a hack to try and fix the mess created by extreme programming. THe key to OO is to design and understand your project BEFORE you code a single line. The Extreme Programming methodology of code first, gather requirements later, leads you to want AOP as you need to hack around to try and make your poorly designed application work.
    />

    Are you suggesting that it is possible to completely understand a project before you begin? At work, we have 3 rules to remember when given reading any business/functional specs.

    1) Any spec is both incomplete & will contain errors. Something is always missing or misunderstood. To assume otherwise is foolish.

    2) Any spec is out of date. The user's requirements evolve, even before you have delivered anything.

    3) Even if you do manage to deliver on everything the user wants (doubtful given the above), they will then want something more which trashes the assumptions of your original design.

    In short, change is inevitable and to pin all your hopes on an initial design seems a bit naive to me. I'm not a commited XP fan, but it does at least admit that errors and change are normal parts of software engineering. The XP tenets can also be viewed as just good ideas to mitigate the effects of change that will inevitably occur.

    Anyway, what has all this got to do with AOP? It seems to me that OO evolved as means of aiding software design and maintenenace. It made it easier to build complex systems by breaking the code into pieces. AOP seems to follow these principles by enabling us to write cross cutting concerns in one place rather than spreading the code over many classes. But I can also think of plenty of examples where AOP would not simplify things but make them far worse. I guess it boils down to having a people design a system who knows what they are doing and how to use tools such as AOP.
  22. \A P\
    Anyway, what has all this got to do with AOP? It seems to me that OO evolved as means of aiding software design and maintenenace. It made it easier to build complex systems by breaking the code into pieces. AOP seems to follow these principles by enabling us to write cross cutting concerns in one place rather than spreading the code over many classes. But I can also think of plenty of examples where AOP would not simplify things but make them far worse. I guess it boils down to having a people design a system who knows what they are doing and how to use tools such as AOP.
    \A P\

    Taking the easiest approach, you can already do this in OO by encapsulating the cross-cutting concern in a seperate class. The difference you need to embed calls to this class in the various classes that need its functionality :-)

    With a slightly more dynamic and complex approach, you can also achieve the same goals by using an event framework. You register regular objects for various "events", and you could easily create a calling chain that handles an event by passing it along to the various handlers. The difference with AOP is that the main classes involved don't need to know they're being used as part of a call chain - you need to design it in.

    This is where alot of people are leery of AOP - you can use it against classes that were never intended to be used in this manner, as opposed to deliberately designing things to work this way. In the worst case you can "retrofit" new behavior on old code without touching the old code (of course, many might not consider this a worst case :-)

    In fact, alot of the bang JBoss people are attributing to AOP could be created with an explicit dynamic event mechanism (possibly not all of it, but alot of it).

    An extra consider is that byte-code instrumenting AOP implementations may have a performance edge over an event system.

        -Mike
  23. I don't see how it becomes more "key" to "design and understand your project
    BEFORE you code a single line" when using OO than with other paradigms (e.g. structured, unstructured, functional ...)

    Also, I suggest you do some reading up on what XP is about...



    > From all i see, AOP is nothing but a hack to try and fix the mess created by extreme programming. THe key to OO is to design and understand your project BEFORE you code a single line. The Extreme Programming methodology of code first, gather requirements later, leads you to want AOP as you need to hack around to try and make your poorly designed application work.
  24. From all i see, AOP is nothing but a hack to try and fix the mess created by extreme programming. THe key to OO is to design and understand your project BEFORE you code a single line. The Extreme Programming methodology of code first, gather requirements later, leads you to want AOP as you need to hack around to try and make your poorly designed application work.


    Code first? Gather requirements later? It's obvious you don't know anything about eXtreme Programming.
  25. Design All Upfront?[ Go to top ]

    "to design and understand your project BEFORE you code a single line"

    You call this kind of practices OO? I'll call them "over-engineering" or "analysis-paralysis". Why so much people like XP? Just because that we can't get all requirements upfront. As project progresses, customers will understand their business area much better. How can you prevent they changing the requirements?
  26. Why people like XP[ Go to top ]

    Why so much people like XP? Just because that we can't get all requirements > upfront. As project progresses, customers will understand their business

    > area much better. How can you prevent they changing the requirements?

    I agree you will never get finalized requirements on any software system, with the exception of systems, where people life is crucially dependent on them functioning well. Anyway. This is *not* why people like XP. The real reasons I have observed are:

    - Programmers like XP, because they need to write less code and they think formal diagrams are a waste of time anyway.
    - Salespeople like XP because it combines a buzzword with the prospect of selling twice as much people (AKA pair programming).
    - Consulting companies love XP because it makes the contracts a lot more flexible
    - Customers love XP because they believe they save a lot of money with higher programmer productivity and less cost for all the testers and technical writers

    Besides of 10 companies I have seen doing "XP" only one or two did it in a sensible way.....
  27. I'm also a little skeptical about the many Java AOP libraries.....The JBoss approach supports a better range of joint points but requires both Java implementation classes and XML descriptors (enough with XML descriptors already).


    We're planning on XDoclet integration with JBoss AOP within a week or two after the DR1 release on Monday. One thing you'll be able to do is define pre-packaged pointcuts that are triggered by metadata. We'll mimick JSR 175 with XDoclet. For example:

    /**
     *
     * @jboss-aop.metadata group="transaction" trans-attribute="RequiresNew"
     */
     public void somePOJOMethod() { ... }

    Pre-defined transaction interceptor pointcuts will be triggered by the attachment of this type of metadata.

    We intend on using JSR 175 for this type of declarative programming when it becomes available.

    Bill
  28. /**

    >  *
    >  * @jboss-aop.metadata group="transaction" trans-attribute="RequiresNew"
    >  */
    >  public void somePOJOMethod() { ... }
    >

    I don't get it. I thought AOP was about separation of concerns. But in this example, the two concerns (business logic provided by somePOJOMethod and transaction semantics provided by the metadata) are not separated.

    If I am a business logic programmer responsible for implementing somePOJOMethod, then I don't want to write the transaction metadata because this is an orthogonal concern. But this approach still forces me to do exactly that.

    Can you explain what I am missing here?
  29. I don't get it. I thought AOP was about separation of concerns. But in this example, the two concerns (business logic provided by somePOJOMethod and transaction semantics provided by the metadata) are not separated.

    >
    > If I am a business logic programmer responsible for implementing somePOJOMethod, then I don't want to write the transaction metadata because this is an orthogonal concern. But this approach still forces me to do exactly that.
    >
    > Can you explain what I am missing here?

    Notice that the code in somePOJOMethod does not have to
    concern itself with creating transactions and doing
    commit or rollback. So that is already a separation.
    Furthermore, the meta data can alternatively be configured
    separately in an XML file. It's about what you find
    easier to manage.
  30. Bill writes
    >/**
    > *
    > * @jboss-aop.metadata group="transaction" trans-attribute="RequiresNew"
    > */
    > public void somePOJOMethod() { ... }

    A competitive advantage of XDoclet is that tag libraries like @jboss build on the EJB specification oriented tag libraries of @ejb. It would be a big step for JBoss aop to standardize tags around @ejb as well. Could you refactor to:

    /**
     *
     * @ejb.transaction type="RequiresNew"
     */

    This would increase portability from other app servers to JBoss, reduce tag redundancy (DRY principle), and prevent needless rework by existing XDoclet/JBoss users. JBoss could get hurt by the "embrace and extend" mentaility of other app server vendors and I think this is an important point.

  31. > This would increase portability from other app servers to JBoss, reduce tag redundancy (DRY principle), and prevent needless rework by existing XDoclet/JBoss users. JBoss could get hurt by the "embrace and extend" mentaility of other app server vendors and I think this is an important point.

    Yes "embrace and extend" is one of the things I'm worried our competitors will paint us as. Its just simple not true. Its more like "innovate and encourage". I'd be happy to get JBoss on a JCP to push J2EE in this direction. Its really up to Sun though. I hope they let us in.

    In the meantime, J2EE is still a good spec. We'll do our best to keep a strong J2EE-based app-server, and push innovation using AOP. Hopefully we can help create enough buzz with other AOP evagelists so that JCP or some other committee can standardize this stuff.

    Regards,

    Bill
  32. Structured AOP[ Go to top ]

    I don't know much about AOP other than a few Java design patterns, however, I do know a thing or two about history.

    In the beginning there was GOTO/JUMP, conditional jump, GOSUB/JSR, and LONGJUMP. Without these construction, you would have to directly manipulate the instruction pointer or directly encode your application as a set of gates. With them, your code was simplified, you could write code that a human could understand, and you could reuse code (especially with GOSUB/JSR). For years, this was the "one true way" of programming high level languages.

    But the power and usefulness of these instructions was a problem. Unrestricted use of these constructs lead to spaghetti code and tight coupling that was very hard to read or maintain. In order to gain the power of these features without losing too many of the benefits, these powerful functions needed to be restricted. Eventually:
    * the conditional jump evolved into if/do/while/switch
    * GOTO/JUMP evolved into break/continue
    * GOSUB/JSR evolved into functions/procedures
    * LONGJUMP evolved into exceptions
    and structured programming was born. We've never looked back.

    Now we're faced with a similar situation with Aspect Oriented Programming. AOP is extremely useful, it promotes code reuse, and makes classes more human readable because they don't have to include orthogonal features to be added via AOP. Yet unrestricted AOP will lead to spaghetti and tight coupling that is very hard to maintain, much less read.

    From an outsider's perspective, the parallels with structured programming are striking. From this perspective, AOP is still immature. However, like unstructured programming, it will evolve into a more restricted "structured AOP" that will be adopted or retrofitted into existing and new languages.
  33. Structured AOP[ Go to top ]

    I don't know much about AOP other than a few Java design patterns, however, I do know a thing or two about history.

    >
    > In the beginning there was GOTO/JUMP, conditional jump, GOSUB/JSR, and LONGJUMP. Without these construction, you would have to directly manipulate the instruction pointer or directly encode your application as a set of gates. With them, your code was simplified, you could write code that a human could understand, and you could reuse code (especially with GOSUB/JSR). For years, this was the "one true way" of programming high level languages.
    >
    > But the power and usefulness of these instructions was a problem. Unrestricted use of these constructs lead to spaghetti code and tight coupling that was very hard to read or maintain. In order to gain the power of these features without losing too many of the benefits, these powerful functions needed to be restricted. Eventually:
    > * the conditional jump evolved into if/do/while/switch
    > * GOTO/JUMP evolved into break/continue
    > * GOSUB/JSR evolved into functions/procedures
    > * LONGJUMP evolved into exceptions
    > and structured programming was born. We've never looked back.
    >
    > Now we're faced with a similar situation with Aspect Oriented Programming. AOP is extremely useful, it promotes code reuse, and makes classes more human readable because they don't have to include orthogonal features to be added via AOP. Yet unrestricted AOP will lead to spaghetti and tight coupling that is very hard to maintain, much less read.
    >
    > From an outsider's perspective, the parallels with structured programming are striking. From this perspective, AOP is still immature. However, like unstructured programming, it will evolve into a more restricted "structured AOP" that will be adopted or retrofitted into existing and new languages.


    This is a great analogy. Mind if I use it sometime? Anyways...
    I totally agree. My fear like others is that AOP will be used as a bandaid rather than to apply real cross-cutting concerns.

    I really think that declarative programming can really help out here with pre-packaged, pre-defined aspects. Let developers define, through simple metatags, cross-cutting behavior via XDoclet now and JSR 175 in the future. Let AOP be the glue.

    and now the sales pitch....

    We're doing a developer release of JBoss 4 Monday that comes with a lightweight AOP framework and a bunch of pre-defined system aspects. (ACID pojos, distributed replication, remoting, transaction, tx locking, security).

    See you Monday?

    Best regards,

    Bill
  34. Nikita,

    I think all the concerns you mention are pretty much valid. But above all, the problem with AOP is that it lacks a sound, fundamental type- and structure theory.

    Even AOP's inventors (Parc) admits that there is a huge amount of research left before AOP is ready for prime time. They also admit AOP has it's own set of problems.

    AOP needs to be solved at the language level, making its mechanisms part of the underlying type system, etc. The connection with OOP concepts is not well understood either.

    As for AspectJ: it's too damn complex and very cumbersome to use.

    In short, I think AOP is not ready for prime time.
  35. White box problem[ Go to top ]

    Note that AOP increases the "white box" problem - that is, it can easilty break encaptulation seriously.

    The theory is that, over time, AOP will lead to fewer self-contained classes, hence making maintenance, reuse, testing and deployment harder.
  36. Is AOP really something more than framework was build around interception pattern(all articles I've read ends with simply interception pattern)?

    It's not right?
  37. AOP Panel at JavaOne[ Go to top ]

    JBossGroup is holding a one day free conference the same week as JavaOne. June 11th. The main attraction is that we're having a 2 hour AOP Panel with the featured guest Gregor Kiczales, The Father of AOP.

    Info is here.

    Sorry for the advertisement, but I think it will be interesting, and it is free.

    Best regards,

    Bill
  38. AOP Panel at JavaOne[ Go to top ]

    Bill: JBossGroup is holding a one day free conference ... 2 hour AOP Panel ... Sorry for the advertisement, but I think it will be interesting, and it is free.

    And on-topic. Not bad ;-)

    (Off-topic: The real question this year is how many people will be at JavaOne to start with?)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  39. Several posts have mentioned that a pure AOP language should bode a lot better than OOP-based derivative because of pronounced OOP-AOP impedance. Although this idea is not new and seems rather logical, there is one question that is crucially important: why do we assume that most of the problems being solved in software engineering are better described as cross-cutting concerns rather than in a usual OOP terms, for example? In fact, if we are into using a pure AOP language, cross-cutting concern will be become a main abstraction that a developer will operate with, much like a class in OOP.

    Another comment that I would side with is the utter lack of any information/analyses on what affect AOP has on a long-haul, large projects (granted, AOP is quite new for such analyses anyways). Using implicit analogy between AOP and XP, one could argue that such effect is not guaranteed to be positive given the fact that according to Agile Modeling pure XP is not a good choice in general for complex, mid- to large-size projects.

    And thanks to Jboss guys for hosting an interesting conference.

    Regards,
    Nikita Ivanov.
    Fitech Labs., Inc.
  40. Light years beyond.
    This is the way to the future. Non intrusive evolution.
  41. AOP is a generalization of the component/container model used in for example EJB and COM+/MTS. These technologies are trying to solve real world problems of high complexity (persistence, distribution, security and so on) although unfortunately they are not succesful. Remember that these problems have not yet been solved, AOP has a higher chance of doing this than any alternative.

    Here at Lecando (http://www.lecando.com) we have replaced all usage of EJB with Nanning (http://nanning.sf.net, an AOP implementation based on dynamic proxies). Compared to the dozens of systems I've built with EJB it has resulted in much clearer design and code. In my experience Nanning is easier to understand and much more powerful than EJB (since you can implement and tune whatever aspects you'd like, not just those defined by EJB).

    We have released two quite large products based on Nanning:
    Lecando LCMS, a learning content management system. (Written from scratch with Nanning.)
    Lecando Training Server, a learning management system. (About 100 EJBs, ported from EJB to Nanning in under two weeks, for one pair of programmers.)
  42. AOP is a generalization of the component/container model used in for example EJB and COM+/MTS.


    I'm glad somebody else sees this connection. EJB is aspect-oriented, but it is statically limited to the pre-defined packaged aspects it provides.

    Bill
  43. AOP'n J2EE[ Go to top ]

    AOP is a generalization of the component/container model used in for example EJB and COM+/MTS.

    >
    > I'm glad somebody else sees this connection. EJB is aspect-oriented, but it is statically limited to the pre-defined packaged aspects it provides.
    >
    > Bill


    I just had a speech at the Italian Java Conference talking about this. IMHO it is a "natural" vision of ejb world and J2EE is the first step to reach the AOP. The Xdoclet aproach enhance this vision.

    So it make really sense adopt AOP to feature a simple POJO, for example creating ejb, webservice, or whatever we need. This are non-functional requirements, like J2EE deployment descriptor.

    I think the real value is in functional requirements, extending and adding feature at POJO with "non intrusive evolution".

    Geeks, let's instrument the future.
    Mike
  44. AOP'n J2EE[ Go to top ]

    \Mondora\
    So it make really sense adopt AOP to feature a simple POJO, for example creating ejb, webservice, or whatever we need. This are non-functional requirements, like J2EE deployment descriptor.

    I think the real value is in functional requirements, extending and adding feature at POJO with "non intrusive evolution".

    Geeks, let's instrument the future.
    \Mondora\

    This in my opinion is the most dangerous possible use of AOP. If I'm reading you right, you're talking essentially about some functional requirements implemented in straight POJOs, and then other (later?) requirements implemented via aspects. This is almost the definition of patching-after-the-fact, and is the hardest sort of system to maintain and debug. Instead of encapsulating functional behavior in well-defined units (like a class), functional behavior that should be logically together is spread out. See also spaghetti :-)

        -Mike
  45. AOP'n J2EE[ Go to top ]


    > This in my opinion is the most dangerous possible use of AOP. If I'm reading you right, you're talking essentially about some functional requirements implemented in straight POJOs, and then other (later?) requirements implemented via aspects. This is almost the definition of patching-after-the-fact, and is the hardest sort of system to maintain and debug. Instead of encapsulating functional behavior in well-defined units (like a class), functional behavior that should be logically together is spread out. See also spaghetti :-)
    >
    >     -Mike

    Mike, this is layered designing. EJB does the same exact thing with transactions and security as the top layer, and persistence as the underneath one.

    The trick is to know when to use pointcuts and advices and when not to. OOP has the same type of decisions. Should I inherit, should I create a new class? Should I write another method?

    Bill
  46. AOP'n J2EE[ Go to top ]

    \Burke\
    Mike, this is layered designing. EJB does the same exact thing with transactions and security as the top layer, and persistence as the underneath one.

    The trick is to know when to use pointcuts and advices and when not to. OOP has the same type of decisions. Should I inherit, should I create a new class? Should I write another method?
    \Burke\

    As I've mentioned before, I think EJB should be considered a special case, not the norm in development.

    The trick for me is to avoid situations where I might think I really need pointcuts and advices. You say "OOP has the same type of decisions", which may be true in the general sense, but actually it does _not_ in Java's case. A fundamental tenent in Java is that it's quite easy to tell what code does just by looking at it. You can obviously break that idea in a number of ways, but it's the general rule. AOP is a whole 'nuther kettle of fish - it encourages what I call "magic" behavior, and you cannot tell what a class does just by looking at it. Instead, you have to know what all the aspects around the class may be doing with it as well.

    Just like I dislike C++'s operator overloading, various specialized constructors and the like - because it makes it so much harder to deduce what code is doing - I dislike AOP, and believe it's misuse potentiality is much higher than the value it may bring.

    As for "EJB does the same exact thing..." - as I mentioned, it's a very special case, and even so it's sometimes tough for even experts to follow it despite the volumes of documentation on it. I don't see a propogation of AOP everywhere being better - I see it as bringing the downsides of EJB-type behavior in the most general sense to all development. And certainly patching-after-the-fact is almost exactly what the previous poster was referring to - bolting on functionality to an existing class without changing the underlying code. If AOP becomes wide spread, many people _will_ use it in this manner, and they are going to end up with unmaintainable spaghetti.

    I understand all languages and approaches involve decisions, but at the same time, some languages _demonstrably_ lead the majority of developers to make better decisions by virtue of their design philosophy. Just like you could add operator overloading to Java and say "it's just another decision", it's really a bit more complex than that. You may say deciding on AOP uses is just another decision, but in my experience it's very nature means alot of developers are going to make the _wrong_ decisions compared to other approaches.

        -Mike
  47. AOP'n J2EE[ Go to top ]

    Mike wrote:

    >
    >I understand all languages and approaches involve decisions, but at the same >time, some languages _demonstrably_ lead the majority of developers to make >better decisions by virtue of their design philosophy. Just like you could >add operator overloading to Java and say "it's just another decision", it's >really a bit more complex than that. You may say deciding on AOP uses is just >another decision, but in my experience it's very nature means alot of >developers are going to make the _wrong_ decisions compared to other >approaches.


    Although I would not necessarily share Mike’s skepticism about AOP in general, I think his plain-English problem explanation is right on target.

    Pre-defined pointcuts (like those used in Jboss 4, for example) used with JSR 175 or XDoclets are definitely mitigating this problem somewhat. But underlying design philosophy of AOP in its purest form is definitely far from maturity, in my opinion.

    Thanks,
    Nikita Ivanov.
    Fitech Labs., Inc.
  48. OOP[ Go to top ]

    Isn't AOP just a reflection on the fact that present OOPL's don't allow fine control over message passing.

    OOP is about passing messages between objects, in the current crop of languages
    messages are represented by fixed methods and some of the flexibility of message
    passing is lost.

    If the languages were flexible enough to allow re-routing of messages then AOP might not be necessary.
  49. OOP[ Go to top ]

    Your comment is very interesting. At the abstract level, OOP discusses messages. An object SENDS a message to another object. However, the method implementation does not look anything like SENDing something. It is actually CALLing or USing something owned by another object. Am I on course, or is my argument too abstract or literal? I really would love to understand the correlation and implementation details of messages, methods, operations, behaviour etc.

    'bioye
  50. Hi

    I think you are right. In Java, C++, and similar languages method calling is not really like message sending.

    If you really like to know how pleasent REAL message sending is, try Smalltalk. It' really awesome. It is less than a week that I have done some coding with Smalltalk and I'm really imprssed.

    The only thing that I'm worried about it, is its dynamic typing in which variables do not have predefined types.

    And abouut that AOP... it really sucks... ugh... :D
  51. OOP[ Go to top ]

    Isn't AOP just a reflection on the fact that present OOPL's don't allow fine control over message passing.

    >
    > OOP is about passing messages between objects, in the current crop of languages
    > messages are represented by fixed methods and some of the flexibility of message
    > passing is lost.
    >
    > If the languages were flexible enough to allow re-routing of messages then AOP might not be necessary.

    Didn't Smalltalk allow for this? (I never used Smalltalk, just asking).

    Bill
  52. AOP'n J2EE[ Go to top ]

    \Mike\
    > This in my opinion is the most dangerous possible use of AOP. If I'm reading you right, you're talking essentially about some functional requirements implemented in straight POJOs, and then other (later?) requirements implemented via aspects. This is almost the definition of patching-after-the-fact, and is the hardest sort of system to maintain and debug. Instead of encapsulating functional behavior in well-defined units (like a class), functional behavior that should be logically together is spread out. See also spaghetti :-)
    >
    \Mike\

    Mike, the point is that there are some requirements that cannot be "incapsulated" into one class, or one interface.

    Some concerns can be related to all or almost all object of our application, so coding inside a class make the object not cohese (ie caching, persitance, profiling, billing etc. etc ).

    We should see this new crosscutting feature like an Aspect, so orthogonal from classes and fuctions. I feel AOP is a powerful way to implement crosscutting feature, without intrusive code modification, into a simple POJO that is unaware of the feature. I don't mean patching-after-the-fact, there are some requirements the emerge from the market, after we have release the software, for example webservice.

    The hardest point is to correctly recognize what is an aspect, to avoid patching-after-the-fact; I agree with you: like all the powerful things, AOP -if misused- could be seriusly dangerous.

    Spaghetti code is a matter of planning, rationalization and documentation; also in flat ObjectOriented we could have spaghetti code :-)

     -michele
  53. AOP'n J2EE[ Go to top ]

    \Mondora\
    Mike, the point is that there are some requirements that cannot be "incapsulated" into one class, or one interface.
    \Mondora\

    Agreed. Fortunately, most languages allow you to use multiple classes :-)

    \Mondora\
    Some concerns can be related to all or almost all object of our application, so coding inside a class make the object not cohese (ie caching, persitance, profiling, billing etc. etc ).
    \Mondora\

    And yet - people have been doing this in OO for years without serious difficulty. I'm sure Cameron can point to many successful uses of Coherence in a completely OO Java environment without any resorting to AOP.

    \Mondora\
    We should see this new crosscutting feature like an Aspect, so orthogonal from classes and fuctions. I feel AOP is a powerful way to implement crosscutting feature, without intrusive code modification, into a simple POJO that is unaware of the feature. I don't mean patching-after-the-fact, there are some requirements the emerge from the market, after we have release the software, for example webservice.
    \Mondora\

    Making a class do something it wasn't intended to do without changing the class, and without adding new classes to control new behavior, is, by definition patching-after-the-fact.

    In today's layered design approach, adding a web service layer to a new application is a straight forward proposition. You can try using AOP instead of a new "front end" without changing any code, but I'll bet you that it won't be nearly as easy or automatic as you might believe, and I sure wouldn't want to debug it.

    \Mondora\
    The hardest point is to correctly recognize what is an aspect, to avoid patching-after-the-fact; I agree with you: like all the powerful things, AOP -if misused- could be seriusly dangerous.

    Spaghetti code is a matter of planning, rationalization and documentation; also in flat ObjectOriented we could have spaghetti code :-)
    \Mondora\

    I've heard this argument many times, and my response is always the same - it has zero semantic content. To distill it to its basics, you're saying all languages and all approaches are exactly the same, and it's all up to the programmer, and that just ain't true. You're less likely to see spaghtetti in Java than in a C programmer - guess why? It's still possible in both, but Java's design steers you away from it. In the same way, I'd say that AOP _by its philosophy_ has a tendency to lead systems towards spaghetti and a morass of aspects and concerns and point cuts. Some language features are more powerful than others, some are easier to understand, and some are much easier to abuse than others.

        -Mike
  54. AOP'n J2EE[ Go to top ]

    So it make really sense adopt AOP to feature a simple POJO, for example

    > creating ejb, webservice, or whatever we need. This are non-functional
    > requirements, like J2EE deployment descriptor.

    I agree, they are non-functional requirements but architectural instead. This is what I read: I have entities of my system that need remoteness, transactionality, security ecc. and normally (without AOP) I could use EJBs. Later I discover AOP: now I can isolate those crosscutting concerns in a more reusable way and I can add other aspects that EJBs do not provide to me. So you want to use AOP (that brings advantages over EJBs) on POJOs to render them back as EJBs?

    Please enlight me if I'm wrong.
    Renzo Borgatti
  55. \Burke\
    I'm glad somebody else sees this connection. EJB is aspect-oriented, but it is statically limited to the pre-defined packaged aspects it provides.
    \Burke\

    Another way to look at it is that EJB is a very special case that adds some hidden behavior. It's saving grace is that it is static and (fairly) well defined and documented. It's not a general AOP model, it's a very specific distributed component w/ transactions model.

    In comparison, I think of home-grown distributed component models with transactions (or similar beasties) done in in-house groups via AOP, and the heebie jeebies won't stop coming. Where the EJB model, for all it's faults, is a standard and well understood, every developer out there doing similar things on his own is going to be largely ad hoc and likely almost completely undocumented. In short, not a system I'd want to maintain.

         -Mike
  56. <mike>
    Another way to look at it is that EJB is a very special case that adds some hidden behavior. It's saving grace is that it is static and (fairly) well defined and documented. It's not a general AOP model, it's a very specific distributed component w/ transactions model.
    In comparison, I think of home-grown distributed component models with transactions (or similar beasties) done in in-house groups via AOP, and the heebie jeebies won't stop coming. Where the EJB model, for all it's faults, is a standard and well understood, every developer out there doing similar things on his own is going to be largely ad hoc and likely almost completely undocumented. In short, not a system I'd want to maintain.
    </mike>

    I agree about the danger of "home-grown" models using custom AOP interceptors for such fundamentals as transaction management. (Although there are custom requirements that might validly be met by custom interceptors.) However, this is a case for standardizing AOP infrastructure APIs and standardizing on common interceptors for common problems, rather than preferring EJB to AOP. Jon Tirsen (Nanning), Bob Lee (jAdvise) and myself (Spring Framework) have made a start on defining such common APIs: see CVS at http://sourceforge.net/projects/aopalliance. The Spring Framework already implements these interfaces.

    Standardization is a long way off, but if it happened it would address a lot of concerns about AOP (no pun intended). Imagine a market for interceptors, most of which would run in any app server. Many would run outside an app server, if necessary.

    Anyone who's interested in contributing to this standardization effort, please drop me an email. (Follow the contributors link on sourceforge to find my email.)

    Regards,
    Rod Johnson, author of Expert One-on-One J2EE
  57. \Rod Johnson\
     However, this is a case for standardizing AOP infrastructure APIs and standardizing on common interceptors for common problems, rather than preferring EJB to AOP. Jon Tirsen (Nanning), Bob Lee (jAdvise) and myself (Spring Framework) have made a start on defining such common APIs: see CVS at http://sourceforge.net/projects/aopalliance. The Spring Framework already implements these interfaces.
    \Rod Johnson\

    This is where we differ, I believe. I don't want to see a standardize AOP infrastructure, because it's not necessary, and an overly generic implementation which does full blown AOP is IMHO dangerous.

    If you want a very simple counter example to AOP, look at how log4j is implemented. The entire system is highly configurable at runtime, and the object relationships "straighten themselves out" based on the config. In many ways, log4j is just a code base that relies heavily on dynamic registration of components. But it also heavily overlaps some areas people are seeing as AOP these days.

    Many transaction systems also work in a similar way, with dynamic registration, post invoke callbacks, pre-invoke callbacks, etc. These work well, work entirely within the OO system, are well understood, and can be made blazingly fast if done right.

    It seems to me that similar people are trying to do the same sorts of things today with AOP, and that the they're taking a risky "short cut" in doing so. If you want the features you can get out of AOP but stay entirely within the OO domain, you can do it. There's some work involved, but not very much, and chained "table driven" systems (as old fogies like me would term them) come remarkably close to many claims made by AOP advocates.

    Many people have enumerated AOP's benefits, but when I've looked at them they've always curiously devolved into "less code". And while I highly admire creative laziness in software developers (let the computer do the work!), at the same time I also worry about maintainability and correctness. An AOP solution may indeed have less code, but by itself I say "so what" - APL needed less code, too :-)

    To bring it back around to your point, I don't see a real need for AOP, and even less of one for standardizing it.

    If you throw out the self-serving new terms that AOP brings to the table (aspects and point cuts, oh my!), and instead see it as an event system which can dynamically hook into message flow, and further consider OO in terms of Smalltalk's object message-passsing concept, you can see pretty fast that in and of itself AOP is not just something new, but also not very special, and also devilishly hard to control if generalized.

    The point is, I can already model a dynamic event system that looks an awful lot like message passing, and can easily design to chain and allow for graceful building of chains (which looks suspiciously like adding a point cut in). But - it's use in code is explicit, and it's dynamicism is obvious. It's painfully obvious in such systems that this approach has been taken by design.

    AOP, by contrast, is striving to break into a generic mechanism where you can magically instrument any POJO to do things it wasn't intended to do. This, to me, isn't design - it's a patch-after-the-fact mechanism. You don't see a design - all you see is a serious of patches overlaid on top of another code base (in fact, AOP feels _very_ strongly like a patch release of a binary if you think of it that way).

    I fell in love with highly dynamic and configurable code bases a very long time ago. And I've built a number of systems designed in that fashion which accomplish most of what AOP people seem to indicate can't be done, or only can be done at tremendous cost. To which I say fooey! And please, please don't "standardize" a chain saw as a best-practice and common way for people to do their programming business.

    In short, if you want dynamic behavior and high flexibility - build it into you're freakin' object design!! Accomplish the same goals in a way that merely competent programmers can understand and have a hope to maintain.

        -Mike
  58. AOPI[ Go to top ]

    <Mike>
    This is where we differ, I believe. I don't want to see a standardize AOP infrastructure, because it's not necessary, and an overly generic implementation which does full blown AOP is IMHO dangerous.
    </Mike>

    Well, it might be premature, but there already is an effort ongoing. It's called AOPI and its homepage is:

    http://aopi.sourceforge.net

    The archives of the mailing-list are at:

    http://sourceforge.net/mailarchive/forum.php?forum=aopi-discuss

    <Mike>
    AOP, by contrast, is striving to break into a generic mechanism where you can magically instrument any POJO to do things it wasn't intended to do. This, to me, isn't design - it's a patch-after-the-fact mechanism. You don't see a design - all you see is a serious of patches overlaid on top of another code base (in fact, AOP feels _very_ strongly like a patch release of a binary if you think of it that way).
    </Mike>

    This is a very valid point and that's why I believe that in the coming months, we will see a set a "AOP principles" emerge, explaining clearly where AOP should be used and where it shouldn't. I recently read an article (I can probably dig it out if there's interest) that made a pretty good case as to why using AOP to implement transactions is *not* a good idea.

    --
    Cedric
    http://beust.com/weblog
  59. AOPI[ Go to top ]

    <Cedric>
    This is a very valid point and that's why I believe that in the coming months, we will see a set a "AOP principles" emerge, explaining clearly where AOP should be used and where it shouldn't. I recently read an article (I can probably dig it out if there's interest) that made a pretty good case as to why using AOP to implement transactions is *not* a good idea.
    </Cedric>

    Hi Cedric,
    If it isn't a big deal, could you please dig this article out? It should be an interesting reading (and i certainly missed it).

    Thanks in advance,
    Nikita Ivanov.
    Fitech Labs., Inc.
  60. Everybody has read the literature regarding service oriented architectures especially as they apply to web services. What AOP brings us is a way to apply services to objects. I get it now. With Jboss i define my objects however I want to. Then I pick and choose among the pre packaged services and apply those to my object. J2EE brought us transactions, persistence, remoteness, etc. Now I do not have to concern myself with anything but gettting my object model right then I can apply these services to my object, but wait what if I need a service that does not exist. what to do? Oh, I simply create my custom service and apply it to my object.

    Now I am really relying on Jboss. But wait anybody can now implement these same services(transactions, persistence, cacheing, etc) and I can use there services. May the one with the best services win. Plug and play.

     The following code contains transactions, persistence, cacheing, and remoteness.

    public Class Pojo
    {
       performSomeMagic();

       performSomeBusinessLogic();

       getLogic();

       setLogic(Logic logic);

    }

    We have object-oriented programming plus AOP = pojo plus some services.

    Who will be next to captialize on prepackaged services. I don't care if it is standard or not only if it works and I can build enterprise level systems fast. OO had a paradigm shift. AOP and prepackaged services most certainly do as well.

    If you haven't noticed i don't care about the details of AOP I only care about the services so I don't have conform to someones contract that does not allow but for the simplest of object models.

    thanks Jboss

    tx

    Matt
  61. \Smith\
    Everybody has read the literature regarding service oriented architectures especially as they apply to web services. What AOP brings us is a way to apply services to objects. I get it now. With Jboss i define my objects however I want to. Then I pick and choose among the pre packaged services and apply those to my object.
    \Smith\

    Sir, this is your lucky day! I just happen to live in the great, modern city of New York, and the opportunities here are just screaming for people to invest in. Yes sirree, in the land of opportunity this is _the_ hot spot of hotspots. Why, just for example, I have this little bridge here that just might interest you.....

    ------

    Indeed - just go ahead and define any object model you wish, and magically service-enable it at no cost to you or your loved ones....

        -Mike

  62. > Sir, this is your lucky day! I just happen to live in the great, modern city of New York, and the opportunities here are just screaming for people to invest in. Yes sirree, in the land of opportunity this is _the_ hot spot of hotspots. Why, just for example, I have this little bridge here that just might interest you.....
    >
    > ------
    >
    > Indeed - just go ahead and define any object model you wish, and magically service-enable it at no cost to you or your loved ones....
    >
    >     -Mike

    you simplly don't get it. or really you are just afraid. i would say what you spille is fud. the fear is there, the doubt is there, but you are very certain with your remarks.

    Armageddon I tell you! AOP will bring forth Armageddon! Unleashing all the powers of hell, don't go down this road! The weak minded won't be able to tell what is happening. Protect them, Protect them. stifle innovation or Armageddon I tell you! Your day has passed. I guess you can't teach an old dog new tricks.
  63. \Matt Smith\
    you simplly don't get it. or really you are just afraid. i would say what you spille is fud. the fear is there, the doubt is there, but you are very certain with your remarks.
    \Matt Smith\

    Any certainty in my tone comes from many people making the same sort of claims down the years. The form letter is "<blank> enable your application with little or no code!". The reality is that the new <blank>-enabler (in this case I suppose web enablement of existing code via AOP) works as promised for the simple cases, but is a devil to use for the more interesting cases common in business and technology. After you're in production awhile and your code base has grown, you find you're fighting the new spangled tool more often than it helps you.

    \Matt Smith\
    Armageddon I tell you! AOP will bring forth Armageddon! Unleashing all the powers of hell, don't go down this road! The weak minded won't be able to tell what is happening. Protect them, Protect them. stifle innovation or Armageddon I tell you! Your day has passed. I guess you can't teach an old dog new tricks.
    \Matt Smith\

    I seem to have somehow learned a new trick or two since I started programming professionally in '88. :-/ And while AOP will likely _not_ bring on the next apocalypse, it is in my opinion a bad idea.

    You _do_ recognize that not everything new is good? I trust you have seen the garbage heap of miracle technologies that never lived up to the hype? Or are _you_ still using Powerbuilder and "push" technologies and building an on ramp to the information super highway (with an OO database as your persistent store)? :-)

        -Mike
  64. AOPI[ Go to top ]

    <cedric>
    I recently read an article (I can probably dig it out if there's interest) that made a pretty good case as to why using AOP to implement transactions is *not* a good idea.
    </cedric>
    I'd also be interested to see this. But how is AOP transaction management less of a good idea than EJB transaction management? And CMT is probably the area of EJB that developers have welcomed most warmly, which is one of the reasons that it's a popular use for AOP.

    Rod
  65. AOPI[ Go to top ]

    <cedric>

    > I recently read an article (I can probably dig it out if there's interest) that made a pretty good case as to why using AOP to implement transactions is *not* a good idea.
    > </cedric>
    <Rod>
    > I'd also be interested to see this. But how is AOP transaction management less of a good idea than EJB transaction management? And CMT is probably the area of EJB that developers have welcomed most warmly, which is one of the reasons that it's a popular use for AOP.
    </Rod>

    I read something similiar here[1]. But I am not sure if this is the same paper Cedric is referring to.

    --Dilip

    [1] http://lpdwww.epfl.ch/rachid/papers/ECOOP02.pdf
  66. Transactions and aspects[ Go to top ]

    <cedric>

    > > I recently read an article (I can probably dig it out if there's interest) that made a pretty good case as to why using AOP to implement transactions is *not* a good idea.
    > > </cedric>
    > <Rod>
    > > I'd also be interested to see this. But how is AOP transaction management less of a good idea than EJB transaction management? And CMT is probably the area of EJB that developers have welcomed most warmly, which is one of the reasons that it's a popular use for AOP.
    > </Rod>
    >

    <quote>
    I read something similiar here[1]. But I am not sure if this is the same paper Cedric is referring to.
    </quote>


    Yes it is, thanks Dilip.

    --
    Cedric
    http://beust.com/weblog


    >
    > --Dilip
    >
    > [1] http://lpdwww.epfl.ch/rachid/papers/ECOOP02.pdf
  67. Transactions and aspects[ Go to top ]


    I'd also be interested to see this. But how is AOP transaction management less of a good idea than EJB transaction management? And CMT is probably the area of EJB that developers have welcomed most warmly, which is one of the reasons that it's a popular use for AOP.


    They are both very different.

    EJB introduced declarative declarations for transactions, thereby removing the concern for "how do I declare my transaction attributes?", but EJB objects are still fully aware they are transactional.

    This is one of the main point of the paper: objects need to know they are transactional because the way they cope with success or failure of the transaction is part of the business logic.

    If you use aspects to define transactions around objects without them being aware of it, it is very likely that you will end up with a broken model.

    This is what the paper says.

    My opinion: a lot of the points made in this paper can be extended to transparent persistency of POJO's, which might turn out to be a very bad idea after all. But I need to think more about this.

    Just like everything, Aspects can be very powerful or very dangerous. We just need to learn when and how to use them, and I am confident that in a few years from now, we will have a much clearer answer to that (and therefore, I disagree with Mike when he says that the whole concept of Aspects is a bad idea).

    --
    Cedric
    http://beust.com/weblog
  68. Transactions and aspects[ Go to top ]


    I wrote:
    EJB introduced declarative declarations for transactions, thereby removing the concern for "how do I declare my transaction attributes?",


    Please remove any superfluous word that starts with "declar" from the above sentence in order to decrypt it.

    Thanks.

    --
    Cedric
    it's not a spellchecker I need, but rather a brainchecker
  69. Transactions and aspects[ Go to top ]

    \Beust\
    Just like everything, Aspects can be very powerful or very dangerous. We just need to learn when and how to use them, and I am confident that in a few years from now, we will have a much clearer answer to that (and therefore, I disagree with Mike when he says that the whole concept of Aspects is a bad idea
    \Beust\

    My own concerns with AOP lies in it being used as generally as OOP. When thinking about general application usage, the danger aspect definitely overrides the benefits, IMHO.

    This is not to say that there aren't any areas where AOP makes sense. To draw from your own comments and tilt them a bit, when objects _don't_ need knowledge that they're part of a larger call chain, AOP (or less glamorous methods that do the same thing :-) can be very easy to use and powerful with little downside. Beyond the obvious things like call tracing, I know some newer profilers behave in a _very_ AOP-like manner and instrument method entry and exit with profiling byte code.

    But, I believe the areas where an object's complete lack of knowledge of its participation in something larger are fairly limited overall. And at the same time, AOP is _awful_ temptation for many developers to misuse.

    In all, there's a niche of a small number of requirements where AOP makes sense, but it's still a small niche - not one which deserves the amount of attention (and attempt at propogating to a wider audience) which AOP seems to be getting at the moment.

         -Mike
  70. Transactions and aspects[ Go to top ]


    Mike writes:

    My own concerns with AOP lies in it being used as generally as OOP.


    I don't think you will find a single AOP advocate claiming that AOP should replace OOP. The general understanding is that AOP is a complement to OOP, which makes total sense for me (horizontal / vertical separation of concerns).


    But, I believe the areas where an object's complete lack of knowledge of its participation in something larger are fairly limited overall. And at the same time, AOP is _awful_ temptation for many developers to misuse.


    Agree on both counts.


    In all, there's a niche of a small number of requirements where AOP makes sense, but it's still a small niche - not one which deserves the amount of attention (and attempt at propogating to a wider audience) which AOP seems to be getting at the moment.


    Attention is good, even if it sometimes takes the appearance of hype :-)

    Your points are well taken, but maybe it's this very attention that will make AOP evolve to a point where it will grow out of its niche.

    For example, initially, "C with Classes" didn't have inheritance, and therefore garnered little interest. One day, inheritance was added to it and C++ was born. The rest is history. Maybe AOP will follow the same path.

    In the meantime, I am very happy to see everyone react and comment about it. Anything that shakes our common views on software engineering is a Good Thing in my book.

    --
    Cedric
    http://beust.com/weblog
  71. Transactions and aspects[ Go to top ]

    \Beust\
    I don't think you will find a single AOP advocate claiming that AOP should replace OOP. The general understanding is that AOP is a complement to OOP, which makes total sense for me (horizontal / vertical separation of concerns).
    \Beust\

    Personally, at the risk of sounding a bit crude, I've found them to be a dime a dozen.

    If nothing else, the JBoss AOP forums demonstrate that amply. Oh, I think there a number of people who have seriously investigated the technology and made reasoned decisions on it, but for every one of them there are innumerable developers who seem to be salivating at the idea of using AOP aggresively, and ultimately supplanting much of what they achieve using OOP today.

    \Beust\
    Your points are well taken, but maybe it's this very attention that will make AOP evolve to a point where it will grow out of its niche.

    For example, initially, "C with Classes" didn't have inheritance, and therefore garnered little interest. One day, inheritance was added to it and C++ was born. The rest is history. Maybe AOP will follow the same path.
    \Beust\

    You pick a very, very intersting example. I myself I have followed the trial and tribulations of C++ since the very early '90s. And the correlation between C++ and AOP is very, very telling.

    To this day, C++ implementations are incompatible at the link level, and often subtly incompatible at the source level as well.

    C++ has a number of mechanisms directly targetted at maximizing the language's power - and the designers' attitude has always been "it's not _our_ fault if developers mis use it".

    In the last three organizations I've worked for in the past 6 years or so, not a single one of them claimed to understand even 50% of the C++ language spec. Worse - the same held for debugging and maintaining other developer's C++ code.

    The parallels to AOP are very compelling to me. They obviously offer enormous power - but at what cost?

    Perhaps, as C with Classes morphed into C++, and yet the larger community found this wanting, the latter refinement ultimately was rejected by the development community in favor of a cleaner implementation with Java. Likewise, perhaps AOP is still in its C++ stage, and will be supplanted by something a bit cleaner.

    But, personally, I rather doubt it. The biggest problem with C++ was always the fact that it was based on C (perhaps coupled with a lack of a common Object to descend from). But AOP's plusses and minuses compared to C++ look quite different to me. Here, you don't have a problem that the underlying fundamentals are flawed and unsafe. Instead, you have the problem of a system predicated on patching code to work in new and different ways. A completely different beast altogether IMHO.

        -Mike
  72. That is what I fear[ Go to top ]

    <QUOTE>
    Oh, I think there a number of people who have seriously investigated the technology and made reasoned decisions on it, but for every one of them there are innumerable developers who seem to be salivating at the idea of using AOP aggresively, and ultimately supplanting much of what they achieve using OOP today.
    </QUOTE>

    And that is one of my primal fears. A lot of those are the people I have seen falling way short to understand clos AOP-like constructs, C++ Macro usage or even simple pluggable object architecture. AOP is - in its most general form - the ultimate shortcut for a lot of very good developers but it can also be the ultimate dead-end for large scale development.

    From what I see in the industry, there are still programmers out there, earning $1000 per day who need 4 weeks to compose a simple JMS message or build a plain EJB (or JDO demo) - let alone, understand what they are doing. A lot of those people have expressed that they are looking forward to using AOP.
  73. That is what I fear[ Go to top ]

    We must work at the same place!

    -Adam
  74. Transactions and aspects[ Go to top ]

    But, personally, I rather doubt it. The biggest problem with C++ was always the fact that it was based on C (perhaps coupled with a lack of a common Object to descend from). But AOP's plusses and minuses compared to C++ look quite different to me.

    Ah, thanks for making this point for me :-)

    Just like you, I am well aware of C++'s history along with its strengths and weaknesses (I was actually a member of the C++ Committee for a few years), but I don't want this thread to turn into a C++ discussion.

    Yes, there is potential for AOP to follow a path similar to C++', but there is also potential for it to become a very useful technology. For example, the AspectJ syntax might turn out as either a strength (built on top of Java) or a weakness (need to comply with an older technology that is not necessarily a good match for the new concepts introduced).

    History tends to repeat itself but in subtly altered ways, and sometimes, the chaos theory kicks in and we get ushered in a brand new era...

    --
    Cedric
    http://beust.com/weblog
  75. Transactions and aspects[ Go to top ]

    <cedric>
    EJB introduced declarative declarations for transactions, thereby removing the concern for "how do I declare my transaction attributes?", but EJB objects are still fully aware they are transactional.
    </cedric>
    The EJB spec promised complete decoupling of transaction management from EJB implementation code, in separate roles. It was intended to be treated as an aspect.

    I agree that there is a potential danger in decoupling tx behaviour from objects themselves. I see metadata attributes as one way to address this. But I think that there is still practical value in being able to add transactional contexts for existing objects. If rollback is triggered by exceptions etc. there is a clear, testable, contract for how those objects will behaviour within an AOP-managed transactional context.

    I 100% agree with your comment that AOP complements OO. I see AOP as solving certain problems that OOP addresses poorly: not as a replacement for OOP.

    Regards,
    Rod
  76. Transactions and aspects[ Go to top ]

    Is that really what the EJB specification attempts to deliver? I'd argue that at it's core EJB is nothing more than a transaction monitor built around components that, as Cedric points out, are very much aware that they have transactional semantics. Rather than marginalizing transaction management to an aspect it tries to make transaction management safer -- as opposed to, say programming in raw TX/XA or OTS, both of which are highly error prone on an ad hoc basis.
  77. AOPI[ Go to top ]

    I'm curious if anyone has a perspective on the paper to which a link was posted in this context as an end user?

    I've said before on other threads that using AOP for transaction management is probably a very bad idea, but I think this may be a perspective shaped by my own experiences writing several EJB containers and related infrastructure. The lifecycle semantics of the bean and the container services are both tied intimately to the participation of the bean in transactions. That is to say that the response of the container to specific events in the bean and the transaction determine well-understood and *appropriate* reponses. I've had a hard time imagining how an aspect on an arbitrary object would provide the same level of safety for end users; or how this would be achieved with other independent aspects competing for "ownership" of the object and control of it's lifecycle. In that case of transaction management, missteps in applying aspects are likely to lead to data inconsistency, which is about the worst outcome I can imagine.

    As a middleware developer, I tend to be attracted to AOP as a mechanism for structuring well-understood implementation strategies, but the more I play around the more I tend to agree that we have a lot to learn before we say this is a generally useful programming paradigm.
  78. AOPAlliance Code[ Go to top ]

    I've looked briefly at the codebase at the provided URL.

    All I can say is - the interfaces appear to model a generalized event mechanism with chaining :-)

    The primary difference in the actual code I see is in terminology. The code base uses terms like "intercept" quite often. If you don't think in terms of AOP, however, and just look at what the code does, it's really a dynamic way to register call chains (or, in general, good old event propogation).

    Of course, I assume the POJOs stuck in the middle aren't supposed to be aware that they're part of a call chain, and this is where AOP differs from my own ideas. Personally, I think if you're participating in an event system you should be aware of it, so you can actively contribute - and also constrain things as necessary. If I need to "widen" my interface of passed around objects to take into account more information than I thought necessary, I'd prefer to do that as an explicit design decision. I particularly do _not_ like the idea that an interceptor can peak at my attributes without my explicitly exposing them.

    What keeps an event system pulled together is that it is somewhat explicit, and you have to work hard to expose extra information when you're propogating events - typically you can only on the information given you, and pass on only what you wish to, and encapsulation still holds. To me, this is a very, very good thing. It means I can make radical changes to what amounts to POJOs in the chain (with chain "awareness") without impacting anything. From what I've heard and seen in AOP, and from the glimmer I've caught in the aopalliance code, that contract appears to be broken. Please correct me if I'm wrong, but it looks like encapsulation is _completely_ broken, and an interceptor can grab things it hasn't been explicit permission to grab. I hope I'm miss reading things, but are things like private methods and instance variables honored here in the POJOs? If so, then I've been overly reactionary :-) If not, it's something I wouldn't touch in a million years.

        -Mike
  79. AOPAlliance Code[ Go to top ]

    <Mike>
    I hope I'm miss reading things, but are things like private methods and instance variables honored here in the POJOs? If so, then I've been overly reactionary :-) If not, it's something I wouldn't touch in a million years.
    </Mike>

    Well, in the purest form AOP does allow to point cut on all constructs of the host language (including private variables, private methods, exception handlers, etc.; see AspectJ, for example)… This, however, is regarded mostly as academia related features and clearly bears little practical usage in actual projects for very reasons you have mentioned. I believe most of the upcoming AOP support will be concentrating around more restricted pointcuts and aspects, and “extreme” AOP will be part of the past.

    I think this area of research is still loosely defined and initial discussion in this topic was to promote the exchange of ideas in this and other areas of AOP.

    Thank you,
    Nikita Ivanov.
    Fitech Labs., Inc.
  80. AOPAlliance Code[ Go to top ]

    <mike>
    I hope I'm miss reading things, but are things like private methods and instance variables honored here in the POJOs? If so, then I've been overly reactionary :-) If not, it's something I wouldn't touch in a million years
    </mike>
    Currently AOP Alliance interfaces only specify method interception against interface methods (to allow dynamic proxy implementation). Thus this doesn't violate encapsulation--in fact it encourages the use of interfaces. AOP can be used to create an implementation of an interface. All the interceptors I've written (or would want to write) do not dig into private methods and variables. There's no more breaking of encapsulation than with EJB.

    If you want to regard this as "a generalized event mechanism with chaining" that's OK by me. I think there's great value in such a mechanism. I'm more interested in how it can be used to solve common problems than what it's called.

    Regards,
    Rod
  81. \Tirsen\
    AOP is a generalization of the component/container model used in for example EJB and COM+/MTS. These technologies are trying to solve real world problems of high complexity (persistence, distribution, security and so on) although unfortunately they are not succesful. Remember that these problems have not yet been solved, AOP has a higher chance of doing this than any alternative.
    \Tirsen\

    Uh - I think you need to define the word "solved" here. Are you saying all those systems out there using J2EE and, say, Stateless Session Beans don't work, or don't use persistence, distribution, security and so on?

    Beyond that - I think saying AOP is a generalization of components/containers is a vast understatement.

        -Mike
  82. AOP is a generalization of the component/container model used in for example EJB and COM+/MTS.

    > Compared to the dozens of systems I've built with EJB it has resulted in much clearer design and code. In my experience Nanning is easier to understand and much more powerful than EJB (since you can implement and tune whatever aspects you'd like, not just those defined by EJB).

    Sure, AOP has the potential to amount to much more than this, but this is a very strong case for using AOP (in Nanning, JBoss, Spring Framework etc) right now. While it only uses a subset of the power of AOP, it enables us to solve many of the problems addressed by EJB in a far more flexible way. It can deliver the benefits of a container without a single monolithic container: choose the aspects you want. And as we're all familiar with the way in which EJB interception works, we have all embraced the fundamental concept. It's just a question of making that concept more general.

    More radical uses of AOP will almost certainly prove themselves. But I think it is fair to say that the jury is still out on their effect on large and complex systems. However, as some posters have pointed out, OO was experimental not so long ago, and now it's an article of faith. So we should be prepared to continue to embrace new concepts.

    Regards,
    Rod
  83. 1. Read-write (mutating) aspects break the fundamental basics of OOP by

    > requiring the knowledge of the internal implementation details for
    > advised code.

    It's just code, as usual, having the usual documentation requirements. This information can be put into JavaDoc and made available, either through HTML or directly in an IDE.

    > 2. Even read-only (non-mutating) aspects applied to non-public constructs
    > may require knowledge of internal details for advised code.

    Again, this is a documentation issue. Some advice will require more understanding of what they do and how they work, but this goes for regular OO-code too I think.

    > 3. AspectJ is a whole new language (i.e. couple of dozens new keywords on
    > top of the Java) and it is a way too much to pay for a new programming
    > technique. OOP-language based AOP framework should give better value.

    This is a loose assertment that I don't know how to comment. It can be good with AOP implemented as a language, and it can be bad. We opted for a framework/descriptor based framework, which has worked well for us in our particular situation.

    > 4. Besides the venerable logging and security check examples that are
    > popping up in every AOP discussion, is there any real-life applications of AOP
    > (i.e. using AOP-based frameworks) large enough for good statistical analyses
    > (excluding Rickard Oberg’s CMS)?

    Not sure why you want to exclude our case. I think much good knowledge can be gained by looking our app as an example. For example, I was surprised to see how many advice are application-specific/domain-specific vs how many are system-oriented (transactions, logging, etc.).

    > 5. As far as security check example (or in general): where is the proof
    > that AOP-based implementation for security check is anyhow better than a
    > traditional one implemented using normal OOP practices? Is it not just an
    > alternate way which can be judged only on the case-by-case basis?

    I guess that depends on how you define "better". It usually amounts to less amount of code which is less mangled into your application, and that's good enough for me at least.

    > 6. Free-defined, unrestricted pointcuts promote spaghetti-like coding and
    > ad-hoc design.

    Sure, but that goes for any paradigm I know of (OO-coding, procedural coding, XP, RUP, etc.). No structure=chaos is a universal rule, which applies here as well as anywhere else.

    > 7. AOP may introduce excessively tight coupling between aspect and advised
    > code. Advised code cannot be freely changed if there is a mutating aspect
    > attached to it (see p.8 for further complication).

    This is entirely depending on the case, and your first assertment appropriately included a "may". Your second should include one too.

    > 8. Since aspects are defined in a different language (or XML), the logic
    > gets split into two semantically different places further complicating
    > coupling.

    Or making it simpler, depending on how the XML/language works, and how the programmer interacts with it.

    All in all, I'm not too worried. At least not about our particular application, using our particular AOP framework, with our particular rules for creating advice/mixins. Your mileage may vary...

    /Rickard
  84. Rickard wrote:

    >> 1. Read-write (mutating) aspects break the fundamental basics of OOP by
    >> requiring the knowledge of the internal implementation details for
    >> advised code.
    >
    >It's just code, as usual, having the usual documentation requirements. This >information can be put into JavaDoc and made available, either through HTML >or directly in an IDE.
    >
    >> 2. Even read-only (non-mutating) aspects applied to non-public constructs
    >> may require knowledge of internal details for advised code.
    >
    >Again, this is a documentation issue. Some advice will require more >understanding of what they do and how they work, but this goes for regular OO->code too I think.

    Well, it just reminds me one person from Microsoft that told me that not having checked exceptions in C# is perfectly fine since there is **always an XmlDoc** that tells you what exceptions are thrown, when and why. One caveat though is that it is a known fact that code-level documentation can be kept up to date only in tightly controlled projects with strict engineering discipline while all other projects (safe to say > 90%) will have documentation that is out-of-date. It is especially true when we are talking about internals of the system or implementation details.

    So the same goes for the Rickard’s comments: relying on code comments for a proper development of aspect is all but impractical for absolute majority of the projects out there.

    >> 6. Free-defined, unrestricted pointcuts promote spaghetti-like coding and
    >> ad-hoc design.
    >
    >Sure, but that goes for any paradigm I know of (OO-coding, procedural coding, >XP, RUP, etc.). No structure=chaos is a universal rule, which applies here as >well as anywhere else.

    Agree in general (any programming paradigm can produce spaghetti-like coding and ad-hoc design). However, I think the point, as it regards to AOP, is missed here. I don’t want to delve into a deep discussion but it is a known fact (among those few really known facts about AOP) that at least in the current implementations that require some sort of “weaving” process, AspectJ is a good example, AOP gently pushes you into ad-hoc mode and pilled up aspects on OOP advised code start to amount to a spaghetti-like code. But again, this can probably be seen only from the certain prospective of a large, long-haul project.

    >> 7. AOP may introduce excessively tight coupling between aspect and advised
    >> code. Advised code cannot be freely changed if there is a mutating aspect
    >> attached to it (see p.8 for further complication).
    >
    >This is entirely depending on the case, and your first assertment >appropriately included a "may". Your second should include one too.
    >
    >> 8. Since aspects are defined in a different language (or XML), the logic
    >> gets split into two semantically different places further complicating
    >> coupling.
    >
    >Or making it simpler, depending on how the XML/language works, and how the >programmer interacts with it.

    I disagree with assessment but in an essence this is exactly why I have excluded Rickard’s work from the possible examples... I have no doubts that his (and Bill Burk’s, and, frankly, mine with certain remarks, and others) experience would be positive since he is rather not a usual case of using AOP in enterprise system. I think we are getting a lit bit of one-sided view since many of us are AOP-framework developers. We don’t really get many thoughts from rank-and-file software developers that are working in other industries building their ERP, EAI, etc. systems and using these AOP-frameworks (but no developing them).

    Thanks!
    Nikita Ivanov.
    Fitech Labs., Inc.
  85. Rickard wrote:

    > >Again, this is a documentation issue. Some advice will require more >understanding of what they do and how they work, but this goes for regular OO->code too I think.
    >
    > Well, it just reminds me one person from Microsoft that told me that not
    > having checked exceptions in C# is perfectly fine since there is **always an
    > XmlDoc** that tells you what exceptions are thrown, when and why.

    Determining the behaviour of an API, whether it is implemented using AOP or not, will always be reliant on how well it is documented. As I said, this is no different from the non-AOP case, although it *does* become more important to have good documentation tools and practices.

    Of course, if the framework being used is based on a per-instance weaving then this will be very difficult, since there is no "class" of objects that behave the same, thus making it difficult to document the behaviour, but that's another topic.

    > One caveat though is that it is a known fact that code-level documentation can
    > be kept up to date only in tightly controlled projects with strict
    > engineering discipline while all other projects (safe to say > 90%) will have
    > documentation that is out-of-date. It is especially true when we are talking
    > about internals of the system or implementation details.

    You may be right, but it probably no difference between AOP and non-AOP projects.

    > So the same goes for the Rickard’s comments: relying on code comments for a
    > proper development of aspect is all but impractical for absolute majority of
    > the projects out there.

    Nope, it's practical alright. Just because noone does it doesn't mean it's not practical. It just means that noone does it, for various reasons.

    > Agree in general (any programming paradigm can produce spaghetti-like coding
    > and ad-hoc design). However, I think the point, as it regards to AOP, is
    > missed here. I don’t want to delve into a deep discussion but it is a known
    > fact (among those few really known facts about AOP) that at least in the
    > current implementations that require some sort of “weaving” process, AspectJ
    > is a good example, AOP gently pushes you into ad-hoc mode and pilled up
    > aspects on OOP advised code start to amount to a spaghetti-like code. But
    > again, this can probably be seen only from the certain prospective of a large,
    > long-haul project.

    What you're saying, then, is that ad-hoc design and spaghetti-like coding is bad. Couldn't agree more. The question seems to be: does AspectJ, or any AOP tool, take the responsiblity from you as a developer, with regard to what the design looks like and evolves? You seem to say yes, and I would say no.

    > excluded Rickard’s work from the possible examples... I have no doubts that
    > his (and Bill Burk’s, and, frankly, mine with certain remarks, and others)
    > experience would be positive since he is rather not a usual case of using AOP
    > in enterprise system.

    Sure, since we are not using AspectJ, and since we're using lots of metadata instead of regexps for pointcut designators, etc., hence avoiding many of the pitfalls of AOP. But, I thought we were talking about AOP in general, both with regard to what the current implementations do and what they could theoretically do.

    /Rickard
  86. RIckard wrote:

    >> One caveat though is that it is a known fact that code-level documentation can
    >> be kept up to date only in tightly controlled projects with strict
    >> engineering discipline while all other projects (safe to say > 90%) will >have
    >> documentation that is out-of-date. It is especially true when we are talking
    >> about internals of the system or implementation details.
    >
    >You may be right, but it probably no difference between AOP and non-AOP >projects.

    I think you've missed the point on that one, in my opinion. You are right, documentation issues are the same for AOP and non-AOP projects. But only AOP makes it almost a requirement to have knowledge about internal implementation, while OOP, as just an example, tries to hide and protect the very same implementation details. I think the difference is obvious, and so the original conclusion.

    Regards!
    Nikita Ivanov.
    Fitech Labs., Inc.
  87. Rickard wrote:

    > Sure, since we are not using AspectJ, and since we're using lots of metadata instead of regexps for pointcut designators, etc., hence avoiding many of the pitfalls of AOP. But, I thought we were talking about AOP in general, both with regard to what the current implementations do and what they could theoretically do.
    >
    > /Rickard

    Rickard, I'm starting to see the same things as I'm using and developing JBoss AOP. That metadata instead of regexps are better for pointcut designators and will probably alleviate some of the pitfalls of AOP are talking about here.

    I like to think of metatags as pluggable Java language keywords. Where XDoclet now, and JSR 175 later, is the way to declare new tags, and AOP is the glue to implement and apply the functionality these new "keywords" describe.

    BTW, one thing I found out about JSR 175 is that there is no dynamic interface so far, or plans to have one. This is truly disappointing. I have fired off a few emails to Joshua Bloch about this. If anyone else agrees that JSR 175 should have a dynamic interface, please help and lobby Mr. Bloch and the JSR 175 committee about this. Thanks.

    Bill
  88. If you dealt with AOP before, there are
    inevitable examples that seem to make perfect sense. One fine example shows how logging and tracing can be factored out to some extent. Surely this can be a great tool for development support. And maybe you
    have seen examples of how to do something else like persistence with AOP - granted this may take you some way down the road. But I tell you what: It is very hard think of a crosscutting concern in the "real world", that is the world of physical things and business processes we all deal with on a day to day basis - even with logging - in the business process meaning - it is not easy to identify the cross cutting characteristics of it. I find this absolutely striking. Both functional decomposition and object orientation had perfect analogies in everyday life - apart from being very useful as a design concept, e.g. for graphical user interfaces in case of object orientation.

    After I thought about it for some time, it dawned on me that there is in fact a perfect analogy in real life: Law. Think about it: You have laws and laws all intersect, they must be considered at once, some may take precedence over others (like constitutional rights over common
    law). There are thousands of lawsuits that must be considered to assess a certain legal problem that add and interpret the law.

    There is however a basic problem with law in the sense aforementioned: It is often so complicated that it cannot be understood even by law professionals and is easily so complicated that it is impossible to handle it yourself. For example, your very country (in a lot of countries that is) doesn't trust you to buy a house on your own, without consulting a lawyer or a notary. Law is so complicated that it is literally on prescription.

    In my opinion, this is precisely what AOP heads to. Instead of creating a construction that can be observed and whose behaviour can be deduced or even anticipated, you actually create a complicated arrangement of laws and convictions. You created something hard to maintain and to understand for newcomers. Or to put it short: AOP can easily create the software developers nightmare.
  89. If you read the articals regarding multidimensional separation of concerns and the foundational theory behind aspects, the concepts are sound. They do help in identifying the different aspects in addition to business logic that need to be addressed.

    I find that language level application of AOP is fundamentally flawed because there is no real structure to it. Because there is no real structure, the contracts are fuzzy. Because the contracts are fuzzy, an Aspect Language coded project is more difficult to understand than a traditional OOPL coded project.

    Nevertheless, that does not negate the benefit of at least considering concerns.

    I find that component oriented programming (COP) provides excellent and natural boundaries where aspects can be applied predictably. Because the container takes care of the individual components, it can impose role-based security, tracing, standardized exception handling, contract enforcement, and more all invisibly to the component writer and the component user. The contracts are much easier to understand, and it is more predictable to define how aspects are applied at component boundaries. If the container supports remoting of your components, then that is an aspect that is orthagonal to what the component *does*. By providing the proper meta data to the container, it can make the proper decisions on what components have which aspects applied.

    To sweeten the pot even more, all this can be done without resorting to language modifications.

    Language modifications are necessary when there is an overuse of the Singleton pattern, or too many static accessors where coupling is completely uncontrolled.
  90. <-- snip -->
    If you read the articals regarding multidimensional separation of concerns and the foundational theory behind aspects, the concepts are sound. They do help in identifying the different aspects in addition to business logic that need to be addressed.
    <-- snip -->

    I am quite under the opposite impression. I have read dozens of articles, conference proceedings etc. and I was absolutely unable to find a "sound concept". In fact I found it quite hard to find any concept at all. "Multidimensional separation of concerns" sounds very cool, but since there is no clear way to express what a concern *is* in the first place, it also sounds quite empty. And terms like join points and pointcut are most of the time defined in a purely practical sense as well. There are implementation you can use to do really cool things with less code - and ultimately less readibility. But that does not support the very idea of orthogonal aspects in software design. There are in fact very few things that are purely orthogonal. Decisions about transaction boundaries, optimistic vs. exclusive, auditing etc. are often at the very heart of what the "component actually does", sometimes called the "business functionality". In fact AOP is - concept wise -like "patch" and "interceptions" on steroids most of the time.
  91. For the philosophers among you, you might like to look at this page
    http://www.basden.u-net.com/Dooy/

    Particularly "Dooyeweerd's Theory of Modal Aspects"
  92. \Karl Banke\
     There are in fact very few things that are purely orthogonal. Decisions about transaction boundaries, optimistic vs. exclusive, auditing etc. are often at the very heart of what the "component actually does", sometimes called the "business functionality". In fact AOP is - concept wise -like "patch" and "interceptions" on steroids most of the time.
    \Karl Banke\

    This cuts right to the heart of the matter, and very elegantly states a significant problem with AOP. I had similar concepts in this shower this morning, but hadn't figured out a good way to state it.

    It seems a fundamental point of AOP is that a single set of well-defined point cuts can provide complete functionality against a given concern - like transactions, logging, etc. If you want the code count to be low, and truly implement a consistent behavior, you'd want your AOP code to be relatively universal, so that it applied to a wide array of of objects and coerced the same kind of concern-specific behavior on them.

    But Karl states a problem here quite well - few things are purely orthogonal. Auditing, logging, transactions in a complex environment driven by all to real complex business needs more often than not break orthagonality. In a nutshell, real business needs often break the consistent "elegance" and regularity that developers strive for.

    In OO, to get around this, there is often default behavior, but a given component can always break in and interact directly with the "concern" in operation. One component may have unusual auditing requirements; another may interact with transactions in a peculiar manner. These sorts of things happen increasingly as systems grow - the exceptions start to outnumber the rules (and hence breed an entire industry of business rules engines :-)

    The point is that existing OO frameworks directly allow individual components to take direct part in the framework flow when they have unusual needs. The default behaviors still exist, and maintainability is still possible because the complex "exceptional" behavior is encapsulated in the components which need it.

    However - AOP seems designed so that components aren't even aware that they're part of a framework. Indeed, the point is that you can intercept a call magically without a component's knowledge. This is fine and well - until the generic AOP "concern" does not address a specific component's needs.

    At that point - what do you do in AOP? In an OO framework, a component can always grab a handle on the appropriate framework object and modify it for it's specific needs (e.g. you can use declarative transactions and get sane defaults most of the time, but you always have the opportunity to grab the transaction context, query it, and perhaps directly affect it). Can this be done in AOP? Can instrumented code interact with the instrumentation? If not - then your AOP pieces may be forced to implement innumerable special cases, and effectively special behavior is now fragemented across the system (in both POJOs and the AOP code as well).

        -Mike
  93. This comment :

    <Mike Spille>
    However - AOP seems designed so that components aren't even aware that they're part of a framework. Indeed, the point is that you can intercept a call magically without a component's knowledge.
    </Mike Spille>

    along with this statement:

    <rod johnson>
    Currently AOP Alliance interfaces only specify method interception against interface methods (to allow dynamic proxy implementation). Thus this doesn't violate encapsulation--in fact it encourages the use of interfaces.
    </rod johnson>

    seem to me to be contradictory. That is, objects need to be AOP aware: Which is highly undesirable. If I have to write inerfaces so that AOP can do its magic, then any orthogonality is lost.
  94. <quote>
    That is, objects need to be AOP aware: Which is highly undesirable. If I have to write inerfaces so that AOP can do its magic, then any orthogonality is lost.
    </quote>

    You may have misunderstood this: The object has to implement _any_ (business) interface it wants, not an AOP-specific one. This is good practice anyway, and a requirement for any component model (or remote services, for that matter): Code to interfaces, not to concrete classes, to enable loose coupling.

    Juergen
  95. For instance:

    public class MyClass {
    private String myState = "this is my state";
    private Logger myLogger = new Logger();

    public void doSomething() {
    myLogger.log("The current state is: " + myState);
    // ... other stuff

    }
    }

    would need to be replaced by:

    public class MyClass {
    private String myState = "this is my state";

    public void doSomething() {
    // ... other stuff
    }
    }

    and AOP could provide me with equivalent functionality only if I have a method
    to get myState??????

    If true then that means the interface is dependent on how AOP is being used...that couples the interface...which defeats the whole purpose, n'est pas?

    I am a neophyte in the AOP arena so please be gentle if I'm off the mark.
  96. Sartoris,

    Better examples of AOP are system-level constructors

    From J2EE:
    - transaction demarcation
    - role-based security

    Beyond J2EE:
    - Transactional ACID POJOs.
    - implicit replication

    Beyond RMI:
    - Declaring an object remotable at runtime.

    These are all Aspects that JBoss 4 implements.

    http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/aop

    Bill

    > For instance:
    >
    > public class MyClass {
    > private String myState = "this is my state";
    > private Logger myLogger = new Logger();
    >
    > public void doSomething() {
    > myLogger.log("The current state is: " + myState);
    > // ... other stuff
    >
    > }
    > }
    >
    > would need to be replaced by:
    >
    > public class MyClass {
    > private String myState = "this is my state";
    >
    > public void doSomething() {
    > // ... other stuff
    > }
    > }
    >
    > and AOP could provide me with equivalent functionality only if I have a method
    > to get myState??????
    >
    > If true then that means the interface is dependent on how AOP is being used...that couples the interface...which defeats the whole purpose, n'est pas?
    >
    > I am a neophyte in the AOP arena so please be gentle if I'm off the mark.
  97. Well, certainly my head is spinning, and I'm seeing _alot_ of conflicting information here. From the first "feature bullet" on the JBoss AOP Page:

     "Java Class Interception. Field, constructor, and method interception, public, private, protected, and package protected, static and class members."

    Sounds to me like JBoss AOP can intercept anything, anywhere, anyhow. And it's the number one feature :-) Am I wrong here? The only example I've seen is the tracing stuff which purposely doesn't trace fields for some reason.

    So is JBoss AOP designed to access private data or not? If so, do you find you need it for some your advices?

        -Mike
  98. JBoss AOP Usage intents?[ Go to top ]

    Bill, scanning the JBoss AOP forums has really put the fear of <insert deity here> into me. From a little discussion on intercepting private class pieces:

    """ (Marc fleury)
    > I have a quick question that I haven't seen discussed
    > here or other AOP sites that I visit. If there is a
    > link to the discussion of this topic that would be
    > great.
    >
    > Is it proper or even a bad thing to intercept private
    > fields and method? Isn't that essentialy breaking
    > encapsulation and possibly security consern.

    If you can do it and it feels good, jfdi as adrian says

    > Will you be able to intercept 3ed party libraries and
    > use their internals in ways that the author didn't
    > intend?

    ok, see bill's answer. The question is valid. The answer is yes we can instrument methods in 3rd party libraries. Say for example that you want to instrument JDBC drivers to scan the invocation in order to add security and plug loopholes then all you have to do is pointcut the methods you want to secure in XML and then add your magic "string watcher". So yes there are very valid uses cases for system level instrumentation of classes (done in classloaders) that allow to statically monitor a given object in the runtime in a fashion that is non-intrusive with the existing class.

    [...]

    I guess the point here is that you can take even poorly architected J2SE applications and kinda make them look like EJB's. In fact this is the way we implement EJB, by bundling aspects.

    """

    """ (spiritual mechanic)
    This it seems to me is one of the more interesting side-effects of an AOP/Proxy approach. JBoss could become a language-agnostic architecture, where you could add services to any object from any language (Python, Ruby, Java, etc.).
    """

    """ (Bill Burke)
    > Will you be able to intercept 3ed party libraries and
    > use their internals in ways that the author didn't
    > intend?
    >

    Of course. But so what? If you're gonna be a stupid programmer, then, just be stupid.
    """

    """ (Corby)
    That is such a cool use case. With AOP the user community will be able to develop and distribute patches and bugfixes to closed, proprietary software. I am geeked!
    """

    """ (thomasa)
    Do you think when private fields on a class have changed, or when private methods have been called, that the object is defined as "dirty"? I realize that in the purely technical aspect that this IS the case, but this could be an interesting topic in terms of what the contract/agreement between the class and its users is, or is perceived to be. In my head in an ideal situation, changes made through the use of purely private variables or methods should not be regarded to mark an object as dirty unless this direcly affects the state as defined by the publicly available methods and/or variables.
    """ (thomasa)

    It sounds to me like JBoss and its lead developers are pushing for the most open ended AOP possible, where anything can be accessed at any time - and which happens to be my worst nightmare. In fact, someone even mentioned using JBoss AOP to patch 3rd party libraries after the fact.

    Don't you guys see what road you're going down here!?!?

        -Mike
  99. I'm beginning to understand some of the concerns about AOP. One concern is that advice can do things with a POJO that it wasn't supposed to be able to. I agree that this opens up a can of worms that is going to be hard to shut. This is why the framework I've written only deals with interfaces so that it is always known what is POJO-internal and what is exposed.

    Another question seems to be what kind of advice are useful besides logging and tracing. In our product that is based on the AOP framework I wrote we have the following kinds of advice:
    * The "standard" transaction/logging/security stuff
    * Some cache-oriented ones, i.e. purge a cache when a write-method is called and cache values from read-methods.
    * A whole lot of lifecycle event side-effect advice. This mostly comes down to initializing and creating/removing aggregate objects. Very useful, and helps keep the objects loosely coupled.
    * Method invocations on the client are caught by an advice and stored in a queue which can then be sent to the server and applied in a standard "Ok,Cancel,Apply" kind of affair. This removes the need for value objects and is very handy.
    * Various side-effects oriented advice, such as setting last-modified on an object when a set-method is called.
    * Some persistence-related ones, such as delaying calls to create/store/remove until the tx commits. This is a decent poor-mans tx's for any underlying store which works quite well. (this obviously doesn't handle system exceptions, but for application exceptions it's awesome to have)

    etc. At the moment about 2/3 advice are application specific ones related to lifecycle side-effects. As time goes this part will obviously increase, as new objects are introduced.
  100. I'm beguiled by AOP, and see that it has both great potential and significant dangers. Currently it is equivalent to "assembly languages" in terms of maturity. Would I use AOP? Yes, judiciously, because I appreciate how AOP would have enabled me to significantly simplify some of my previous code and, in one case, to achieve a significant increase in functionality.

    Nonetheless this note concentrates on some of the problems that I would like to see addressed.


    Average-quality Developers and Maintainers
    ------------------------------------------

    Given some of the truly bizarre misuses of standard OOP/OOD technology that I've seen (even though OOP/OOD is nominally mature and well understood), I hate to think of the incomprehensible mess that would result from letting average-quality developers use it. The result could be like a bowl of spaghetti that mutated into green beans whenever it is executes.

    Yes, I realise that good developers would use it "cleanly and responsibly", but let's keep our feet on planet earth.


    Code Review, Debugging, Testing, Deployment
    -------------------------------------------

    With standard OOP/OOD techniques, the entire behaviour of an application can be defined in the source code. One of AOP's stated benefits is that you specifically *can't* define the behaviour in the source code, since the "object code" can be invisibly mutated/patched by the AOP framework.

    "Patching the binaries" is, justifiably, a red-flag to many people.

    Unit and component level testing becomes less sufficient, since the component's *internal* behaviour might be modified each time it is integrated/deployed.

    Debugging binaries that aren't in-step with their source code is "interesting". (Yes I realise that level of debugging is often inappropriate/impossible).

    When I'm trying to locate a problem, I hate having to "mentally merge" several files. That's one reason why I hate c++'s operator overloading: I've no idea what "a=b+c" actually "means" without looking in several different files.


    Maturity
    --------

    We need the equivalent of the GoF Design Patterns. Yes Design Patterns are merely a codification of existing practice; that's the point, and "battlefield experience" is missing with AOP.


    AspectJ/Interceptors
    --------------------

    AspectJ is a great "assembly language level tool" in that it is extremely flexible and powerful, and doesn't preclude any form of AOP. Thus it is a superb research tool, but for production code I'd require that only gurus are allowed to use it.

    Interceptors and dynamic proxies feel far more controllable, somewhat analagous to "structured programming".


    Alternatives
    ------------

    Yes, there are alternatives to achieving the benefits claimed for AOP. Code generation has a lot going for it, particularly if it starts from a sound theoretical level.

    MDA is particularly interesting in that respect (for some classes of problems), since it is based on the best techniques developed over the past 50 years (I got a similar feeling with Java :). But there's a lot of hype about MDA.
  101. Does it Matter?[ Go to top ]

    AOP is another choice for programmers. Nobody is making anyone use AOP. It has some tremendous benefits and some of your criticisms are valid.

    Bottom Line: Why debate something that is here and not going away? Some will use it many others wont. I have found using the .NET version (I know.. Not REAL AOP but who cares.. it works) quite helpful.

    How about discussing some of the advanced and innovative things people have done with AOP? .NET only offers a few Strongly typed Collection: BitArray, StringCollection and StringDictionary. Everything else takes 'Object'. This creates a BOXING problem as when you store a VALUE type like 53 in an Object, it is boxed on the Managed Heap (and unboxed when accessed). I cannot fix that, but I did create an AOP Attribute that will Strongly type the values passed in to a collection. Here is what it looks like:

    [StronglyTypedKeyValue("Add", "System.Decimal", "System.Type")]

    Do a Decimal is the Qualified key and the stored value is a .NET Type. If you pass in anything else you get (with no Exception handling in the code):

    Error in Paramater based on Attribute Restriction. The Type of the Key Passed Into the Method does not Match the Required Key Type. The Type of the value was System.String amd we require System.Decimal

    It stops at the first Exception but I could easily modify it to include both. If I change the first parameter to be a Decimal I get:

    Error in Paramater based on Attribute Restriction. The Type of the Value Passed Into the Method does not Match the Required Value. The Type of the value was System.Int32 amd we required System.Type


    Is all this worth it? Absolutely. I use it all the time when I am too lazy to use CodeSmith to generate a Strongly Typed Collection.

    So my point here is who cares is AOP is revolution, evolutionary or rudimentary. It is offering real value now and we shoul ddiscuss how it has helped (or hurt) us.

    Kind Regards,
    Damon Carr, CTO
    agilefactor
    www.agilefactor.com