AOSD 2004: Looking at the future of AOP

Discussions

News: AOSD 2004: Looking at the future of AOP

  1. AOSD 2004: Looking at the future of AOP (27 messages)

    Marc Fleury has a piece on the upcoming AOSD in March 22-26. This is an interesting year for the conference, as it morphs from a largely academic enterprise, into a conference which aims to mix the world of academia with the private sector. Marc discusses the JBoss perspective.

    Excerpt

    "Why am I so excited about system aspects? Well, it is rather clear that middleware is really a collection of system aspects--JBoss is already implemented that way. Therefore, these system aspects are candidates for JBoss'ification, thereby enhancing the semantics of the EJB container or the JBossAOP container in general. In fact, most the papers in that category were talking about CORBA proof of concepts and J2EE/JBoss proof of concepts. That is very exciting to me, since it means low hanging fruit, where most of the hard work has been done and we just "package" these innovative aspects for the larger industrial consumption."

    Read Marc Fleury on AOSD 2004: Looking at the future of AOP

    AOSD 2004

    The conference is taking place in Lancaster, UK (not London) from March 22-24. The early registration is open until Feb 13th.

    "The AOSD conference is the premier event devoted entirely to aspect-oriented technologies and practices. The conference brings leading researchers and practitioners together to discuss the latest developments in the field.

    The program includes:

    - technical papers presenting new research results
    - reports describing practical experience with the technologies
    - tutorials (from beginner to advanced)
    - workshops for in-depth discussion of advanced topics
    - a panel on AOSD and enterprise development
    - demonstrations of leading edge technologies"


    View the AOSD 2004 Conference web site

    Threaded Messages (27)

  2. Ahh. Now I understand...[ Go to top ]

    ... why Rickard wasn't supposed to be there.

    "This year, as a member of the selection committee for the AOSD 2004 (Aspect Oriented Software Development) conference to be held in Lancaster, UK this March, ..."

    Nice move, Marc.
  3. Ahh. Now I understand...[ Go to top ]

    The AOSD conference is allowing JBoss AOP to participate but turned down Rickard's paper? How ironic. Unfortunately the community and the future of AOP will pay the price.
  4. Ahh. Now I understand...[ Go to top ]

    The AOSD conference is allowing JBoss AOP to participate but turned down Rickard's paper? How ironic. Unfortunately the community and the future of AOP will pay the price.


    FYI, the selection committee wasn't just Marc. It was at least 20 other people from different universities around the world including Gregor Kiczales. I got to sit in part of the selection committee as an observer (it was in Boston) and the competition between technical papers was fierce. I think tutorials were a bit more lenient as there were much fewer submissions. AspectWerkz got in so there is no reason we should not have either. My understanding was that Rickard's paper was left out as there were just better papers than his, plain and simple.

    Bill
  5. Ahh. Now I understand...[ Go to top ]

    FYI, the selection committee wasn't just Marc. It was at least 20 other people from different universities around the world including Gregor Kiczales. I got to sit in part of the selection committee as an observer (it was in Boston) and the competition between technical papers was fierce. I think tutorials were a bit more lenient as there were much fewer submissions. AspectWerkz got in so there is no reason we should not have either. My understanding was that Rickard's paper was left out as there were just better papers than his, plain and simple.

    >
    > Bill

    I just said it was ironic. ;)
  6. Not quite[ Go to top ]

    Marc:
    In fact, most the papers in that category were talking about CORBA proof of concepts and J2EE/JBoss proof of concepts.


    Rrrright... There is only one session about JBoss, and it's presented by Bill and Marc, of course.

    I am not seeing anything about J2EE either, unfortunately... (nor CORBA for that matter)

    At least, when Steve Jobs makes up facts, he makes sure they can't be verified :-)

    --
    Cedric
    (the program is at http://www.aosd.net/2004/overview.php )
  7. Regarding J2EE content in the program[ Go to top ]

    I am not seeing anything about J2EE either, unfortunately...

    > (nor CORBA for that matter)

    You should find Adrian Colyer and Andy Clement's paper on "Large-scale AOSD for Middleware" interesting. It discusses how AspectJ was applied to a real enterprise system. I think that CORBA is discussed in the "Building Adaptive Distributed Applications with Middleware and Aspects" paper. J2EE support is also bound to come up in the industry panel on "AOP for the Enterprise". Ron Bodkin will also be talking about it in his tutorial on "Enterprise Aspect-Oriented Programming with AspectJ".
  8. Regarding J2EE content in the program[ Go to top ]

    From the overview, see the following for J2EE pieces:

    Industry Panel, AOP For the Enterprise:
        http://www.aosd.net/2004/technical.php#panel

    Enterprise Aspect-Oriented Programming with AspectJ:
        http://www.aosd.net/2004/tutorials/entaop.php

    aTrack: an enterprise bug tracking system using AOP
        http://www.aosd.net/2004/demos/d7.php

    I couldn't find any CORBA stuff.

         -Mike
  9. Ah, now it makes sense[ Go to top ]

    OK, _now_ I understand why AOP was laying fallow in the CVS tree for five months and suddenly started seeing frantic activity 2 weeks ago....

    And I love the extensive use of present tense in the abstract (http://www.aosd.net/2004/tutorials/jboss.php).

    Such as "The tutorial will describe in detail the set of aspects that come with JBoss: aspects for remoteness, acidity, transactions, security, asynchronous invocations, and replicated/transactional caching".

    Shouldn't it say "The tutorial will describe in detail the set of aspects that we wrote on the plane this morning as a re-write to experimental stuff we were playing with last year"? :-)

    It's also fun to read the advertsing spiel in the JBoss abstract vs. almost pure technical descriptions in all of the others. I mean come on guys:

    "JBoss is one of the most popular Java application servers in the industry. Developed as open source software, and with over four million downloads since inception, JBoss is arguably the de facto Java application server development standard".

       -Mike
  10. Ah, now it makes sense[ Go to top ]

    OK, _now_ I understand why AOP was laying fallow in

    > the CVS tree for five months and suddenly started seeing
    > frantic activity 2 weeks ago....

    Right.

    However its sounds like "business as usual" to me. Someone needs to show something which isn't there yet, but already announced to the public. The only difference here is that you can measure their previous statements through CVS and CVS activity. Which you can't usally.
  11. Ah, now it makes sense[ Go to top ]

    "OK, _now_ I understand why AOP was laying fallow in the CVS tree for five months and suddenly started seeing frantic activity 2 weeks ago...."

    It's great to have a bulldog when it comes to marketing fluff, but seriously man, are you checking JBoss's CVS log every night? Maybe you should ask Cedric to get you a job at BEA, if you're that interested in container development or marketing.
  12. <fleury>
    "Why am I so excited about system aspects? Well, it is rather clear that middleware is really a collection of system aspects--JBoss is already implemented that way. Therefore, these system aspects are candidates for JBoss'ification, thereby enhancing the semantics of the EJB container or the JBossAOP container in general. In fact, most the papers in that category were talking about CORBA proof of concepts and J2EE/JBoss proof of concepts. That is very exciting to me, since it means low hanging fruit, where most of the hard work has been done and we just "package" these innovative aspects for the larger industrial consumption."
    </fleury>

    I think this thought process is rather naïve. Despite perceived sophistication of "AOP is generalization for J2EE" thought it is oversimplification, from my point of view. Sure, every specialized conference would have plenty of people saying "we have done this and that and we are happy to report"... But by in large it does not prove anything beyond a specific project. Look, there are still people who develop complex CRM/CMS applications using Perl...

    This overexciting knee-jerk reaction to AOP reminds me the old logging use-case for AOP that was so popular couple of years ago. Well, it turned out that you cannot practically use AOP for logging – you can use it only for tracing, which value is somewhat dubious in our days. There are many other examples (including our own experience with early version of our product where we used AOP/AspectJ and ended up dropping it for good) such as transaction management, etc.

    I think we are going to see gradual cooling down from AOP-ism and start finding some new (rather rare) niches when AOP as a technique makes sense.

    Regards,
    Nikita.
    xTier - Service Oriented Middleware
  13. I think we are going to see gradual cooling down from AOP-ism and start finding some new (rather rare) niches when AOP as a technique makes sense.

    I notice that aspects are praised mostly by container architects. I infer that aspects should be hidden under tooling and not shown to application developers. That would limit excitement about aspects.
  14. Brian:
    I notice that aspects are praised mostly by container architects.

    Not all of them :-)

    I disagree completely with the idea that AOP belongs in middleware before everything else. If you have a middleware that works fine with current OOP practices, there is no point in ripping it apart just because it's cool and it allow you to sell more training.

    However, I do believe that there is tremendous potential for users (of containers). It's a great way to give them access to the innards of the container in a controlled and formal way.

    Hence the WebLogic Aspect Framework, which allows you to leverage the most achieved AOP implementation to date (AspectJ) and use it on all versions of WLS (back to 6.1) while allowing you to specify pointcuts in a very simplified way ("all finders on this EJB").

    http://www.yahoogroups.com/group/weblogic-aspects

    --
    Cedric
  15. and a whopping 116 subscribers agree ;)
  16. AOSD 2004: Looking at the future of AOP[ Go to top ]

    Brian:

    > I notice that aspects are praised mostly by container architects.
    >

    > Not all of them :-)
    >
    > I disagree completely with the idea that AOP belongs in middleware before everything else. If you have a middleware that works fine with current OOP practices, there is no point in ripping it apart just because it's cool and it allow you to sell more training.
    >

    If you look at the current trend, many popular projects are focusing heavily on POJO-based frameworks. AOP can be a critical glue to applying cross-cutting concerns to POJOs and many of these projects use Aspect-Oriented techniques to provide their functionality. The end goal in JBoss land is to let application developers write POJOs and "snap-on" what middleware functionality they need.

    > However, I do believe that there is tremendous potential for users (of containers). It's a great way to give them access to the innards of the container in a controlled and formal way.
    >

    I think this is a tremedously great point. I see vendors (container, library, framework) providing not only a set of annotations and pre-packaged aspects, but also pre-defined set of pointcuts that developers can use reliably. It is great to see that BEA has finally published some public pointcuts. I know our users have found our exposed EJB and MBean invocation stack quite useful over the years.

    AOP will be a great transparent way for programmers to integrate with these types of products and avoid a lot of the bloating glue code that traditional OOP programs/libraries provide (or more importantly sometimes not provide!).

    Bill
  17. AOSD 2004: Looking at the future of AOP[ Go to top ]

    If you look at the current trend, many popular projects are focusing heavily on POJO-based frameworks.

    Yes, the infamous J3EE.

    The end goal in JBoss land is to let application developers write POJOs and "snap-on" what middleware functionality they need.

    I still don't understand how a user can embrace this and not lose vendor neutrality? And I'm unaware of any vendor community initiative to remedy this?

    I see vendors (container, library, framework) providing not only a set of annotations and pre-packaged aspects, but also pre-defined set of pointcuts that developers can use reliably.

    Portably?

    AOP will be a great transparent way for programmers to integrate with these types of products and avoid a lot of the bloating glue code that traditional OOP programs/libraries provide (or more importantly sometimes not provide!).

    Again, portably?
  18. AOSD 2004: Looking at the future of AOP[ Go to top ]

    If you look at the current trend, many popular projects are focusing heavily on POJO-based frameworks.

    >
    > Yes, the infamous J3EE.
    >
    > The end goal in JBoss land is to let application developers write POJOs and "snap-on" what middleware functionality they need.
    >
    > I still don't understand how a user can embrace this and not lose vendor neutrality? And I'm unaware of any vendor community initiative to remedy this?
    >

    The thing is that, hopefully, you won't care about vendor neutrality as you will be writing POJOs not to an API like EJB. This is another one of the end goals. Allow the vendors flexibility to provide the best software and yet not pollute application code with proprietary APIs. AOP has the potential to fill this.

    > I see vendors (container, library, framework) providing not only a set of annotations and pre-packaged aspects, but also pre-defined set of pointcuts that developers can use reliably.
    >
    > Portably?
    >

    Portability is a myth in J2EE land. For instance, the CMP spec is so generalized that a common requirement such as a Object/Relational mapping is left out of the spec. EJBQL is so hobbled that vendors are forced to provide their own proprietary extensions. Caching is not defined at all, and again, each vendor implements their own strategies. Clustering is not addressed and each vendor has different functionality and behavior when running in a cluster. If you don't believe me ask the ISVs that have to support multiple application server vendors.

    Bill
  19. Portability is a myth in J2EE land.


    J2EE != EJB -> Portability of J2EE is not a myth. Portability of EJB may be a myth though.
  20. Portability is a myth in J2EE land.

    >
    > J2EE != EJB -> Portability of J2EE is not a myth. Portability of EJB may be a myth though.

    J2EE is EJB as EJB is a subset of J2EE. I will go further then. Up until J2EE 1.4, plugging in security propagation in the client side was left open to the vendors. JBoss chose JAAS, other vendors went other routes. Also defining security repositories for authentication and authorization (ldap, etc...) was also left for the vendors to decide. Let me go further even more. Single Sign On is also vendor specific and not even addressed by the spec(AFAIK). The behavior of HTTP Session replication in a cluster is not defined. I could go on and on and on....
  21. AOSD 2004: Looking at the future of AOP[ Go to top ]

    Portability is a myth in J2EE land.

    > >
    > > J2EE != EJB -> Portability of J2EE is not a myth. Portability of EJB may be a myth though.
    >
    > J2EE is EJB as EJB is a subset of J2EE. I will go further then. Up until J2EE 1.4, plugging in security propagation in the client side was left open to the vendors. JBoss chose JAAS, other vendors went other routes. Also defining security repositories for authentication and authorization (ldap, etc...) was also left for the vendors to decide. Let me go further even more. Single Sign On is also vendor specific and not even addressed by the spec(AFAIK). The behavior of HTTP Session replication in a cluster is not defined. I could go on and on and on....

    Wanted to add that the only really portable thing is JTA and the spec doesn't even standardize on how to lookup the TransactionManager within a J2EE application. Some vendors don't even allow you to get a reference to the TM. Instead you have to rely on the bloatness of JCA just to interact with it.

    This isn't to say that the standardization process is useless. What the specification process does is make it easier to port, but portability itself is a myth.

    Bill
  22. Portability is a myth in J2EE land.

    > >
    > > J2EE != EJB -> Portability of J2EE is not a myth. Portability of EJB may be a myth though.
    >
    > J2EE is EJB as EJB is a subset of J2EE.

    Our solar system is Earth as Earth is a subset of our solar system. Right?
  23. AOSD 2004: Looking at the future of AOP[ Go to top ]

    I think we are going to see gradual cooling down from AOP-ism and start finding some new (rather rare) niches when AOP as a technique makes sense.

    >
    > I notice that aspects are praised mostly by container architects. I infer that aspects should be hidden under tooling and not shown to application developers. That would limit excitement about aspects.

    Cedric already talked a bit about this in a previous thread, but one of the current problems with a lot of complex software is that the designers are never able to identify all the integration points that their user base need. AOP has the potential to fill this void by allowing vendors to specify new integration points through AOP pointcuts and do this via a support email, wiki, or documentation rather than changing existing code and putting out a new release. Huge potential here.

    Bill
  24. <burke>
    a lot of complex software is that the designers are never able to identify all the integration points that their user base need. AOP has the potential to fill this void by allowing vendors to specify new integration points through AOP pointcuts and do this via a support email, wiki, or documentation rather than changing existing code and putting out a new release. Huge potential here.
    </burke>

    Well, taking this statement on the face value of today’s AOP state of the art Bill Burke suggests us that, in a nutshell, emailing or wiki-posting method signature for a pointcut (or a metadata tag that was coded but not exposed before) is the right way to do EIS integration…

    I happen to think that disillusions like that to this day clobber the AOP development. It is, by the way, an interesting observation to me that often AOP future-statements resemble mainstream "understanding" of grid computing when people start to describe it in terms of biology, physics or sometimes human reproductive functions. I think it was Edgar Dijkstra who once said that such comparisons are the clear sign of a blunt confusion about the problem in hand.

    Regards,
    Nikita Ivanov.
    xTier - Service Oriented Middleware
  25. <burke>

    > a lot of complex software is that the designers are never able to identify all the integration points that their user base need. AOP has the potential to fill this void by allowing vendors to specify new integration points through AOP pointcuts and do this via a support email, wiki, or documentation rather than changing existing code and putting out a new release. Huge potential here.
    > </burke>
    >
    > Well, taking this statement on the face value of today’s AOP state of the art Bill Burke suggests us that, in a nutshell, emailing or wiki-posting method signature for a pointcut (or a metadata tag that was coded but not exposed before) is the right way to do EIS integration…
    >
    > I happen to think that disillusions like that to this day clobber the AOP development. It is, by the way, an interesting observation to me that often AOP future-statements resemble mainstream "understanding" of grid computing when people start to describe it in terms of biology, physics or sometimes human reproductive functions. I think it was Edgar Dijkstra who once said that such comparisons are the clear sign of a blunt confusion about the problem in hand.
    >
    > Regards,
    > Nikita Ivanov.
    > xTier - Service Oriented Middleware

    Rather than posting a rather long response, I have addressed some of your points on our blog:

    http://jboss.org/jbossBlog/blog/bburke/?permalink=AOP%2C+Interception%2C+Integration.html


    Bill
  26. <burke>
    http://jboss.org/jbossBlog/blog/bburke/?permalink=AOP%2C+Interception%2C+Integration.html
    </burke>

    Well, at least it doesn’t mention the emailing and wiki part. In a nutshell though, I still think that such practice is rather afterthought fix for a flawed design. It is quite clear to me that it is lot better to provide a stronger-then-AOP contract for extension points via normal OOP means rather then allowing unnecessary "freedom" to the end user. But I concede, it is a hard to argue question.

    Regards,
    Nikita.
    xTier - Service Oriented Middleware
  27. <burke>

    > http://jboss.org/jbossBlog/blog/bburke/?permalink=AOP%2C+Interception%2C+Integration.html
    > </burke>
    >
    > Well, at least it doesn’t mention the emailing and wiki part. In a nutshell though, I still think that such practice is rather afterthought fix for a flawed design.

    All designs are flawed and never meet the requirements of every specific user.

    >It is quite clear to me that it is lot better to provide a stronger-then-AOP contract for extension points via normal OOP means rather then allowing unnecessary "freedom" to the end user. But I concede, it is a hard to argue question.
    >

    I don't think it is better, but really both approaches can be used to create a flexible design that can better meet user requirements.

    bill
  28. Oh Aspects[ Go to top ]

    Aspects seem to reflect a weekness in the java language.

    I'd like to be able to do the following;

      x = new Person();
      x.setFirstName("xxx");


    -----

    mapmessage setFirstName -> Logger.logMethodEntry;
    -> Person.firstNameSet;
    -> Logger.logMethodExit;

    -----

    class Person

    firstNameSet(x) {
    this.firstName = x;
    }


    Where mapmessage defines the linkage between the public interface, and the private implementation. This decoupling of caller/callee could be very powerful.