Discussions

News: Setting the Story Straight: AOP != Interception

  1. Setting the Story Straight: AOP != Interception (60 messages)

    Ted Neward (on his blog) steps to the plate to dispell the rumour that AOP is basically just the Interception pattern. He claims that to understand AOP as Interception is like thinking OOP is data structs plus a bunch of function pointers.

    He goes on to define AOP compared to Interception, and walks through an example of where an AOP system is capable of capturing elements that a traditional Interception system couldn't.

    Read Ted's thoughts on AOP

    He also makes some Predictions for 2003:

    - .NET will grow in acceptance
    - Java adoption rates will slow down
    - Mobile devices will continue to remain a Holy Grail
    - EJB will be almost a dead horse by years-end
    - Microsoft will get sued again

    Threaded Messages (60)

  2. Ted got some response claiming that he glosses over the underlying reasons and takes for granted that AOP must be implemented as a language extension.

    He responds to this here
  3. I am sorry, but who is Ted Neward?
  4. Ted Neward is...[ Go to top ]

    From one of his home pages:

    "I'm a C++, Java and .NET instructor, architect and mentor, living and working in the Northern California (specifically, Sacramento--Go Kings!) area. My professional interests center around software, specifically enterprise server-side development."
  5. Ted Neward is...[ Go to top ]

    This is crazy. You can easily see where the world is moving on - open source , Linux , java - freedom.
    I look at M$ as something that kills our freedom. Maybe Ted just wants to dream by posting here. Give me a flying break!
  6. Ted Neward is...[ Go to top ]

    Ted is neither associated with "M$" nor Microsoft.
    He is one of those, who still enjoy "freedom": neither Java nor .Net zealot. His blog is a good read every morning.

    Regarding the AOP post: I guess he is blaming the "new" AOP people for the wrong thing. They are well aware, that their interception framework is not a perfect implementation of the AOP theory like AspectJ is. However, the common concensus is "AspectJ is static. Invocation dynamic" (read e.g. href="jutopiahttp://roller.anthonyeden.com/page/tirsen/20021210#runtime_attributes_and_aop_considered">jutopia>). Together with runtime attributes Invocation is the way to go. And why can't we call it AOP as well? Attribute oriented programming?
  7. Static & dynamic aspects[ Go to top ]

    I thought that one of the new features in 1.2 AspectJ was dynamic definition of aspects? At least before it moved to Eclipse - I can't find it anymore..
    Anyway, dynamic stuff is nice and cool, but I would still argue that static compilation has its advantages (performance & compile time checking being the most important IMO).
    Also, for a large class of the functionality, I know at compiletime that I want to do something (persistence, remoting, transactionality).
    Regards,
    Vlad
  8. Static & dynamic aspects[ Go to top ]

    "..persistence, remoting, transactionality..>"

    Exactly the kinds of services application servers offer. JBoss, for instance, is perhaps one of the best examples of this sort of stuff being done in an AOP-style way.

    I think this started out with Rickard Oberg not wanting these kinds of constructs statically woven into the JBoss kernel. Great decision - the current JBoss interceptor stack is an excellent piece of software engineering. Using XML files to configure and maintain the stack worked out well too.

    Sandeep.
  9. Static & dynamic aspects[ Go to top ]

    Yep, but my point is that I know about them at the compile-time.
    I was claiming for more than two years now that the main problem with EJB is that it offers all-or-nothing approach instead of modularized one. (and I was advocating aspects (except I called it subject-programming) for almost five years now :) ). I think that the approach JBoss 4 is taking is what the original EJBs should have been from start
    I dispute the implementation though, as while the dynamic stuff is ok and cool to code, you a price for it. Currently, also, why do I need dynamic declarations, when I can only change what I declare at the deployment time? And even if I could change it at runtime, how often would I really need it?
    Some things I would like to have available at runtime, such as instrumentation, profiling, logging (to help operations), but other (such as the services I mentioned in the previous post) I generally don't want to add during the runtime.
    So, I think that both the dynamic and static addition has it's place, but allow for only one is a mistake.
    Regards,
    Vlad
  10. Ted Neward is...[ Go to top ]

    Hold on a second there, Ted was formerly with DevelopMentor which was Don Box's company (the COM & SOAP guy who is now a .Net architect at MS). I'd say he has a propensity towards MS.
  11. Ted Neward is...[ Go to top ]

    Hold on a second there, Ted was formerly with DevelopMentor which was Don Box's company (the COM & SOAP guy who is now a .Net architect at MS). I'd say he has a propensity towards MS.


    Actually, I'm still with DevelopMentor, which is actively teaching in three different areas: .NET, XML, and Java. For those of you who believe, as many do, that DevelopMentor is just a Microsoft stooge, I'd like to point out that Kevin Jones is a JCP Expert Group member on both the Servlets and JSP committees, I'm on JSRs 111 (services) and 175 (metadata), Simon Horrell is on the StAX JSR, and we all speak regularly at Java conferences--Kevin's given talks at JavaOne, as has Stu Halloway, our CTO, and Brian Maso, Stu and I are all speaking at various NoFluffJustStuff conferences across the country (www.nofluffjuststuff.org). Trust me, DevelopMentor is *not* a Microsoft stooge, despite what you may see or hear. I invite anybody here to come listen to any of us speak and come away still believing that.

    That said, I'll also freely admit that I'm also deeply involved in the .NET space, having co-authored three books for OReilly (C# In A Nutshell, SSCLI Essentials, and VB.NET Core Classes In A Nutshell) and done several .NET conferences, such as DevConnections '02 and .NET One '02. Frankly, both environments are so strikingly similar to one another that I find knowing both to be an advantage in working with either.

    What my pedigree with respect to MS has to do with my assertion that Interception != AOP, however, is entirely a mystery to me. Microsoft uses a simple interception model to provide services in COM+ (and their .NET ContextBound architecture is essentially the same thing, albeit a tad more flexible), which, although an interesting idea in its own right, still isn't AOP any more than EJB's interception-based architecture is. Without a rich join point model *beyond* callee interception, it's just not an AOP system.
  12. Ted Neward is...[ Go to top ]

    I apologize for the misnomer "propensity". I should have used "background" instead. And I see having knowledge of both sides of the battlefield as a very positive thing and am trying to do the same myself.
  13. Ted Neward is...[ Go to top ]

    Hi,

    You realize that even if Ted is being inflammatory, he has some good points.

    It IS true AOP has often been mistaken as being just an additional way of extracting additional value out of the Interceptor pattern.

    That's an understandable misconception: many AOP problems can be solved using interception as the underlying implementation approach. But's that's not equivalency.

    For me, one way of representing AOP-ish approaches to friends is that - its like an interesting way of refactoring code. In that sense, its about taking little pieces of semantically similar thingeys scattered all over your code, and creating some sort of an external construct for it.

    Also, Ted's very likely right about Microsoft getting sued. Yup. Yup. Yup. In fact, I'm betting they'll get sued again and again and again.

    Sandeep.
  14. Ted Neward is...[ Go to top ]

    Thingies? is that you explination? you are kind of an idiot.

    If there is confusion over aop, it is because the concept is ill defined by people like yourself... and this ted guy.

    Interception of method calls and proxing objects is a very valid way if implementing an AOP system.
  15. Ted Neward is...[ Go to top ]

    Hi,

    Its not thingies! Its thingeys! With a 'ey'. Sigh. Misunderstood every time.

    Sandeep.

    Btw, I like your name. Your family is pretty original.
  16. AOP and interceptors[ Go to top ]

    Ah, I was wondering when the first ad hominem comes..
    But anyway..
    <q>Interception of method calls and proxing objects is a very valid way if implementing an AOP system.<q>
    Only if you can intercept any and all calls in your system. Including standard runtime libraries, any third party libraries etc.. Of course, not just intercepting calls insice your own system, but even calls _within_ those libraries (say, I want to log all calls to StringBuffer.append across the application - regardless where it's called from).
    In Java, you could write your own classloader, made it the boot classloader (you need to proxy all classes), and proxied join-point classes.
    But if you would want to do aspects dynamically, you would have to proxy all the classes as they are created, as you could never know which class gets aspects later on, and you can't replace existing instances AFAIK. Adding bytecode would have to modify just the class code itself (in all the classloaders that loaded the class of course). Of course I just glossed over all the problems with synchronizing this etc..
    In other words, yes, you can use proxies & method interceptions to implement full AOP system. I doubt whether it's the most effective way though.
    Regards,
    Vlad
  17. AOP and interceptors[ Go to top ]

    yes, you can use proxies & method interceptions to implement full AOP system



    I am glad you agree vlad.. then one needs to ask why this article was written and what is it's point?

    At no point in time does the auther disclose a feature that an AOP system must have that can not be implemented through interception.

    Ted does bring up how limitation of java prevent such an implementation but we are not taking about java at all.. but about two concepts ,"interception" and "aop". They are different concepts but so are "coffe" and "emacs" the author does not even attempt to discuss what the relationship might be, he just answers this silly question poorly.
  18. AOP and interceptors[ Go to top ]

    I think that his point was most of the people put an equals between AOP and interception - sort of "I have an interception FWK, so it's as if I had AOP, isn't it?", to which the answer is "No, unless your FWK is really your system.".
    It's sort of like a discussion between C and C++ that was happening years ago..
    "I have function pointers, arrays and structs, so it's as if I had objects, isn't it?". Yes, you can implement objects using function pointers, arrays and structs (in fact, that's more or less what a vtable is), but does it mean the two are equal? (and if so, why so few people are using C these days?)
    Regards,
    Vlad
  19. Who is Ted Neward? He only wrote one of the best books around for anyone wanting to really understand the issues involved in writing server side java code. His book is "Server Based Java Programming". And he is correct that AOP != Interception. And for all you that think AOP == AspectJ - you are wrong because the concepts of AOP are not tied to a particular programming language.
  20. Marc Fleury (JBoss founder) says "I love EJB". Ted talks of EJB dying at the end of the year. I will go with Marc's vision. Ted is just another guy who thinks "I will devote 50% of my life to J2EE and another 50% to .net"
  21. Ted is just another guy who thinks "I will devote 50% of my life to J2EE and another 50% to .net"


    So? That just means he's more likely to work in the future no matter what happens. Or, more likely, that he doesn't feel the need to be loyal to companies (MS or Sun) that show no loyalty to him. Programming languages and frameworks are not religions; they don't offer insights into the mysteries of the universe. People need to stop treating them like they are and see that there are many ways to skin a cat, most of which are usually valid in some way and most of which offer something that the others do not.
  22. Just because Marc Fleury says he loves EJBs does not mean EJB use will start to fade at the end of the year. He does not say it will disappear.

    I really don't care or know what will become of EJB by the end of the year (for that matter, no one knows unless you have a time machine). It's just one guy's opinion.

    And for the record, .NET acceptance pretty much has to go up...it has no where else to go from where it is at this point. And Java acceptance is so high at this point, yeah, the acceleration curve is flattening out a little bit. It just means the technology is maturing a bit.

    Mobile devices will continue to be elusive because there is no common standard to build UI for them. Yeah yeah, MIDP 2.0, blah blah...it still doesn't mean there will be any compelling killer app built for them this year.

    I think he's just stating a lot of the obvious from a less religious point of view. Take it for what you will.

    -Mike
  23. I meant to say, "Just because Marc Fleury says he loves EJBs does not mean that EJB use will NOT start to fade at the end of the year."

    My mistake.
  24. * I'm tired *

    May i say ... *bollocks* ..... this guy needs to research more before professing to be *an expert*.

    Why do the TSS even bother, seems all they publish is crap these days.

    Why ?
  25. They publish it because they (secretly:) hate Rickard Oberg and Rickard Oberg (not so secretly) hates them. Since he kind of started the use of interceptions in jBoss (= no money for TSS) and now pushes his new (secret:) AOP-ish interception framework to get rid off EJBs (= big money for TSS), they probably thought Ted would knock him out, as he currently anyway seems to be more quiet than usual. Ah, what a fabulous rant, somebody bring me a straightjacket ...:)
  26. May i say ... *bollocks* ..... this guy needs to

    > research more before professing to be *an expert*.
    > Why do the TSS even bother, seems all they publish is
    > crap these days.

    Floyd

    Can't you moderate posts like these? A good topic like AOP because of posts like this would descend to satisfying Godwin's law quite soon. Do we need that?

    --Dilip
  27. **** you Dilip.

    >A good topic like AOP

    If you get your technical information from tss you need a good layoff to set you straight.

    >Can't you moderate posts like these?

    I hope you rot in hell you censorship hate mongering facist, you are crap.

    As i stated in other threads, AOP is nothing new, in fact this industry has yet to come up with anything that is not at least 2 decades old. If it takes you two decades to catchup then see the **** you quote above. AOP is crap, you are crap.

    If floyd realy gave a shit, rather then spreading the latest hype on Oracle's new shitty j2ee rehash, we would see topics on how xml is a step backwards, n-tier systems are overly complex, declaritive language implementatins, and advances in type theory.
  28. <QUOTE>
    we would see topics on how xml is a step backwards, n-tier systems are overly complex, declaritive language implementatins, and advances in type theory.
    </QUOTE>

    Not to mention that pigeons work much more reliably as an implementation technique for distributed transactions than any DB vendor's XA drivers.
  29. Yes, check out the upcoming project on sourceforge.net, PIGEONXA based on the CPIP protocol:

    http://www.blug.linux.no/rfc1149/
  30. I believe this becomes my alltime favourite thread: RFC 1149 rocks. I bet it was lots of fun to do this:
    <P>
    64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms
    <P>
    Looks like those guys drank some beer and talked about Dos and DDDos attacks, although it surely takes quite some time persuading a pigeon spoofing the location of the home cage.
  31. Pigeons[ Go to top ]

    Damn, shows you should never throw anything away. Back in the 70s on a project at Reuters (whose founder made his fortune from information carried by pigeon) we wrote a paper on pigeons as a transport mechanism. Our problem was that you could never find a parity pigeon when you needed one.
  32. Rickard and Ted discuss...[ Go to top ]

    Rickard and Ted had an interesting discussion in their blogs:

    Read Rickards Responses

    Ted's Response to Rickard
  33. Rickard and Ted discuss...[ Go to top ]

    A few points on this thread:

    1. I think Ted's argument that "interception via dynamic proxies is not AOP" is a quibble. One key difference between what Rickard, Jon Tirsen and a lot of others are doing with dynamic proxies and the traditional interceptor approach is that it's transparent: when methods on interfaces are invoked, "aspect interceptors" get invoked by concealed plumbing. Personally I think there may well be value in moving at least some of the AspectJ functionality into core Java in time, but it isn't going to happen overnight and there's still a way to go to establish which is the most effective way to apply AOP concepts. For example, the use of metadata attributes (which will be standard in Java 1.5) has significant advantages over AspectJ-style pointcuts for addressing some problems. I don't really care whether or not what Rickard, I and others are doing is "true AOP"--I care whether or not it delivers the advantages AOP offers, such as improved separation of concerns, modularization. And I think it will.

    2. Ted has written some excellent books and articles. He has every right to make predictions and argue controversial positions on his personal pages. Those who disagree should try to make a convincing case as to why, not abuse him or question his right to express himself.

    3. Like Rickard, I'm not convinced by Ted's JDBC example. AOP can solve many problems, but it isn't primarily a technique for cleaning up bad code. Use PreparedStatements. If you must use plain Statements, escape the SQL as a matter of course. Furthermore, the database user a web app uses shouldn't have the permission to drop tables, so the last part of the example is artificial.

    Rod Johnson, author of Expert One-on-One J2EE Design and Development.
  34. Rickard and Ted discuss...[ Go to top ]

    I think whether AOP is implemented via a runtime Java interceptor approach (a la Rickard and Jboss), or by language extensions is really an implementation detail.

    Although writing a Java based interceptor approach that doesn't just use a dynamic proxy on interface methods, but can advise on public attribute interception and other more complex pointcuts is REALLY hard.

    (Advising on public attribute interception would require you to advise all methods that get/set the attribute - a very difficult problem to solve using the JBoss/Rickard approach)

    I think this kind of stuff really needs to be done at a JVM level, to remove the complexity.

    Having said that, I don't think AspectJ has it quite right either.

    As Rickard mentions, AspectJ's "regex style" matching of pointcuts sucks, a much better way to to do this is with metadata.

    Considering class metadata is scheduled to be added to Java sometime in the (not too distant) future, this should solve that problem.

    Combine this with JVM level dynamic weaving, and some extra java syntax to describe how this weaving is to occur, and we avoid most of the disadvantages previously mentioned, and don't limit us to the simplest pointcut cases.

    In the absence of Java changing it's syntax in the near future, the simplest route is to limit yourself to simple pointcuts plus sacrifice some performance and take the jboss/rickard route, or to write some fancy classloader hijacking, byte code mangling aspect engine, that did dynamic complex aspects, with added metadata - although that's by no means a trivial task.


    jm2c
  35. Rickard and Ted discuss...[ Go to top ]

    Writing and returning an AOP class loader, while a neat idea, is likely to cause major problems when applications need to run in a J2EE app server, as the app server normally controls class loaders.

    Rod
  36. Rickard and Ted discuss...[ Go to top ]

    Rod-
    a good point.
    as you say, this would only work if it cooperated with the appserver's classloading policies.
    however i think it's the only option if you want to advise on public field interception (and other complex types of pointcuts), and do dynamic aspects transparently (in the absence of java syntax changes).
  37. Rickard and Ted discuss...[ Go to top ]

    Personally I find that interception of interface methods provides most of the functionality I need. After all, coding against interfaces, not classes or instance variables, is good OO practice. I think it's another case of the 80/20 rule: going the extra mile adds more complexity than benefit.
  38. Rickard and Ted discuss...[ Go to top ]

    Rod-
    <quote>
    After all, coding against interfaces, not classes or instance variables, is good OO practice.
    </quote>

    But this isn't OO, it's AO. I agree it's not good OO practice, but I don't agree that it's not good AO practice.

    Your point on just advising on interface methods is fine if you've got a green-field project - but what if you're layering aspects onto a legacy system, and you can't change the code?

    Really though, as you say, you can probably get away with doing most things using interface methods, but my point is if you're happy with that subset of AO, that's fine. But if you want to advise on any/all of the "nodes" of the topology of your program (pointcuts) (i think that made sense ;)), then that's incredible difficult/maybe impossible with the current state of the Java platform, one of the reasons being the classloader problem you yourself mentioned.
  39. Rickard and Ted discuss...[ Go to top ]

    <tim>
    Your point on just advising on interface methods is fine if you've got a green-field project - but what if you're layering aspects onto a legacy system, and you can't change the code?
    </tim>
    Good point. I've used AspectJ in such cases--although I wouldn't try to add aspects into a legacy system lightly. Also, AspectJ can be extremely useful for testing: Nick Lesiecki published an interesting article on this recently (IBM DeveloperWorks). I was talking about how I would apply AOP in a new project.

    <tim>
    I agree it's not good OO practice, but I don't agree that it's not good AO practice.
    </tim>
    I guess I haven't yet reached true AOP master status, but I tend to view AOP as a layer on top of sound OO design. I see it as complementing OO in areas where OO is weak.

    Rod
  40. Rickard and Ted discuss...[ Go to top ]

    <rod>
    I guess I haven't yet reached true AOP master status,
    </rod>
    apologies for preaching :)

    <rod>
    but I tend to view AOP as a layer on top of sound OO design. I see it as complementing OO in areas where OO is weak.
    </rod>

    I guess it can certainly be thought of in that way, but you may have a perfectly sound OO design, but still want to advise on object creation(), public field interception etc. Writing such an aspect does not in any way make your OO design any "worse" - in fact in doesn't change it in any way.
    IMO the concepts of an "aspect" and an "object" will merge at some point - whether we then label it an "aspect", an "object" or something else is anybody's guess.
  41. Rickard and Ted discuss...[ Go to top ]

    Tim, I think you may well be right. I guess my position is that the consequences of OO are well understood (although plenty of people still apply them badly :-). Hence I feel very comfortable applying AOP to complement OO. I think we have a lot to learn about AOP antipatterns--remember how people used C++ and other OO languages in the early days?

    I agree that in the end we may well take AOP much more to heart. But I see a lot of benefits in the interface/method interception approach in the mean time without going to the bleeding edge.

    Rod
  42. Rickard and Ted discuss...[ Go to top ]

    I guess my position is that the consequences of OO are well understood


    It's a very bold statement. There wasn't mass OO craze even 4 years ago. I believe that in few years we'll be able to examine where OO led us to. I'm afraid some consequences won't look that attractive as they seem now.

    As to meaningfull discussion on AOP/Interceptors/OO/whatever, if even "gurus" can't agree what is what, then the others won't care, then the difference is irrelevant.

    As Bill Gates shown as million times, it's TOOLS that make technologies matter. Happily, the everyday reality of our work isolates us from "important" theoretical subjects. At the work place I've Oracle 9 iAS, and I've to deal with it somehow. Huh.... what a speech!
  43. Rickard and Ted discuss...[ Go to top ]

    <argyn>
    There wasn't mass OO craze even 4 years ago
    </argyn>
    4 years ago? Yes. C++ and even Java were very widely used even then, and people had mostly gotten past writing C with // comments. 7 or 8 years ago, maybe not. But I do take your point that OO hasn't always delivered what might have been hoped...

    <argyn>
    As to meaningfull discussion on AOP/Interceptors/OO/whatever, if even "gurus" can't agree what is what, then the others won't care, then the difference is irrelevant.
    </argyn>
    My point was that the debate about "what is true AOP" is irrelevant. I care about what benefits AOP can bring, and I agree with both Ted and Rickard & co on that.

    Rod
  44. Rickard and Ted discuss...[ Go to top ]

    My point was that the debate about "what is true AOP" is irrelevant. I care about what benefits AOP can bring


    Totally agree with this.
  45. AspectWerkz[ Go to top ]

    I've just started looking at AspectWerkz, but it appears they have implemented your class mangling custom classloader idea. So maybe it's doable after all... ;)

    http://aspectwerkz.sourceforge.net/
  46. Rickard and Ted discuss...[ Go to top ]

    It doesn't appear to me that Ted has examined Rickard's AOP approach in depth. His comments seem to be general and high-level, while Rickard's weblog on AOP during the past months have been quite in-depth and practical - making one realize how AOP can help in one's day-to-day job.

    Regarding the recent discussion "AOP != Interception". In the past, Rickard had summarized his AOP approach (dynamic proxy based) with the following
    1. Extending behavior at method level - this is interception
    2. Extending interface at object level - this is composition

    So it's clear to me that Rickard (and consequently Tisen, JBoss, etc.) certainly don't view AOP == interception. The question is whether the "composition" side of their approach is understood.

    I'm kida surprise that Rickard didn't bring this up in his reply and reply2.

    --Hao
  47. I came across a lot of these ideas a few years ago, before AOP really hit the scene, in the context of reflective systems. Reflection is the ability to reason about the structure of your applications and the reflection APIs currently in Java only cover one aspect of reflective systems (the ability to explore an objects interface). Interestingly, another aspect of reflection, the ability to reason about the object graph of an application, although not baked into Java, can be done with JMX aware applications. The guys behind reflection are also the people behind AOP.

    My understanding is that most of these ideas come from the Lisp community. The idea of interceptors (or before and after methods) is built into Lisp. The heritage is a long one.

    A paper explaining how some of these ideas relate to middleware can be found here:

    http://citeseer.nj.nec.com/blair98architecture.html

    One final point, just because these ideas are old doesn't detract from the achievement of the JBoss team in getting these ideas into mainstream middleware. When I first came across them middleware researchers were talking purely in terms of CORBA and the vendors didn't seem that interested. With JBoss these ideas have become mainstream and that can only be a good thing.

    Ian.
  48. TED NEWARD IS AN IMBECILE[ Go to top ]

    Ted Neward Predicts:
    1).NET will grow in acceptance
    4)EJB will be almost a dead horse by years-end
    (http://www.neward.net/ted/weblog/comment.jsp?entryID=1041405373924)

    But according to the Seattle Times/Bloomberg:
    .Net software name shelved!!
    see the bottom of http://seattletimes.nwsource.com/html/businesstechnology/134613370_antitrust11.html

    Ted Neward wants to replace all(Entity,Stateful/less Session, Message-Driven) Beans:
    (http://www.neward.net/ted/weblog/index.jsp?date=20030101)
    Ted Neward writes:
    "writing a JMS program from the ground up is about two steps simpler than writing an EJB MDB"

    I do not think Ted Neward is an imbecile(marc fleurys words)

    http://www.jboss.org/modules.php?op=modload&name=Journal&file=display&jid=10

    He is either an idiot or a trolling pimp.
  49. TED NEWARD IS AN IMBECILE[ Go to top ]

    This is really sad. David, there's no content in your post. You really think a link to a rant from Marc Fleury is the last word on the pros and cons of EJB? I don't agree with everything Ted says, but at least he presents some arguments. How about a detailed rebuttal without the abuse?

    I respect Marc for what he's done for the J2EE community with JBoss, but he should have known better than to write this under the JBoss banner. IMHO, it has the potential to scare off the kind of enterprises JBoss should be attracting. Typical quote:
    <marc>
    The he worship Wes Isberg from the AspectJ team. AFAICT this guy is an impostor with lofty blabla but really very littly solid pieces in his flow.
    </marc>

    Why get so defensive when someone criticizes EJB? Debate the points. EJB is not the answer to everything. Ted may be going a bit far, but it's healthy to question assumptions.

    P.S. The Oxford dictionary defines both "idiot" and "imbecile" to mean "a stupid person". So your distinction between the two is meaningless.

    Rod
  50. I keep reading about AOP and all the interesting and enthusiastic comments I read about it. Yet, if I look at what it actually *does* I am alomst always set back.

    From my point of view an aspect is either declared or automatic.

    If it is automatic, it boil down to the interceptor pattern - never mind how you declare them or whether it happens at compile time or execution time. That is you end up with a framework that does something before or after your function call. Gee, I AM IMPRESSED!

    If they are declared, this boils down to knowing what to declare. So I end up with something that is semantically absolutely equal to calling a static method on some helper class. Again, I AM IMPRESSED.

    No really, it seems that the AOP discussion, while it might provide a couple of nice tools, does nothing new nor something that is particularly hard. Instead it introduces a new layer of complexity and potentially a new "language". To me that does nothing to

    - Speed up development
    - Reduce errors
    - Reduce training

    I can see that it can speed execution time in certain areas, like the dreaded logging example, but that is it.
  51. i think the important thing here (as someone pointed out earlier in this thread) is that especially rickard öberg is doing enterprise systems in java using this AOP framework, as opposed to using EJB, and finding it simpler and faster (and this from someone who undoubtedly knows about enterprise EJB systems).
    Whether or not the idea are old or new, and whether or not his framework is or is not an AOP framework by some arbitrary standard is to me irrelevant.
    if this can point to a way to simplify the EJB model then im all for it.

    from my own small experiments, plus from reading rickards blog, it seems to me he has indeed speeded up the development time, increased the reuse of objects and have created a slimmer framework than ejb is. this must certainly be a good thing.

    sincerely
    morten wilken
  52. Jeez, Deja vue all over again...

    AOP addresses each of these concerns, one by one:

    Speed up development:

    Infrastructure can be written once, and coupled transparently. This means that your business code developers don't need to understand the workings of the infrastructure they are using. This creates a Design Firewall and hides implementation details, a good thing.

    AOP allows for the consistent coherent application of policy, once the policy is embodied in an aspect, the aspect can be reused to apply it.

    Does inheritance speed up development? Think of AOP as a new form of inheritance, whereas inheritance is vertical, top down, Aspects offer horizontal form of weaving.

    How many times have you had to write the code that applies the policy defined for various exceptions in multiple locations, across multiple developers? Aspects eliminate that need - you set the policy and use it.


    Reduce Errors:

    Seen Bertrand Meyer do his Ariane speel? Contracts which are supported by most forms of AOP allow for contract application at the interface level - making pre-conditions, and post-conditions easy to implement and apply. This reduces common interface level errors ( think of the benefits of typing in reducing errors... )

    Reducing the senseless rewriting of infrastructure has always been at the core of reuse, Aspects are a form of reuse. Less code, less errors.


    Reduce Training:

    By having aspect weaving, the developers who understand business don't need to also know the logging, exception handling, or other policy API issues. They can mostly center on the problem domain, not the problems of the solution domain. Additionally, the converse is true, infrastructure developers don't need to understand the issues of the business problems to the depth they often do now.

    Written or integrated a cacheing subsystem? Haven't you needed to understand the business requirements? Aspects can be used to hide all of those issues.


    I am not in love with static AOP systems like AspectJ, and my personal preference is towards dynamic aspect systems like Prose from ETH in Zurich (http://prose.ethz.ch/). But anything that offers, or increases the offering of:

    -Consistent Application of design and implementation policy
    -Infrastructure reuse
    -Interface contract application and definition
    -Reduction of explicit or tight coupling
    -Further hiding of implementation details, a design firewall
    -The ability to focus on the problem domain

    Are all very good things, reducing errors, reducing development issues, and offering more engineering options.


    Why do you think so many people are excited by AOP? Because they don't get it? Because they are just trying to be hip?


    Cheers,
    Greg Noel
    www.navit.ch
  53. dynamic aspect systems like Prose from

    > ETH in Zurich (http://prose.ethz.ch/)

    Nice. However, it requires a JVM extension and works only on Linux/Solaris and only with Sun JVMs. Thus, currently it seems to be for academical usage only.

    -- Andreas
  54. Ya, somewhat limited, they are making the valiant effort tho. I think that the non-neolanguage approach is better. In discussions with them, they are trying to show how small modifications to the JVM can be harvested to great benefit.

    I admire them, and hope that the needed facilities spread to other JVM/Platforms.

    I think a declarative approach, defining point/cross cuts and contracts in a switch box ( ans.1/xml ) which is used for dynamic dispatching within Java is a good interim solution ( www.aspectejb.com ) until a language is created that addresses all of the various requirements ( AspectJ is still in the cfront like stage ).

    Given Bertrand Meyer's rant against the pitfalls of dynamic invokations, how do most people feel about static vs. dynamic aspect systems?

    Greg Noel
    www.navit.ch
  55. Jeez, Deja vue all over again...


    Absolutely, but unfortunately the Deja Vue is on my side not on yours! There is no need to discuss that infrastructure re-use is a good thing. We all know, there a multiple ways of having infrastructure re-use. I just cannot see that aspects add anything on top of other infrastructure re-use techniques nor that they a concept in their own right. If they are just compiler directives or just the interception pattern, this is not very impressive (though I don't say it might not be useful).
    >
    > Pre-and Postconditions
    >
    I am in love with pre- and postconditions. But these are just function call interceptions. Again, to consider it a concept in its own right that would justify to switch say to another runtime environment seems way off to me. Besides pre-and postconditions as originally thought of, i.e. turn them off in the working system, has proved fatal in distributed environments where no stable assumptions can be made on the actual caller.
    >
    > Reduce training
    >
    I daresay your arguments are plain wrong. Precisely the opposite is true. By introducing another language - the aspects - developers need not only more training but also in different domains. For example logging, error handling etc. will predominantly be a business not an infrastructure task, because the reaction to an error is dependant on the business context.
    >
    > Why do you think so many people are excited by AOP?
    > Because they don't get it? Because they are just trying
    > to be hip?
    >
    A very valid question in our industry. Given that people were excited by a lot of technologies that turned out to provide nothing fundamentally new (like Java, EJB, .NET, SOAP you name it) any of your suggestions might be very valid indeed.
    Maybe, because it is a theoretically interesting problem with little *additional* value over current techniques handled properly. Maybe because they have never seen a C/C++ program, where you need to read Macros, Directives, Makefiles and C/C++ code all at the same time to get an idea of how everything works together. Or maybe because they love just that. There are literally zillions of reasons, but the main point is probably: Because it is (seems to be) new and interesting and it stimulated thought.
  56. Man, guess I'm convinced, there are no better way to engineer software than those that are currently the norm. Innovation might as well stop now, we've achieved the pinnacle.

    Though, naggingly, I am still considering the problem of consistent application of policy in a large projects. Exception handling is a good example, how do I get the eight folks working on my large project all to handle the same infrastructure exceptions in a consistent fashion without tightly coupling to that infrastructure? Without exposing implementation details?

    And boy, and it sure would be great to have contracts handled at the semantic level, where I could easily maintain them - handled where the interface is defined. And, ya got to wonder, why is it that Gosling wanted contracts for Java? Why does he feel it was a mistake not to include them?

    Yes, interceptors can be used to implement interface contracts, albeit in a labor intensive, error prone fashion. Just curious, how many people here are actually using interceptors for contract enforcement? How about hand coding the byte code? Certainly that is a set complete approach, the lost concept of appropriate abstraction is not needed right?

    There are several AOP mechanism out there which do not require everyone learning a new language, JAC, Prose, and the fatally out of date Hyper/J all come to mind. I personally think a declarative approach ( an XML/ASN.1 switchbox applied dynamically for example ) is a better for now.

    The Deja Vue I spoke of relates to complaints dating back to cfront, and the adoption of Java ( Brad Cox & NeXT also comes to mind, but they lost... ). Doomed to repeat I guess.

    And now back to your regularly scheduled grind, like the discussion of the best JSP based framework for handling MVC, thinking in new ways makes the brain hurt.


    Greg Noel
    www.navit.ch
  57. And now back to your regularly scheduled grind, like the > discussion of the best JSP based framework for handling > MVC, thinking in new ways makes the brain hurt.

    >

    I would all but agree with your argument, if it *was* thinking in new ways. Yet, I have a strong feeling is is not. When you say, interception are not the best way to enforce contract - hey your right - unfortunately they are semantically identical to most other ways proposed. Again, I absolutely agree that enforcing policy in large projects *is* a problem. But then again, I am more likely to take a step back and look at what has been tried before and to what effect. The most successful tactiques I have seen used to that end are

    - Standardized APIs
    - Code Generation
    - Interception

    Call the last two AOP if you will, but they have been around for ages anyway. So I do think people find it hip
    :-).
    My experience shows that the worst thing you can do to any project is to have people use (and in the worst case learn) three to four languages at once and expect excellency in each of those - at least not from a each and every member of a large team. It just did never work.

    As I side note, I also would like contracts to be part of any language. Yet in a distributed environment, contracts need to be always enforced anyway. They naturally become part of the application rather than the development domain.

    As for the JSP frameworks you mention: The best JSP framework will no doubt
    - Make development faster
    - Include aspects in the JSP to enforce a contract (As you might know, this is called "including" and "filtering")
    - Enforce application policies
    - Do people make a fuss about calling it AOP - not to my knowledge!
  58. You convinced me, you don't get it.

    I can used assembly language to achieve:

    Policies
    Contracts
    Interceptors
    Aspects
    Objects

    That doesn't mean that assembly language supports any of those things.

    Did you read any of the other thoughtful posts in the thread? The C language can be use to code in an object oriented fashion - that doesn't mean it supports objects. Just because I can use interceptors to to code in an aspect oriented fashion, doesn't mean interceptors make Java have aspects.

    Go read some of the seminal papers on the subject, I personally endorse the Hyperj MDSC papers from IBM. Multi-dimensional separation of concerns is thinking in a new way - a new way of composing software, and many feel a better way.

    Back to your bone knives and bear skins.....
  59. Basically that is crap. I never did claim that Java supports aspects, what I claimed is that aspects in itself tend to introduce a new programming language or provide little value at all. You might be surprised, I read a lot of these papers, played around with the software and came to the conclusion that it does not add much value.

    > Multi-dimensional separation of concerns is thinking in > a new way - a new way of composing software, and many
    > feel a better way.

    It is not a new way. It is a very old way of doing things. The concept is not fundamentally new and it is not even in the slightest way comparable to the introduction of objects in its impact or its intellectual weight. I think that has been claimed by some of the more thoughtful postings.

    >
    > Back to your bone knives and bear skins.....
    >

    Precisely, what you do: Use another bone knife and wear another bear skin. I'd be more impressed if you moved from bone knives to something else, like say bronze.
  60. Ahm, more of the ad hominem we all know and love (and not just on TSS).
    <q>...that is semantically absolutely equal to ...<q>
    Hmmm, so I assume you code using Turing's notation only? After all, all anyone has ever done so far can be expressed by a Turing's machine using his original notation and as such we have a great semantical equivalence..
    So, either we declare everything over and above TM syntactic sugar (because semantically it's really just the same thing), or a accept that there are constructs that are semantically equivalent, but still heplful.
    V.
  61. Absolutely. They are (or can be) helpful constructs. What I challenge is the idea that multidimensional separation of concerns is a new (or even a very challenging) concept. What I do not challenge is that its implementation is of course very challenging, especially since as far as I can see there is no clear way of where and how this should be done, judging from how the available products work on different levels in the development or runtime domain.