Tech Talk with Bill Burke on JBoss 4 and the AOP Framework

Discussions

News: Tech Talk with Bill Burke on JBoss 4 and the AOP Framework

  1. In this interview, Bill Burke, Chief Architect of JBoss, discusses what's new in JBoss 4 and looks at some of the new services provided by it's aspect-oriented architecture. He compares JBoss AOP to other frameworks like AspectWerkz and AspectJ, looks at how ISVs and tool vendors can use the AOP framework and discusses the Javassist project.

    Watch Bill Burke's Interview

    Threaded Messages (151)

  2. From this month's JavaWorld article by Rick Grehan(http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-iw-jboss.html):

    "I must confess some initial uneasiness about JBoss's AOP. It is very similar to the sort of "under the covers" classfile manipulation performed by such systems as the object-oriented database FastObjects, and I have a great deal of respect for FastObjects. JBoss's AOP is simultaneously more elegant—and more disturbing. It instruments at classload time, so there is no explicit, post-compilation step. In so doing, a Java class is injected with behavior that is nowhere apparent in the source code"

    Grehan implies the existence of risk with this implementation. Can anyone quantify or qualify these risks? I'm completely new to AOP and I'm concerned about JBoss being somehow compromised.
  3. Class enhancement[ Go to top ]

    From this month's JavaWorld article by Rick Grehan(http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-iw-jboss.html):

    >
    > "I must confess some initial uneasiness about JBoss's AOP. It is very similar to the sort of "under the covers" classfile manipulation performed by such systems as the object-oriented database FastObjects, and I have a great deal of respect for FastObjects. JBoss's AOP is simultaneously more elegant—and more disturbing. It instruments at classload time, so there is no explicit, post-compilation step. In so doing, a Java class is injected with behavior that is nowhere apparent in the source code"
    >

    JDO uses a similar technique. In JDO, it is called "class enhancement"
    or "class file enhancement"
  4. Hmmm, I thought I had posted the response so apologies if this is a duplicate,

    >
    JBoss's AOP is simultaneously more elegant—and more disturbing. It instruments at classload time, so there is no explicit, post-compilation step. In so doing, a Java class is injected with behavior that is nowhere apparent in the source code"
    >
    > Grehan implies the existence of risk with this implementation. Can anyone quantify or qualify these risks? I'm completely new to AOP and I'm concerned about JBoss being somehow compromised.
    >

    Ok, no no no no. Don't worry about AOP. If you are worrying about AOP, you should not be worrying about AOP :)

    In JBossAOP (and most AOP frameworks out there) you specify WHERE you want the aspect with tags. EJB is a primitive AOP framework where you specify behavior (remoteness, persistence, transaction, security) in ejb-jar.xml and the fact that you code to an EJB. In JBoss4 we allow you to do that a la carte with XML tags only and POJO's not just EJB's.

    Some aspects even require NO DECLARATION FROM YOU, such as 'monitoring' or 'cache replication'. See cache insertion is programmatic

    cache.insert("anObject", anInstance);

    and the cache does

    ((AOP) instance).getStack().addInterceptor( new CacheInterceptor(this)) // All crud operations are done.

    It's pseudo code, but the bottom line is that the instance is instrumented for CRUD operations and the cache is notified (through the this variable) of state changes at transaction demarcation time. Other domain of applicability is persistence (JDO, CMP, Hibernate) where extracting state CRUD change is relevant information.

    There is no definition of anything in teh case of cache and in the case of persistence you only provide a persistence.xml mapping file a la hibernate or cmp2.0 for example.

    Trivial. Non-intrusive.

    A better example yet is the one I already gave Rickard, monitoring. Monitoring may not be built in every object in the runtime by the developer but a system doctor could come in and dynamically insert the thread count/medium time aspect in a given object like a doctor uses a stetoscope to hear various parts of your body. The developer didn't code support for that introduction at every point but if the system holds a reference to the POJO (JMX or IoC) then the admin can dynamically request that introduction.

    clear?
  5. EJBs not AOP[ Go to top ]

    <Mark F.>
    In JBossAOP (and most AOP frameworks out there) you specify WHERE you want the aspect with tags. EJB is a primitive AOP framework where you specify behavior (remoteness, persistence, transaction, security) in ejb-jar.xml and the fact that you code to an EJB. In JBoss4 we allow you to do that a la carte with XML tags only and POJO's not just EJB's.
    </Mark F.>

    This is not correct and it's also at the heart of a lot of confusion out there related to the application and misapplication of AOP concepts. So let's be very, very clear: EJBs are not an early example of AOP. They are much closer -- and even this is a mistake -- to early pre-AOP CLOS style dynamic proxies, if you really must think about them from a mechanistic perspective.

    Do we really need to say it again? AOP is not interception. The EJB container manages a component model that does indeed intercept calls, but it doesn't intercept calls to an object -- the system services that are provided are provided for a component, not an object. Weaving directly into an object isn't desireable for EJBs or most of their services. The fact that the programming model makes the programmer cognizant and and to some extent responsible with respect to the system services (transactions, distribution) is a good thing, not a liability. And because there is not a direct connection between object instances and the component the container can do things to help, for example, to enforce error handling rules that preserve consistency of outcomes in the face of failures.

    It's also not true that "remoteness" is specified in ejb-jar.xml. It's determined by the use of the remote interface. We know from CORBA systems that the semantics of parameter passing need to be explicit or we introduce all kinds of subtle programming bugs when we change the parameter passing semantics from the intent of the original author of the component. It's also happends to be the case that the error handling semantics are altered in important ways from the standpoint of the client coder in the two cases (in fact, they are an improvement with local interfaces since runtime exceptions in J2EE mimic in some respects thread cancelation models that other TP systems might use within the limits of Java). Incidently, when we did the 2.0 spec, some companies did propose meta-data driven parameter passing semantics.

    I'm not saying EJBs are inherently good or that AOP is bad. They aren't the same thing and shouldn't be thought of that way.

    Greg
  6. EJBs not AOP[ Go to top ]

    <Mark F.>

    > In JBossAOP (and most AOP frameworks out there) you specify WHERE you want the aspect with tags. EJB is a primitive AOP framework where you specify behavior (remoteness, persistence, transaction, security) in ejb-jar.xml and the fact that you code to an EJB. In JBoss4 we allow you to do that a la carte with XML tags only and POJO's not just EJB's.
    > </Mark F.>
    >

    marc with a c not a k :) and please read my "blue" white paper or why EJB is an early pre-packaged AOP framework. It is simple stuff.
    >
    closer -- and even this is a mistake -- to early pre-AOP CLOS style dynamic proxies, if you really must think about them from a mechanistic perspective.
    >

    That is incorrect Greg, EJB's in JBoss leverage dynamic proxies (thanks to rickard btw) but in BEA you do compilation mess.

    EJB mandate indirection and pre-post computing aka interception. It is clearly AOP or how to add system behavior to a component.

    >
    are provided for a component, not an object. Weaving directly into an object isn't desireable for EJBs or most of their services.
    >

    ??? you kidding right?
    JDO, hibernate, remoteness, acidity, transactions, security why these would be attributes of the class and component and not the object?

    > It's also not true that "remoteness" is specified in ejb-jar.xml. It's

    Yes it is true, you specify the JNDI name and that is one of the triggers to add remoteness to the EJB.

    >
    kinds of subtle programming bugs when we change the parameter passing semantics from the intent of the original author of the component. It's also
    >

    Ok that is a valid point but remoteness and semantics of data are orthogonal aspects. It deserves a research paper.

    Georgia Tech, which whom we have a relationship, has implemented "pass by copy restore" a.k.a NRMI and have implemented the corresponding aspect.

    What it boils down to is that you should be able to specify data semantics per object, you may want "detached (serialized)" you may want by reference (NRMI) you may want mirror copies that get updated asynchronously from server (Observer/Observable pattern).

    today there is minimal support for expanded semantics in J2EE, EJB defines RMI and local but none of the advanced data behaviors I just talked about. With aspects we are capable of providing that behavior a la carte for the designer.

    Clearly powerful, clearly useful, think of all the apps that fail because they don't properly use passing semantics of EJB and come crying to us with scalability problems. These semantics of data are key and barely addressed today.

    But remember the transport (remoteness configuration: SOAP, webservice, RMI) is imho largely independent from the data copy semantics and behavior. EJB does a simple version,we should go beyond it in a big way. I think there is research papers to be written there.
     
    >
    happends to be the case that the error handling semantics are altered in important ways from the standpoint of the client coder in the two cases (in
    >
    Agreed, agreed, these semantics need to be explicit. And they are.

    marcf
  7. EJBs not AOP[ Go to top ]

    <Mark F.>

    > > In JBossAOP (and most AOP frameworks out there) you specify WHERE you want the aspect with tags. EJB is a primitive AOP framework where you specify behavior (remoteness, persistence, transaction, security) in ejb-jar.xml and the fact that you code to an EJB. In JBoss4 we allow you to do that a la carte with XML tags only and POJO's not just EJB's.
    > > </Mark F.>
    > >
    >
    > marc with a c not a k :) and please read my "blue" white paper or why EJB is an early pre-packaged AOP framework. It is simple stuff.
    > >
    > closer -- and even this is a mistake -- to early pre-AOP CLOS style dynamic proxies, if you really must think about them from a mechanistic perspective.
    > >
    >
    > That is incorrect Greg, EJB's in JBoss leverage dynamic proxies (thanks to rickard btw) but in BEA you do compilation mess.
    >
    > EJB mandate indirection and pre-post computing aka interception. It is clearly AOP or how to add system behavior to a component.
    >
    > >
    > are provided for a component, not an object. Weaving directly into an object isn't desireable for EJBs or most of their services.
    > >

    I think you've missed the point. What I'm saying is that any EJB implementation (whether it does dynamic proxies or compilation) is doing interception at a component not an object level. Different means to achieve this in different application servers are irrelevant. More importantly, the model is intentionally not generalizing the application of those services.

    Your basic claim is that there are no fundamental problems moving the system services from a container model to a object model. It's my opinion that in many cases you are defining an emerging anti-practice. Even in the list you provide, and setting aside the general issue of introducing behavior to code that is oblivious to the semantics of an aspect, it's not clear that binding transaction semantics to an object instance directly or blurring the issue of location transparency is a good idea to generalize out of the container.

    BTW, I read blue when it was published and I thought then that in this area it missed this distinction in order to promote some what you guys are experimenting with. My theory on enterprise software: it's better to have your software ensure correctness than be perceived as cool.

    Greg
  8. EJBs not AOP[ Go to top ]

    Greg Pavlik wrote:
    >So let's be very, very clear: EJBs are not an early example of AOP. They are much closer -- and even this is a mistake -- to early pre-AOP CLOS style dynamic proxies, if you really must think about them from a mechanistic perspective.
    >

    It is not a mistake. EJB is a good analogy of AOP concepts that people understand. EJB is a perfect example of separation of concerns. The concerns being transactions, security, and persistence. Sure, you're limited to those aspects and limited to only applying them to classes that implement and extend EJB interfaces/classes. But you're applying aspects implicity to an existing object model.

    In CORBA, you had to explicity code transaction demarcation. EJB was the first attempt to separate this logic from application code. This is why AOP fits so well with middleware.

    Bill
  9. EJBs not AOP[ Go to top ]

    As an analogy, I think EJB is a great starting point. But analogies do not equate to equivalence. You're not making an analogy with your aspects, you're attempting to generalize the container services.

    Greg
  10. EJBs not AOP[ Go to top ]

    \Bill Burke\
    It is not a mistake. EJB is a good analogy of AOP concepts that people understand. EJB is a perfect example of separation of concerns. The concerns being transactions, security, and persistence. Sure, you're limited to those aspects and limited to only applying them to classes that implement and extend EJB interfaces/classes. But you're applying aspects implicity to an existing object model.
    \Bill Burke\

    You're missing a fundamental point of AOP here. EJB code...:

       - declares specialized interfaces explicitly
       - Has explicit knowledge that it is being managed, and (to an extent) how
       - Can access and modify the transaction/security/persistence information

    To say that in a shorter way - the code the developer is writing is written with full awareness that it's part of a transaction (or persistence, or what have you). The "full awareness" part is the key - you know you're part of a larger lifecycle. The writer of an EJB component has to follow very strict rules when they're doing so.

    Because of this, EJBs are nothing like AOP at all, because the code in question is fully aware of the container services, knows its in a container, can affect what happens to it within the container, and has to be written to a very specific contract.

    And once again - if you think EJB are a good analog to AOP,then you really, really don't get AOP (really!).

        -Mike
  11. EJBs not AOP[ Go to top ]

    <Mike>
    > To say that in a shorter way - the code the developer is writing is written with full awareness that it's part of a transaction (or persistence, or what have you). The "full awareness" part is the key - you know you're part of a larger lifecycle. The writer of an EJB component has to follow very strict rules when they're doing so.
    </Mike>

    To underscore this (crucial) point: the writer of the EJB follows these rules because the container and the rules combine to help to ensure correct outcomes.
  12. EJBs not AOP[ Go to top ]

    <Mike>

    > > To say that in a shorter way - the code the developer is writing is written with full awareness that it's part of a transaction (or persistence, or what have you). The "full awareness" part is the key - you know you're part of a larger lifecycle. The writer of an EJB component has to follow very strict rules when they're doing so.
    > </Mike>
    >
    > To underscore this (crucial) point: the writer of the EJB follows these rules because the container and the rules combine to help to ensure correct outcomes.

    JMX services + AOP in JBoss allows you to write generalized containers. The container is not a magical entity it is an assembly of aspects that follow well defined semantics.

    point in case the transactions. The semantics of the transactions demarcation are well understood today, start, stop, when, how and the acidity of the objects well defined (rollback state on a rollback).

    You have a service (the tm), and an aspect (the transaction demarcation interceptor) that understand the tag semantics. The acidity of the objects in EJB is in fact a by-product of load and store semantics in the objects and the validity of the state in cache. That validity is driven by listener on the transaction demarcation and its results. long story short, Synchronization is the interface we are talking about.

    nowhere in J2EE do you define acidity as a system property applied to objects. Bill has implemented ACID objects in JBoss 4.0 from an idea Julien Viet (the nukes developer) had while at NIST in the US. Any object can be made ACID where we version the state and register Synchronizations on behalf of the object and automatically rollback the state.

    Meaning the containers today, the EJB ones, have a clunky way of achieving ACID semantics and in fact don't do it AT ALL for session. How many times have we seen people putting stuff in HTTPSession and doing manual rollback of state on transaction failure? that feature is today NATIVE as an AOP enabled aspect in JBoss 4. You web layers, your tomcat on jboss container can host completely acid objects.

    Beyond the mind-bloging coolness of the feature, it is actually a high end enterprise feature that is today nowhere, or only partially present in J2EE, which we have generalized to all pojo's.

    clear?
  13. EJBs not AOP[ Go to top ]

    I am on vacation now, so I'm abandoning this discussion.

    > > <Mike>
    > > > To say that in a shorter way - the code the developer is writing is written with full awareness that it's part of a transaction (or persistence, or what have you). The "full awareness" part is the key - you know you're part of a larger lifecycle. The writer of an EJB component has to follow very strict rules when they're doing so.
    > > </Mike>
    > >
    > > To underscore this (crucial) point: the writer of the EJB follows these rules because the container and the rules combine to help to ensure correct outcomes.
    >
    > JMX services + AOP in JBoss allows you to write generalized containers. The container is not a magical entity it is an assembly of aspects that follow well defined semantics.
    >

    This just isn't accurate. I'm completely lost as to how to make this clear. I believe Mike has lucidly described why this is false in better detail than I have been able to.


    > point in case the transactions. The semantics of the transactions demarcation are well understood today, start, stop, when, how and the acidity of the objects well defined (rollback state on a rollback).
    >

    Some aspects of transactions are well understood today (though there are plenty of religious disagreements and areas that are not well understood). But ACID properties aren't guaranteed by rollbacks. Since JBoss doesn't support ACID transactions, I'm not surprised by this.

    > You have a service (the tm), and an aspect (the transaction demarcation interceptor) that understand the tag semantics. The acidity of the objects in EJB is in fact a by-product of load and store semantics in the objects and the validity of the state in cache.

    Sorry, this is only part of the story.

    > Beyond the mind-bloging coolness of the feature, it is actually a high end enterprise feature that is today nowhere, or only partially present in J2EE, which we have generalized to all pojo's.
    >
    > clear?

    What's clear is that you don't fully understand transaction semantics.
  14. EJBs not AOP[ Go to top ]

    As a complete aside, I think a number of people in this thread are throwing around the term "ACID" as a generic buzzword without knowing (or caring) what it means.

    Putting on my own professor hat for a moment (and apologies for those who know this and have to now endure it)...

    ACID means "Atomicity Consistency Isolation Durability"

    Atomicity means all or nothing - you commit all or roll back.

    Consistency - in the face of failures, you'll be consistent (really a modifier to atomicity).

    Isolation - you're stuff in transaction "A" is seperate from other transactions.

    Durability - It's persistent.

    -------------

    Sorry for the lecture, but it's rather important, and I think it exposes the fact that specific terminology has been bandied about carelessly here. It sounds to me like, by default, object graphs are in fact not atomic, because of "Requires New" being the default. By default only individual objects are atomic, the graph is a mass of seperate trasactions.

    Consistent - See the last part, since this really has to do with durability.

    Isolation - I haven't heard any mention of JBoss implementing any sort of isolation. Are transactions independent and their effects invisible to each other until commit time?

    Durability - I haven't heard anything about durability, which ties into consistency. I guess these are in-memory-only transactions? Or are these tied into a persistence engine? If so, which one? And if so, how do you persist a POJO in a reasonable manner?

    Of course, pure "ACID" is the ideal, and modern systems have various levels thereof (various isolation levels, people turning off disk forcing, that sort of thing). But the intent is to try to achieve some level of all 4 pieces of ACID, and to (hopefully) document where you're not part of the ideal.

    ---------

    The above is of course rather pedantic, but it I went through the exercise for a point. Here JBoss developers are talking about automatically adding "ACID" properties to POJOs, but unless I've missed something fundamental, the auto-transactional container described is nothing more than a delta mechanism tied into rollback/commit semantics - hardly ACID.

    And, perhaps, I have grossly misunderstood what the JBoss team has actually achieved, and it really is all-the-way ACID. But again - I haven't been able to find that out from _these_ discussions, and I haven't been able to find it out from any documentation (and haven't had the time or energy to slog through the source at this time). I have looked at the JBoss AOP page, and it appears that what is actually described is a "transactional cache", which lets you commit or rollback changes. But there's no talk of the C, I, or D parts of ACID.

    The same sort of loose language is being used to describe the "AOPness" of the new JBoss code as well, and with similar effects and resulting confusion. And there's the same lack of real concrete information - just vague assertions along the lines of "We're JBoss, trust us. We know what we're doing".

    Many people might think this sort of analysis is frivolous, but it's not. Certain technical terms are supposed to mean certain technical things, and it is by common usage of these terms that people can understand each other, and also evaluate new things. If something claims to be XA-compliant, I hope it has a transaction log (and disk forces by default!). If a container of some form claims to provide ACID guarantees, I'll damn well assume that Isolation levels, Durability, and Consistency will be in there somewhere. If someone claims to be a cutting edge AOP inovator, I expect to act like the rest of the AOP products on the planet.

    When these forms of communications are broken - a lingustic contract, if you will - everyone suffers. It's an insidious form of FUD. The XA driver isn't quite. The cluster doesn't always cluster. The "ACID" component is really just an "A" component. The sleek and sexy AOP implementation is a weak (yet also horribly powerful) runtime interceptor. Developers become confused. People get humilitated on the job for recommending an evaluation of "X" based on its wildly inaccurate documentation. Blossoming new technologies get trashed by half-implementations that fail. Money is lost when the process crashses, and the recover() method always returns "new Xid[0]"

    In case Bill and Marc et al were wondering, this is why JBoss gets so much resistance from a select group of people. It's not because of technology, it's not because of bugs, it's not because of sexiness or lackthere of, it's not because of perceived risk taking. It's because you play fast and loose with language, and no one can get a straight answer out of you. Sane people don't trust what they don't (and can't possibly) understand.

       -Mike
  15. On ACID....[ Go to top ]

    (Yes, subject pun intended).

    Incidentally, I really am interested in what "ACID" means for transactional objects and the cache in JBoss. The term "ACID POJO's" in various forms have been bandied about in the JBoss forums, the AOP documentation, and here, and I am truly interested in whether the goal is to go for real ACID semantics, or if the goal is just the more loosey-goosey "transactional".

        -Mike
  16. On ACID....[ Go to top ]

    I recently downloaded the JBoss 4.0 DR2 build but I haven't had a chance yet to look at any of the new acid pojos. I think your points / concerns are worth looking into.

    FWIW - I would say though that the "D" in acid doesn't necessarily mean "persistence" (i.e. disk) ... durability can imply that it is 'backed up' elsewhere in the cluster etc. ... just as long as it will survive something, like a server going down. Claiming durability usually implies that you have to explain what situations it can and cannot survive. If JBoss has a backup copy on a different cluster member, or does a 2pc by updating another cluster member with the "prepared" state of the pojo(s) and then commits, then I think they could reasonably claim the "D" in acid.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  17. On ACID....[ Go to top ]

    Hmmm, cluster based updates. Sounds suspiciously like a cluster-based caching product I've heard about. :-)

    Yes, what you're saying makes sense. However, in a non-clustered environment, "D" does imply that you can bounce the server and your stuff is still there.

    Back to the cluster part, though. I haven't seen any solid information on how JBoss deals with clustering in general WRT consistency. There's the right/consistent way, as you describe, and then there's the plain old fast way that an unfortunately large body of developers seem to favor. I haven't found any details on JBoss' clustering to be able to tell which is applicable here.

        -Mike
  18. On ACID....[ Go to top ]

    Hmmm, cluster based updates. Sounds suspiciously like a cluster-based caching product I've heard about. :-)

    >
    > Yes, what you're saying makes sense. However, in a non-clustered environment, "D" does imply that you can bounce the server and your stuff is still there.
    >
    > Back to the cluster part, though. I haven't seen any solid information on how JBoss deals with clustering in general WRT consistency. There's the right/consistent way, as you describe, and then there's the plain old fast way that an unfortunately large body of developers seem to favor. I haven't found any details on JBoss' clustering to be able to tell which is applicable here.
    >
    >     -Mike

    It is really sad that you show again and again that all you really know is how to make a complete ass of yourself. That you have done absolutely no research what-so-ever on any of the topics we're discussing and that you rely on TSS as the basis for all your knowledge about JBoss (and probably other subjects).

    1) JBoss clustering is based on the well known and respected open-source project Javagroups. www.javagroups.com. I don't think you want to question Bela's credentials as he was some of the brains behind Isis, Ensemble, and Horus. Javagroups provides guaranteed messaging over IP multicast. Guaranteed message ordering, group management protocols, and state synchronization algorithms. All solid foundations for any distributed transactional caches, or clustering implementation.

    2) Bela is doing JCache work under the JBoss umbrella and within our our CVS. Bela has been accepted to this JSR committee as well. Bela, Ben Wang, Harald Gliebe and myself implemented two separate kinds of caches for the JB4 DR2 release. One is based on pessimistic locking with read/write locks. The other on snapshot isolation and optimistic locking. Unlike you, we actually did some research on what would be the best way to implement a replicated cache. See below.

    The main page is at
    http://www.inf.ethz.ch/department/IS/iks/publications.html.
     
     
    The 3 papers I'm referring to are (all publicly available):
     
     (below is the main paper)
     
     
       A New Approach to Developing and Implementing Eager Database
       Replication Protocols
     
     http://www.inf.ethz.ch/department/IS/iks/publications/ka00b.html
     
     
     M. Wiesmann,F. Pedone, A. Schiper, B. Kemme, G. Alonso.*Database
    Replication Techniques: a Three Parameter Classification*In: Proc. of
     the 19th IEEE Symposium on Reliable Distributed Systems (SRDS2000),
     Nörnberg, Germany, October 2000.
     
     B. Kemme, F. Pedone, G. Alonso, A. Schiper: *Processing Transactions
     over Optimistic Atomic Broadcast Protocols
     <http://www.inf.ethz.ch/department/IS/iks/publications/kpas99a.html>*.
     In: 19th International Conference on Distributed Computing Systems
     (ICDCS), Austin, Texas, USA, June 1999.
     
     B. Kemme, F. Pedone, G. Alonso, A. Schiper : *Using Optimistic Atomic
     Broadcast in Transaction Processing Systems
    <http://www.inf.ethz.ch/department/IS/iks/publications/tech325.html>*.
     Technical Report No. 325, 1999.
     
     B. Kemme, G. Alonso: *Transactions, Messages and Events: Merging Group
     Communication and Database Systems
     <http://www.inf.ethz.ch/department/IS/iks/publications/ka99b.html>*. In:
     Third ERSADS European Research Seminar on Advances in Distributed
     Systems, Madeira Island, Portugal, April 1999.
     

    3) Its also obvious that you have most of your information about JBoss AOP and the aspects we've written from TSS. Just in case there is even the remotest possibility that the JBoss website could have more information about JBoss AOP than TSS, I'll provide you with the link to the JBoss AOP documentation which could always be navigatable from the front page of our website.

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

    The sourcecode is available at:
    cvs checkout -r Branch_4_0_DR3 jboss-head

    testcode under:
    jboss-head/testsuite/src/main/org/jboss/test/aop, cache

    4) The main goal of JBoss 4 is to be J2EE compliant and also introduce an entirely new strategy of aspect-oriented middleware. The AOP framework was written, first and foremost to be the basis of our POJO (plain old java object) strategy and as a by-product, to enhance our J2EE layer for easier and tighter ISV integration.

    Bill
  19. On ACID....[ Go to top ]

    (Taken somewhat out of order)

    \Bill Burke\
    It is really sad that you show again and again that all you really know is how to make a complete ass of yourself. That you have done absolutely no research what-so-ever on any of the topics we're discussing and that you rely on TSS as the basis for all your knowledge about JBoss (and probably other subjects).

     [...]
    3) Its also obvious that you have most of your information about JBoss AOP and the aspects we've written from TSS. Just in case there is even the remotest possibility that the JBoss website could have more information about JBoss AOP than TSS, I'll provide you with the link to the JBoss AOP documentation which could always be navigatable from the front page of our website.
    \Bill Burke\

    You are rather far from the mark in these comments. And as any one who has read TSS regularly for awhile, if anything I am overly pedantic and tend to research issues far past most people's stamina or interest. More often than not I'm the one who quotes specifications, reference specific pieces of source code, and comment on the subtler aspects a topic.

    On JBoss AOP - I was probably one of the first ten people to go to the AOP link after you posted it awhile back. Since then, I've visited it repeatedly and read it in detail at least 10 times. The purpose of those visits and scrutiny was to try to understand what was actually offered. I have also downloaded the entire JBoss source base on several occasions and investigated areas that were of interest to myself. That's how I learned about the various holes and problems in the 3.x JMS implementation - not from documentation or conversations, but by reading the code. I've made repeated references in fact to JBoss JMS' incomplete XA support, and the infamous:

        public Xid[]
        recover ()
        {
           return (new Xid[0]);
        }

    snippet in the JMS XAResource implementation. I have my own XA implementation and JMS implementation based (very loosely now) on OpenJMS, and have had spirited discussions with a number of IBM folks about generic JMS and XA support in Websphere - some of which conversations have resulted in my acknowledging and fixing problems in my own implementation, and some of which have resulted in Websphere releasing eFixes to address problems myself and on-site IBM consultants have found in the Websphere JMS/XA implementation.

    As for knowledge of JBoss AOP - that is based solely on TSS posts. Plus the AOP documentation on the JBoss site. Plus reading the JBoss AOP forum on a regular basis. Plus downloading the DR2 head snapshot source code and trying to make sense of the contents of both the aop/ and aspects/ source areas. It was from reading this code that it gelled in my consciousness that the current implementation only supports the equivalent of AspectJ around() advice, and that advice has to always manually chain the calls via invocation.invokeNext(). It's also how I realized that the existing objects deal with advised code in a fairly generic manner (which makes sense, given their goals), but that future advice which needs to access the guts of an advised object directly is going to need a lot of casts and reflection-type access, and how ugly/error prone that appears compared to the statically typed AspectJ method. I even noted the high level of commenting in the aspect code, and relative dearth of comments in the Aspect code.

    The one thing I haven't been able to determine is how ACID ACID objects are in your TxCache, since the code is fairly dense and I haven't had the time to trace through it all in detail (and lack any sort of design guide or diagrams to help me through it).

    A question which you've yet to directly address.

    So in fact, Mr. Burke, your guesses are completely wrong, and I've studied this subject (and others) in alot more detail then perhaps you realized.

    \Bill Burke\
    1) JBoss clustering is based on the well known and respected open-source project Javagroups. www.javagroups.com. I don't think you want to question Bela's credentials as he was some of the brains behind Isis, Ensemble, and Horus. Javagroups provides guaranteed messaging over IP multicast. Guaranteed message ordering, group management protocols, and state synchronization algorithms. All solid foundations for any distributed transactional caches, or clustering implementation.
    \Bill Burke\

    Javagroups is indeed a fine product, and I've used it myself and like it. Bela did a bang up job there.

    However, strictly by basing JBoss clustering on top of Javagroups doesn't mean that by extension JBoss clustering is good. Javagroups is in fact very well documented, in direct opposition to what I can say about just about any JBoss feature.

    \Bill Burke\
    2) Bela is doing JCache work under the JBoss umbrella and within our our CVS. Bela has been accepted to this JSR committee as well. Bela, Ben Wang, Harald Gliebe and myself implemented two separate kinds of caches for the JB4 DR2 release. One is based on pessimistic locking with read/write locks. The other on snapshot isolation and optimistic locking. Unlike you, we actually did some research on what would be the best way to implement a replicated cache. See below.
    \Bill Burke\

    How does this relate to the TxCache AOP implementation? And how does it relate to my questions on ACID? Let me ask again in an altered form:

      - how does TxCache look in terms of isolation (the I in acid)? It appears it does what you call "snapshot isolation/optimistic locking", which appears to be a fancy way of saying there isn't any isolation. I'd go a little further and say that optimistic locking is a bit weird for in-memory objects.

      - Does TxCache address Durable at all (the D in acid)? I haven't seen any indication that it does, and pointing me at a bunch of research papers doesn't tell me anything at all about what JBoss TxCache actually does. And as I said, I don't have the time to trace out all the logic and relationships in aop/versioned, aop/tx, and other places to determine it quickly myself.

      - How can you possibly address Consistency (the C in acid) if you don't have durability?

    ------------------------

    Just so we're clear, Mr. Burke, I'm not an idiot who bases all of his opinions on TSS posts. I've read _all_ of your documents, read all of the JBoss AOP form, read your posts here, and looked at pieces of the source code as well. And after doing that, it's still very unclear to me what the code in question actually does. The docs and your posts throw terms like ACID around, but your documents give no indication what the actual guarantees are, and the code I've seen appears to contradict your documents and public statements.

    This goes back to my previous comments - JBoss communicates conflicting information in various formats, and (as you've demonstrated here) it's frustratingly difficult (sometimes impossible) to get straight unambiguous answers to simple concise questions. A complete lack of design documents exacerbates this problem even further. And, no, a one page post to a forum about "DR 2" goals, or pointing to other people's research papers does not consistute a design document in my opinion.

    And all of this is especially relevant now, since we're talking about a non-standard feature that will require some lock-in. If you don't document your behavior, people are going to start writing code against just what JBoss 4 happens to do at the moment, and you're likely to change that code over time - with no hint to people that it might break their existing code. If you don't document semantics, people don't know what to expect, and don't know how much risk they might be taking by trying to use something. If there's no design, people have no way to evaluate how closely the actual code matches the design ideals (and therefore potential areas for future change).

    To summarize, you're selling people hard on this fabulous new paradigm that JBoss is attempting with AOP - but you don't tell them exactly what that is. All we have is the usual JBoss half-marketing/psuedo-technical single AOP page which makes claims without giving any indication on how those claims or met, and with disturbing disconnects between what the AOP page says, and what the code actually does.

        -Mike
  20. Ippon![ Go to top ]

    ..and mr Spille wins by Ippon!
  21. On ACID....[ Go to top ]

    Mike Spille wrote:
    As for knowledge of JBoss AOP - that is based solely on TSS posts. Plus the AOP documentation on the JBoss site. Plus reading the JBoss AOP forum on a regular basis. Plus downloading the DR2 head snapshot source code and trying to make sense of the contents of both the aop/ and aspects/ source areas. It was from reading this code that it gelled in my consciousness that the current implementation only supports the equivalent of AspectJ around() advice,

    If you have an interceptor, then you implicitly have before, after, and around all together.


    and that advice has to always manually chain the calls via invocation.invokeNext(). It's also how I realized that the existing objects deal with advised code in a fairly generic manner (which makes sense, given their goals), but that future advice which needs to access the guts of an advised object directly is going to need a lot of casts and reflection-type access, and how ugly/error prone that appears compared to the statically typed AspectJ method. I even noted the high level of commenting in the aspect code, and relative dearth of comments in the Aspect code.

    My guess is that AspectJ before() and after() still have a lot of the same overhead as our framework because they still have to allocate all the objects necessary for the AspectJ framework (all the joinpoint objects and such), which is the bulk of overhead.


    > The one thing I haven't been able to determine is how ACID ACID objects are in your TxCache, since the code is fairly dense and I haven't had the time to trace through it all in detail (and lack any sort of design guide or diagrams to help me through it).
    >
    > A question which you've yet to directly address.
    >
    > So in fact, Mr. Burke, your guesses are completely wrong, and I've studied this subject (and others) in alot more detail then perhaps you realized.
    >
    > \Bill Burke\
    > 1) JBoss clustering is based on the well known and respected open-source project Javagroups. www.javagroups.com. I don't think you want to question Bela's credentials as he was some of the brains behind Isis, Ensemble, and Horus. Javagroups provides guaranteed messaging over IP multicast. Guaranteed message ordering, group management protocols, and state synchronization algorithms. All solid foundations for any distributed transactional caches, or clustering implementation.
    > \Bill Burke\
    >
    > Javagroups is indeed a fine product, and I've used it myself and like it. Bela did a bang up job there.
    >
    > However, strictly by basing JBoss clustering on top of Javagroups doesn't mean that by extension JBoss clustering is good. Javagroups is in fact very well documented, in direct opposition to what I can say about just about any JBoss feature.


    I think Sacha and I beg to differ as we have written numerous articles as well have a 50 page for-pay document on the subject. Again, you're showing your complete lack of research.


    >
    > \Bill Burke\
    > 2) Bela is doing JCache work under the JBoss umbrella and within our our CVS. Bela has been accepted to this JSR committee as well. Bela, Ben Wang, Harald Gliebe and myself implemented two separate kinds of caches for the JB4 DR2 release. One is based on pessimistic locking with read/write locks. The other on snapshot isolation and optimistic locking. Unlike you, we actually did some research on what would be the best way to implement a replicated cache. See below.
    > \Bill Burke\
    >
    > How does this relate to the TxCache AOP implementation? And how does it relate to my questions on ACID? Let me ask again in an altered form:
    >
    > - how does TxCache look in terms of isolation (the I in acid)? It appears it does what you call "snapshot isolation/optimistic locking", which appears to be a fancy way of saying there isn't any isolation. I'd go a little further and say that optimistic locking is a bit weird for in-memory objects.
    >


    Snapshot isolation solves the C and I of ACID since a snapshot is created from the "real" data. Databases like Firebird and McKoi are the two examples I can think of that use this pattern. Since every transaction gets it own snapshot of the "real" state, Consistency can be maintained since on TX rollback the snapshot is just thrown away, and isolation is maintained because the tx is working with a snapshot and no other transaction sees this snapshot.

    Optimistic locking allows you to have high concurrent access with no locking. Great for read-mostly datastructures. Pessimistic locking can protect access to a single shared instance, but we don't actually use it for this purpose in our caching since snapshots are always taken.


    > - Does TxCache address Durable at all (the D in acid)? I haven't seen any indication that it does, and pointing me at a bunch of research papers doesn't tell me anything at all about what JBoss TxCache actually does. And as I said, I don't have the time to trace out all the logic and relationships in aop/versioned, aop/tx, and other places to determine it quickly myself.
    >


    We're not talking Data objects here. We're talking plain pojos. As long as there is one member in the cluster alive, then any new members of the cluster will receive all replicated data. Most of this guarantee and consistency of data is done by JavaGroups as it has strict protocols for group membership and state synchronization. Our EJB cluster implementation has relied on these for quite some time now. I'll be happy to explain further on these features if you like.


    > - How can you possibly address Consistency (the C in acid) if you don't have durability?
    >


    Do you really not know what ACID means? Consistency has nothing to do with durability. Durability just states that the data is available in the event of a failure and restart. Consistency means that a rollback is possible.

    Again, since you can listen to cluster membership change events with JavaGroups, we're pretty much good-to-go as long as one member of the cluster stays alive.


    > ------------------------
    >
    > Just so we're clear, Mr. Burke, I'm not an idiot who bases all of his opinions on TSS posts.


    My wife has a funny bumpersticker. "All men are idiots, and I married their king." Is that you Monica? Ya know, I could spend more time in the yard if you stopped this posting to TSS dear.


    > I've read _all_ of your documents, read all of the JBoss AOP form, read your posts here, and looked at pieces of the source code as well. And after doing that, it's still very unclear to me what the code in question actually does. The docs and your posts throw terms like ACID around, but your documents give no indication what the actual guarantees are, and the code I've seen appears to contradict your documents and public statements.
    >


    I talk about all this stuff in the doco. Go read it again. I even give a simplified algorithm on what happens at commit time with the replicated cache. That's just my stuff. Bela has a much better design guide in our CVS under jboss-head/cache/docs:

    Fine_Grain_Locking.doc
    Requirements.txt
    todo.txt
    TreeCache.doc
    TreeCacheAOP.txt
    TreeCacheLocking.doc
    UseCases.txt
    varia.txt

    Bill
  22. On ACID....[ Go to top ]

    \Bill Burke\
    If you have an interceptor, then you implicitly have before, after, and around all together
    \Bill Burke\

    I don't think in terms of interceptors, I think in terms of AOP in general, and the AspectJ language in concrete terms. As such I hadn't mentally made the connection, and needed to look at the code for it to become clear to me.

    And to be pedantic - before, after (in its various forms), and around are all language level constructs in AspectJ. Alot of advice written in AspectJ ends up being before() and after(), with no need to manually chain (the language does this for you). From one point of view you can certainly say that JBoss AOP does them all - but in practical terms, there's only around() advice.

    \Bill Burke\
    My guess is that AspectJ before() and after() still have a lot of the same overhead as our framework because they still have to allocate all the objects necessary for the AspectJ framework (all the joinpoint objects and such), which is the bulk of overhead.
    \Bill Burke\

    I don't believe your guess is correct. See the thisJointPointStaticPart, along with target() and args() and other pieces. Also, it's not all about performance - before() and after() tell you exactly where your advice is supposed to run, and serves as implicit documentation. Optimizations that can be made because of their being distinct just serve as added bonus points.

    \Bill Burke\
    I think Sacha and I beg to differ as we have written numerous articles as well have a 50 page for-pay document on the subject. Again, you're showing your complete lack of research.
    \Bill Burke\

    For once I'll let the subtle shift from the original subject to something more palatable to you stand :-) I'm sure you won't believe me, but I have researched this stuff in-depth. And it's entirely possible that I haven't found all documentation on the subject - I am only human, and can only do so much checking, and spend so many hours (so many, many hours) tracking this sort of thing down. If the little scraps I've found are sometimes contradictory, and some of it has evaded 3 or 4 hours of searcing, I suppose that is indeed somehow my fault.

    \Bill Burke\
    Snapshot isolation solves the C and I of ACID since a snapshot is created from the "real" data. Databases like Firebird and McKoi are the two examples I can think of that use this pattern. Since every transaction gets it own snapshot of the "real" state, Consistency can be maintained since on TX rollback the snapshot is just thrown away, and isolation is maintained because the tx is working with a snapshot and no other transaction sees this snapshot.
    \Bill Burke\

    I'm aware how snapshots work in general, and I thank you for documenting the details of how TxCache does this. It would be useful, I think, if this was documented explicitly in the TxCache docs.

    \Bill Burke\
    Optimistic locking allows you to have high concurrent access with no locking. Great for read-mostly datastructures. Pessimistic locking can protect access to a single shared instance, but we don't actually use it for this purpose in our caching since snapshots are always taken.
    \Bill Burke\

    I understand this from an RDBMS perspective, in particular when an app server is accessing a possibly shared database. It doesn't make as much sense to me for in-memory objects, particularly in a non-clustered environment. The locks here just don't have as high a cost as a database lock. In a clustered environment the cost of course can go up. Clustered, it comes down to deadlocks vs. optimistic lock exceptions.

    As and aside, all of this informationo you're presenting may be crystal clear to you, but it's not nearly so clear when an outsider is trying to find it out. The relationship to TxCache and other Aspects to the rest of the larger JBoss code base is not at all clear in the docs, and I don't happen to carry a semantic map of all of JBoss in my head.

    This wouldn't matter very much if we were talking J2EE, because people can always go back to the spec to figure much of it out. In areas such of this, outside of the spec, we have to rely on the vendor to document behavior.

    \Bill Burke\
    We're not talking Data objects here. We're talking plain pojos. As long as there is one member in the cluster alive, then any new members of the cluster will receive all replicated data. Most of this guarantee and consistency of data is done by JavaGroups as it has strict protocols for group membership and state synchronization. Our EJB cluster implementation has relied on these for quite some time now. I'll be happy to explain further on these features if you like.

    [...]

    Do you really not know what ACID means? Consistency has nothing to do with durability. Durability just states that the data is available in the event of a failure and restart. Consistency means that a rollback is possible.

    Again, since you can listen to cluster membership change events with JavaGroups, we're pretty much good-to-go as long as one member of the cluster stays alive.
    \Bill Burke\

    This goes to the heart of the matter - what does it mean to be ACID, and what does it mean to be transactional? In a non-clustered environment, by far the most common one out there, there is no durability here. This isn't good or bad, but it's a very important thing to know if you're going to be using it.

    As for Consistency - consistency does not mean that rollback is possible. That's covered by Atomic. In an RDBMS sense, consistency means the backing store does not get screwed up, ever - and most particularly, does not get screwed up in the face of failures. Consistency means that if your server blows up, when you get it back all commited stuff will be there and there won't be any corruption. This ties in directly to Durability - the guarantees you get as to when stuff is saved durably, and when it's transient. Consistency modifies durability by saying not only must stuff be saved at preditable points, but you have to save stuff in such a way that you don't have inconsistent state or outright corruption if you go down. By your description, consistency is available only if you're in a cluster. In a non-clustered environment, it sounds like if your server is bounced, your cache is gone. This is not consistent or durable - the committed data is gone.

    \Bill Burke\
    I talk about all this stuff in the doco. Go read it again. I even give a simplified algorithm on what happens at commit time with the replicated cache. That's just my stuff. Bela has a much better design guide in our CVS under jboss-head/cache/docs:
    \Bill Burke\

    I think I've read your documents quite enough, thank you. But thank you for the pointers to Bela's stuff, I'll take a look at it. If it's as good as most of Bela's other pieces, you might want to consider promoting it to documentation more readily available on the site.

        -Mike
  23. On ACID....[ Go to top ]

    \Bill Burke\

    > I talk about all this stuff in the doco. Go read it again. I even give a simplified algorithm on what happens at commit time with the replicated cache. That's just my stuff. Bela has a much better design guide in our CVS under jboss-head/cache/docs:
    > \Bill Burke\
    >
    > I think I've read your documents quite enough, thank you. But thank you for the pointers to Bela's stuff, I'll take a look at it. If it's as good as most of Bela's other pieces, you might want to consider promoting it to documentation more readily available on the site.

    Thanks for the comments Mike ! But don't go and read the docs in cache/docs yet. I'm in the process of creating a standalone version of the cache and will provide good documentation on it. The docs in cache/docs are just bits and pieces, and in some cases, outdated.

    Regards,
    Bela
  24. On ACID....[ Go to top ]

    I've read through the source in some more detail, and having gone through particularly through DistributedPOJOState I think I have a better idea of what's going on. In particular I have a better idea of the invocation chaining that's involved, but also a somewhat better insight into the locking mechanism used.

    But this has lead to a question. Given the Optimistic locking policy and snapshots involved, what is the result of this sort of operation (using the example from the AOP page):

      thread 1
      --------
          // Assume address.city is "New York", and address.state is "NY" right now.
          tm.begin();
          person.age = 32;
          address.city = "Patterson";
          address.state = "NJ";
          person.hobbies.add("fishing");
          tm.commit();
          // address.city is now "Patterson", state is "NJ", age is 32.

      thread 2
      --------
          tm.begin();
          String city = person.city; // #1 - reading city

          // #2 - Do something somewhat time consuming

          String state = person.state; // #3 - reading state
          // #4 Do something with city/state.
          tm.commit();

    In the above example, imagine thread #2 has read the city (marked #1), and is now in #2 (doing something time consuming). Everything has been read-only up to this point. Thread #1 now comes in, sets age, city, and state, and successfully commits. Now thread #2 comes back to the fore, reads person.state, and does something with city & state.

    Here's the question: what are the values of city and state within thread #2? Are the values a) "New York NY", b) "Patterson NY" (inconsistent state), or c) does thread #1 or thread #2 get whacked with an exception?

    Looking through the code, it's difficult for me to tell. Read operations seem to only acquire a read lock while reading, then release it, all within the method call itself. There doesn't seem to be read-only version correlation so that you don't get a) (with thread #1 presumably paused until thread #2 is done). And for the same reason you don't seem to get c). It looks like you get b).

    The heart of the question is: how does read-only operations in one thread interact with update operations in another thread, both within a transaction? Reading the code, and the fact that you state that single-VM installations can't get a deadlock exception, would lead me to believe that read-only operations can end up reading inconsistent state, because the object equivalent of row-level (object level I suppose) locking isn't used. This could work if once a version is read, all future reads are forced into the same version, but I don't see that in operation here (but perhaps it is and I've missed it).

        -Mike
  25. On ACID....[ Go to top ]

    Mike,

    even for oversimplified example, you better
    include object reading into transaction. You can not expect
    any useful outcome from updating if TX manager does not
    aware of object. I think that Burke suggest snapshot izolation
    upon transactional READ and all subsequesnt reads will be
    against this snapshot (separate for every TX).

    In you example, it must be (by theory) something like famost:
    ORA-08177: cannot serialize access for this transaction

    Another question (not directly connected with JBoss implementation):
    what happenning (must happen) with lazy loaded attributes.
    Will transactional snapshot include all subordinate objects
    (e.g., state or phone)???

    Thanks,

    Alex V.
  26. On ACID....[ Go to top ]

    \Alex V\
    even for oversimplified example, you better
    include object reading into transaction. You can not expect
    any useful outcome from updating if TX manager does not
    aware of object. I think that Burke suggest snapshot izolation
    upon transactional READ and all subsequesnt reads will be
    against this snapshot (separate for every TX).
    \Alex V\

    I'm with you. My comments were based on limited reading of the source code - there seemed to be a disconnect, but I haven't exhaustively read the code, so there's a high percentage chance that I just missed something. I think most people (myself included) don't have much trouble with general transaction concepts. But to some extent what JBoss is attempting with things like TxCache is somewhat new, and there may be quirks (designed or accidental) that I'd like to know about.

    \Alex V\
    In you example, it must be (by theory) something like famost:
    ORA-08177: cannot serialize access for this transaction
    \Alex V\

    Something like that, or also possibly something like dirty reads.

        -Mike
  27. On ACID....[ Go to top ]

    Mike,

    Now I got an aproximate idea:
    http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projects/jboss/aop
    ...and why you example did not start from read/create -
    because JBoss does it BEFORE (?!?) start of transaction
    (see my comment below)...

    My first impression about TxCache:

    1. What is the use of "transactional" object in the cache
    without any transaction? cart before horse? It can be
    of some advantage if there expected to be several subsequent
    TX and a programmer is lazy to write code to register
    the object for every new transaction. But this is
    "usual practise". The object reference can come
    from various sorces and it can be "registered" or not-"registerd"
    with TxCache.

    2. I suggest just incorporate TxCache functionality as
    implementation of transaction manager - objects are to be
    moved to TxCache UPON (just in time) read/create within transaction.
    AFAIU - the object/attributes are interseptable, so it can be done(?)

    3. What happend if somebody wants to remove the object from cache
    while another thread doing TX with the object? What if the limit
    is reached and ALL 100 objects are in transactions?
    Or it is not-thread-safe bag?

    4. Is TxCache commit will immediately push data to datastore?

    Thanks,

    Alex V.
  28. On ACID....[ Go to top ]

    Alex: Another question (not directly connected with JBoss implementation):
    what happenning (must happen) with lazy loaded attributes.
    Will transactional snapshot include all subordinate objects
    (e.g., state or phone)???


    It can be argued that a serializable isolation level has to either make a snapshot of the complete database when a transaction starts (or act as if it has), or it can keep read/write dependencies layered such that the commit of other transactions (or even rollbacks, if the uncommitted state of the data from another transaction were used) will cause the transaction to be marked as rollback-only.

    Serializable transactions are implemented in startlingly different manners by different databases. The definition of the isolation level is that the result of concurrent transactions is the exact same as the transactions being run one after another (serially). That means that it appears to the the "client" to be a system that no one else is using, and if that assumption is in any way incorrect, the client should receive an exception (e.g. the transaction should be marked for rollback).

    Note that a read-committed isolation level does not have any such requirements.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  29. On ACID....[ Go to top ]

    Cameron,

    Looks like TxCache is "trying" to be intermediate buffer
    between real datastore and application. With this, it is
    hard to talk about "serialization" on TxCache level.
    What if real datastore is updated (independantly)
    while object is in TxCache? I hardly belive TxCache is
    in constant synch with datastore.

    (Cameron, I am aware of your specialization to keep
    data in-synch ABOVE database :-)

    Alex V.
  30. On ACID....[ Go to top ]

    Alex: Looks like TxCache is "trying" to be intermediate buffer
    between real datastore and application. With this, it is
    hard to talk about "serialization" on TxCache level.
    What if real datastore is updated (independantly)
    while object is in TxCache? I hardly belive TxCache is
    in constant synch with datastore.


    If the cache is a database cache, then you would usually want to avoid the database being updated through anything but the cache. (I say "usually" because there are a few cases in which applications can tolerate out of sync data by using something akin to BPM to route conflicts through automated resolution handlers, and only failing that will resort to manual correction. It's a very interesting problem, but a necessary one to solve for most geographically distributed applications that can suffer occasional disconnects yet cannot stop processing.)

    However, I do not know the full background behind the TreeCacheAOP impl in JBoss, as to the requirements or the thinking behind it. It may be intended as a largely "transient" (in-memory) transactional data store, which is also a handy idea (which put things in the database when you need them -- and only need them -- in the cluster of app servers?)

    Anyway, I just started last night trying to catch up on the work Bela has been doing on it, but it's a lot of code, so it's like starting from scratch for me to understand it.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  31. On ACID....[ Go to top ]

    Looking at the design doc references that Bill Burke posted, there seem to actually be three seperate beasties in the discussion:

       - Tree Cache. A very ambitious caching mechanism with lots of docs.
       - Tree Cache AOP. A nebulous creature that seems to be an AOP version of Tree Cache.
       - TxCache - the stuff discussed on the JBoss AOP page.

    TreeCache appears, for all the world, to attempt to do the stuff that Coherence does. Lots of options (async, sync, read_dirty=true, read_dirty=false) and apparently it is a front-end to a datastore (this is explicitly discussed). Impact on ACID properties are discussed in detail.

    TreeCacheAOP appears to be AOP enabling of TreeCache, or possibly a parallel implementation of it under AOP. I couldn't find much on that.

    TxCache is what is actually available under JBoss AOP (along with QueuedTxLock). The docs are again nebulous, but towards the end of one there are comments that locking via AOP is problematic somehow, and that a versioned scheme might be usable w/ optimistic locking. This appears (somewhat) to be what TxCache does, but I don't see a strong relationship between it and TreeCache. Bill's comments about a TxCache's contents not being DataObjects seems to underscore this to an extent. In addition, it does appear for all the world that the read mechanism might not be atomic across a transaction (e.g. multiple reads don't look to be guaranteed to pick up the data from the same object version - versioning appears to be done as data is read or written).

    In any case, most (all?) of the extended TreeCache documentation and information doesn't appear to be applicable to TxCache, and I'm back to my original questions re: ACID.

        -Mike
  32. On ACID....[ Go to top ]

    TreeCacheAOP appears to be AOP enabling of TreeCache, or possibly a parallel implementation of it under AOP. I couldn't find much on that.


    The AOP version is just an automation of the TreeCache where CRUD operations are detected automatically. Another way to do that is JPDI.
  33. On ACID....[ Go to top ]

    "The AOP version is just an automation of the TreeCache where CRUD operations are detected automatically. Another way to do that is JPDI."

    What is the relationship between TxCache and the AOP version of TreeCache?

         -Mike
  34. On ACID....[ Go to top ]

    thread 1

    > --------
    > // Assume address.city is "New York", and address.state is "NY" right now.
    > tm.begin();
    > person.age = 32;
    > address.city = "Patterson";
    > address.state = "NJ";
    > person.hobbies.add("fishing");
    > tm.commit();
    > // address.city is now "Patterson", state is "NJ", age is 32.
    >
    > thread 2
    > --------
    > tm.begin();
    > String city = person.city; // #1 - reading city
    >
    > // #2 - Do something somewhat time consuming
    >
    > String state = person.state; // #3 - reading state
    > // #4 Do something with city/state.
    > tm.commit();
    >
    > In the above example, imagine thread #2 has read the city (marked #1), and is now in #2 (doing something time consuming). Everything has been read-only up to this point. Thread #1 now comes in, sets age, city, and state, and successfully commits. Now thread #2 comes back to the fore, reads person.state, and does something with city & state.


    With pessimistic locking (implemented in TreeCacheAop):
    - thread #1 is first
    - thread #1 acquires W lock on person.age
    - thread #1 acquires W lock on person.address.city
    - thread #1 acquires W lock on person.address.state (no-op since already owned)
    - thread #2 blocks on acquisition of R lock for person.address.city
    - thread #1 acquires W lock on person.hobbies, adds "fishing"
    - thread #1 commits, replicates all values. If successful, writes values back to POJO, otherwise no-op. thread #1 releases all locks.
    - thread #2 unblocks and acquires R lock on person.address.city
    - thread #2 proceeds


    With respect to optimistic locking (I didn't write this code so bear with me wrt details):
    - thread #1 is first
    - thread #1 acquires W lock on person.age. Since there is no workspace associated with the TX, a new workspace is created, and person copied to it (including address and hobbies). Deep copy afaik
    - thread #1 releases W lock on person
    - thread #2 acquires accesses person and copies it to workspace
    - thread #1 commit. Changes are replicated and (if successful) workspace is written
    back to POJO. (includes temporarily locking POJO)
    - thread #2 commits. The version check ID shows that somebody modified person after thread #2 created its private workspace. (This is not the case for thread #1) Therefore this will throw an exception and rollback the TX.




     
    > Here's the question: what are the values of city and state within thread #2? Are the values a) "New York NY", b) "Patterson NY" (inconsistent state), or c) does thread #1 or thread #2 get whacked with an exception?

    c) It will be whacked.

    Bela
  35. On ACID....[ Go to top ]

    thread 1

    > > --------
    > > // Assume address.city is "New York", and address.state is "NY" right now.
    > > tm.begin();
    > > person.age = 32;
    > > address.city = "Patterson";
    > > address.state = "NJ";
    > > person.hobbies.add("fishing");
    > > tm.commit();
    > > // address.city is now "Patterson", state is "NJ", age is 32.
    > >
    > > thread 2
    > > --------
    > > tm.begin();
    > > String city = person.city; // #1 - reading city
    > >
    > > // #2 - Do something somewhat time consuming
    > >
    > > String state = person.state; // #3 - reading state
    > > // #4 Do something with city/state.
    > > tm.commit();
    > >
    > > In the above example, imagine thread #2 has read the city (marked #1), and is now in #2 (doing something time consuming). Everything has been read-only up to this point. Thread #1 now comes in, sets age, city, and state, and successfully commits. Now thread #2 comes back to the fore, reads person.state, and does something with city & state.
    >
    >
    > With pessimistic locking (implemented in TreeCacheAop):
    > - thread #1 is first
    > - thread #1 acquires W lock on person.age
    > - thread #1 acquires W lock on person.address.city
    > - thread #1 acquires W lock on person.address.state (no-op since already owned)


    Correction, of course the W lock has to be acquired on person.address, not on the individual fields.
    Bela
  36. On ACID....[ Go to top ]

    \Me\
    Here's the question: what are the values of city and state within thread #2? Are the values a) "New York NY", b) "Patterson NY" (inconsistent state), or c) does thread #1 or thread #2 get whacked with an exception?
    \Me\

    \Bela\
    c) It will be whacked.
    \Bela\

    Is this true in the case of thread #2 if thread #2 turns out to be read-only WRT the transaction?

    Also, is versioning per field or per object?

    I get the pessimistic locking side, this make sense. But I'm also confused by the whole

       cache/src/org/jboss/cache/TreeCacheAOP
    vs.
       aspects/src/main/org/jboss/aop/versioned

    ...thing. The AOP page references stuff in aspects/src/..., but not cache/src (and nothing in aspects/src seems to refer to anything over in in cache land). Poking about seems to show that TreeCacheAop is about replicating state, and also seems to get transactions via the parent class TreeCache. TxCache seems to be doing much of the same thing, but doesn't use any of the TreeCache stuff even though much of the guts appear to be identical in function (if not in internal structure).

    Part of my problem may be the splitting headache I have from tracing the various interceptor chains in TxCache, of course :-/ Plus the large numbers of objects each Advisable object in cache seems to require in that implementation.

         -Mike
  37. On ACID....[ Go to top ]

    Hi Mike

    > Is this true in the case of thread #2 if thread #2 turns out to be read-only WRT the transaction?

    Yes - I think so. Note that in TreeCacheAop we will have optimistic locking further down the road, and there you can enable dirty reads, so your statement above would be true.


     
    > Also, is versioning per field or per object?

    Per object.

     
    > I get the pessimistic locking side, this make sense. But I'm also confused by the whole
    >
    > cache/src/org/jboss/cache/TreeCacheAOP
    > vs.
    > aspects/src/main/org/jboss/aop/versioned
    >
    > ...thing.


    There is no connection between TreeCacheAop and TxCache (yet). We want to take some of the ideas of TxCache and integrate them with our TreeCacheAop once we implement optimistic locking.

    Bela
  38. On ACID....[ Go to top ]

    Thanks for the responses. In retrospect, and even more headaches and staring at code, I believe what truly through me off was that it looks like a acquireReadLock() is called on every field read, and acquireWriteLock() is acquired on every field write (and each respectively is released before the field read/write interceptor completes, so the locks are quite ephemeral). The locking lead me to believe there was more work going on per read then actually appears to be the case. It'd be interesting to see performance and memory requirements numbers for various cases using TxCache.

    \Bela Ban\
    There is no connection between TreeCacheAop and TxCache (yet). We want to take some of the ideas of TxCache and integrate them with our TreeCacheAop once we implement optimistic locking.
    \Bela Ban\

    Does this mean TxCache is effectively lame duck code, or will it just live on with TreeCacheAOP guts in the future?

        -Mike
  39. On ACID....[ Go to top ]

    \Bela Ban\

    > There is no connection between TreeCacheAop and TxCache (yet). We want to take some of the ideas of TxCache and integrate them with our TreeCacheAop once we implement optimistic locking.
    > \Bela Ban\
    >
    > Does this mean TxCache is effectively lame duck code, or will it just live on with TreeCacheAOP guts in the future?

    It is a nice use case for a *local* transactional cache. No support for replication. We can probably copy the code 1:1 to our TreeCacheAop once we get to optimistic locking. The important thing here is that we believe the lessons learned from TxCache will lead to a better design for the latter.
    Bela
  40. TxCache Diving[ Go to top ]

    It so happens that I'm bored tonight and have nothing better to do (a sad comment, I know), so I decided to run through all the TxCache with some discipline to really figure out what it does.

    My findings don't quite match the postings here. This is based off of the CVS Head that I downloaded a few days ago, most files are dated July 8th or earlier (except for DistributedTxCache, which I haven't looked at).

    First the summary, then the running commentary on what's happening. Only the truly die-hard will read the running commentary, I figure.

    Summary:

       - Versions are indeed held per field.
       - Each object has one global "workspace", which holds all the per-field workspaces.
       - workspace creation is triggered on the first _update_.
       - read operations never create a workspace, but they may access it
       - It looks like if a transaction has started, reads will break (unless
         someone's written first).
       - Dirty, inconsistent reads look quite likely, especially if you read
         first in your tran, then write, then read some more.
       - There's two sets of stuff: DistributedXXX, and VersionedXXX. Following from TxCache, it looks like only the DistrubtedXXX stuff gets used.
       - The Versioned stuff looks unused. Maybe it was used in DR2 but got switched around in the cvs head? I dunno. The Versioned stuff is indeedy one version per object, not per attribute.
       - My headache has come back and re-trebelled, so perhaps I've misread it all, and wasted my time.

    Running in-depth Commentary:

    Details are of course seriously truncated from the full code reality...

    On insertion into a TxCache, DistributedVersionManager.makeVersioned() is called. In summary this does the following:

      - Initializes a DistributedPOJOState object one to one
      - Adds in the StateChangeInterceptor against the DistributedPOJOState object.
      - Foreach field:
         - Check if the field is advised. If so, recurse
         - Add field to DistributedPOJOState's fieldMap. The field is now represented as a DistributedFieldUpdate object.
      - Add the set of newly created objects (can be multiple due to the recursion) to the LocalSynchronizationManager.

    The StateChangeInterceptor is the "interceptor" that intercepts field reads and writes, and forwards them to the DistributedPOJOState manager instead.

    The DistributedFieldUpdate object holds the initial value, a version, an index. As mentioned above, there is one of these suckers per field. Additionally, the value held here is replaced with a VersionReferenced object.

    On interception of a field read, the following happens:

       - a read lock is acquired. This effectively locks the enclosing Object (actually, the DistributedPOJOState guy, but the effect is the same).
       - We check for a TX state. If we see it, we use a fieldMap (a map to fields) from what looks like a ThreadLocal. Otherwise, we use the default fieldMap embedded in DistributedPOJOState.
       - Return the value we get from the map (which in turn gets it from DistributedFieldUpdate).

    On interception of a field write, the following happens:

       - We make sure the field is "versioned" as per the initial cache insert.
       - We check for a transaction.
        - If there's none:
          - aquireWriteLock
          - Get the DistributedFieldUpdate thing, update the field and the version
          - releaseWriteLock
        - If there is a transaction:
          - acquireReadLock()
          - register us for synchronization with the Transaction Manager.
          - look for map info in the thread local (our object workspace)
           - if none
             - create one, add it to the presumed ThreadLocal
             - create the workspace for this field, set the update in that workspace
             - Add this field workspace to the ThreadLocal workspace
           - if there is a map info thread local (object workspace)
             - set the update in this field's workspace
             - add this field workspace to the ThreadLocal workspace

    Note that only updates get recorded in the "workspace" - no copy exists of the original fields.

    At transaction commit:

      - beforeCompletion:
         - acquireWriteLock()
         - checkOptimisticLock() - this checks the workspace versions against the original versions (the original fieldMap in DistributedPOJOState).
         - if mismatch in the above, throw an OptimisticLockFailure exception.

      - afterCompletion:
         - move all of the workspace updates back into fieldMap in DistributedPOJOState.

    There's also a whole bunch of VersionedXXX classes, but these don't seem to be used at the moment. Or maybe I'm missing a whole 'nuther Interceptor stack somewhere.
  41. TxCache Diving[ Go to top ]

    Come on, Mr. Burke, this is a ready-made cue for you to tell me "that you have done absolutely no research what-so-ever on any of the topics we're discussing and that you rely on TSS as the basis for all your knowledge about JBoss (and probably other subjects)". This is yours and Mr. Fleury's big chance to simultaneously show how wrong I am, and show just how transparent your system aspects are to developers. To explain to the world that, from just one example, you don't hold seperate versions for each field, and don't have serious dirty read problems, and invalid read-only accesses under transactions, or that you don't allocate 6 objects per advisable object in a cache (plus 2 per field!), and even more within a transaction (around 3 per advisable per tx, plus an extra 1 or 2 per field).

    I've presented my own take on the existing TxCache code, and expressed my bafflement at the plethora of other closely related cache code that either isn't advertised, or doesn't appear to be used. What say _you_, gentlemen? The marketing and web site docs and various posted claims have been stripped away, and now we're down to the nitty gritty of the actual code. So what say you?

            -Mike
  42. Informative silence[ Go to top ]

    Silence is rarely informative, but this would be such an occasion I believe. Thanks for the dive Mike.

    /Rickard
  43. Informative silence[ Go to top ]

    My pleasure, Rickard.

    What really gets to me is conflicting info from various JBoss people - most often Bela and Bill Burke, but often others as well. Diving through code is a pain, and correlating various documents is tedious, but trying to reconcile 2 or 3 people offering radically different views of how something works now, and will work in the future, all of whom are authoritative in some way, just can't be done by the likes of me.

    In this case, I'm clueless as to which vision presented here - Bela's or Bill Burke's - will actually come to fruition (or, possibly, neither).

        -Mike
  44. Informative silence[ Go to top ]

    My pleasure, Rickard.

    >
    > What really gets to me is conflicting info from various JBoss people - most often Bela and Bill Burke, but often others as well. Diving through code is a pain, and correlating various documents is tedious, but trying to reconcile 2 or 3 people offering radically different views of how something works now, and will work in the future, all of whom are authoritative in some way, just can't be done by the likes of me.
    >
    > In this case, I'm clueless as to which vision presented here - Bela's or Bill Burke's - will actually come to fruition (or, possibly, neither).
    >
    > -Mike

    Get a life guys. Not everybody can be the top TSS poster for the week. I answered your cache questions in detail within the "Hibernate joins JBossGroup" thread.

    Bill
  45. Informative silence[ Go to top ]

    \Bill Burke\
    Get a life guys. Not everybody can be the top TSS poster for the week. I answered your cache questions in detail within the "Hibernate joins JBossGroup" thread.
    \Bill Burke\

    After a significant amount of pushing, yes. Would you have answered here if I hadn't pushed in the "Hibernate joins JBossGroup" thread? It's fairly obvious you would not have.

       -Mike
  46. Well said Mike.[ Go to top ]

    <Mike>
    In case Bill and Marc et al were wondering, this is why JBoss gets so much resistance from a select group of people. It's not because of technology, it's not because of bugs, it's not because of sexiness or lackthere of, it's not because of perceived risk taking. It's because you play fast and loose with language, and no one can get a straight answer out of you. Sane people don't trust what they don't (and can't possibly) understand.
    </Mike>

    I have always wanted to get that abstract thought out of my head and put it into concrete words. I think, Mike, you have described it well.

    As a JBoss (3.x) fan and long time supporter of the JBoss project, I have nevertheless felt there was something amiss in the project's sometimes ambiguous positioning. There is, in my personal perception, a certain lack of precision that I've always associated with a number of the JBoss tech discussions.

    A J2EE server is not just any piece of software. For most large Java-based applications, it is the piece of software. I think I will wait for the dust to settle before I move on to JBoss 4.

    Sandeep
  47. EJBs not AOP[ Go to top ]

    In general, Mike's comment is well said. Consistency, however, requires the preservation of application specific invariants, ie, it also places a burden on the application (and container, since in J2EE the container subsumes some of the role the application played in pre-existing transaction models like DTP or OSI TP).

    As to Cameron's point about durability, the conventional expectation is that the results are made "permanent" outside of catastrophic failures (like disk crashes), which is a little different than "available". Purely volatile storage is probably not a good idea if you are really trying to provide ACID guarantees. Of course, some applications can tolerate relaxation of ACID properties or may require other transaction models altogether.

    Greg
  48. EJBs not AOP[ Go to top ]

    \Bill Burke\

    > It is not a mistake. EJB is a good analogy of AOP concepts that people understand. EJB is a perfect example of separation of concerns. The concerns being transactions, security, and persistence. Sure, you're limited to those aspects and limited to only applying them to classes that implement and extend EJB interfaces/classes. But you're applying aspects implicity to an existing object model.
    > \Bill Burke\
    >
    > You're missing a fundamental point of AOP here. EJB code...:
    >
    >    - declares specialized interfaces explicitly
    >    - Has explicit knowledge that it is being managed, and (to an extent) how
    >    - Can access and modify the transaction/security/persistence information
    >
    > To say that in a shorter way - the code the developer is writing is written with full awareness that it's part of a transaction (or persistence, or what have you). The "full awareness" part is the key - you know you're part of a larger lifecycle. The writer of an EJB component has to follow very strict rules when they're doing so.
    >
    > Because of this, EJBs are nothing like AOP at all, because the code in question is fully aware of the container services, knows its in a container, can affect what happens to it within the container, and has to be written to a very specific contract.
    >
    > And once again - if you think EJB are a good analog to AOP,then you really, really don't get AOP (really!).
    >
    >     -Mike

    When explaining a new concept to somebody you need to build a bridge between what the student knows and what you want to teach them. EJB is a good analogy because it has separation of the concerns of transactions, security, and persistence. EJB attempts to separate system-level constructs from the underlying application code. Most EJB developers see this separation as a good thing. Again, building bridges between what the student knows and what you want them to understand. EJB separates concerns on a static finite set of aspects. You show the student the object model(the Bean), the aspects( transactions, role based security, etc...), and the application/glueing of the aspects(ejb-jar.xml).

    Then you show them AOP. AOP is a generalized form of this. You have the plain class. Your aspects (written as interceptors or advices) and show them that you apply aspects via some pointcut language or XML binding. You explain to them that instead of having a finite set of aspects like in EJB land, you have an infinite set and they can applied to your classes in all sorts of intricate ways.

    You need to build bridges and the EJB analogy is a good one for our user community.

    Bill
  49. EJBs not AOP[ Go to top ]

    We are (hopefully) not students, but instead are professional software developers. And professional software developers who do understand EJBs, and perhaps know a bit about AOP, are going to see that the analogy breaks down very rapidly, most specifically in the absence of a contract. By saying that EJB was like an early form of AOP _grossly_ misleads people as to what AOP is actually about.

        -Mike
  50. EJB analogies[ Go to top ]

    Bill: It is not a mistake. EJB is a good analogy of AOP concepts that people understand. EJB is a perfect example of separation of concerns. The concerns being transactions, security, and persistence. Sure, you're limited to those aspects and limited to only applying them to classes that implement and extend EJB interfaces/classes. But you're applying aspects implicity to an existing object model.

    I tend to agree with Bill, that starting with an EJB analogy is one good way to discuss AOP. I am not an AOP expert in the least (I think it stands for "Already Over Promised"), but for those of you that are Certified AOP Experts, if EJBs do not provide a good place to start explaining concepts from, then use the example of an EJB to explain *why* it's not a good analogy.

    As for Bill and his measly six years of experience, or the fact that he used to work on CORBA, I personally think that bringing sh*t like that up in an argument is childish. Stick to the conceptual issues and the technical details. We've all got something to learn out of this.

    And Gregor, thanks for the thoughtful replies.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  51. EJB analogies[ Go to top ]

    \Cameron\
    I tend to agree with Bill, that starting with an EJB analogy is one good way to discuss AOP. I am not an AOP expert in the least (I think it stands for "Already Over Promised"), but for those of you that are Certified AOP Experts, if EJBs do not provide a good place to start explaining concepts from, then use the example of an EJB to explain *why* it's not a good analogy.
    \Cameron\

    I'm hardly a certified anything, at least not in the technical sense, but I'll give it a stab.

    A big problem with the analogy is that it leads many people down a very specific mental road which doesn't end up in AOP. People hear some stuff about AOP, and then they think of EJBs, and inevitably they say "Ah, AOP is about intercepting calls". Someone else says "Ah, it's intercepting and also decorating a class after the fact with extra 'implements' clauses". And that's where they stop. This is indeed where where the JBoss team appears to have stopped - they've taken the analogy a bit too seriously, and don't perceive where the analogy breaks down.

    There are differences in the mindset as well. As I've already mentioned, an EJB implies a contract, it requires you to implement interfaces, and it gives you hooks into the larger container enveloping you. This generates certain expectations, and pushes you towards doing things a certain way.

    An AOP approach, in contrast, doesn't put a contract in the component code. More often, it's the extra advice that's adding extra contracts to the component. Additionally, in full-bore AOP writers of the components are also writers of the advice and varoius point-cuts, and they write cooperating code between the code (such as making a component more amenable to access via pointcuts, or exposing things in a slightly different manner to make the advice's work easier). This generates a very different set of internal expectations, has a different feel altogether than doing EJB development.

    And, of course, in an AOP approach where you're not afraid of plain old programmers (POPs?) writing aspects, the POP is seeing both sides of the equation. In an EJB world, they are largely locked out from the container side - they are aware of it, and can affect it, but the effects are pre-determined and limited in nature.

    \Cameron\
    As for Bill and his measly six years of experience, or the fact that he used to work on CORBA, I personally think that bringing sh*t like that up in an argument is childish. Stick to the conceptual issues and the technical details. We've all got something to learn out of this.
    \Cameron\

    It would be nice if this would happen. But occasionally, when the discussion goes beyound just the technical, and people's personalities come to the fore, it sometimes makes sense to bring stuff like that into the discussion. When a relative novice tells a highly respected expert that the expert is all wrong, it sometimes pays to point out that the relative novice is what he is. Many people of varying experience levels have interesting technical ideas to add to the mix, but at the same time experience does play a part. Gregor has been researching AOP in-depth for nine years or so, and is the acknowledged expert in the field. This does not make him a God, or mean that he is infallible. But it does give a helluva lot of weight to his arguments. The man who has been there and done that for nearly a decade is going to have something interesting to say. At the same time, someone who blatantly attacks said expert, and has barely gotten their feet wet in the AOP arena, and who writes posts that sound like a particularly arrogant Chief Architect, occasionally needs to be reminded that perhaps he has a way to go before he's seen and done everything that someone like Gregor has.

    In an overly PC world, it may be unfashionable to point to a person's relative experience. And we all have something to learn, right up until we take our final breaths. And age does not equate to wisdom. But at the same time, you can make judgements in individual cases. This is a case where the experience disparity is IMHO entirely valid, and Bill brought it into play himself by making gross mistatements and attacking someone who obviously knows his business. And occasionally it saves everyone a lot of time to remind readers and posters the credentials on two sides of a debate.

    Is it childish to point out someone's relative inexperience? Perhaps. But at the same time - should we let someone rant on and bang our heads repeatedly against their ignorance, and meticulously avoid pointing out that ignorance and its source? Perhaps both choices are "evil" in some sense, but I also think there is a clearly a lesser of evils here. And so, I'd personally rather risk being called childish, call a spade a space, and maybe short-circuit a small number of ridiculous attacks and groundless assertions.

        -Mike
  52. EJB analogies[ Go to top ]

    In an overly PC world, it may be unfashionable to point to a person's relative experience.

    I wasn't trying to single out any comment in particular ... I was just hoping to see the conversation get a little less personally charged. I am still forming my own opinions on AOP and I really enjoy imagining some of the possibilities of new technologies such as this, and frankly I think Bill's work is helping to stimulate the discussion, whether everyone happens to agree with his approach or not.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  53. Merit or PR?[ Go to top ]

    I wasn't trying to single out any comment in particular ... I was just hoping to see the conversation get a little less personally charged. I am still forming my own opinions on AOP and I really enjoy imagining some of the possibilities of new technologies such as this, and frankly I think Bill's work is helping to stimulate the discussion, whether everyone happens to agree with his approach or not.


    Peace Cameron!

    I'm definitely with you on this.

    These conversations seem to gravitate towards the boundary between technological and promotional (personal, business, etc.) debate.

    Clearly there are business, as well as personal (read: egotistical), interests involved here -- and it is a shame, since we do not really want to repeat the J2EE pattern here again, do we? (e.g. rush-off with a 'me me me' solution before the major implications of the technology are well understood.

    On merit:

    Clearly the "academic" approach of AspectJ is more comprehensive, better researched, and more rigorous. I do however see the point in raising objections regarding static/dynamic enabling of this technology -- can we discuss this in a civilized manner, please?


    The JBoss "AOP" framework -- nice move there! It is "AOP" for marketting reasons, it is NOT AOP for IP (that nasty patent) reasons :) -- also has a few compelling features directly addressing the issues of component based applications -- the application is an object-graph, and quite analogous to EJB DDs, the orthogonal instructions inform/operate-on instances rather than classes.

    But it is not clear how this 'sub-set' of "AOP" is more enabling than the complete set other than the issue of class/instance, static/dynamic approach.

    Regarding the Visual/Programmatic approach ala "Minority Report": Surely the JBoss team recognizes the possibility of visual tools generating the AspectJ programmatic instructions?

    (Yes I do understand the visualization is of an object-graph -- but again, I wish to find out from the AOP -- the real pattented AOP -- experts whether an extension of the technology to operate on instances is possible or not.)


    Peace.
  54. Merit or PR?[ Go to top ]

    Well, it's interesting. Individuals here make technical assertions that are either wrong, or just simply have no basis. To exaggerate, they say the sky is silver-pink. Or they claim a standard or leading model with no references behind it. Or, as I mentioned, multiple posters from the same organization make conflicting claims, and again there's no reference to go to resolve it (other than the source code).

    And, strangely, that's OK. Few people call the JBoss folks on stuff like this. The few people who do, such as Rickard, are told they are being "personal" or attacking people, even when their posts are purely technical, and are making valid technical points. A surprisingly large number of people take JBoss claims on face value.

    And then, someone mentions that certain people are arguing from a context of fairly little experience, and _that_ upsets the TSS populace.

    Make wild claims with nothing to back them up - good!

    Attempt to refute those claims technical - bad!

    Make a statement of fact about an individual - worse! bad! childish!

    I'm not sure why, but the TSS community seems to cut JBoss people an enormous amount of slack, but for no apparent reason. I guess "Open Source" and "Java" and "fighting Sun" means that you're above reproach.

        -Mike
  55. Discussion / argument isn't bad[ Go to top ]

    Hi Mike -

    I don't want you to think that the "TSS populace" thinks that way. A lot of people are reading the great points that you (and others) come up with and you are making them think.

    Many more people are reading what is said, compared with the amount that are commenting.

    Keep up the good work.

    Dion
  56. Merit or PR?[ Go to top ]

    I agree with everything you say except the part about people cutting slack to JBoss folks. Bill Burke has been slapped around quite a lot on TSS forums.

    I think the JBoss people have earned their bragging rights. It's a high risk-high reward game. Remember, these are the people who showed us the power of JMX and now every vendor is adopting it. (they were proved right). With AOP, again, they are applying it as they see fit (they are users of AOP too, they just happen to be using it to build a system). Your complaint is "don't call what you are doing as AOP". Fair enough. A year from now, I would not be surprised if other system vendors use AOP exactly as they are using it. At that time, you can say "this is not AOP" and you would be right then too.
  57. Merit or PR?[ Go to top ]

    \code freedom\
    It's a high risk-high reward game.
    \code freedom\

    We're talking about a free product that has substantial amounts of code written for free by volunteers. Actual employees of JBoss Group appear to be spread around the globe, and communicate virtually. From what I can tell, a good deal of revenue is likely coming from contractors working on-site at various clients, with JBoss Group getting a cut.

    So it's very low overhead, lots of volunteer work, and lots of leverage to expand or cut back as need be. From a business perspective, the risk is amazingly low.

    Focusing just at the code base, I truly don't understand how you can imply risks are being taken. What exactly is the "risk" here?

    Don't get me wrong - there is some interesting stuff in JBoss. But there's not much that I'd consider as revolutionary as you do. Big chunks of it come from outside of JBoss. Much of the code is written against standard J2EE specs. Pieces like JMS have been brought in from the outside and altered over time. In many respects JBoss is a number of seperate pieces that have been fairly well glued together, not a monolithic base.

    On earning bragging rights - for me the jury is still out there. From a strictly technical perspective, it appears middle of the road to me. Pieces like JMS have been badly broken up to the 3.x levels. Severe lack of docs get in the way of learning about it. But also it does some interesting stuff in clustering, some interesting stuff with EJBs, and of course their core JMX engine is very interesting. But it's not what I'd call a slam-dunk, and I think you have to consider JBoss the code base, contributed to by a huge number of people, and JBoss Group the company, and where things are going to go in the near future.

    The legion of coders who have contributed to JBoss over the years certainly deserve accolades for the sum of the accomplishment. But things are changing. It appears that control of JBoss the code base is tightening. Bill Burke seems to be involved in all the major pieces to some extent. The CDN guys have defected and are forking the code. Marc F. shows many signs of trying to have JBoss less of a number of seperate components glued together admirably, and more of a single centralized base (I don't mean centralized in a technical sense or about modularity, but centralized in terms of control and ownership).

    I give full credit and bragging rights to all the developers out there who have made JBoss what it is today. But I don't think that that distributed credit should be given in equal weight to Marc and Bill.

    It should be interesting to see what happens. In the past, lots of people were behind JBoss, and in addition the focus was on implementing pre-defined specifications. Now a boatload of people have abandoned the effort, and in my opinion JBoss Group is attempting to consolidate control (technically and ownership wise). Indeed you see Marc F. urging people to put things directly under the JBoss umbrella, instead of seperate but integratable. And they are also moving out from pre-defined specs more into doing things truly on their own.

    They may succeed, but I rather doubt it. For one thing, when you don't have a J2EE spec to work from, to my mind you'd want to do some serious design work, but apparently marc/bill don't see much value in upfront design.

    \Code Freedom\
    With AOP, again, they are applying it as they see fit (they are users of AOP too, they just happen to be using it to build a system). Your complaint is "don't call what you are doing as AOP". Fair enough. A year from now, I would not be surprised if other system vendors use AOP exactly as they are using it. At that time, you can say "this is not AOP" and you would be right then too.
    \Code Freedom\

    Bad terminology, and bad "tagging" of technologies can have long-reaching negative effects. If (and I do say "if") the JBoss "AOP" attempt fails, they're going to put a big black stain on the concept AOP in general. And that will truly be ashame, particularly because what they're doing has little actual resemblence to what I'd call "real" AOP. You seem to believe they'll succeed - but please keep in mind, the context and situation has changed since "the power of JMX" days. Different industry situation, different employment environment, different attitudes toward J2EE, and most of all different people will be doing the work. As they say in my industry, past performance is not indicative of future results, and in this case much of the mental juice that brought JBoss where it is today has moved on to greener pastures.

        -Mike
  58. The Community[ Go to top ]

    Yes, some members of the community post ridiculous messages... such as the classic "I-am-the-100th-poster-of-this-discusson" one...

    ~C
  59. Merit or PR?[ Go to top ]

    Hi Mike,

    I think it becomes harder to address the technical merits directly (pro or con) when people think they are being attacked, or when the conversation "feels" personal. I get accused of being a JBoss backer (for example by my buddies at BEA) and I get accused of being a anti-JBoss FUD generator (for example by some of the JBoss Group + fanboys) ... and sometimes I even get accused of both for the same comments.

    But I don't feel like I have to be "pro JBoss" or "anti JBoss" to learn both the good and bad of their "AOP research work" (call it what you will ... prototyping or commercial implementation or research or production quality code). And it makes it easier for me to criticize or compliment the technical aspects (no pun intended) of their aspect-oriented work if I don't get personal on other aspects (such as Marc's ego or Bill's youthful impertinence ;-). And if what they say isn't exactly in sync, then that's a promising sign, because it indicates that they can think for themselves and hold different opinions on a subject, or that they are still forming their own thoughts. Personally, I'd be worried if my co-workers always agreed with me because that would definitely mean that someone had been 'serving the koolaid' (or coloured pills or whatever ... OK, OK, I'm just kidding ;-).

    I learn a lot by reading what other people are getting to play with, and this is no exception. I'd like to encourage Bill to keep playing with it, and you never know, he might get lucky and discover and/or build something very useful. It's just as likely that it'll be a rubbish experiment in the end. That's the way it is when you're trying to do something new -- but nothing ventured, nothing gained. As for the universal marketing and hand-waving that seems to have been perfected by some, well maybe I've just learned to tune it all out so it doesn't bother me as much as it should ... you could be right that the claims (to the unjaded) are dangerous snake oil.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  60. Merit or PR?[ Go to top ]

    Cameron, as usual much of what you say makes good common sense.

    I'll quibble on one point though (as it's my nature to do).

    \Cameron\
    And if what they say isn't exactly in sync, then that's a promising sign, because it indicates that they can think for themselves and hold different opinions on a subject, or that they are still forming their own thoughts. Personally, I'd be worried if my co-workers always agreed with me because that would definitely mean that someone had been 'serving the koolaid' (or coloured pills or whatever ... OK, OK, I'm just kidding ;-).
    \Cameron\

    In general terms I agree, but I think perhaps you're missing a point. In my opinion, a large degree of the disagreement and contradictions in postings from JBoss personnel stems directly from a lack of upfront design. I think the most design work being done for JBoss 4 is probably no more and no less than the disorganized postings you see here on TSS. Disagreements, arguments, varying viewpoints, those all happen. But there's also a flip side - is there a common ground that is agreed upon? In other words - is there an actual design that shows in general "the plan", and which everyone understands to some extent? Here, there fairly obviously isn't. Marc and Bill and various others are most probably disagreeing because they have no central plan beyond the glib marketing blurbs we've seen here. Certainly there is no true technical design that I've ever heard of or seen. They're just coding by the seat of their pants.

         -Mike
  61. Merit or PR?[ Go to top ]

    I get accused of being a JBoss backer (for example by my buddies at BEA) and I get accused of being a anti-JBoss FUD generator (for example by some of the JBoss Group + fanboys) ... and sometimes I even get accused of both for the same comments.

    Yeah, Cameron. Then just be honest. Tell them that you don't have technical points to make nor any insights to share. Tell'em that the only reason why you post here and in the many BEA and IBM etc newsgroups is simply to plug your signature.
  62. Merit or PR?[ Go to top ]

    <quote>
    Yeah, Cameron. Then just be honest. Tell them that you don't have technical points to make nor any insights to share. Tell'em that the only reason why you post here and in the many BEA and IBM etc newsgroups is simply to plug your signature.
    </quote>

    Andreas, I see where you're going, but I am not sure that plugging a signature is all that bad. TSS is almost like a virtual community, where frequent posters recognize each other based on the merit of their arguments and posts over a length of time. Cameron has mostly been non-partisan, objective and very circumspect in his posts. He offers a balanced, though sometimes non-commital, viewpoint. This is key in any discussion forum. So, more power to you, Cameron.

    Sandeep
  63. Merit or PR?[ Go to top ]

    Andreas, I see where you're going, but I am not sure that plugging a signature is all that bad.

    No problem, Sandeep. It was only an advice from me since he got bashed from all that many friends that it's time to tell'em the truth that the intention is to stamp any thread with his sig as many times as possible, regardless of the content. I'm sure they will understand that and will not disturb him further.

    I have no need for a sig, Cameron. Usually one or two sentences are enough for my enemies to call my product name. Thanks btw. ;-)
  64. Merit or PR?[ Go to top ]

    Andreas: Yeah, Cameron. Then just be honest. Tell them that you don't have technical points to make nor any insights to share. Tell'em that the only reason why you post here and in the many BEA and IBM etc newsgroups is simply to plug your signature.

    Something tells me that the humor was lost in the translation. Regarding "insights to share", you have to admit that my link to the "saddam camping" article is the highlight of the thread.

    As for the signature, if you'd like, I would be glad to help you build your very own signature. Start with a catchy phrase, for example: "SwiftMQ: When it Absolutely Positively Has to Get There". Or perhaps: "SwiftMQ: It's the Message, Stupid!" Or even: "SwiftMQ: There's SwiftMQ, and there's 'Not Exactly'". You'll need a parting salute, perhaps "Tschus!" (or the anglican "Cheers!" or the american "Dude!"). Put it all together and you have something like this:

    == for demo purposes only ==
    == do not try this at home ==

    Tschus!

    Andreas Mueller
    IIT GmbH
    SwiftMQ: When it Absolutely Positively Has to Get There!


    == end demo ==
    == disclaimer: this signature was only a test and this ==
    == message was not actually written by Andreas Mueller ==

    Now, save that off (markup included, but not the lines with "==") and make sure you add it to the end of every post you make. I suggest you select your own buzz-phrase, as the one I suggested sounds just like a certain large international company's own slogan and they might sue. Anyway, with your very own signature, people will know who you are, and not confuse you with all the other Andreas Muellers of the world. Plus, they can easily associate you with your company and its products, and they never have any doubt where you are coming from.

    I'm even thinking of patenting the whole signature concept. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  65. Clearly the "academic" approach of AspectJ is more comprehensive...


    I know you used scare quotes around academic, so I probably don't need to say this to you, but since this has come up a few times its probably worth saying...

    AspectJ is not academic. It was developed in industry, and has always had more industrial users than academic users. There are three books etc. etc. Reading the logs of aspectj-users at eclipse dot org will also give you a sense of this.

    In the beginning it was research technology, but not anymore. One thing I believe the AspectJ team showed is how to do that kind of research with nearly direct connection to early adopters in research.
  66. Clearly the "academic" approach of AspectJ is more comprehensive...

    >
    > I know you used scare quotes around academic, so I probably don't need to say this to you, but since this has come up a few times its probably worth saying...
    >
    > AspectJ is not academic. It was developed in industry, and has always had more industrial users than academic users. There are three books etc. etc. Reading the logs of aspectj-users at eclipse dot org will also give you a sense of this.
    >
    > In the beginning it was research technology, but not anymore. One thing I believe the AspectJ team showed is how to do that kind of research with nearly direct connection to early adopters in research.

    Dear Gregor,

    Certainly you have misunderstood me! The "scare quotes" were quoting the "academic" label thrown your way by a certain fan of Krzysztof Kieslowski. (Adopting original ideas seems to be a trend here, don't you think Gregor? :)

    http://www.kansascity.com/mld/kansascity/entertainment/movies/video_dvd/5374918.htm
    http://images.allposters.com/images/22/21_BLUE.jpg


    If I wanted to imply that _I_ found AspectJ an 'academic' exercise, I would try something else.

    I personally find it an excellent step in the right direction.

    Best regards.

    Peace
  67. (Yes I do understand the visualization is of an object-graph -- but again, I wish to find out ... whether an extension of the technology to operate on instances is possible or not.)


    Sure it is. As I see it, the issues are are about how to get the right balance between the flexibility of dynamic deployment and operating on individual instances, efficiency, static checking and comprehensibility. I believe the jury is still out on that. We have to look at how the whole spectrum of approaches to more dynamic approaches work out.

    As a sampler of ways to do it:

      - Use AspectJ, get dynamic deployment by weaving in the loader, and get per-instance aspects using a HashSet or something other collection together with if pointcuts or if statements in the advice.

      - Caesar (which is currently an academic system) has mechanisms to directly support dynamic deployment and per-instance aspects. Its designed as an extension to AspectJ, so that it keeps static typing etc.

      - and there are AspectWerkz, Nanning and JBoss too of course.

    Gregor
  68. (Yes I do understand the visualization is of an object-graph -- but again, I wish to find out ... whether an extension of the technology to operate on instances is possible or not.)

    >
    > Sure it is. [...]
    >
    > As a sampler of ways to do it:
    >
    > - Use AspectJ, get dynamic deployment by weaving in the loader, and get per-instance aspects using a HashSet or something other collection together with if point cuts or if statements in the advice.

    OK, thank you. So the issue is not a feasibility criterion -- AspectJ can be dynamic as well -- but merely an implementation tactic (with associated cost/benefits).)

    > As I see it, the issues are about how to get the right balance between the flexibility of dynamic deployment and operating on individual instances, efficiency, static checking and comprehensibility. I believe the jury is still out on that. We have to look at how the whole spectrum of approaches to more dynamic approaches work out.

    I do understand and appreciate the validity of what you are saying here in context of software 'engineering', but I think these issues should perhaps be approached a bit differently. I believe that AOP is fundamentally a software design paradigm, and not merely a software engineering one. (But perhaps I have misunderstood this.)

    I would like to propose the following suggestions, if you are receptive to it:


    Conceptually, the fundamental duality is not one of 'static vs dynamic' aspect orientation, but rather 'canonical vs contingent' aspect orientation.

    (The currently debated duality (Dynamic/static) seems, IMHO, to be an implementation (engineering) rather than a logical (design) distinction. (And I think this blurring of logical vs implementation considerations is not helpful.))

    Canonical is to be understood in the sense of 'conforming to orthodox or recognized rules' and/or 'reduced to the simplest and most significant form possible without loss of generality'.

    Contingent is to be understood in the sense of 'determined by conditions or circumstances not yet established'. (I refrain from using the term 'contextual' here, since clearly a 'canonical context' -- e.g. EJB's Transaction Context -- is a valid notion.)

    Lets take the prototypical scenario where Aspect orientation seems a natural fit to make things a bit more clear:

    1) The simple Figure Editor system, where you have the FigureEditor, FigureElement, Line, Point, etc. You wish to enforce display side effects of FigureElement positional modifications in a localized (modularized) manner, and do so by identifying a) the 'move' crosscut, and b) the advice to be applied, such as when FigureElement moves, update the FigureEditor display.

    This is a 'canonical'[*] concern: whenever a FigureElement (or sub-class) is repositioned, we wish to update the FigureEditor display.

    2) We have a need to monitor (trace, debug, etc.) a given call pathway between various components. (A specific FigureElement in a complex CAD model, for example.)

    This is a 'contingent' concern: We are merely concerned with a specific (subset of) FigureElement(s).

    Now certainly it is equally possible to enforce a canonical concern 'dynamically' as it is to do so 'statically'. (The former makes little sense, but it is certainly possible.)

    And it is _nearly_ equally possible to enforce a contingent concern 'statically' as it is to do so 'dynamically'. (The former approach would constrain us to the application of this contingent concern to static, or predetermined, object-graphs: For example, the EJB declarative transaction demarcation of a specific method of a given deployment of a given Component is a 'contingent' aspect applied statically.)

    [*] Of course the issue is a bit more complex (and interesting) in that there seems to exist the opportunity to apply the notions of canonical/contingent at each stage of the engineering process.

    For example, in general, it seems quite reasonable to assert that the updating of the display of FigureEditor after a 'move' operation is a valid 'canonical' advice. (Lets assume this occurs at the component development stage, and one way or another, the component designer identifies and codifies this canonical concern.)

    However, in a given application where FigureEditor and FigureElement components are used, it may be that it is possible to 'move' FigureElements not presently displayed in the 'view port'. In which case the application of the canonical advice (e.g. update display) without contingent considerations (there ain't nothing to update!) would be inefficient.

    An analogous example is that after having defined a 'canonical' concern regarding the refreshing of cached data in a forward layer of a distributed system, we would further wish to elaborate this concern with a 'contingent' advice regarding the futility of updating the subset of the cache data that is apparently of no interest to the client layer.

    ~

    I hope the above conveys the general idea behind what I am proposing, and lends support to my criticism of the prevalent debates on effectiveness and nature of "static vs dynamic" aspect oriented frameworks.

    I believe the issue is rather orthogonal and far more interesting.


    Peace.
  69. Here we go...[ Go to top ]

    A couple of comments on this stuff.

    Bill says:
    "
    So AspectJ's been around for 4 years so they have a very extensive point cut language. But that point cut language is described in an extension of Java. You have to compile it before runtime. The reason why JBoss 4 did not use something like AspectJ is that we wanted to do things dynamically at runtime. The caching stuff I talked to you about was a perfect example.
    "

    From AspectJ FAQ:
    "What about load-time weaving? Can I weave aspects at runtime?

    AspectJ 1.1 can weave binary aspects into classes in bytecode form. Hooked up to a class loader, this can weave class bytecodes after they are read in, before the class is defined by the VM. In the 1.1 release (or soon thereafter) we will provide a proof-of-concept class loader, but we expect most people will already have a custom class loader which they will adapt to invoke our weaver.

    Some have asked about only weaving particular classes specified at run-time. Aspects should work across an entire namespace, and problems will likely result from weaving some classes but not others. Also, it's confusing to specify crosscutting both in the aspect and in the list of runtime classes; the crosscutting specification should be in the aspect itself, where it can be processed by tools.

    And just to state the obvious: do not use bytecode weaving, at load-time or otherwise, to modify .class files protected by license, without permission from the licensor. "

    So, assuming that you're ok with actually compiling the code, there's not much of a difference here. Of course, if he instead of talking about weaving *mechanics* had talked about weaving *semantics* there's much more interesting differences, and it's a pity he didn't mention that.

    Bill says about AOP:
    "What you have is, you have a caller of a method, and the actual method-the logic of the method. And what aspect oriented programming is is about inserting objects in between the caller of the method and the actual method itself so that you can add specific behavior between the caller and the actual method.[...]"

    The above is the implementation of the framework side of things, and has very little to do with what AOP *is really about*. I can almost feel Gregor's pain when he reads this as the explanation for "What is AOP?".

    Bill says:
    "Some of the aspects we're writing are transactional objects, transactional cache. You can write a plain Java class, create an instance of that at run-time and insert it into our transactional cache and the state of that object will become transactional."

    The way this is done is, IMO, going to create quite unmaintainable messes in applications. As a developer you have no idea how it's supposed to work (unless you RTFS), and knowing whether an object is indeed transitively touched by this transaction magic is not going to be easy.

    Bill says:
    "Really, building an AOP framework is a lot easier than you think. If you think about it, that's why there're so many of them out there right now; it's because it's really easy to write.[blah blah bytecode blah reflection]"

    Again, he's focusing way too much on the internals of his particular implementation instead of adressing the main issues, which IMO have to do with the core concepts of AOP involving how pointcuts are made and getting reasonable weaving semantics.

    Bill says:
    "Somebody did a benchmark with our DR1 release with AspectJ and the performance was very similar. So with our DR2 release, we found we already in improved performance by a factor of 6 so that benchmark is going to prove in our favor."

    And the p-g contest is on :-) The really important thing to understand here, IMO, is not that JBoss AOP is as fast or faster than AspectJ, but that there is indeed a cost involved here, which means that you may not want to aspectize every single class in your application. Talking about things like that would be interesting. Talking about how fast JBoss AOP is compared to AspectJ isn't. IMO.

    Bill says:
    "Take the Red Pill."

    Rickard says:
    "Wake up"

    If Bill wants to evangelize about AOP then this interview is the worst kind of disinformation he could possibly achieve. I'm disappointed.
  70. Here we go...[ Go to top ]

    taking the red pill means waking up? :)

    <rickard>
    The above is the implementation of the framework side of things, and has very little to do with what AOP *is really about*. I can almost feel Gregor's pain when he reads this as the explanation for "What is AOP?"
    </rickard>

    Curious, where can i find a better explanation? don't know much about aop.

    tks.
  71. Here we go...[ Go to top ]

    Rickard,

    The points you make are extremely weak IMHO, more my way is better than your way, do you have any meat in what you say? What have you coded lately? Those that can code, those that can't talk. Where is the code? Get to work, we all know you are smart and have great ideas, but how about some code? These people from what I can tell are giving us code we can use, you are giving us pie in the sky vision with no implementation.

    Come on man, I know you are better than that. I used to read all your stuff on the original EJB mailing lists and always liked it. This stuff just does not seem like the real Rickard who used to talk about deep technology not semantics nit picky stuff.

    Arun
  72. Don't fall for that Rickard[ Go to top ]

    That's really low Patel.. Why should Rickard put up his code? The guy is trying to get his startup going.. He is working damn hard at it too..
    He is brilliant and it is about time he put it to use for his own welfare.. And he gives us enough. Read his blogs.. He comes up with great ideas and certainly makes me think, and opens my horizons.. So, get off your lazy ass and implement the damn code yourself.. If you can't, then, you deserve the likes of JBoss/BB's low quality, clueless AOP implementation..

    Rickard, don't fall for that.. That's the one thing they keep attacking you with.. If they had anything 1/10th as good as what you came up with, they wouldn't even share it with their mother.. The reason, most people do opensource or like opensource is that, most of them can't come up with anything original on their own, like you do, and they are just like bunch of sheep following the blind.
  73. Here we go...[ Go to top ]

    Hello Rickard,

    > So AspectJ's been around for 4 years so they have a very extensive point cut language. But that point cut language is described in an extension of Java. You have to compile it before runtime. The reason why JBoss 4 did not use something like AspectJ is that we wanted to do things dynamically at runtime. The caching stuff I talked to you about was a perfect example.
    > "
    >
    > From AspectJ FAQ:
    > "What about load-time weaving? Can I weave aspects at runtime?
    >
    > AspectJ 1.1 can weave binary aspects into classes in bytecode form. Hooked up to a class loader, this can weave class bytecodes after they are read in, before the class is defined by the VM. In the 1.1 release (or soon thereafter) we will provide a proof-of-concept class loader, but we expect most people will already have a custom class loader which they will adapt to invoke our weaver.
    >

    That part is just the lack of compilation it doesn't talk about purely non-intrusive system-driven insertions like bill is talking.

    TreeCacheAOP: It is the responsibility of the cache to insert it's interceptors (for state change) in POJO's. That dynamic behavior is not available with AspectJ or the classloading weaving you are refering to. It is in JB4.

    Monitoring: to be able to insert a monitor aspect in pojo (JMX or IoC controlled) at run-time, in the middle of execution, not at classloading time is a perfectly valid use-case for systems. You come in it, the server is not performing, you instrument the particular access point to your application and define the pointcut as being a particular method on a particular instance. It is run-time, not classloading run-time but real execution runtime.

    We talked with Gregor a bit about that feature, which we view as very relevant (dynamic insertion of aspects) and I believe it is a J2SE (*SE*) feature. A VM level feature.


    > The above is the implementation of the framework side of things, and has very little to do with what AOP *is really about*. I can almost feel Gregor's pain when he reads this as the explanation for "What is AOP?".
    >

    There is no need to invoke "Gregor-the-father-of-AOP", he is perfectly able to understand the non-invasiveness points and the dynamic instrumentation as being non-gimmicky. He said aspectJ couldn't do that in private discussions, but since he reads TSS as well, I will let him update us.


    > Bill says:
    > "Some of the aspects we're writing are transactional objects, transactional cache. You can write a plain Java class, create an instance of that at run-time and insert it into our transactional cache and the state of that object will become transactional."
    >
    > The way this is done is, IMO, going to create quite unmaintainable messes in applications. As a developer you have no idea how it's supposed to work (unless you RTFS), and knowing whether an object is indeed transitively touched by this transaction magic is not going to be easy.
    >

    That is incorrect. The 'mess' you are referring to is mess that is inherent in component assembly under transactional scope. Do you remember the early JBoss 2.x days ? (I do, they were fun when you were around ;) tons of people were using the REQUIRED tag in EJB and that let to graphs of objects being locked under transactional scope and thus single threaded access of the graph, which is not good. We moved to REQUIRED NEW by default and that magically went away.

    What that means is that transaction assembly is TRICKY INDEPENDENTLY of the surrounding technology (it is not an AOP problem, like it wasn't an EJB problem, it is an state assembly problem). Bill has gone the extra mile and provide various locking mechanisms that are being integrated in our cache and persistence layers, that supports optimistic locking and various fancy stuff.

    The bottom line is that graph isolation with transactional scope is a problem of *programming* and how we access state in systems, not an AOP problem. I argue that exposing that construct as "transactional aspect" like Bill has done in fact promotes the visibility of it for developers to deal directly with.

    Finally we support recursive instrumentation of the graph, transitive closure.


    > Again, he's focusing way too much on the internals of his particular implementation instead of adressing the main issues, which IMO have to do with the core concepts of AOP involving how pointcuts are made and getting reasonable weaving semantics.
    >

    1- how aspects are done is interceptors, you made that first implementation when you were working for me at telkel.

    2- the weaving semantics is an interesting problem, but not a fascinating one. I am still not convinced that the language (aspectJ) is the best way to specify pointcuts. I think it is very visual and have seen very interesting research done in Germany and IBM about UML2 assembly of aspects. You can say with you finger "here and here". Aspects as described above DO NOT REQUIRE any specification of pointcuts and weaving they are automated by the system, the cache inserts.

    > And the p-g contest is on :-) The really important thing to understand here, IMO, is not that JBoss AOP is as fast or faster than AspectJ, but that there >is indeed a cost involved here, which means that you may not want to aspectize every single class in your application. Talking about things like that would be interesting. Talking about how fast JBoss AOP is compared to AspectJ isn't. IMO.
    >

    Yes and no, JPDI already does that at a minimal overhead. I think that is a very interesting approach (AW and Alonso in research), I believe and I am working with Gregor to make sure we promote that feature to J2SE standard so it becomes a VM level feature so the java VM will look more like the C# VM. That work has to be done at Joshua Bloch's level imho.

    What you aspectize is driven by system design, what is persistent, what is remote, what is ACID, what is replicated etc and only these points are aspectized, there isn't much to discuss though, it is not like it is a 'trade-off' or a 'design desicion' just like doing JDO (which is an AOP candidate btw) says "I want these objects persisted" and that is what drives the decision.
     
    Speed is somewhat important and since most prod system we see are sitting at 10% utilisation and going down thanks to Moore's law it may become a moot point better left for academics and computational freaks.


    >
    If Bill wants to evangelize about AOP then this interview is the worst kind of disinformation he could possibly achieve. I'm disappointed.
    >

    Rickard with all due respect (and we do give you a lot) I would ask you elevate the debate and not spread disinformation yourself.
  74. Here we go...[ Go to top ]

    That part is just the lack of compilation it doesn't talk about purely

    > non-intrusive system-driven insertions like bill is talking.

    I read his comments a couple of times and the only thing he said related to what you mention is this:
    "When an object is inserted into a JBoss AOP cache we apply aspects at runtime rather than at compile time."
    Which I suppose could be argued to be the same as what you are saying. Maybe.

    Other than that he is talking about classes, and not object instances, and for those cases there is little difference now between what AspectJ can do and what JBoss can do, as far as I can tell anyway.

    > TreeCacheAOP: It is the responsibility of the cache to insert it's
    > interceptors (for state change) in POJO's. That dynamic behavior is not
    > available with AspectJ or the classloading weaving you are refering to.

    Right, because you are talking about per-instance "weaving" and not per-class weaving and that concept is only available in JB4, as far as I know.

    Whether that is a good thing or not, well, I'm with Mike S. on this one.

    > Monitoring: to be able to insert a monitor aspect in pojo (JMX or IoC
    > controlled) at run-time, in the middle of execution, not at classloading time
    > is a perfectly valid use-case for systems. You come in it, the server is not
    > performing, you instrument the particular access point to your application and
    > define the pointcut as being a particular method on a particular instance.
    > It is run-time, not classloading run-time but real execution runtime.

    Right. Any dynamic AOP framework (e.g. AspectWerkz) should be able to do this. Whether you really want to do this or not is another story, of course. See the comment by Mike S. on this.

    > There is no need to invoke "Gregor-the-father-of-AOP", he is perfectly able to
    > understand the non-invasiveness points and the dynamic instrumentation as
    > being non-gimmicky.

    The point is that when Gregor talks about AOP you hear things like "enabling programmers to modularize crosscutting structure in their code", and when Bill talks about AOP you hear things like "bytecode manipulation", "interceptors" and "reflection". If you didn't know you'd be surprised to find out that they were supposedly talking about the same thing.

    To generalize, Gregor usually talks from the concept perspective and Bill usually talks from the implementation perspective. It's a very important difference if you want to explain AOP to others.

    > That is incorrect. The 'mess' you are referring to is mess that is inherent
    > in component assembly under transactional scope.

    Yes. Except now POJO's are automatically considered to be components. A.k.a. "a mess".

    > tons of people were using the REQUIRED tag in EJB and that let to graphs of
    > objects being locked under transactional scope and thus single threaded access
    > of the graph, which is not good. We moved to REQUIRED NEW by default and
    > that magically went away.

    Oh great. Instead of doing one transactions that delineates some unit of work you instead define each method invocation to be a unit of work and hence a transaction. Very clever! So for a thousand invocations you have a thousand transactions, and if you want to rollback them all you're screwed. Almost sounds like not using transactions at all would've achieved the same thing but with better performance. But what do I know ;-)

    > What that means is that transaction assembly is TRICKY INDEPENDENTLY of the
    > surrounding technology (it is not an AOP problem, like it wasn't an EJB
    > problem, it is an state assembly problem).

    Right. So, given this, introducing transactions transparently with REQUIRES_NEW semantics on all POJO *instances* transitively touched in some process is supposed to be a good thing?

    > Bill has gone the extra mile and provide various locking mechanisms that are
    > being integrated in our cache and persistence layers, that supports optimistic
    > locking and various fancy stuff.

    It's like deja vu all over again. Hani, is that you?

    > The bottom line is that graph isolation with transactional scope is a problem
    > of *programming* and how we access state in systems, not an AOP problem.

    Maybe, but since you are introducing it under the covers using AOP it really becomes a JBoss problem.

    "Are you interested in transaction messes using implicit transactional scopes that we know are inherently difficult to get right? Well, step right up and you'll get a free copy of JBoss to handles those needs for ya!"

    > I argue that exposing that construct as "transactional aspect" like Bill has
    > done in fact promotes the visibility of it for developers to deal directly
    > with.

    Exactly how does it promote the visibility?

    > Finally we support recursive instrumentation of the graph, transitive closure.

    I know. That's the whole point. You think of this as a good thing, I think of it as a disaster waiting to happen.
     
    > 1- how aspects are done is interceptors, you made that first implementation
    > when you were working for me at telkel.

    For the umpteenth time: AOP != Interceptors

    > 2- the weaving semantics is an interesting problem, but not a fascinating one.

    On the contrary, I think weaving semantics is one of the most fascinating problems, because those are what sets the possibilities and limitations in any given AOP system.

    > I am still not convinced that the language (aspectJ) is the best way to
    > specify pointcuts. I think it is very visual and have seen very interesting
    > research done in Germany and IBM about UML2 assembly of aspects. You can say
    > with you finger "here and here". Aspects as described above DO NOT REQUIRE
    > any specification of pointcuts and weaving they are automated by the system,
    > the cache inserts.

    One question here: if you insert them automatically, how can you be sure that they are inserted in the correct order with respect to other advice that are already applied to the object? Or is that a random thing?

    > Speed is somewhat important and since most prod system we see are sitting at
    > 10% utilisation and going down thanks to Moore's law it may become a moot
    > point better left for academics and computational freaks.

    Or maybe we need to learn how to utilize those leftover 90% better. Which means introducing more complex problems and solutions. Which means that understanding the structure of the system becomes more important. Which means that inserting advice like you are describing is a disaster waiting to happen.

    > Rickard with all due respect (and we do give you a lot) I would ask you
    > elevate the debate and not spread disinformation yourself.

    Such as? What, exactly, in the comments I made are disinformation? I'm going to do a couple of AOP seminars this fall, and I sure don't want to spread disinformation.

    /Rickard
  75. Here we go...[ Go to top ]

    And here we go again, really. This AOP stuff, IMO, needs a lot of improving, until all dependencies, gotchas, pitfalls, semantics, effects, counter-effects, etc. are fully understood. Ok, it really looks good, but I think it is risky to jump on it so early now. Just by reading this kind of discussions, I can see that the people pushing this new tecknology forward don't really understand it completely. What we are seeing is a new way of dealing with designing and coding systems. A new way of thinking, a new paradigm, almost like the shift from structured to OO development. So maybe this stuff is still too "academic" to be used so deeply in a complex framework as J2EE is. The gurus who are "defining" AOP for us are disagreeing in how to implement it! How safe can we, mere mortals, feel, seeing the "code gods" fighting like this? Lots of people are hearing about AOP for the first time, and until the knowledge about it is fully spread and understood (like OO is now), people will misuse it, like it happened with OO in the early days (and it still happens today!!).

    I love to learn new stuff, but regarding AOP I don't even know what to learn!! ;-)

    Is someone planning to write an "AOP reference book", or something like that? Its definitions and all should be well stablished to everyone, before people jump on (and not under ;-) this train.

    My R$0,0002
  76. Here we go...[ Go to top ]


    > I love to learn new stuff, but regarding AOP I don't even know what to learn!! ;-)
    >

    Right, and our point is that you should not LEARN ANYTHING. That is part of my AOP is boring rant. I will publish that editorial for september in some more details.

    See a few system designers are getting all excited about it, because for middleware designers dynamic AOP is nirvana. JBoss, research academia are example.

    If you are an end user developer you don't care about AOP, you care about the tags (see above for transactions) and you care about the aspects themselves and you care about the cache and monitoring, you don't care about AOP.


    > Is someone planning to write an "AOP reference book", or something like that? Its definitions and all should be well stablished to everyone, before people jump on (and not under ;-) this train.
    >

    If you are using JBoss3.x you are already in that train, without knowing it. I am almost sorry we promoted the AOP discussion to the fore-front, it is the "latest and greatest" effect that we all like, but it doesn't deserve front page for end-users.

    Seriously do you think C# users give a hoot about the aspect orientation of the framework as a philosophy of implementation done by Simyone (sp?) who is (was) a collegue of GregorK and Bill Gates right arm at MS and responsible for great stuff from Visual Basic, to word, to great influence on C#? no they don't they just use ".NET remote" and ".NET persistence".

    The same will go happen to AOP in java. As soon as we put some VM level support to make java runtimes more like C# runtimes we are DONE from a middleware standpoint. You don't need to learn anything


    marcf
  77. Henrique,

    Four quick points:
    1) There are many commercial projects using AspectJ in production today. If you peek at the AspectJ users list, you'll see developers busy using the technology successfully on projects today. And you can read good books about AOP and AspectJ such as "AspectJ in Action" and "Mastering AspectJ".
    2) OO was filled with similar controversy as it was emerging, with raging debates among camps such as C++ and Smalltalk. This was true even though the different camps were mature and had had good success.
    3) I believe you should consider the source of the information. Perhaps some organizations thrive on controversy? By analogy, this thread has contained a lot of controversy about the nature of EJB and how to do transactions. I hope you wouldn't infer from 'the "code gods" fighting like this' on these topics that EJB or transactions are academic or unproven.
    4) I do agree that it's important to learn from early OO projects that jumped in head first. You can start using AOP to make life easier for developing and testing code, and then use it incrementally for auxiliary concerns like error handling, management, and logging. Don't start using AOP by building a system with as many aspects as classes!

    Ron
  78. Hello Ron,

    From MIT MBA classes to TSS discussions there is one step ;)

    > these topics that EJB or transactions are academic or unproven.

    clearly. EJB is well understood and many of the ideas here proven in academia and industry alike. Just like aspectJ, JBoss is used for its transactional interception in very high end and transaction system (retail, telco, finance)

    > 4) I do agree that it's important to learn from early OO projects that jumped in head first. You can start using AOP to make life easier for developing and testing code, and then use it incrementally for auxiliary concerns like error handling, management, and logging. Don't start using AOP by building a system with as many aspects as classes!
    >

    It is a point that for people that evangelize GregorK's baby we need to start telling the masses "AOP is irrelevant" (75% probability) unless you are an ISV that builds aspects and already monitoring companies are doing it, an academic that prototypes research in aspects (GeorgiaTech, Standford) for reuse or a JBoss core developer. By and large the people who use middleware are using AOP already and don't really need to know about it. AOP as an enduser construct, I still find it difficult to evangelize.
    > Ron
  79. Hello Ron,

    Hi Marc.
     
    > From MIT MBA classes to TSS discussions there is one step ;)
    Well, that class on Internet business models in 1996 was right that something big was was coming :-)

    > It is a point that for people that evangelize GregorK's baby we need to
    > start telling the masses "AOP is irrelevant" (75% probability) unless you
    > are an ISV that builds aspects and already monitoring companies are doing
    > it, an academic that prototypes research in aspects (GeorgiaTech, Standford)
    > for reuse or a JBoss core developer.
    Here I beg to differ. Just as the first uses of OO were restricted to pre-defined frameworks for GUI, some of the natural first uses of AO are in middleware. However, I think users will benefit from AOP both from direct use and from indirect use by vendors packaging it. Indeed, the best scenario is vendors that use it for benefit and expose clean extension APIs.

    Here are some use cases that end users will care about and that can only be done (modularly) with full AOP support, i.e., including declarative specification of pointcuts rather than tagging:

    development-time support:
    - unpluggable debugging (tagging makes it invasive!)
    - virtual mock objects for testing (using cflow or dynamic deployment)
    - performance monitoring (tailored timings based on context sensitive behavior - tagging and untagging is unwieldly)
    - system archeology (targeted tracing to figure out how something works, ditto)
    - architectural enforcement (layering rules, use of logger not printing, etc.)

    infrastructure support:
    - error handling (has to be done for a specific app/domain and needs to be defined across packages and groups of types)
    - systems management (again, app specific)
    - timing (again, best done by defining abstract layers not tagging all over)
    - caching (obviously we have different perspectives on this one)
    - servlet buffering

    business logic:
    - application security (roles change and its painful to retag; rules are helpful, moreover instance-level checks like only an employee's manager can do x benefit from complete separation)
    - feature management (including or excluding variations; using tags you get the joys of C++ #if-riddled code)
    - publishing business events based on diffuse conditions (help inquiry, purchase, RFP received)
    - metering (unpluggable, and permits different metering policies and separate evolution)

    Stay tuned for more details on how these can be usefully implemented to take advantage of the power of AspectJ-style AOP. Some of these are also covered by recent books on AspectJ (e.g., AspectJ in Action has chapters on using JAAS and policy enforcement).

    Finally, let me point out that anything you can do by dynamically deploying an aspect can be done with an AspectJ aspect that includes a runtime test for a condition. There are likely to be different performance characteristics and ease of development characteristics, but on which side the balance tilts is not so clear.

    There is also an interesting idiom in AspectJ that allows one to essentially tag an object on construction with a marker interface (using a subtype) so that advice will only apply to certain instances...

    Ron
  80. Here we go...[ Go to top ]

    Rickard, I think you hit on a key point in your post. It's something I caught in the interview, but couldn't put into clear, concise words. Thankfully you did it for me:

    \Rickard\
    The point is that when Gregor talks about AOP you hear things like "enabling programmers to modularize crosscutting structure in their code", and when Bill talks about AOP you hear things like "bytecode manipulation", "interceptors" and "reflection". If you didn't know you'd be surprised to find out that they were supposedly talking about the same thing.
    \Rickard\

    When I first started investigating AOP, and started focusing on AspectJ, the implementation details were mostly unmentioned. Perusing various books, websites, etc, the emphasis was on the semantics of the AspectJ language, and how those semantics translated into the higher goals of the designers. You could run into semantics that were constrained by the currently implementation, and documentation stating such, but that was generally a side bar. The focus was always on showing cross-cutting concerns, creating pointcuts to define the code which is 'cross-cut', and defining the advice which is run against those pointcuts.

    Performance was also always at the top of the documentation list - urging people to narrow pointcuts through constructs like target(), args(), etc, preferring static joinpoint information to dynamic information, etc.

    The whole is obviously a carefully designed language with well defined semantics, and an equally well-thought out (but ever changing) runtime system, all of which sprung from very high level and throughly analyzed goals.

    Other Aspect frameworks have, perhaps, less rigor applied to them. But for the most part they are striving to move towards an AspectJ-like model. I think those designers see the value that is inherent in the AspectJ model, and that model is easier to emulate in many ways because it's always defined for the greatest part in semantic terms, not implementation terms.

    In contrast, after looking at JBoss AOP somewhat in-depth over a month or so,
    it doesn't look much like an AOP system to me. In particular, one of the main goals of JBoss "AOP" appear to be mutating code and objects and call graphs at runtime according to runtime context. This goes to the heart of the "transactional cache" examples - the system is not implementing a cross-cutting concern in any sense of the term. Instead, certain objects become mutated to an extent when they are placed in a certain context (lik a transactional cache). The "mutation" may not be literally on the POJOs involved, but the overall effect is the same.

    This, to me, doesn't sound like an AOP system. And it's not based on a well-integrated, highly thought out system like an OO language or AspectJ. Instead, the fundamental basis appears to be solely contextual manipulation and mutation of objects using one or more interceptor mechanisms.

    Incidentally, I use terms like appears" and "one or more" because it's tough to get acccurate and concise information on the JBoss "AOP" framework, it's capabilities, it's limitations, and especially its high level conceptual model. Bill Burke and others have posted informatin here - which is flatly contradicted by information they've posted on the JBoss AOP web site. Individual posters have contradicted each other as well on what JBoss AOP can and cannot do. I don't believe this is some sort of conspiracy or anything, but it points to the lack of well-defined conceptual models and semantics. This appears to be a system being grown, not designed. I've seen the same thing in JBoss JMS discussions as well - a fictional "Peter" and "Paul" and "Mary", each supposed experts in JBoss JMS, all contradicting each other on fundamental design points in posts here on TSS.

    Personally, I think this fractured approach is going to cause alot of difficulties down the pike, and certainly something like the JBoss AOP system is being grown in ways that I find deeply disturbing - and the low level language people like Bill Burke use to describe it (interceptors, byte code manipulation) is a symptom of a larger problem. And this sort of chaotic non-design, organic growth from the hip approach seems to be spreading to other areas of JBoss 4 as well, such as the JMS discussions I mentioned.

        -Mike
  81. Here we go...[ Go to top ]

    mike,

    the Hulk in me will focus on the technical parts and ignore the bile and rant.

    There isn't much in technical meat in your post.

    > The focus was always on showing cross-cutting concerns, creating pointcuts to define the code which is 'cross-cut', and defining the advice which is run against those pointcuts.
    >

    right and if you think about it a middleware platform is crosscutting behavior by definition. Persistence can be applied orthogonaly to many object, so is remoteness so the capacity to replicate in cache, so is acidity. All middleware SERVICES are almost BY DEFINITION aspects as they are cross cutting behavior.

    That is why I say AOP is nirvana for middleware designers and ISV/OEM's but largely irrelevant for end users. I am not sold on the relevance of AOP for end user apps, but that is not my domain so I will take a passive/positive attitude. If AOP succeeds with enduser apps, great, in the meantime JBoss will push AOP as mass market technology, embedded and transparent.

    Bill made the point once that JBoss and middleware in general is AOP first killer application and its poster child of a success. We are already there and the rest of the discussion, that that is not relevant to systems, is not relevant to us at JBoss.

    JBoss, we do systems.
     
    >
    graphs at runtime according to runtime context. This goes to the heart of the "transactional cache" examples - the system is not implementing a cross-cutting concern in any sense of the term.
    >

    Au contraire mon ami, middleware IS CROSSCUTTING service by definition.

    Which is why AOP is so relevant to system designers and imho irrelevant to end users, it is our duty, like it is microsoft's to offer simpler frameworks, starting from the framework itself, rather than GUI'fying complex frameworks (BEA).

    >
    This, to me, doesn't sound like an AOP system. And it's not based on a well-integrated, highly thought out system like an OO language or AspectJ.
    >

    "We value running code over opinions"
    -- some spokesperson for the IEEE in the late 90's

    " The problem with the kernel dev list is that people come with opinions, not code, opinions"
    -- Alan Cox

    Don't assume "well thought out" isn't part of JBoss.

    >
    Instead, the fundamental basis appears to be solely contextual manipulation and mutation of objects using one or more interceptor mechanisms.
    >

    That is true though, contextual computing is in fact a big topic of research right now, from routers to smart JMX and recovery oriented computing, most frameworks lack the contextual awareness. We got some of it in JBoss, since context is a function of runtime execution (cache, monitoring are examples of "context") or even routing based on apps is contextual.

    >
    This appears to be a system being grown, not designed.
    >

    That's XP. It is designed AND grown, can't you tell there is a vision here? We also have a public CVS for it.

    I will be presenting at IBM wattson next week (www.jboss.org and follow the events link) with Ivar Jacobson ans Swainson. IBM research is ALL OVER the aspects as middleware constructs. I think it is an open session and I invite you to come there and talk directly with me.

    marcf
  82. Here we go...[ Go to top ]


     Other than that he is talking about classes, and not object instances, and for those cases there is little difference now between what AspectJ can do and what JBoss can do, as far as I can tell anyway.
    >

    We are talking about instances and even Gregor K concedes that it is a feature Aspect J cannot support yet has clear and immediate use cases (monitoring/persistence/cache and god knows what you will think of next).
     
    >
     Right, because you are talking about per-instance "weaving" and not per-class weaving and that concept is only available in JB4, as far as I know.
    >

    correct, get the VM level spec and this is available to everyone


    >
     Yes. Except now POJO's are automatically considered to be components. A.k.a. "a mess".
    >

    incorrect, part of the current trend from EJB -> JMX+AOP+IoC
     
    >
    Oh great. Instead of doing one transactions that delineates some unit of work you instead define each method invocation to be a unit of work and hence a transaction. Very clever! So for a thousand invocations you have a thousand transactions, and if you want to rollback them all you're screwed. Almost sounds like not using transactions at all would've achieved the same thing but with better performance. But what do I know ;-)
    >

    Well, you never were a transaction expert, even in the days, were you ;) yes that is the programmatic model of transactions since the Microsoft DCOM days to Corba to EJB to C#.NET to JBoss4 today, declarative transaction demarcation is an accepted practice. A simpler one, in spite of the inherent difficulties of parralel transaction with shared data.

    We didn't invent it, we stole it from .NET who stole it from EJB who stole it from DCOM. Reification of transactions in aspects is a closed research domain. See a recent INRIA research paper on the topic (phillipe merle), it is a dead horse for the past 10 years. That part is clearly understood and implemented in various frameworks.

    >
     Right. So, given this, introducing transactions transparently with REQUIRES_NEW semantics on all POJO *instances* transitively touched in some process is supposed to be a good thing?
    >

    yes, and implemented since DCOM/EJB days.
     
     
    > > I argue that exposing that construct as "transactional aspect" like Bill has
    > > done in fact promotes the visibility of it for developers to deal directly
    > > with.
    >
    > Exactly how does it promote the visibility?

    /**
    *
    * @jboss:aop:transactions tag=REQUIRES_NEW
    *
    */

    public void someSessionMethod() { ...}


    C# like, implemented in JBossIDE (Eclipse+XDoclet) very visual from an assembly standpoint, see research on those tags generated by UML2 transaction demarcation drag and click. Nirvana.

    it promotes visibility of that construct. There are some construct that don't work with class level tags (monitoring/cache) and these are dealt with in JB4 only.

    >
     On the contrary, I think weaving semantics is one of the most fascinating problems, because those are what sets the possibilities and limitations in any given AOP system.
    >

    AOP is boring from a user standpoint imho, I am about to write an editorial for JDJ talking about it. We have implementations so the discussion is dead from a user standpoint imho.

    The bottom line is the user cares about the tags and the aspects (transactions as above) not about the mechanisms that is used to weave it in (AOP). In fact if we have the VM support we may not need an AOP framework at all to do all of this and more. It will be AOP's success and immediate irrelevance.
     
    >
    One question here: if you insert them automatically, how can you be sure that they are inserted in the correct order with respect to other advice that are already applied to the object? Or is that a random thing?
    >

    You know the answer to that question, you implemented the first version in JB2 when you were my employee at Telkel. Some require order (cache retrieval before persistence for example) and we support ordered interceptors in a chain, some don't as they really represent orthogonal behavior.

    marcf
  83. Here we go...[ Go to top ]

    <rickard>
    Oh great. Instead of doing one transactions that delineates some unit of work you instead define each method invocation to be a unit of work and hence a transaction. Very clever! So for a thousand invocations you have a thousand transactions, and if you want to rollback them all you're screwed. Almost sounds like not using transactions at all would've achieved the same thing but with better performance. But what do I know ;-)
    </rickard>

    <marc>
    Well, you never were a transaction expert, even in the days, were you ;) yes that is the programmatic model of transactions since the Microsoft DCOM days to Corba to EJB to C#.NET to JBoss4 today, declarative transaction demarcation is an accepted practice. A simpler one, in spite of the inherent difficulties of parralel transaction with shared data.
    </marc>

    I think its important to clarify here:

    Transactional context MTS/COM+ (which is really what you mean by DCOM) is an *object* property, not a method property. I.e. the transaction context is created when an object that requires a transaction is created, and a transaction can not be inherited from the objects creator. If you invoke 1000 methods on this object, you do *not* get 1000 transactions. All work is done against the single transaction that was created when the object was created . This still applies in .NET, because the COM+ is still used as the underlying plumbing. Additionally, you can only apply TransactionAttribute to a class in C#, not to a method.

    -John
  84. Here we go...[ Go to top ]

    And now I see that you've noted my point yourself already, so disregard
  85. I think the point needs to be made here is this:

    If Session Bean A calls Session Bean B, and they are both set to Required for the transaction, then the calls are handled in the same scope of the transaction. If it is your intention to have dependent session beans affect the parent, then Required must be set.

    If Session Bean A calls Session Bean B, and they are both set to Requires New for the transaction, then both session beans will operate in the scope of their own transaction. So if Session Bean B fails, then Session Bean A will not roll back. This is useful for some purposes such as logging.

    Setting everything to Requires New would, as implied earlier, creates a situation where every call operates in the scope of its own transaction, which isn't always desirable if you want multi step operations contained in a single transaction, where one error can roll back everything.
  86. Here we go...[ Go to top ]

    Transaction context is a property of the transaction manager and it is bound to a thread not an object.
  87. Here we go...[ Go to top ]

    Richard wrote:
    >
    > The point is that when Gregor talks about AOP you hear things like "enabling programmers to modularize crosscutting structure in their code", and when Bill talks about AOP you hear things like "bytecode manipulation", "interceptors" and "reflection". If you didn't know you'd be surprised to find out that they were supposedly talking about the same thing.
    >

    The average developer "gets" interception. They don't get "enabling programmers to modularize crosscutting structure in their code". I've had people ask me. What is AOP? I used to start off with "It is a way componentize behavior that spans multiple separate and distinct object models. It is a way to specify cross cutting behavior across object hierarchies." What I get is head scratching and, "huh? I don't get it". Then I say, its about inserting code between the caller of a method and the method body. Its about interception. And they get it. Yeah sure, I'm not the most articulate person in the world, but this is what people get.

    > To generalize, Gregor usually talks from the concept perspective and Bill usually talks from the implementation perspective. It's a very important difference if you want to explain AOP to others.

    That's the problem. The average developer doesn't get concepts. They get implementation. This is what I've experienced in the field.

    > > 1- how aspects are done is interceptors, you made that first implementation
    > > when you were working for me at telkel.
    >
    > For the umpteenth time: AOP != Interceptors
    >

    AOP IS interception. (At least the important part of AOP.) AOP is about the implicit interception of JVM events (construction, method calls, field access, exceptions) and the triggering of certain behavior when this event is intercepted. Please spare me the vocabulary lessons.

    I'm not a big fan of introductions in pure Java based AOP frameworks. If you're doing introductions with pure Java and dynamic proxy based frameworks, you have to do aggregation to implement this and the introduction itself has to know the structure of the object it is being introduced to anyways. I guess what I'm saying is that you have to write a lot of the same bullshit code anyways with pure Java based AOP frameworks that you would have to write without AOP to get the advantages that introductions provide for you.

    For AspectJ and JBossAOP, introductions are really a static thing and can't be done at runtime so this cuts a lot of the power of introductions right there. AspectWerks may be a different story as they use the JDPI and hotswap. Anybody know the consequences of running in debug mode? I've heard overall performance of the JVM drops 50%. Dynamic proxy based AOP frameworks can support dynamic introductions, but then object references become invalid because you would have to generate a new proxy class/instance. Really what you're doing is a framework to apply adapter classes.

    Introductions will really only become powerful when the JVM changes to support this feature. Python, Smalltalk, ObjectiveC all have these features, its time Java did too.



    > One question here: if you insert them automatically, how can you be sure that they are inserted in the correct order with respect to other advice that are already applied to the object? Or is that a random thing?

    As far as aspects at the class-level, aspects are applied in the order in which they are deployed and defined.

    At runtime, right now, per instance you can add interceptors at the beginning or end of the chain. This has been sufficient so far with the aspect-oriented middleware we're writing. We'll be extending the expressiveness of this as time goes on and as requirements dictate that we expand it.

    >
    > > Speed is somewhat important and since most prod system we see are sitting at
    > > 10% utilisation and going down thanks to Moore's law it may become a moot
    > > point better left for academics and computational freaks.
    >
    > Or maybe we need to learn how to utilize those leftover 90% better. Which means introducing more complex problems and solutions. Which means that understanding the structure of the system becomes more important. Which means that inserting advice like you are describing is a disaster waiting to happen.
    >
    > > Rickard with all due respect (and we do give you a lot) I would ask you
    > > elevate the debate and not spread disinformation yourself.
    >
    > Such as? What, exactly, in the comments I made are disinformation? I'm going to do a couple of AOP seminars this fall, and I sure don't want to spread disinformation.

    The disinformation he is talking about is that you're trying to make AOP out to be more than it is. Let's articulate what AOP is in simple terms rather than wrapping in up in all this new language and academic mumbo-jumbo. That it is an aggregation of concepts and patterns that have been in use for years and that many are already familiar with.

    Bill
  88. (wow, there's a lot of discussion here to read)

    I'm going to hold myself to three points, this message is about
    the "its both" point.

    I think its natural that there's a tension between describing AOP
    in conceptual terms (modularizing crosscutting) and describing it
    in mechanical terms (pointcuts, advice, [interceptors see below).

    The same debate happened with OOP, and exists still today. Is OOP
    objects, inheritance, methods and polymorphism? Or is it about
    organizing the system according to self-contained actors that
    know how to operate on themselves?

    Clearly OOP is both. Similarly AOP is both. The challenge, as we
    develop AOP is to develop both style and mechanisms in a synergistic
    way, just as we did with OOP. For example, in OOP we didn't have
    interfaces at the beginning, they evolved out of working a number of
    concerns, including getting static typing to work and trying to get
    the benefits of multiple inheritance without the costs.

    I think we're going to keep arguing for the next several years about
    whether AOP is a style or a mechanism. I think the argument is to
    some extent healthy. But I think its really a synergy between both,
    and I think that in order to develop the best mechanisms and the
    best styles, we need to keep both, and the synergy in explicit
    focus all the time.
  89. AOP - interception > 0[ Go to top ]

    (wow, there's a lot of discussion here to read)

    I'm going to hold myself to three points, this message is about
    the "there is something new here point".

    Bill says:

    > The disinformation he is talking about is that you're trying
    > to make AOP out to be more than it is. Let's articulate what
    > AOP is in simple terms rather than wrapping in up in all this
    > new language and academic mumbo-jumbo. That it is an aggregation
    > of concepts and patterns that have been in use for years and that
    > many are already familiar with.

    This point of view stems, I think, from the subset of AOP functionality
    that you are focusing on.

    You are right that explicit tagging of places where extra code should
    run, i.e. with attributes or xdoclet, is not a new idea. Its called
    syntactic macros, or compile-time metaprogramming, and its been around
    for > 20 years. Nothing new there.

    But that's not what's new in AOP. What's new in AOP is a principled
    mechanism for defining, composing and abstracting over crosscutting
    structure. The ability to say "yes, that code has this module structure
    to it, but for the purpose of defining this part of the functionality,
    I want it to have this different (crosscutting) module structure".

    In AspectJ there are two such mechanisms the pointcut language, and
    the type pattern plus introduction syntax. (Note that the advice mechanism
    itself in AspectJ is not new.)


    Now you can keep saying that AOP is just interceptors and just
    explicit tagging as long as you want. But its not right. Believe
    me, we wouldn't have spent the 9 years we spent on it to reinvent
    something that already existed.

    What is true is that now that AOP works, and attributes have been
    invented, we can see a fantastic synergy between the two. Its
    interesting, useful and important to see what Jboss and others are
    doing to exploit that synergy. There have been some very interesting
    and substantive discussions on aosd-discuss about exactly when to use
    attributes and not.

    That is all TRULY GREAT; but zeroing in on the subset consisting of
    interceptors and attribute-based macros and then defining AOP to be
    no more than that just isn't right. AOP is more, and the ways in
    which it is more are new.
  90. AOP - interception > 0[ Go to top ]

    (wow, there's a lot of discussion here to read)

    >
    > I'm going to hold myself to three points, this message is about
    > the "there is something new here point".
    >
    > Bill says:
    >
    > > The disinformation he is talking about is that you're trying
    > > to make AOP out to be more than it is. Let's articulate what
    > > AOP is in simple terms rather than wrapping in up in all this
    > > new language and academic mumbo-jumbo. That it is an aggregation
    > > of concepts and patterns that have been in use for years and that
    > > many are already familiar with.
    >
    > This point of view stems, I think, from the subset of AOP functionality
    > that you are focusing on.
    >
    > You are right that explicit tagging of places where extra code should
    > run, i.e. with attributes or xdoclet, is not a new idea. Its called
    > syntactic macros, or compile-time metaprogramming, and its been around
    > for > 20 years. Nothing new there.
    >
    > But that's not what's new in AOP. What's new in AOP is a principled
    > mechanism for defining, composing and abstracting over crosscutting
    > structure. The ability to say "yes, that code has this module structure
    > to it, but for the purpose of defining this part of the functionality,
    > I want it to have this different (crosscutting) module structure".
    >
    > In AspectJ there are two such mechanisms the pointcut language, and
    > the type pattern plus introduction syntax. (Note that the advice mechanism
    > itself in AspectJ is not new.)
    >
    >
    > Now you can keep saying that AOP is just interceptors and just
    > explicit tagging as long as you want. But its not right. Believe
    > me, we wouldn't have spent the 9 years we spent on it to reinvent
    > something that already existed.
    >

    What you've done, IMO, is taken interception and introduction and apply it to a language that does not have those concepts built in. Definately not a trivial thing and the 9 years you took definately shows in the quality of the AspectJ project, but let's take it as it is. Interception of JVM events based on a set of criteria, attribute and metatags being just one aspect of that criteria. AspectJ has specified how to define the event you want to intercept and what code you want to trigger based on that event.

    > What is true is that now that AOP works, and attributes have been
    > invented, we can see a fantastic synergy between the two. Its
    > interesting, useful and important to see what Jboss and others are
    > doing to exploit that synergy. There have been some very interesting
    > and substantive discussions on aosd-discuss about exactly when to use
    > attributes and not.

    The concepts though of AOP are old and familiar. Introductions are concepts that Smalltalk/ObjectiveC has had since the beginning. Interception has been used in one form or another for over a decade in one framework or another (at least from my experience).
     
    What I'm saying is that there is a difference in what AOP really is and why you need to use it. The why is a compelling story and the definition of the why is definately needed. The what is nothing new IMO.

    There's a lot of talk about how us JBoss folks don't understand what AOP is. But please tell me how we have used AOP in the wrong way to apply the aspects we have written to application code. We have a clear separation of concerns with the aspects we are writing and how to apply those aspects to application code.

    Bill
  91. AOP - interception > 0[ Go to top ]

    What you've done, IMO, is taken interception and introduction and apply it to

    > a language that does not have those concepts built in.

    No, what they have done is "enabling programmers to modularize crosscutting structure in their code".

    > AspectJ has specified how to define the event
    > you want to intercept and what code you want to trigger based on that event.

    No, what they have done is "enabling programmers to modularize crosscutting structure in their code".

    > The concepts though of AOP are old and familiar.

    No, because before AOP there was no paradigm which was "enabling programmers to modularize crosscutting structure in their code".

    > What I'm saying is that there is a difference in what AOP really is and why
    > you need to use it. The why is a compelling story and the definition
    > of the why is definately needed.

    Right, and it is (basically) "enabling programmers to modularize crosscutting structure in their code".

    > The what is nothing new IMO.

    Right, it is about as old as AspectJ.

    > There's a lot of talk about how us JBoss folks don't understand what
    > AOP is.

    Maybe it's because everything you say and do contradicts your own claims of understanding it. Just maybe.

    Here's an analogy that might work for you. If you want to explain quantum mechanics to someone that doesn't have a physics degree you may want to simplify things in order to get the ideas across. You use terms and language that is accessible for the one you're explaining it too. You yourself, Bill, explained that you ended up in these kinds of situations all the time. But, you must always keep in mind that they are just that, simplifications. Following this analogy, I see little evidence (in talk or code) that you understand that what you are saying/doing is the (over-)simplification of what AOP is, and that there is a bigger picture to it all. You're like a child looking at a car and describe it like "it's a metal box with wheels", which is an adequate conceptualization for a child, but doesn't really describe what a car really is. Your description of what AOP is is equally simplified and far from the original idea and concept.

    Get it?

    /Rickard
  92. AOP - interception > 0[ Go to top ]

    What you've done, IMO, is taken interception and introduction and apply it to

    > > a language that does not have those concepts built in.
    >
    > No, what they have done is "enabling programmers to modularize crosscutting structure in their code".
    >
    > > AspectJ has specified how to define the event
    > > you want to intercept and what code you want to trigger based on that event.
    >
    > No, what they have done is "enabling programmers to modularize crosscutting structure in their code".
    >
    > > The concepts though of AOP are old and familiar.
    >
    > No, because before AOP there was no paradigm which was "enabling programmers to modularize crosscutting structure in their code".
    >

    But that's exactly what we've been using those old and familiar concepts for.

    Bill
  93. No, because before AOP there was no paradigm which was "enabling programmers to modularize crosscutting structure in their code".

    > >
    >
    > But that's exactly what we've been using those old and familiar concepts for.

    You really really really should consider Mike's advice and actually listen, like, for once. That is not even close to "exactly" what you've done.

    I give up. This is pointless.

    /Rickard
  94. I give up.

    >
    > /Rickard

    don't, or bill will be doing the victory dance for 3 straight days,

    you can do better rickard, don't drop out, we are just getting started kid.

    marcf
  95. Bill,

    Its not like I don't have 1M other things to do, but let me try to shift the discussion to a very technical point. I think this very technical point might help bridge the impasse. (I'm out of wind after this, I promise.)

    IMHO the mechanism called "pointcut" in JBoss is a very different thing than the mechanism called "pointcut" in AspectJ. I think that difference in the designs may underlie a lot of the difference in perspective.

    I believe what JBoss calls pointcuts are more like what AspectJ calls advice. JBoss pointcuts seem to say "bind this advice implementation to these points". But the points are hard coded into the binding construct. There isn't a first-class construct that describes *just* the points.

    To be concrete, in JBoss AOP you write (from the o'reilly example).

    <aop>
       <interceptor-pointcut class="POJO">
          <interceptors>
             <interceptor class="TracingInterceptor" />
          </interceptors>
       </interceptor-pointcut>
    </aop>

    instead of something like:

    <aop>
       <attach-interceptors>
          <within-pointcut classname="POJO">
          <interceptors>
             <interceptor class="TracingInterceptor" />
          </interceptors>
       </attach-interceptors>
    </aop>

    This small change to your design would make JBoss much more like AspectJ, and IMHO much more powerful. (AspectWerkz made essentially this change over the summer.) It would make pointcuts first-class, so that you could abstract and compose over them. You could then write things like:

    <aop>
       <define-named-pointcut name="foo">
          <within-pointcut classname="POJO">
       </define-named-pointcut>
       <attach-interceptors>
          <named-pointcut name="foo">
          <interceptors>
             <interceptor class="TracingInterceptor" />
          </interceptors>
       </attach-interceptors>
    </aop>

    and later change just the definition of foo, for example to be:

       <define-named-pointcut name="foo">
          <and-pointcut <within-pointcut classname="foo">
                        <call-pointcut methodname="helloWorld">
          >
       </define-named-pointcut>

    (forgive me if I get the XML wrong)

    Of course you could also, as in AspectJ, just put the compound pointcut
    directly in the advice, you don't need to define a named pointcut first.


    This would give you compositional crosscutting, which I'm saying is the
    new idea of AOP. I don't *think* you have compositional crosscutting now,
    which would explain why you see AOP as just interception and introduction.


    Just for reference, the AspectJ equivalent to the o'reilly example is
    something like the following:

    pointcut foo(): within(POJO);
    before(): foo() { print("entering " + thisJoinPointStaticPart); }
    after() returning: foo() { print("leaving " + thisJoinPointStaticPart); }

    Gregor

    PS IMHO the O'Reilly example is not a good one for benchmarking, because
    it mostly measures string operations, rather than measuring the overhead
    of advice dispatch.
  96. Gregor,

    > Bill,
    >
    > Its not like I don't have 1M other things to do,

    Your time is appreciated.

    > I believe what JBoss calls pointcuts are more like what AspectJ calls advice. JBoss pointcuts seem to say "bind this advice implementation to these points". But the points are hard coded into the binding construct. There isn't a first-class construct that describes *just* the points.
    >

    the example you show, our initial article, does show harcoded hardcoded points and binding of aspects. However we already have stand-alone points definition with no bindings or rather late bindings (treecache comes to mind) so we already support stand-alone definitions of points.
      
    > To be concrete, in JBoss AOP you write (from the o'reilly example).
    >
    > <aop>
    >    <interceptor-pointcut class="POJO">
    >       <interceptors>
    >          <interceptor class="TracingInterceptor" />
    >       </interceptors>
    >    </interceptor-pointcut>
    > </aop>
    >
    > instead of something like:
    >
    > <aop>
    >    <attach-interceptors>
    >       <within-pointcut classname="POJO">
    >       <interceptors>
    >          <interceptor class="TracingInterceptor" />
    >       </interceptors>
    >    </attach-interceptors>
    > </aop>
    >
    > This small change to your design would make JBoss much more like AspectJ, and IMHO much more powerful. (AspectWerkz made essentially this change over the summer.) It would make pointcuts first-class, so that you could abstract and compose over them. You could then write things like:
    >

    Ok, that would not be a difficult thing to do, we like what the aspectWerkz guys are doing anyway and are talking to them.

    > <aop>
    >    <define-named-pointcut name="foo">
    >       <within-pointcut classname="POJO">
    >    </define-named-pointcut>
    >    <attach-interceptors>
    >       <named-pointcut name="foo">
    >       <interceptors>
    >          <interceptor class="TracingInterceptor" />
    >       </interceptors>
    >    </attach-interceptors>
    > </aop>
    >
    > and later change just the definition of foo, for example to be:
    >
    >    <define-named-pointcut name="foo">
    >       <and-pointcut <within-pointcut classname="foo">
    >                     <call-pointcut methodname="helloWorld">
    >       >
    >    </define-named-pointcut>
    >
    > (forgive me if I get the XML wrong)

    Ok that is interesting. I see 3 things

    1- Late binding of interception. Again interesting if you are doing runtime dynamic (not aspectJ classloading stuff) aspects and already supported in JBoss

    2- composition. Defining composing pointcuts as pointcut foo = pointcut faa + pointcut fee and applying bindings to pointcut foo is an interesting one. However an example, specifically an example in the static world of aspectJ would be relevant, apart from saving on the XML mumbo jumbo (for those that do XML like AW and JB) what does it REALLY buy us? use case! use case! saving on XML is not groundbreaking but a nicety and we will definitely put it in.

    3- contextual computing. Something completely missing from static AOP (aspectJ) is the capacity to bind interceptors based on context. An example of context is "application", the same pojo may be accessed from different application and the security interceptor (for example) completely depends on the application context. That is impossible do to in EJB and AspectJ yet it is a vibrant research community in middleware. Late binding of contextual logical container IS relevant and groundbreaking. But don't let me oversell you on it we don't have support in JBoss yet. It wouldn't be that hard though as we have a level of indirection and configuration of interceptors that could be applied dynamically as the thread is tagged (through the Invocation object in JBoss3-4 series) with the application identifier and the object knows to insert that stack for that thread. powerful stuff, more research oriented at this point.
     
    > This would give you compositional crosscutting, which I'm saying is the
    > new idea of AOP. I don't *think* you have compositional crosscutting now,
    > which would explain why you see AOP as just interception and introduction.

    AOP as interception and introduction and a language to put it together. Compositional weaving, besides being an xml saver would need to be justified through use-cases, let us work on that (just the xml would classify as 'nice to have' not defining). In any case there is already support for indirected pointcut and binding so composition would be quite trivial to add. Will do. Merci.

    marcf
  97. I too give up.[ Go to top ]

    It's amazing how both yourself and Bill Burke come across like experts and authorities on a subject in which you are neither. It's amazing to watch you both talk down to acknowledged (and real) experts in a field like they are children.

    And it's sad and amazing at the same time how much damage this dynamic duo is doing to both the industry in general and AOP specifically.

    I only wish I had the poise and restraint which Gregor has demonstrated here. But I don't, so I will sign off saying: Marc, Bill - your posts here are making almost no sense, as usual for JBoss people your posts are contradicting each other, there's more slight of hand and marketing fluff going on here then actual technical discussion, and you run away from valid technical points from other people like they were flaming swords aimed at your hearts. Your individual credibilities, and the greater credibility of JBoss in market is, IMHO, severely weakened by your various posts here.

        -Mike
  98. AOP - interception > 0[ Go to top ]

    Rickard,

    > > AspectJ has specified how to define the event
    > > you want to intercept and what code you want to trigger based on that event.
    >
    > No, what they have done is "enabling programmers to modularize crosscutting structure in their code".
    >

    and what we are doing is identifying a clear and useful and immediate subset of behavior, all the services an appserver provides and offer them as a library to developers and a way to easily assemble them.

    The easy way to assemble them is what we are talking about when we disagree. I am not sold on the fact that you need a language and I argue over and over that UML2 is closer to a solution, a visual one, than tags are (which are class bound) and aspectJ is which classbound by and large and static.

    It is a simple

    AOP-interception == pointcut language.

    That language is VISUAL. At most xml driven, at worst language driven.
     
    > > The concepts though of AOP are old and familiar.
    >
    > No, because before AOP there was no paradigm which was "enabling programmers to modularize crosscutting structure in their code".

    orthogonal code reuse is as old as routines and OOP.

    JDK is a library of code that you reuse over and over. DO you think twice about the "Collections" framework? did you ever read its source? maybe you did, but the vast majority JUST USES that cross cutting structure.

    In the same sense what we are doing in JBoss 4 is give you a LIBRARY of crosscutting structure that are the services the appserver brings you. And we give you simple ways, programmaticaly speaking to weave it in.

    In java you new() an object in JBossAOP you insert that behavior in your objects and classes.

    System behavior as aspects will be as familiar and intuitive and TRANSPARENT as working with JDK classes one day. In fact the J2EE standard effort I would like to push is not AOP it is the aspects themselves. That is a generalization of EJB en route to greater and generalized containers.


    > Get it?

    stay off physics analogies ;)

    marcf
  99. Teaching Granma to suck eggs[ Go to top ]

    \Bill Burke\
    There's a lot of talk about how us JBoss folks don't understand what AOP is. But please tell me how we have used AOP in the wrong way to apply the aspects we have written to application code. We have a clear separation of concerns with the aspects we are writing and how to apply those aspects to application code.
    \Bill Burke\

    Wow. Bill Burke, with his mountainous amount of software development experience (what is it, Bill, a whopping 6 years?), telling Gregor Kiczales what AOP is and is not. Yes, the JBoss kids know it all, and highly respected and accomplished researchers like Gregor are all wrong.

    The man who's been looking at AOP in-depth for longer than your professional career, and is the acknowledged leader in the field, is wrong, and the mighty "Chief Architect" of JBoss is right.

    Sheesh.

    As to what's wrong with your approach, this has been pointed out in too many public conversations to mention. You just choose not to listen.

        -Mike
  100. AOP - interception > 0[ Go to top ]

    What you've done, IMO, is taken interception and introduction

    > and apply it to a language that does not have those concepts
    > built in.

    You keep repeating your basic position that AOP is just interception
    and introduction. (As do I repeat mine that it is more.)

    Let me try it in very mechanistic terms (so I will talk about AspectJ in particular not AOP in general). What is new in AspectJ is pointcuts, not
    advice. Advice is like interception (old). But pointcuts give you a way
    of talking about <where/when to do interception> that is:

    compositional - you can compose pointcuts with others usefully

    crosscutting - it doesn't have to follow the existing module
                    structure

    non-invasive - you don't have to touch any of the points at
    (oblivious) which the interception will occur

    (Note that AspectJ pointcuts are different from JBoss pointcuts. The
    pointcuts in the most recent AspectWerkz are much more like those in
    Aspectj.)

    I don't believe something like pointcuts existed before, pointcuts are
    more than interception.
    (The closest thing before was full reflection (intercession), and what's
    important about AOP with regard to full reflection is that it is less
    powerful and more declarative.)

    > The concepts though of AOP are old and familiar. Introductions
    > are concepts that Smalltalk/ObjectiveC has had since the beginning.
    > Interception has been used in one form or another for over a decade
    > in one framework or another (at least from my experience).

    You're doing it again. So will I! :)

    Interception is old, but that's not all there is to AOP (see above). And
    introduction (aka open classes) is indeed old, although the prior mechanisms
    didn't have things like type patterns, which have some of the same properties
    as pointcuts.

    > There's a lot of talk about how us JBoss folks don't understand
    > what AOP is. But please tell me how we have used AOP in
    > the wrong way to apply the aspects we have written to application
    > code.

    This trick won't work.

    No one is saying that you are using AOP wrong. And no one is saying
    that you misunderstand AOP. All I see people saying is that when you
    claim AOP is just interception and introduction, you are leaving a big
    part out. While leaving that out may be a good move with regard to
    marketing reasons (for example to reduce the perceived dangers of AOP
    for your customers) it isn't an accurate portrayal of what AOP is.
  101. AOP - interception > 0[ Go to top ]

    Professor,

    You got bill and I at the back of the class running wild with your stuff, we've done our home work, we done research, we talked to other researchers that are embrassing AOP, we seen the middleware community EMBRACE AOP as system nirvana. Rickard is the good kid on the front row, looking at you with puppy eyes, but don't believe him he is a B- student, he is just sucking up ;)

    I did that talk in RIO, the keynote for the middleware conference, you should have seen the middleware crowd, wild and throwing panties at us, like superstar DJ's. You have seen some of them at the last AOSD (they refer to paper in your conference) but I don't know if you realize what is going on in our field, it is your first mass market success and JBoss is running ahead with it (and BEA's is doing a feeble attempt at following).

    The guys get it, it is useful in many forms, even the simplest ones.

    > You keep repeating your basic position that AOP is just interception
    > and introduction. (As do I repeat mine that it is more.)

    Not quite, we say

    AOP for systems == interception + introduction + pointcuts

    Bill clobbered the point on interception, I clobbered the introduction (fan of dynamic that is what we need in the VMs). It is how you define the pointcuts that we are discussing here. For most practical aspects we are shipping xml and tags, or no tags and dynamic behavior is sufficient. Meaning that as far as use cases go we are well beyond the logging example that still plague theoretical AOP, we don't feel the pain enough to justify a language for pointcuts. Or rather we feel some of it and the solutions are visual imho, at worst scripted, not compiler based... More on that language below.

    > What is new in AspectJ is pointcuts, not

    is it its only 'raison d'etre'?

    The philosophy of AspectJ, forcing designers to modularize cross-cutting concerns is AOP for sure, but 'theoretical AOP' more a design methodology than a real framework.

    > But pointcuts give you a way
    > of talking about <where/when to do interception> that is:
    >

    That's right. A language to do that is overkill in all scenarios we run into. We still need a clear use case today of that need. To many AOP'ers (including bill's first article) focus on the logging aspect, one that certainly doesn't require a language to specify where. We are already counting almost 10 new aspects in JBoss and we still don't need nothing more than XML. We need that use case.


    > compositional - you can compose pointcuts with others usefully

    give me an example use case.

    > crosscutting - it doesn't have to follow the existing module
    >                 structure

    ok

    > non-invasive - you don't have to touch any of the points at
    > (oblivious) which the interception will occur

    yes we do that, see TreeCache/persistence/monitoring.


    > > There's a lot of talk about how us JBoss folks don't understand
    > > what AOP is. But please tell me how we have used AOP in
    > > the wrong way to apply the aspects we have written to application
    > > code.
    >
    > This trick won't work.

    it should, as we are sitting here with probably the most succesful example of your technology in the mass market. This year there will be 3M downloads of AOP enabled server, the masses will be non the wiser for it, except that the frameworks will be simpler, and we should get an A+ for it, professor. Applied AOP is rulling the generalized container theory.

    >
    > No one is saying that you are using AOP wrong. And no one is saying
    > that you misunderstand AOP. All I see people saying is that when you
    > claim AOP is just interception and introduction, you are leaving a big
    > part out. While leaving that out may be a good move with regard to
    > marketing reasons (for example to reduce the perceived dangers of AOP
    > for your customers) it isn't an accurate portrayal of what AOP is.

    Ok, not to brag but I was talking to grady booch and dean wampler from IBM the other day. Dean came to our AOP panel and the talk went great. Next week I will meet Ivar Jacobson for the first time and I am about to pee my pants.

    The point is not so much much name dropping as the fact that I am trying to evangelize a VISUAL approach to pointcutting.

    Visually applying service aspects to objects is a trivial VISUAL task. I don't need a query language to say

    "take these object from my runtime and make them persistent, now take these objects from the front and make them remote, use SOAP and NRMI semantics for copy restore, now take these objects in the web layers and make them ACID with respect to the transactions that are going to come through them"

    I can totally see the "minority report" screen of visual tools that are to come out of IBM research (if I can only sell them on it) with UML2. It's kick ass stuff. Adrian Brock, JBoss Group director of support and JMX author was pitching that in fact the minority report analogy wasn't that crazy. On one hand of the screen you have the aspects (for systems at least) on the other hand you have the POJO classes. Adding behavior at development time is one hand mixes with the other which tells the system, visually, to 'please insert this behavior in this object'

    I will be so proud the day a JBoss system consultant walks into a running installation of worldwide routers and is capable of jacking in the 'minority report' goggles and screen and can look at a running graph and say "insert diagnostics here", where by the way we are inserted the latest and greatest diagnostics from 'diagnostic inc a subsidiary of jboss group' and that code wasn't added at development time. That code however sends a contextual sticky thread that collects all log4j messages on a invocation (we have that in the drawing boards actually) and sends that back. Once you are done with it, you remove the aspect (only JB4 and up) remove your goggles, light a cigarette and walk out in the setting sun.

    And like that 'pfff' he is gone.

    oh... I can't wait, I can't wait.
  102. AOP - interception > 0[ Go to top ]

    I got all carried away on the vision crack and forgot the second possibility for the language.

    Just to rehash, the first possibility for the language is a visual assembly language the "minority report" vision.

    The second possibility stems from the SAP world where I used to work and the presence of work-flow engines. These engines are masters at computing state and deciding on contextual state what to do next. I haven't run into a complex scenario yet, but can foresee that if you want to do user-land AOP for enterprise designs (we do systems) then you need that work-flow engine. That kind of logic enables you to say 'if condition A/B/C/D are met then apply this pointcut on all the records that exhibit that behavior'. Whether AOP is the best approach for this remains to be seen, there are many languages out there that do that kind of contextual AI.
  103. AOP - interception > 0[ Go to top ]

    CEO,

    > Not quite, we say
    >
    > AOP for systems == interception + introduction + pointcuts

    I misunderstood what Bill was saying. I thought he was saying AOP was just interception plus introduction.


    > I will be so proud the day a JBoss system consultant walks into a running installation of worldwide routers and is capable of jacking in the 'minority report' goggles and screen and can look at a running graph ...

    Sounds very cool. Also makes me realize that I was wrong to think that you were worried about scaring people with AOP seeming too high tech! :)
  104. Ivar+Marc=True![ Go to top ]

    Next week I will meet Ivar Jacobson for the first time and I am about to pee

    > my pants.

    Funny you should mention him. I did a seminar in Stockholm about a year ago, and Ivar presented after me. I was as eager to see/meet him as you are now, but it was rather embarassing to see his talk. Totally over-inflated ego, exceeding his time limit by about 30 minutes, much of which was spent talking about a seminar in China where they wanted his autograph, and what he said provoked quite a few giggles in the audience as he showed a graph over expressability of languages. The graph was rising steadily as newer languages were presented, and ended in Java being the best one yet but still being quite low on the graph. Then it was a giant leap as the next marker on the graph said "UML". He wants to program in UML, just like you, and the more he talked the audience began giggling. His "bonus" slide on why RUP is superior to XP was also quite confusing, as he tried to explain that the two were almost incomparable since, after all, RUP is 15.000 pages and XP is only a fraction of that.

    I looked over to the organizer of the conference who was visibly uncomfortable, and almost apologized when I talked to him afterwards.

    To summarize, I think you two will get along just fine. :-)

    /Rickard
  105. AOP - interception > 0[ Go to top ]

    On the one hand:
    > Rickard is the good kid on the front row, looking at you with puppy
    > eyes, but don't believe him he is a B- student, he is just sucking up ;)

    And on the other hand, from "Why I love EJBs" by MarcF:
    "I remember Rickard Oberg, then a grad student in Sweden, giving me a brand new container design, something
    totally alien, something based on dynamic proxies and interceptors. I remember how logical, magical and
    lightweight the result was. I remember throwing away my own work and starting from scratch based on his
    ideas. I proved the point that dynamic proxies generate superior middleware, way superior to compilation-
    based approaches. Most of the industry still doesn’t get it."

    Bill, be aware that whether Marc calls you an "A" student or "B-" student has nothing to do with your actual abilities, and everything to do with whether he happens to like you or not that day. Just a tip for future reference.

    /Rickard
  106. AOP - interception > 0[ Go to top ]

    marcf:
    I proved the point that dynamic proxies generate superior middleware, way superior to compilation-based approaches.


    Well, I proved the exact opposite not long ago. There's not enough room in the margin to reproduce my demonstration, so I'll leave it as an exercise to the reader, but it's obvious. Really.

    --
    Cedric
    http://beust.com/weblog
  107. AOP - interception > 0[ Go to top ]

    Well, I proved the exact opposite not long ago. There's not enough room in the

    > margin to reproduce my demonstration, so I'll leave it as an exercise to the
    > reader, but it's obvious. Really.

    Does it have anything to do with tunneling protocol A in B always being more heavyweight than using protocol A directly? Am I on track?

    /Rickard
  108. AOP - interception > 0[ Go to top ]

    Cedric: Well, I proved the exact opposite not long ago. There's not enough room in the margin to reproduce my demonstration, so I'll leave it as an exercise to the reader, but it's obvious. Really.

    Rickard: Does it have anything to do with tunneling protocol A in B always being more heavyweight than using protocol A directly? Am I on track?

    I've proven it for numbers up to 3 ... all you have to do is prove it for 4 and beyond. ;-)

    (See "Fermat's Last".)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  109. Suggestion[ Go to top ]

    I would like to suggest that the following people come over to my house for an all-night party:

    - Marc Fleury: Marc should arrive wearing a yellow T-Shirt, ear-muffs and a pair of those open-toed Birkenstock sandals. He should have a toothpick hanging out of the left side of his mouth, it must be well-chewed.

    - Rickard Oberg: Rickard should present himself at the entrance with horn-rimmed glasses that contain only plain glass, no prescription lenses. As I open the door, Rickard should be holding a case of Canadian Labatt's Blue in one hand, and "NHL Hockey" by EA Sports for Genesis in the other. We will be holding a Genesis video game hockey tourney all night, round-robin.
     
    - Cedric Beust: Cedric will arrive late and park his car on my lawn.

    - Gregor Kiczales: Gregor will immediately ask about sleeping arrangements when he arrives, and hint at the convenience of a private washroom. He will introduce himself to the others as having just got over the flu, making it easy for him to not participate in the party if he should find himself needing the excuse to do so. Very proactive of him...

    ~C
  110. Oh[ Go to top ]

    Oh, and Cameron Purdy is invited too, but he will immediately lose at the video game tournament and suggest that we all engage in Yahtzee, because he can't stand anything to do with Sega (he's a Nintendo man by heart) but doesn't really want to admit it. Cameron will occassionally be the life of the party, but draws the line at ever really controlling the conversation for too long...

    ~C
  111. Yeah, Right[ Go to top ]

    Oh, and Cameron Purdy is invited too, but he will immediately lose at the video game tournament and suggest that we all engage in Yahtzee, because he can't stand anything to do with Sega (he's a Nintendo man by heart) but doesn't really want to admit it. Cameron will occassionally be the life of the party, but draws the line at ever really controlling the conversation for too long...

    Yahtzee? Is that the game in which I would rail-gun your camping azz?

    BTW what does this have to do with AOP or the Bill Burke interview? Are you saying that if Quake IV were built in Java, we could use AOP to build mods? Now that is something that could really draw some interest ....

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  112. AOP - interception > 0[ Go to top ]

    What you've done, IMO, is taken interception and introduction

    > > and apply it to a language that does not have those concepts
    > > built in.
    >
    > You keep repeating your basic position that AOP is just interception
    > and introduction. (As do I repeat mine that it is more.)
    >
    > Let me try it in very mechanistic terms (so I will talk about AspectJ in particular not AOP in general). What is new in AspectJ is pointcuts, not
    > advice. Advice is like interception (old). But pointcuts give you a way
    > of talking about <where/when to do interception> that is:
    >
    > compositional - you can compose pointcuts with others usefully
    >

    I've thought a lot the compositional nature of pointcuts and I'm not exactly sold yet on its relative impact.

    1) I think that if your application is starting to use complex compositional pointcuts, you're probably doing something wrong as your application code will become much harder to read and you'll be less able to tell what actual classes and such the given pointcut applies to. Our scope in the use of AOP is myopic in the sense that we've only applied it to middleware, so maybe compositional pointcuts have other uses that we are oblivious to. I'll check out the aosd site and aspectj site again to see if there are any papers/articles about further use cases of compositional pointcuts.

    2) That JSR-175 and metadata will replace a lot of the need of compositional pointcuts. One of your examples in the TSS interview under the question "What are your thoughts on the relationship between metadata (JSR-175) and AOP? Will we define pointcuts based on metadata on methods?"

    particularly:

    P.S. Note that if you write without attributes, something like:

    pointcut changesDisplayState(): call(void Point.setX(int)) || ...;

    after(): changesDisplayState() { Display.update(); }

    then both concerns are well localized in the code! Which just goes back to that we have some learning to do in terms of guidelines for when to use attributes and when not to. I'm writing something about that now, but its not ready to send out.


    I'm wondering if this is the way a lot of users actually use composition. It just seems to me that attributes could replace a lot of the need for compositional pointcuts.

    3) Then again, maybe the real power of compositional pointcuts is when you want to use AOP as a Rules engine and define Rules as pointcuts. Although I've never built an application that used a rules engine, I'm wondering if it would be better to delegate this kind of responsiblity to a real work-flow or rules engine.

    > crosscutting - it doesn't have to follow the existing module
    >                 structure
    >

    Don't get you here. Interception allows you to do crosscutting and the structure does not have to follow existing module structure.

    > non-invasive - you don't have to touch any of the points at
    > (oblivious) which the interception will occur
    >

    At least when I've used interception, its always been non-invasive. And I used interception to provide separate of concerns.

    > (Note that AspectJ pointcuts are different from JBoss pointcuts. The
    > pointcuts in the most recent AspectWerkz are much more like those in
    > Aspectj.)
    >
    > I don't believe something like pointcuts existed before, pointcuts are
    > more than interception.
    > (The closest thing before was full reflection (intercession), and what's
    > important about AOP with regard to full reflection is that it is less
    > powerful and more declarative.)
    >

    I guess I made too far of a leap saying that if you want to further generalize and expand interception, you obviously need some way of defining the events you want to intercept.

    > > The concepts though of AOP are old and familiar. Introductions
    > > are concepts that Smalltalk/ObjectiveC has had since the beginning.
    > > Interception has been used in one form or another for over a decade
    > > in one framework or another (at least from my experience).
    >
    > You're doing it again. So will I! :)
    >
    > Interception is old, but that's not all there is to AOP (see above). And
    > introduction (aka open classes) is indeed old, although the prior mechanisms
    > didn't have things like type patterns, which have some of the same properties
    > as pointcuts.
    >
    > > There's a lot of talk about how us JBoss folks don't understand
    > > what AOP is. But please tell me how we have used AOP in
    > > the wrong way to apply the aspects we have written to application
    > > code.
    >
    > This trick won't work.
    >
    > No one is saying that you are using AOP wrong. And no one is saying
    > that you misunderstand AOP. All I see people saying is that when you
    > claim AOP is just interception and introduction, you are leaving a big
    > part out. While leaving that out may be a good move with regard to
    > marketing reasons (for example to reduce the perceived dangers of AOP
    > for your customers) it isn't an accurate portrayal of what AOP is.

    Ok, I'll stop stating publicy that all AOP is, is interception and introduction. But in my mind, you cannot have separate of concerns without interception, yet, you could still have separation of concerns without pointcuts, compositional pointcuts, type safety etc....To me these are just implementation details and the power of the given framework that provides those features.


    Bill
  113. AOP - interception > 0[ Go to top ]

    I've thought a lot the compositional nature of pointcuts and I'm not exactly sold yet on its relative impact.

    >

    We need a use case that's all. To tell the difference between "logical progression" of the framework and actual "must have" you need the real life. Unfortunately Computer Science is less a science than it is a trade (imho) like legal or medicine and until I see a case that says "I cannot survive without composition" I will view it for its immediate benefit, smaller XML due to one more layer of indirection in the naming.

    See if the pointcut composition still starts with class level pointcuts (state/methods/constructors) then combinations thereof will still refer to a body of state/methods/contstructors or rather to a set of them across a hierachy of classes. Big deal, XML saver.

    The rules engine point IS AN ENTIRELY DIFFERENT POINT, but it hasn't been argued by anyone here, we are in meta-talk land and opinions land most of the time.
     
    >
    1) I think that if your application is starting to use complex compositional pointcuts, you're probably doing something wrong as your application code will become much harder to read and you'll be less able to tell what actual classes and such the given pointcut applies to.
    >

    again with compositional bla bla I save time on XML, it is a nice to have not a must have. Show me a FEATURE that is impossible without it, say like dynamic monitoring when we introduce dynamic AOP. Dynamic AOP is a clear MUST HAVE for a whole new field of aspects that require the dynamicity.

    >
    Our scope in the use of AOP is myopic in the sense that we've only applied it to middleware, so maybe compositional pointcuts have other uses that we are oblivious to. I'll check out the aosd site and aspectj site again to see if there are any papers/articles about further use cases of compositional pointcuts.
    >

    hmmm, the onus is on aspectJ imho. I stay steadfast in my position that MOST USERS DON'T CARE, SHOULDN"T CARE about AOP. We are sitting here in a discussion that appears deep to outsiders, but it isn't really, it is shallow, the depth is in the aspects, the library for reuse.

    Our main claim here is that there is a excellent match between middleware technology and AOP, that much is trivially established as middleware is "orthogonal concerns" to the applications. Mathematically speaking Middleware => AOP. We don't have AOP <=> middleware (which would say that middleware is equivalent to AOP and thus no other application than middleware will ever see the mass media light of the day.

    On a positive side it is not up to the JBoss crowd to establish that, it is up to the aspectJ guys to establish mass penetration of user land AOP as a succesful constructs and then all the AOP'ers including us at JBoss will cheer and recognize it as a valid approach.

    >
    > I'm wondering if this is the way a lot of users actually use composition. It just seems to me that attributes could replace a lot of the need for compositional pointcuts.
    >

    compositional pointcuts is just a Sygma(local pointcuts), you don't logically define a new class of pointcuts just a new set of existing pointcuts.

    I will say it clearly: you don't need a language like aspectJ to do that. It is silly and overkill.

    "here kid, sit in this class and we will teach you a new language"
    "cool, what can I do with it"
    "compositional pointcuts"
    "cool, what can I do with it"
    "we don't know yet"

    PR and marketing are tricky and trust me when you reach mass media and public scrutiny, you better know that what you got is justified. Otherwise you get a wall of "huh?" by guys you always preface their response with "this is really cool, I can feel the sexyness, but frankly I wouldn't know what to do with it.

    It is part of the reason we are shifting the message from AOP itself (again we shouldn't throw that message to the users) to the aspects themselves such as the discussion on ACIDITY here and transactional demarcation and cache replication and persistence. I am surprised persistence as aspects hasn't really catched on as a discussion. Application of AOP, what you do with the aspects, what is it good for, how everyday ISV and OEM and IT will use this stuff is what we must talk about. Whether you use, aspectJ or JBossAOP to weave in JBoss Aspects is secondary, and within that secondary discussion the use case for compositional aspects almost completely academic at this point.


    >
     3) Then again, maybe the real power of compositional pointcuts is when you want to use AOP as a Rules engine and define Rules as pointcuts. Although I've never built an application that used a rules engine, I'm wondering if it would be better to delegate this kind of responsiblity to a real work-flow or rules engine.
    >

    Correct, although again compositional pointcuts == sum(existing pointcuts).

    You don't introduce a new CLASS of pointcuts. Whereas a rules engine WOULD INTRODUCE A NEW CLASS OF POINTCUTS. Trigger that are not tied to the body of the code (which we couldn't care less about in this case) but are tied to LOGICAL CONDITIONS OF THE CONTEXT would create an entirely NEW CLASS of pointcuts. Meaning a rules engines or an AI analyser would be capable or creating new pointcuts in the application that have nothing to do with method/class/constructor, and are impossible to express in JSR175 class level XML lingo.

    Yeah that may be useful, and I am sure there are some folks in academia that have generated some way to automate these logical pointcuts. The threads that are spewed from these engines are completely detached from user threads. We can come up with use cases I am sure.

    You could STILL define composition of these pointcuts.
     
    > Don't get you here. Interception allows you to do crosscutting and the structure does not have to follow existing module structure.
    >

    GregorK was not making fun of interception he was just listing the features needed.

    > > non-invasive - you don't have to touch any of the points at
    > > (oblivious) which the interception will occur
    > >
    >
    > At least when I've used interception, its always been non-invasive. And I used interception to provide separate of concerns.
    >

    The XML we have can be non-invasive, cacheAOP defines zero binding, they are all programatically triggered by cache insertion in JBoss 4.

     
    >
     Ok, I'll stop stating publicy that all AOP is, is interception and introduction.
    >

    aaah the gist of the discussion here, is the pointcut language.

    WHO CARES?

    instead of bickering we should all go back to our respective implementations and push our super-users strands of AOP, a standard will emerge (hopefully BOTH implementation and specification) until then we should call AOP all these and appear united, we are in fact united in how we all use AOP, as a methodology for modular concern generation, (JBoss is a sum of them) and how we specify them is really secondary.

    Mass adoption of the 'why' as bill said, should prevail over the less interesting (at least to the mass of developers) 'how' as far as pointcut generation goes.

    >
    > Bill

    marcf
  114. AOP is about users[ Go to top ]

    marcf:
    It is part of the reason we are shifting the message from AOP itself (again we shouldn't throw that message to the users) to the aspects themselves


    Good, you are finally getting it.

    This is exactly why we

    - Didn't reinvent our own AOP framework (we built on an existing base).
    - Shipped pre-made pointcuts (so that users don't have to learn how to define them).
    - Provided a few example aspects to get them started (more to come).

    --
    Cedric
    http://beust.com/weblog
  115. AOP is about users[ Go to top ]

    marcf:

    > It is part of the reason we are shifting the message from AOP itself (again we shouldn't throw that message to the users) to the aspects themselves
    >

    >
    > Good, you are finally getting it.
    >
    > This is exactly why we
    >
    > - Didn't reinvent our own AOP framework (we built on an existing base).
    > - Shipped pre-made pointcuts (so that users don't have to learn how to define them).
    > - Provided a few example aspects to get them started (more to come).
    >
    > --
    > Cedric
    > http://beust.com/weblog

    I saw your presentation Cedric. All you seem to be doing is giving a set of pointcuts into your codebase. Pretty lame since we've had that with our EJB interception framework for some years now. We're actually providing POJO based middleware.

    Bill
  116. AOP - interception > 0[ Go to top ]

    \marc fluery\
    We need a use case that's all. To tell the difference between "logical progression" of the framework and actual "must have" you need the real life. Unfortunately Computer Science is less a science than it is a trade (imho) like legal or medicine and until I see a case that says "I cannot survive without composition" I will view it for its immediate benefit, smaller XML due to one more layer of indirection in the naming.
    \marc fluery\

    This is an interesting mutation on the normal application of the term "use case". Systems design, application design, and language design is not normally broken down in terms of "use cases". I think a big reason why this is so is because creating an app server container, or programming language, or a wide ranging application design is not the same exercise as describing how to open a document, or access a web site, or calculate a blending of graphics channels.

    Systems/application/language design is more generalized than the notion of use cases can handle, particularly because the goals are much farther reaching and abstract. There's no "use case" for OO, there's no "use case" for compositional pointcuts. OO and compositional pointcuts are tools that are brought to bear to break someone else's use case down into managable development chunks.

    If you want to evaluate compositional pointcuts, analyze what benefits they bring to developers, and what the drawbacks are. These benefits are measured in terms of millions of developers working on thousands of projects, all with varying goals and aims. Think of the drawbacks in the same way - what impact will they have on a large user community.

    If you stick to use-case land, you're going to pigeon hole yourself into a narrow solution.

    \marc fleury\
    See if the pointcut composition still starts with class level pointcuts (state/methods/constructors) then combinations thereof will still refer to a body of state/methods/contstructors or rather to a set of them across a hierachy of classes. Big deal, XML saver.
    \marc fleury\

    Indeed. And classes are just C structs with function pointers embedded in them. :-)

    A big problem facing developers today is that many solutions are much larger than the method, class, or even Java package level. The programmer is out to create a city, but his only tools are buildings (classes) and roads (class relationships). The programmer quickly finds that at times he needs a way to deal a single building, and other time he needs to deal with groups of buildings . Let's call that a neighborhood. But if the city is really big, even a neighborhood might be too small a tool when they are considering really, really far reaching public works.

    What successful developers (and city engineers) do is describe solutions in varying levels of detail - a building, a neighborhood, a borough, a city. Plus multiple views - the subway, the streets, the water/electric infrastructure, plus buildings, plus neighborhoods, plus boroughs.

    Stretching the analogy out to its limit - Java gives us methods (floors), buildings (classes), and very small neighborhoods (packages). Everything above the package level is imposed outside of the language by the developers. People have all sorts of development practices, frameworks, scripts, and sometimes just mental models that aggregate a package into a logical sub-system of some time, that ties multiple sub-sytems into something greater, and so on in decreasing orders of magnification until you see the "application architecture" diagram showing 4 boxes and a 2 circles. :-)

    AOP is an attempt to deal with code at a higher level than a method, or class, or even a package. With an AOP system you can (in a logical sense) lasso a group of methods, classes, or packages and deal with it as a logical unit that is larger than any of those individual ones. In AspectJ, you have a new set of abstractions that let you capture greater-than-class-level collections of code _as a language level construct_. You can write larger-than-class concepts directly in code and have it enforced. It's a higher (and also different) abstraction level than what Java allows, and it's not enforced as a convention or through an external tool, but at a language level.

    What AspectJ has that JBoss AOP doesn't is the ability to work at higher abstraction levels (and to create abstractions of your own). To use a really low level example, it's like imagining C as it is with structs, and C without structs. Both have variables that you can do cool stuff with, but a struct lets you codify a relationship between variables and treat it as an abstraction. Both C and C-without-structs have variables, but the former adds a great deal of power and control (both are important together!) which translates into higher quality software, more consistency, and better producitivity, and better interoperability/standards.

    \marc fluery\
    I will say it clearly: you don't need a language like aspectJ to do that. It is silly and overkill.
    \marc fleury\

    At a low level...
    "You don't need structs to compose variable relationships - we'll stick with individual variables"

    At the next iteration...
    "We don't need classes - we'll stick with structs and function pointers."

    At some point, with the approach you're talking about, development teams will start dying the death of a thousand point cuts. And they'll start yearning for a way to aggregate pointcuts together and deal with them in a modular fashion as groups. And at the same time to make individual pointcuts more powerful.

        -Mike
  117. \fluery\
    aaah the gist of the discussion here, is the pointcut language.

    WHO CARES?
    \fluery\

    Outside of your JBoss-centric world, many people care. All of your arguments boil down to, if you'll excuse a paraphrase, "As long as it's JBoss, that's all that matters. Anything else is a trivial detail". Indeed, all of your comments appear to be centered around the question "What will give JBoss bigger marketshare, higher adoption rates, and better differentiation?". Perhaps others here care about such things, but I don't give a damn about what's better for JBoss and what juicy bits its marketing department can use.

    I care about technology, technology that works, that's as standard as feasible, and fits what I need. And I'm intensely interested in finding out the nuts and bolts of how different products get there. And as I mentioned in another post, it's pretty apparent that JBoss is moving rapidly away from standards and is consolidating as much as it can within the JBoss umbrella. And further, you're doing it without a technical plan to speak of beyond pushing up your download numbers.

    Anyway, keep on trying to pull all discussions into JBoss-is-superior orgies of self congratulation. It's rather boorish, but that's your business, and I admi it is rather fun to watch (though perhaps in a somewhat morbid fashion).

        -Mike
  118. AOP - interception > 0[ Go to top ]

    \Bill Burke\
    1) I think that if your application is starting to use complex compositional pointcuts, you're probably doing something wrong as your application code will become much harder to read and you'll be less able to tell what actual classes and such the given pointcut applies to.
    \Bill Burke\

    The term "complex" is a bit slippery - how complex is too complex?

    In a language like AspectJ, pointcuts are indeed much more than specifying what to "intercept". Pointcuts also directly tie into the static typing system - you can use things like target() and args() to not only narrow the pointcut, but you can also reference the items specified therein directly in a statically typed manner.

    You can also use things like abstract pointcuts to compose pointcuts. This is more complex than specifying just a method or a class or a field, but the complexity is constrained by the modularity of the language.

    You see, AspectJ gives you the tools to manage the comlexity. Composing compound pointcuts lets you build up, and mix and match, different specifications by name (and somewhat by inheritance), in a way very similar to inheritance and "has-a" in OO. Narrowing via things like target() and args() also not only declaratively narrow the criteria, but put the burden of type correctness on the language instead of the programmer.

    Yes, when pointcuts are coming from multiple sources, it's more complex, and there's room for errors. But in many cases it's a contract, just like OO has contracts. And it all hangs together because AspectJ is specifically designed to help you control the mechansims in a OO like way.

    \Bill Burke\
     Our scope in the use of AOP is myopic in the sense that we've only applied it to middleware, so maybe compositional pointcuts have other uses that we are oblivious to. I'll check out the aosd site and aspectj site again to see if there are any papers/articles about further use cases of compositional pointcuts.
    \Bill Burke\

    Any book on AspectJ will give you a rich set of examples of the uses of compositional pointcuts. Part of why you may have missed it is because most AOP frameworks encourage uses of AOP where you're writing cooperating code. There may be a library or container which provides certain services and hooks, but at the same time users are expected and encouraged to write their own app-specific aspects which interact with aspects from others (often in the form of provided abstract aspects). In contrast, JBoss AOP is focused heavily on POJOs, and aspects are a one-way thing, flowing from JBoss out to application developer's POJOs. Imagine a world of two-way flow, where there are POJOs, and a container's Aspects, but also a developer's aspects that may operate on/with both the container's aspects and the POJOs. JBoss has this is a very limited form, in that developer's write XML to specify what advice to apply to what app classes, but it stops there (part of this is the XML/Java split, too).

    \Bill Burke\
    I'm wondering if this is the way a lot of users actually use composition. It just seems to me that attributes could replace a lot of the need for compositional pointcuts.
    \Bill Burke\

    Meta data has its uses, but it's fairly limiting. The big problem, which was alluded to by another poster, is that you have to go around tagging stuff everywhere. You can end up building an enormous body of tags (which is really configuration information) that's a pain to maintain. Furthermore, by embedding metatags into code, you're locking your POJO in to external behavior to some extent.

    The problem is very much one of granularity, with tags in many cases being just too fine grained. You can end up in a situation where you have to maintain hundreds of tags, while an AspectJ solution could handle the same thing with a handful of pointcuts. What it comes down to is that the class or method level is something you want to avoid when you're dealing with cross-cutting concerns. If you have hundred (or thousands) of POJOs in a domain model, you don't want to go through decorating all of that code with class and method meta-data. You'd much rather work at a higher level than the class - more of a conceptual level based on collections of classes as a sub-system.

    \Bill Burke\
    Ok, I'll stop stating publicy that all AOP is, is interception and introduction. But in my mind, you cannot have separate of concerns without interception, yet, you could still have separation of concerns without pointcuts, compositional pointcuts, type safety etc....To me these are just implementation details and the power of the given framework that provides those features.
    \Bill Burke\

    The devil's in the details. VB, perl, Java, C++ - they're all object oriented languages. But calling them OO is attaching a pretty useless tag - without knowing what you call the "implementation details", you can't properly evaluate what the actual language gives you. Indeed, it's a futile exercise to study OO from a purely abstract level, because an individual language is going to demolish many of your pure OO assumpions. It's important to keep the abstract level in mind to keep high level goals straight, but it's not going to be useful information without a concrete language and practices to back that abstract knowledge up.

    Likewise, while it's important to understand abstract AOP concepts, you can't really evaluate the value of it without a concrete implementation, and that implementation is going to have quirk and warts and various design decisions built into it which is going to significantly warp the AOP ideal (just like real OO languages warp OO ideals so that they're actually useful to applying to real problems). Adding some OO stuff to VB is nice for VB programmers, I suppose, but it pales in comparison to something like Java. Java shows how limiting the VB OO really is. Likewise, the low-level, speed-oriented OO of C++ has very real problems because of that low-level/speed focus, and those problems really come into sharp focus when you start using a language like Java in-depth. A focus you may not have if you've only ever used C++.

    And so, your own AOP framework may demonstrate some aspects of AOP, and can be plausibly called AOP. And for JBoss people, JBoss + AOP may seem a nice thing. But if you use something like AspectJ for awhile, the closer-to-the-ideal semantics and day-to-day coding realities of the language bring the limitations of your AOP approach into sharp focus. It's plain as day that you've never used AspectJ to any depth, and so you don't understand what people are talking about here. And so your AOP implementation seems pretty cool. But you may want to actually take some time out and do some extended experimentation with AspectJ (it's very easy, trust me!). Stepping out of your own world and into a mature and very, very well thought out AOP system will give you something solid and real to contrast to your own efforts. And in doing so you may gain critical insight into why certain people have grown so attached to AspectJ, and apply that insight back into your own code. The end result certainly won't be AspectJ, but it will certainly be a better product for the experience. But that sort of knowledge and insight can only be gained by actually giving AspectJ some extended use, not just skimming a few books and having some casual conversation with people.

       -Mike
  119. AOP - interception > 0[ Go to top ]

    What you've done, IMO, is taken interception and introduction

    > > > and apply it to a language that does not have those concepts
    > > > built in.
    > >
    > > You keep repeating your basic position that AOP is just interception
    > > and introduction. (As do I repeat mine that it is more.)
    > >
    > > Let me try it in very mechanistic terms (so I will talk about AspectJ in
    > > particular not AOP in general). What is new in AspectJ is pointcuts, not
    > > advice. Advice is like interception (old). But pointcuts give you a way
    > > of talking about <where/when to do interception> that is:
    > >
    > > compositional - you can compose pointcuts with others usefully
    > >
    >
    > I've thought a lot the compositional nature of pointcuts and I'm not exactly sold yet on its relative impact.
    >
    > 1) I think that if your application is starting to use complex compositional pointcuts, you're probably doing something wrong as your application code will become much harder to read and you'll be less able to tell what actual classes and such the given pointcut applies to.

    A couple of thoughts about this.

    First, to have crosscutting (a pointcut mechanism) without abstraction and composition would be like having algol without procedures. It would be saying its great to be able to do this, but you'll never want to build up anything out of it. From first principles, it seems unlikely that something truly useful in constructing software would only ever want to be used in small ways, but I suppose its possible. For another perspective on this, see Abelson and Sussman. The idea that abstraction and composition mechanisms are the fundamental things a language has to provide comes from them.

    Second, there are very many examples. Ramnivas's book. Nicholas's book. Probably Ivan's book too, but I don't have a copy right now. The original AspectJ paper. The original AOP paper. The archives of the AspectJ-users mailing list has several threads about how you even need the ability to define abstract pointcuts, compose them, and then make them concrete. So examples are in abundant supply.
  120. AOP - interception > 0[ Go to top ]

    Ok, I'll stop stating publicy that all AOP is, is interception and introduction. But in my mind, you cannot have separate of concerns without interception, <yet, you could still have separation of concerns without pointcuts, compositional pointcuts, type safety etc....To me these are just implementation details and the power of the given framework that provides those features.>


    Sure you can have separation of concerns without interception. And this is an important point.

    Procedures are an excellent separation of concern mechanism. The design paradigm is procedural decomposition (functional decomposition); procedures are the composition mechansism. Procedural programming produces a fairly hierarchical decomposition.

    Object-oriented programming is an excellent separation of concern mechanism. The design paradigm is OO decomposition; objects, classes, inheritance etc. are the composition mechanisms. OO programming produces a different kind of fairly hierarchical decomposition.

    AOP is a separation of concern mechanism (that will hopefully turn out to be excellent). The design paradigm is still being developed, but it has to do with identifying concerns with crosscutting structures, and decomposing them that way. The mechanisms are something like pointcuts, something like advice, something like type patterns, something like introduction (and several other mechanisms worth studying in systems like Caesar, Demeter, etc.).

    So you can have separation of concerns without AOP at all. What you can't have without about is separation of concerns with crosscutting structure.
  121. AOP - interception > 0[ Go to top ]

    Ok I like the way the thread is turning out, technical meat is the good stuff.

    I will pull a "jacobson" on you guys and kick the discussion level up a notch on expressivity of languages.

    language == grammar + vocabulary

    and since I am not an expert at languages bear with me a second here.

    > Sure you can have separation of concerns without interception. And this is an important point.
    >
    > Object-oriented programming is an excellent separation of concern mechanism. The design paradigm is OO decomposition; objects, classes, inheritance etc. are the composition mechanisms. OO programming produces a different kind of fairly hierarchical decomposition.
    >

    Ok I think most people here understand the point you are making, namely that OO is a good methodology to do design (object are chunks or RE-USABLE code) and the OO languages rebuild hierarchical decomposition by new() of objects and building graphs at runtime.

    But what make the power of java over say C++ is the library of pre fabricated objects one could reuse, again you don't think twice about using a Map or Collection you just use it.

    So the grammar is the java syntax but the vocabulary is the JDK libraries.

    I see the same going on in AOP and we say the library to use are the SYSTEM aspects in JBoss for example. That is why we feel middleware is such a great fit, because we can ship aspects and features, that make up the basic system for middleware and users can leverage that power without the constraining body of J2EE/EJB.

    That library needs to grow, gone are the days of the logging example as the only pre-packaged aspect we can talk about.
     
    >
     So you can have separation of concerns without AOP at all. What you can't have without about is separation of concerns with crosscutting structure.
    >

    When you say this I keep hearing SYSTEM. Systems are by definition crosscutting structures. What degree of re-use exists today in business applications? There is no standardized customer object or aspect, there is no standardized "account" there are however standardized libraries for net and set manipulation in JDK. In the same way there are today a collection of aspects in JB4 that the end user can apply because they are truly re-usable in a completely transparent fashion.

    The question of user interaction is an interesting one and for me lies somewhere in a research field around visual modeling as the "minority report" vision or UML2 or what have you, a simple language that can compose sentences such as "apply persistence to this class, cache replication to this instance, and monitoring of performance to these connectors" our vocabulary of operating system is enhanced with the words 'persistence, replication, monitoring' and we must expand that vocabulary for end-users to grock AOP.

    Ironically they will grock AOP the day they use it without knowing if it is tag-driven-interception just like I use java without knowing it is "pointers-to-function-calls" or whatever it really is. To me persistence is a property of an object that can be bolt on at run-time... and that is a natural way to think and work with it.

    marcf

    PS: I am at IBM wattson today and speaking tommorrow morning (Ivar will be here rickard, and I am still excited to meet the man ;)),

    http://www.jboss.org/index.html?module=html&op=userdisplay&id=news/events
  122. AOP - interception > 0[ Go to top ]

    \marc fleury\
    But what make the power of java over say C++ is the library of pre fabricated objects one could reuse, again you don't think twice about using a Map or Collection you just use it.
    \marc fluery\

    To an extent, yes. But it's not the real source of the power. You'd be more on the mark if you said:

       - Simplicity
       - Dynamic (Clsas.forName().newInstance())
       - Simplicity
       - Clean interface mechanism
       - Simplicity
       - Exceptions instead of core dumps
       - Simplicity

    I understand that you've created JBoss, not Java, and so you're inclined to emphasize object libraries/frameworks/containers over the core language and core runtime. But I think you've got a bit over inclined here. VB can access a staggering amount of COM-like stuff from languages like C++, but this doesn't make VB more powerful than anything.

    The core semantics make a big productivity difference. This is even more true when you're talking to established shops with their own frameworks and libraries (like the financial services companies you're aggressively courting now).

    To put another way - if you took all of Java's pre-packaged stuff, went back in time and mandated it as Core C++ in 1990, a language like Java would have still resulted, and C++ would still have its same old problems.

    \marc fluery\
    I see the same going on in AOP and we say the library to use are the SYSTEM aspects in JBoss for example. That is why we feel middleware is such a great fit, because we can ship aspects and features, that make up the basic system for middleware and users can leverage that power without the constraining body of J2EE/EJB.

    That library needs to grow, gone are the days of the logging example as the only pre-packaged aspect we can talk about.
    \marc fleury\

    Everything runs in cycles, and I can easily see a cosmic wheel turning, and some X years from now people bemoaning the "constraining body of JBoss System Aspects". With the views you've espoused here, that's exactly where I believe you are heading. The main difference is that it will be proprietary, and probably not heap as much damage on the development world.

    \marc fleury\
    When you say this I keep hearing SYSTEM. Systems are by definition crosscutting structures. What degree of re-use exists today in business applications? There is no standardized customer object or aspect, there is no standardized "account" there are however standardized libraries for net and set manipulation in JDK. In the same way there are today a collection of aspects in JB4 that the end user can apply because they are truly re-usable in a completely transparent fashion.
    \marc fluery\

    The crucial piece you're missing is rather simple: the concept of plain old developers writing their own aspects, and defining their own cross-cutting structure. There are, in fact, far more application-specific cross-cutting concerns in code today than generic concerns that can be implemented in a container such as JBoss. Developers get a much bigger bang out of using AOP to address their own concerns, then they will by using a handful of concerns from a proprietary source. The difference is, of course, you can't sell that. It puts the power in the hands of individual developers, and draws it away from the JBoss core.

    Perhaps standard aspects and abstract pointcuts will grow out of the above, and a standard will arise in time for truly generic concerns. If so it would come from many thousands of developers kicking the AOP tires, seeing what works, and learning their own lessons, and developing the technology over time. This is fairly close to what Weblogic has done.

    You see, Mr. Fleury, what you're missing is that people can easily do transactions and persistence and logging today. They have a thousand and one choices for _that_ space, and JBoss and JBoss' "system aspects" are a tiny, tiny little slice of that pie. Hell, they could use Spring or a number of other frameworks if they just want auto-magic behavior along those lines, no need to become the 3 millionth and 1 JBoss downloader.

    What people _can't_ easily do today is write code that cross cuts their code structure. Well, no, actually they can - with existing products like AspectJ.

    On the flip side, looking at your quote "in completely a transparent fashion". Oh, brother - you honestly believe that, don't you?

    \marc fleury\
    Ironically they will grock AOP the day they use it without knowing if it is tag-driven-interception just like I use java without knowing it is "pointers-to-function-calls" or whatever it really is. To me persistence is a property of an object that can be bolt on at run-time... and that is a natural way to think and work with it
    \marc fluery\

    Literally tens of thousands of developers have learned the hard way that you never "bolt" something like persistence onto anything without some serious consequences. Persistence is a bit more complicated then sticking a class name in an XML file and saying "persist me, baby". This is a lesson, IMHO, which yourself and Bill Burke have yet to learn, but will also learn the hardway in the near future.

       -Mike
  123. AOP - interception > 0[ Go to top ]

    The crucial piece you're missing is rather simple: the concept of plain old

    > developers writing their own aspects, and defining their own cross-cutting
    > structure. There are, in fact, far more application-specific cross-cutting
    > concerns in code today than generic concerns that can be implemented in a
    > container such as JBoss.

    From my own experience, building a CMS product using AOP techniques, I can say that this is absolutely true. The first months or so we wrote loads of system aspects, and a linearly increasing number of application aspects. After that the system aspects began leveling, and now we write about one system aspect each month, if even that. But, the application aspects (both mixins and advice) still increase in a linear fashion (almost anyway, because now we can start reusing even application aspects more and more). In about six months from now I think we will almost exclusively be writing application aspects, since all the system aspects are "done", at least for our purposes.

    > Developers get a much bigger bang out of using AOP to address their own
    > concerns, then they will by using a handful of concerns from a proprietary
    > source. The difference is, of course, you can't sell that. It puts the power
    > in the hands of individual developers, and draws it away from the JBoss core.

    Again, from my experience I think the above is true.

    > On the flip side, looking at your quote "in completely a transparent fashion".
    > Oh, brother - you honestly believe that, don't you?

    Yup, he does. And that's his problem. In my experience (which is fairly extensive) Marc cannot distinguish between wishful thinking (i.e. how he'd like the world to work) and objective reality. This is the common trait, whether it has to do with business (Telkel: Marc wanted to build an ASP business even though we had no idea how system administration or data centers worked) or technology (see his rants about "we were first with feature X" and compare with reality).

    > Literally tens of thousands of developers have learned the hard way that you
    > never "bolt" something like persistence onto anything without some serious
    > consequences. Persistence is a bit more complicated then sticking a class
    > name in an XML file and saying "persist me, baby". This is a lesson, IMHO,
    > which yourself and Bill Burke have yet to learn, but will also learn the
    > hardway in the near future.

    I don't think so. Both Bill and Marc are so invested, ego-wise, in the idea that it is indeed a "transparent" aspect of technology, that I seriously doubt they'll ever acknowledge it. Same way with Ivar: he'd never admit that UML isn't the most expressive programming language ever devised. It simply won't happen.

    Or so I think.

    /Rickard
  124. AOP - interception > 0[ Go to top ]

    <rickard> From my own experience, building a CMS product using AOP techniques, I can say that this is absolutely true. The first months or so we wrote loads of system aspects, and a linearly increasing number of application aspects. After that the system aspects began leveling, and now we write about one system aspect each month, if even that. But, the application aspects (both mixins and advice) still increase in a linear fashion (almost anyway, because now we can start reusing even application aspects more and more).
    >

    Ok, it seems we can reach some common understanding on the NP completeness of the system aspects dependencies (fixed number, clear demarcation of shared state).

    I think the fact that application aspects keep on growing is a clear sign that AOP IS IRRELEVANT for application design. OOP is the king there, YES OF COURSE the number of classes will grow with your functionality as THERE IS ALMOST NO *REPEAT NO* reuse of the app classes :). So using AOP only bought you
    a/ making the flow indirected in a XML file and writing everyting in detyped (some will argue against it, I believe the stateless machines are the way)
    b/ IVAR JACOBSON'S point on extending stands. That will teach you to make fun of legends ;) That is the only benefit you have. ANd then that benefit could be had by AOP without the WHOLE APPLICATION being AOP.


    <rickard>
     This is the common trait, whether it has to do with business (Telkel: Marc wanted to build an ASP business even though we had no idea how system administration or data centers worked)
    >

    Rickard you still have a problem with anyone who paid you, Telkel paid for you, you would rather entertain the romantic image of lord biron the selfless coder. In any case, yes Telkel wasn't the best business plan although one of the few companies that actually made it through 2001 IPO was "loudcloud" (marc andreesen) which was Telkel on BEA :). It is since dead so I guess it wasn't the best anyway. We tried, and paid for your time, but gratitude isn't in your heart, ungrateful lil' punk ;) It is past history and failing a business is the best lesson.
     
    <rickard> Bill and Marc are so invested, ego-wise, in the idea that it is indeed a "transparent" aspect of technology, that I seriously doubt they'll ever acknowledge it. Same way with Ivar: he'd never admit that UML isn't the most expressive programming language ever devised. It simply won't happen.
    >

    Well the whole AOP thing relies on real transparency. For the case of persistence I EVEN FEEL IT SHOULD BE A LANGUAGE FEATURE. Say like "serialization' is a language feature in Java. Some pluggability would be needed but if a language came with it it would be killer stuff.

    See points above on fixed set of aspects, and interception of call flow, many aspects today don't share state with objects or other aspects and thus in QED fashion are purely orthogonal and transparent, most system level aspects are.


    marcf
  125. VISUAL EXAMPLE OF JBOSS AOP[ Go to top ]

    the future :)

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

    Go to the BOTTOM of the page.

    What this shows is a simple example of J2EE a la carte. Most aspects are present in EJB/J2EE but here are applied where and when they are needed.

    You will see a J2SE application (aka Java application). It is OOP at this point. We use AOP to put the aspects in front of the calls in the layer below. The drawing may be a bit heavy at this point and a animation would make it a lot clearer.

    The argument of this thread can be seen in various places.
    1- AOP vs OOP for application architecture
    We argue system AOP application OOP. Essentially the top application (a business application) is written in OOP. It is clear what the flow of calls is. We go from the left to the right with a call and you can follow the black links. The architecture is explicit in the code. IT IS A GOOD THING. As opposed to going to an XML file to understand the flow of calls. THEN THE SYSTEM aspects are inserted with AOP, there is no programmatic call from the application NO KNOWLEDGE of the fact that you are going to be running in an enhanced framework. Contrast that with EJB where you would need to have the J2SE layer implement the EJB APIS' forcing dependency on J2EE.

    2- insertion of code.
    This is a minor problem but it seems to lead to a lot of confusion. AspectJ/XML approaches/C# all define different ways to specify where and when you put the interceptor in the flow (or aspect or whatever). AspectJ is a complete language to say that, C#/XML approaches allow you to insert the aspects with XML-like bindings. I ARGUE IT IS VISUAL and THIS SLIDE SHOWS IT. Take the application above and point WITH YOUR FINGER!!!! here! I want persistence, here! I want remoteness, and here! I want a big finger to the guys who like to complicate things for the sake of appearing intelligent. Merci.

    I will do the gavin trick and offer $5000 to the first penguin that implements that drag and drop tool. Serious.
  126. VISUAL EXAMPLE OF JBOSS AOP[ Go to top ]

    \marc fleury\
    The argument of this thread can be seen in various places.
    1- AOP vs OOP for application architecture
    We argue system AOP application OOP. Essentially the top application (a business application) is written in OOP. It is clear what the flow of calls is. We go from the left to the right with a call and you can follow the black links. The architecture is explicit in the code. IT IS A GOOD THING. As opposed to going to an XML file to understand the flow of calls. THEN THE SYSTEM aspects are inserted with AOP, there is no programmatic call from the application NO KNOWLEDGE of the fact that you are going to be running in an enhanced framework. Contrast that with EJB where you would need to have the J2SE layer implement the EJB APIS' forcing dependency on J2EE.
    \marc fleury\

    The "NO KNOWLEDGE" (caps yours) bit is what's going to kill you. For real applications, with real problems, you'll find that some code actually needs to be aware that it's running in a container, and what the semantics of this container are. It needs this information so it can tune the container's actions. And you can't do this with tags because tags aren't a programming language, they're properties, and properties aren't expressive enough to capture all of the work an entperprise developer needs to do to solve the problems presented to them.

    \marc fleury\
    2- insertion of code.
    This is a minor problem but it seems to lead to a lot of confusion. AspectJ/XML approaches/C# all define different ways to specify where and when you put the interceptor in the flow (or aspect or whatever). AspectJ is a complete language to say that, C#/XML approaches allow you to insert the aspects with XML-like bindings. I ARGUE IT IS VISUAL and THIS SLIDE SHOWS IT. Take the application above and point WITH YOUR FINGER!!!! here! I want persistence, here! I want remoteness, and here! I want a big finger to the guys who like to complicate things for the sake of appearing intelligent. Merci.
    \marc fleury\

    Wow - it's in a picture, so it must be true!!!! Look - "point WITH YOUR FINGER" - someone drew a bunch of 3D cirlces and boxes with connecting lines, therefore the code that implements this must exist, must work, and must be the savior of my application!!!!

    Earth to Mr. Fleury - when you point your magic finger and say "I want remoteness here", you've just entered the world where people care about network failures, latency, and recovery procedures. They cannot rely solely on the container to provide these services - applications have their own requirements outside of JBoss when it comes to dealing with failures, dealing with latency, and recovery in the face of failures. And that's just one example - the transactional and persistenc examples are far thornier and far worse.

        -Mike
  127. AOP - interception > 0[ Go to top ]

    I see the same going on in AOP and we say the library to use are the SYSTEM

    > aspects in JBoss for example.

    Maybe, but as Mike pointed out there are lots of various ways to do automatic transactions, and each AOP framework will have their own implementations. They're not really that hard to do (implementing the actual JTS/JTS API's is though). So, the question then is why use JBoss AOP instead of something else?

    > That is why we feel middleware is such a great
    > fit, because we can ship aspects and features, that make up the basic system
    > for middleware and users can leverage that power without the constraining body
    > of J2EE/EJB.

    You can see it that way, or you can see it the way many other posters in this thread has said it: those constraints are what brings the power, because you know exactly what tools you have and how they will behave. (this coincidentally happens to be rule #1 in Rickard's Rules for good Frameworks)

    > What degree of re-use exists today in business applications?

    Let me give you a real-life example from our CMS product. Of the "business objects" we have in our system about half are used once and the rest are reused in at least two places. Example: we first created a library for creating surveys. Then we reused the basic model to create email forms. Then we reused the same basic model to create a web-based workflow engine. Then we reused the same basic model to create a web-based booking engine. So, the same fairly complex business model is reused in a couple of different ways, where each new case is defined in XML that simply points to the same model.

    On the one hand this is standard OO reuse, yet at the same time we wouldn't be able to reuse and re-structure that code as efficiently as we have without being able to do the composition using AOP. We used XML in our case to do the composition specification, but the AspectJ approach would've accomplished the same thing.

    We have many more similar examples of reused business objects, but this is the most advanced one so far. And note that these are mixins, i.e. cross-cutting concerns that are *not* advice(/interceptors).

    > There is no standardized customer object or aspect, there is no standardized
    > "account" there are however standardized libraries for net and set
    > manipulation in JDK.

    But, as already pointed out, within a particular organization (which can be fairly large), it is quite possible to have such standardized libraries which can be reused many many times by using AOP as the "glue" mechanism.

    And many of the reusable aspects (/mixins) that I have mentioned above could easily be reused outside of our CMS product.

    > In the same way there are today a collection of aspects in JB4 that the end
    > user can apply because they are truly re-usable in a completely transparent
    > fashion.

    In order to be able to reuse code, any code, it needs to be well-documented and well-understood. Since JBoss aspects aren't, at least not yet, they're so far not good candidates for reuse. If you wrote a large document, kind of like the EJB spec, detailing how each works and how they would work together (THIS IS THE TRICKY PART!) then the situation would change of course.

    > The question of user interaction is an interesting one and for me lies
    > somewhere in a research field around visual modeling as the "minority report"
    > vision or UML2 or what have you, a simple language that can compose sentences
    > such as "apply persistence to this class, cache replication to this instance,
    > and monitoring of performance to these connectors" our vocabulary of operating
    > system is enhanced with the words 'persistence, replication, monitoring' and
    > we must expand that vocabulary for end-users to grock AOP.

    In other words, you and Ivar will get along just fine. You're equally delusional about how the world works.

    > PS: I am at IBM wattson today and speaking tommorrow morning (Ivar will be
    > here rickard, and I am still excited to meet the man ;)),

    Of course you are. I never said anything else :-)

    /Rickard
  128. AOP - interception > 0[ Go to top ]

    \Rickard Oberg\
    Let me give you a real-life example from our CMS product. Of the "business objects" we have in our system about half are used once and the rest are reused in at least two places. Example: we first created a library for creating surveys. Then we reused the basic model to create email forms. Then we reused the same basic model to create a web-based workflow engine. Then we reused the same basic model to create a web-based booking engine. So, the same fairly complex business model is reused in a couple of different ways, where each new case is defined in XML that simply points to the same model.

    On the one hand this is standard OO reuse, yet at the same time we wouldn't be able to reuse and re-structure that code as efficiently as we have without being able to do the composition using AOP. We used XML in our case to do the composition specification, but the AspectJ approach would've accomplished the same thing.
    \Rickard Oberg\

    That's a great example of what I was referring to, Rickard. Thanks for the assist :-)

    Incidentally, the sort of reuse scenarios you're talking about also put the kibosh on the more dramatic uses of code-embedded meta-data that some people here have been getting all hot and bothered over lately. Tying your example back to the recent discussions about meta-data, you can see how embedding something like transaction meta-data, lock-meta-data, persistence meta-data, etc into your code would defeat reuse of your model objects. If a POJO is going to be used in multiple contexts, each with possibly different cross-cutting concerns, the last thing you want is to embed meta-data directly into the POJO. At best, you'd only want to describe what the class does (e.g. READ_ONLY), not to signal information for use by a cross-cutting aspect.

    It's yet another case where people aren't thinking real usage scenarios through. They're optimizing use for the simple (almost trivial) cases, and making the more difficult (and in my experience, more common) usage scenarios impossible, or more difficult than they need to be.

         -Mike
  129. AOP - interception > 0[ Go to top ]

    Incidentally, the sort of reuse scenarios you're talking about also put the

    > kibosh on the more dramatic uses of code-embedded meta-data that some people
    > here have been getting all hot and bothered over lately. Tying your example
    > back to the recent discussions about meta-data, you can see how embedding
    > something like transaction meta-data, lock-meta-data, persistence meta-data,
    > etc into your code would defeat reuse of your model objects. If a POJO is
    > going to be used in multiple contexts, each with possibly different
    > cross-cutting concerns, the last thing you want is to embed meta-data directly
    > into the POJO. At best, you'd only want to describe what the class does
    > (e.g. READ_ONLY), not to signal information for use by a cross-cutting aspect.

    Indeed, and we have some examples for this problem too. In our case our model is being used both on the client and server, but we have different XML for the different deployment platforms. I.e. if you have an AOP object on the server using a specific structure (mixins+advice) it can be entirely different if it's serialized to the client.

    Also, some mixins of ourse use a very useful versioning technology (i.e. an object with a particular id can have several versions of the mixins with different state) which is triggered by attributes. But, not all objects using a particular mixin uses versioning, so the attribute needs to be set on a mixin(/POJO) *depending on what object it is introduced on* (note: it needs to be per-mixin since not all mixins in an object are versioned. tricky tricky). The way we "fix" this is by specifying runtime attributes in XML where we can set it for a mixin only when it's used in a particular object.

    So, on the one hand attributes are useful for triggering this versioning stuff, and on the other hand the standard "one class - one attribute" model quickly breaks down considering the above. But, you can only really see this if you do a fairly large and complex application, so none of the examples using aspects and attribues will consider it.

    /Rickard
  130. AOP - interception > 0[ Go to top ]

    <rickard>there are lots of various ways to do automatic transactions, and each AOP framework will have their own implementations. They're not really that hard to do (implementing the actual JTS/JTS API's is though). So, the question then is why use JBoss AOP instead of something else?
    >

    They are not hard, they are trivial. Using JBossAOP enables you to point to any object in your graph and say "this one will be the transaction front" something you use EJB session object for.

    <rickard> Let me give you a real-life example
    Finally :) I am tired of in the vaccuum opinions.


    <rickard> from our CMS product. Of the "business objects" we have in our system about half are used once and the rest are reused in at least two places. Example: we first created a library for creating surveys. Then we reused the basic model to create email forms. Then we reused the same basic model to create a web-based workflow engine. Then we reused the same basic model to create a web-based booking engine. So, the same fairly complex business model is reused in a couple of different ways, where each new case is defined in XML that simply points to the same model.
    >
    > On the one hand this is standard OO reuse,

    clearly! OO is there to create to packages you will reuse and be able to call into through your interfaces.

    <rickard> yet at the same time we wouldn't be able to reuse and re-structure that code as efficiently as we have without being able to do the composition using AOP.
    >

    Explain. When I think about the re-use it is just putting code before and after an actual call. The point is not so much about re-use as it is about extending. Let me explain (actually it was a point made by ivar jacobson in his presentation). If you have an application and you want to change some class, if you have interfaces then the implementation can change without disruption. If you don't have dependencies in the classes calling others then putting the class in the flow of the thread essentially EXTENDING the behavior is done easily by AOP since let anyone modify the thread execution by saying to execute some aspect at some point of the flow.

    So you are assuming that the particular aspect you have is completely orthogonal (not actual call from a->B with a type). Doing purely detyped flow of calls isn't the most natural way of thinking for most developers.


    Interfaces allow you to change the implementation with typed calls.

    <rickard>
    We used XML in our case to do the composition specification, but the AspectJ approach would've accomplished the same thing.
    >

    composition of application aspects with XML seems strange to me. It means the flow of execution is indirected in an XML file. I find it better than inventing a new language like aspect J to do that stuff, but it still seems odd. I remember the early days of JBoss where we had the detyped aspects assembled in XML. It meant most code analysis tools would fail as they couldn't infer the structure of the code calls (the stack of calls) by doing static analysis of raw code. I find it VERY clear, but that is because in EJB we deal with a finite/fixed set so I could grow familiar with it.

    The notion of blocks of code that don't explicitely call each other but that you assemble in a detyped fashion with XML seems ok for system, strange for apps. Not to say it doesn't work though. At the end of day all we do in computing is one computation after the other so wether we specify it in OOP actual typed calls or AOP xml assembled composition of "first this then that" seems equivalent, readability is the point. System's are more readable (and also dynamic) apps not necessarily.

    I still go back to IVAR's point on 'extending' to transparently extend the behavior of a system (he was giving the example of a telco system where the billing functions have change) then extending that system without disruption to the code DOES MEAN a construct like AOP and at least in the case of java ALL THE CONTEXTUAL INFORMATION IN THE THREAD (which would throw this discussion back into the stateful/stateless invocation/aspects). I would agree that this is a valid use case, the transparent extension. I give a 'blah' on re-use. I give a 'buark' on aspectJ as a language to achieve that insertion of code at a given point of the stack. Way way overkill for 99% use cases.

    <rickard> We have many more similar examples of reused business objects, but this is the most advanced one so far. And note that these are mixins, i.e. cross-cutting concerns that are *not* advice(/interceptors).
    >

    Agreed, multiple inheritence due to mixins is a nice way to circumvent the one inheritance in java. We use it in the system level as well (so you can extend EJBHome for example)
     
    <rickard> But, as already pointed out, within a particular organization (which can be fairly large), it is quite possible to have such standardized libraries which can be reused many many times by using AOP as the "glue" mechanism.
    >

    Yeah I disagree there. OO failed in that re-use because, by and large there is very little reuse or all reuse needs the extends etc... so you end up diving in the body of the code. That is a discussion on OOP, but the lack of component market is a thorny proof if you ask me. AOP won't adress it, it will just provide a 'glue' as you say to assemble the components "first this then that" I am also curious as to what the call in the actual component would look like, do they do next() as in JBoss aspects or do they just 'return' (since they have no way of knowing where the thread goes next) and you chain through a manager that does reflection?

    Bottom line: within an application YES you can re-use (OOP) within an organization somewhat, across companies NAY. As an ex-SAP guy.


    <rickard> And many of the reusable aspects (/mixins) that I have mentioned above could easily be reused outside of our CMS product.
    >

    The component market for APPLICATION I don't know. There is no component market to speak of today due to various little realities of business. HOWEVER in the case of SYSTEMS i will believe we may see that market one day. For example the best aspect for "monitoring" is already a vibrant market and all the constructs end up in aspects from an architecture standpoint (they don't call it that they call it AXIS interceptors or SERVLETS Filters or EJB interceptors) but yeah I believe we may see a market for the best persistence aspect one day (we are trying that with Hibernate). And there AOP is a necessity as assembly of them aspects requires a non-programmatic, non-code-invasive glue. Again I argue this is visual.

     
    <rickard> In order to be able to reuse code, any code, it needs to be well-documented and well-understood. Since JBoss aspects aren't, at least not yet, they're so far not good candidates for reuse. If you wrote a large document, kind of like the EJB spec, detailing how each works and how they would work together (THIS IS THE TRICKY PART!) then the situation would change of course.
    >

    1- most aspects in JBoss 4 are EJB ones, with the semantics of the EJB.
    2- You are correct the clean definition of the aspects is the next frontier.
    3- While at Wattson we discussed these points. Here is what I think we will see

    a/ The number of system aspects are limited, we have about 8 or 9 in JBoss. 5 or 6 are straight J2EE.
    b/ The combinatorials of them are simplified in the sense that since JB3 we isolated the namespaces for the variables in the Invocation. What that means is that if aspects are not dependent on each other state there is no "working together", they NEVER share ANY state so their orthogonality is proven.
    c/ most of the dependencies examples we come up with this day have all to do with transactions. Not to say there aren't other examples, but that is what we do today, all examples are "persistence is dependent on TX" " Cache is dependent on TX"

    What I am saying is that the 'packaging of aspects' and their dependencies is an NP complete problem we can solve in our lifetimes :) combinatorials of aspects that share state is a feasible human endeavor with some simple underpinning such as state separation in the Invocation.

    Francisco (JBG operative in Brazil) just created the "JBoss scolarship" and I hope to sponsor some Ph-D students to study these. I expect the problems to be humanly feasible. Also it is a good opportunity to document these IN RESEARCH PAPERS. See the paper from INRIA from Rouvoy and Merle's paper on Abstraction of Transaction Demarcation, proceeding of middleware 2003. They spend 10 pages describing the transaction demarcation. They effectively describe an aspect and the abstraction from the actual implementation of the JTS service.

    You are right that the dependencies are the tricky part, the IBM Wattson crowd was making the same. I argue it is honestly a simple problem we can tackle in maybe 2 years FOR THE MIDDLEWARE LAYER. WE will push for it in JBoss.

    All bets are of in the application layers and AOP as 'mass developer' constructs since there are as many components as there are application/developers etc.


    <rickard> In other words, you and Ivar will get along just fine. You're equally delusional about how the world works.
    >

    I can't believe this. The future of this assembly is visual and I hope to show it to everyone as a visual construct in a bit.

    > > PS: I am at IBM wattson today and speaking tommorrow morning (Ivar will be
    > > here rickard, and I am still excited to meet the man ;)),
    >
    > Of course you are. I never said anything else :-)

    Show some respect you little punk. Ivar made the point on extending vs re-use which goes right to the heart of your faulty argumentation above. Also let's protect our own kind, the innovative developers, as you never know when the fire will leave you (or the aliens in your case) so show some support and compasion. I want to be able to support all of you punks (bill, scott, you adrian) without the snipping of talent.
  131. AOP - interception > 0[ Go to top ]

    \marc fleury\
    They are not hard, they are trivial. Using JBossAOP enables you to point to any object in your graph and say "this one will be the transaction front" something you use EJB session object for.
    \marc fleury\

    Perhaps you haven't looked at your own company's code, but I have (beyond TxCache as well). What you have right now is a worst-of-breed transaction system - it's poorly defined, slow, and eats memory for breakfast. Your own technical people disagree on pretty much all of the details of how it should work. So far you've proven that using AOP, in the highly dynamic manner you advocate, is a bad idea.

     
    \marc fleury\
    Explain. When I think about the re-use it is just putting code before and after an actual call. The point is not so much about re-use as it is about extending. Let me explain (actually it was a point made by ivar jacobson in his presentation). If you have an application and you want to change some class, if you have interfaces then the implementation can change without disruption. If you don't have dependencies in the classes calling others then putting the class in the flow of the thread essentially EXTENDING the behavior is done easily by AOP since let anyone modify the thread execution by saying to execute some aspect at some point of the flow.

    So you are assuming that the particular aspect you have is completely orthogonal (not actual call from a->B with a type). Doing purely detyped flow of calls isn't the most natural way of thinking for most developers.


    Interfaces allow you to change the implementation with typed calls.
    \marc fleury\

    This is interesting - AOP is OK if JBoss does it, it's bad, bad news if regular programmers do it.

    Also - please note that the best AOP code out there I've seen makes extensive uses of interfaces, and allows cooperative AOP - where a closely-coupled, non-orthagonal AOP code snippet has intimate knowledge of a specific POJO or set of POJOs. In fact, it is in non-orthagonal uses of AOP that you'll see the biggest bang for regular developers. In something like AspectJ, this is absurdly easy because developers are using a fully Java-typed system and are using their own objects and classes. In something like JBoss AOP you have a point - you have to constantly work with "Object" and meta-data, with no static typing to help you, and you end up with alot of boilerplate code to narrow the generic Object and meta-data stuff into your specific application domain. If you have the time, compare Bill Burke's difficult to read aspects littered with meta-data calls and casts from Object to similar Aspects done in AspectJ, where none of the boilerplate exists, and the developer can work fully in their accustomed domain of classes.

    \marc fleury\
    composition of application aspects with XML seems strange to me. It means the flow of execution is indirected in an XML file. I find it better than inventing a new language like aspect J to do that stuff, but it still seems odd. I remember the early days of JBoss where we had the detyped aspects assembled in XML. It meant most code analysis tools would fail as they couldn't infer the structure of the code calls (the stack of calls) by doing static analysis of raw code. I find it VERY clear, but that is because in EJB we deal with a finite/fixed set so I could grow familiar with it.

    The notion of blocks of code that don't explicitely call each other but that you assemble in a detyped fashion with XML seems ok for system, strange for apps. Not to say it doesn't work though. At the end of day all we do in computing is one computation after the other so wether we specify it in OOP actual typed calls or AOP xml assembled composition of "first this then that" seems equivalent, readability is the point. System's are more readable (and also dynamic) apps not necessarily.
    \marc fleury\

    Here you've made an excellent argument against an XML-based pointcut system, and at the same time admitted that your own AOP system is hard to use and prone to errors, and difficult to debug. Try AspectJ sometimes - you'll find that none of your objections above apply.

    \marc fleury\
    1- most aspects in JBoss 4 are EJB ones, with the semantics of the EJB.
    2- You are correct the clean definition of the aspects is the next frontier.
    3- While at Wattson we discussed these points. Here is what I think we will see

    a/ The number of system aspects are limited, we have about 8 or 9 in JBoss. 5 or 6 are straight J2EE.
    b/ The combinatorials of them are simplified in the sense that since JB3 we isolated the namespaces for the variables in the Invocation. What that means is that if aspects are not dependent on each other state there is no "working together", they NEVER share ANY state so their orthogonality is proven.
    c/ most of the dependencies examples we come up with this day have all to do with transactions. Not to say there aren't other examples, but that is what we do today, all examples are "persistence is dependent on TX" " Cache is dependent on TX"
    \marc fleury\

    Mr. Fleury, you speak here as if you have a finished product. What you in fact have are a bunch of rather fragile and tentative aspects that your own developers have admitted are going to have to change mightily to really make useful, and they can't agree on a plan to actually make that happen. Everything you're saying above sounds right _but JBoss hasn't done it yet_. I happen to know what I'm talking about in this area but I'm absolutely positive that I've looked at, and understand, the aspect code far better than you do.

    \marc fleury\
    All bets are of in the application layers and AOP as 'mass developer' constructs since there are as many components as there are application/developers etc.
    \marc fleury\

    Yeah, 'cause all mass developers are dumb, and only the wicked-smart JBoss people know how to pull off something so monumentally difficult as AOP. Please, keep throwing around more nonsense about "NP completeness" to even further confuse and bedazzle people.

    \marc fleury\
    Show some respect you little punk. Ivar made the point on extending vs re-use which goes right to the heart of your faulty argumentation above. Also let's protect our own kind, the innovative developers, as you never know when the fire will leave you (or the aliens in your case) so show some support and compasion. I want to be able to support all of you punks (bill, scott, you adrian) without the snipping of talent.
    \marc fleury\

    Yes, all innovative developers had better show Mr. Fleury some respect, and scurry as fast as they can under his protective umbrella, because only _Marc Fleury_ can save them from their horrid fate. Everyone sell out to Jboss quick before their fire leaves them!

        -Mike
  132. Here we go...[ Go to top ]

    Hi,

    > That is incorrect. The 'mess' you are referring to is mess that is inherent
    > in component assembly under transactional scope. Do you remember the early
    > JBoss 2.x days ? (I do, they were fun when you were around ;) tons of people
    > were using the REQUIRED tag in EJB and that let to graphs of objects being
    > locked under transactional scope and thus single threaded access of the
    > graph, which is not good. We moved to REQUIRED NEW by default and that
    > magically went away.

    Aargh! Isn't that exactly the worst thing to do in this case? Instead of having to manage ONE transaction for all interrelated method-calls, the app-server is going to suffer from the overhead of managing lots of transactions (think recursion or some kind of visitor pattern). Yeah sure, each tx is very short, but what you do is disconnecting two operations which might have to run in the same context, as defined by the semantics of the underlying business transaction. As I understand, this might lead to subtle errors.

    Regards,
    Lars
  133. Here we go...[ Go to top ]

    Hi,

    >
    > > That is incorrect. The 'mess' you are referring to is mess that is inherent
    > > in component assembly under transactional scope. Do you remember the early
    > > JBoss 2.x days ? (I do, they were fun when you were around ;) tons of people
    > > were using the REQUIRED tag in EJB and that let to graphs of objects being
    > > locked under transactional scope and thus single threaded access of the
    > > graph, which is not good. We moved to REQUIRED NEW by default and that
    > > magically went away.
    >
    > Aargh! Isn't that exactly the worst thing to do in this case? Instead of having to manage ONE transaction for all interrelated method-calls, the app-server is going to suffer from the overhead of managing lots of transactions (think recursion or some kind of visitor pattern). Yeah sure, each tx is very short, but what you do is disconnecting two operations which might have to run in the same context, as defined by the semantics of the underlying business transaction. As I understand, this might lead to subtle errors.
    >
    > Regards,
    > Lars

    It's virtually impossible to say which is the "best" default transaction demarcation, since the appropriate demarcation is entirely dependent on the requirements of the application. Having said that, RequiresNew is unlikely to be a good default choice; it's likely to both lead to inconsistent outcomes and to deadlock if the assumption is that transactions will transitively scope EJB interactions (which I seems to be the normal model people assume).
  134. Here we go...[ Go to top ]

    Pavlik,

    >
     It's virtually impossible to say which is the "best" default transaction demarcation, since the appropriate demarcation is entirely dependent on the requirements of the application.
    >

    Totally agree.


    >
     Having said that, RequiresNew is unlikely to be a good default choice; it's
    >

    it was the correct default for JBoss 2.0, mostly by experience and feedback. All tags lead to use cases that can be problematic depending on the application (and you correctly identify one in your post) but then the answer is statistical. We saw less problems coming back to our professional support with that tag than without. Without I saw very clever designers shoot themselves in teh foot with long running transactions and killing scalability. We solve the new ones in seconds and they are few and in between.

    It is experience of statistical feedback in this case.
  135. Here we go...[ Go to top ]

    I can't argue with your experiences, but I can say that mine have been different. I'm struggling to define a use case where the norm is to have a transaction per method invocation in nested EJB interactions; this seems to be a special case in my experience. On the other hand, if the cases you are dealing with really have extended transaction needs, they need to look at extended transaction models and those are not available in EJB (at least in any kind of standard way).
  136. Here we go...[ Go to top ]


     Aargh! Isn't that exactly the worst thing to do in this case?
    Instead of having to manage ONE transaction for all interrelated method-calls,
    >

    no it is not and it is the accepted model since the DCOM days, with EJB as another adopter and NET and us today.

    You start ONE transaction at the front (session facade style) and the subsequent interceptors know to not start a transaction in REQUIRES mode for example. We are talking about default behavior in the appserver.

    Nothing new here girls, don't get your panties all tied up

    marcf
  137. PLgC[ Go to top ]

    The future of AOP may be java if we do the right thing at the VM level (see my points on J2SE) but let's not let a valid discussion degenerate and let's keep personal rencor aside.

    I think a Object should support (Instrumentable)object.get/set/manipulateInterceptionStack(bla, where bla bla);

    and then

    Interception
    public Invocation invoke(Invocation);

    or something like that, and WE ARE DONE at the spec level, we are so close.

    Peace Love and good Code

    marcf
  138. <complete-facetiousness>
    Um, Marc, is that really you with that id? You seem to have mellowed down a bit. 8-)
    </complete-facetiousness>
  139. <complete-facetiousness>

    > Um, Marc, is that really you with that id? You seem to have mellowed down a bit. 8-)
    > </complete-facetiousness>

    I am mellow, I am running a business these days, I am taking time off from reviewing contracts with our lawyers to read the thread and I enjoy the technical talk as bill/adrian and most of our crew has been running wild with the AOP stuff.

    But don't push it or the hulk in me will bust right out :)

    marcf
  140. PLgC[ Go to top ]

    \marc fleury\
    Interception
    public Invocation invoke(Invocation);

    or something like that, and WE ARE DONE at the spec level, we are so close.
    \marc fleury\

    The above, or something like that, isn't even close to what would be needed at a VM level. What you're describing is trivially intercepting a method call, which is the easiest and least interesting thing you can do with something like AspectJ (and other frameworks). And at the same time, it would make figuring out what source code actually does a rather difficult exercise.

    You might want to read up more on AspectJ, and specifically on the many areas where it focuses on _constraining_ AOP usage and make it more easily managable.

    What you're talking about is effectively giving enormous power and dynamicity to the language/VM with no corresponding checks. If you want to go that route, you'd be better off abandoning a statically type checked system and go more of a Smalltalkish route.

        -Mike
  141. PLgC[ Go to top ]

    mike,

    > \marc fleury\
    > Interception
    > public Invocation invoke(Invocation);
    >
    > or something like that, and WE ARE DONE at the spec level, we are so close.
    > \marc fleury\
    >
    > The above, or something like that, isn't even close to what would be needed at a VM level. What you're describing is trivially intercepting a method call, which is the easiest and least interesting thing you can do with something like AspectJ (and other frameworks). And at the same time, it would make figuring out what source code actually does a rather difficult exercise.
    >

    We disagree, we argue we don't need much more. It is the C# approach and purely a VM level feature. If we have that *we can build JBoss* in a more native fashion by leveraging the VM capability. I recommend reading Gustavo Alonso's recent paper in the proceedings of Middleware 2003 where he describes robot control with a microkernel + dynamic AOP on JPDI, an approach very similar to JBoss 4. With just that we can do stuff from robots all the way up to clustered routers on JBoss.

    > You might want to read up more on AspectJ, and specifically on the many areas where it focuses on _constraining_ AOP usage and make it more easily managable.
    >

    listen to bill's talk, we _did_ read up on AspectJ a lot, we talk with Gregor a lot and the limitations are clear. We prefer a C# like light-tag, or no-tag approach rather than a new language. That part is trivially clear, these approaches are more manageable. Move on.
     
    >
    you'd be better off abandoning a statically type checked system and go more of a Smalltalkish route.
    >

    right on. See the examples above where STATICALLY typing your systems prevents you from doing the iterative monitoring for example, these are very simple use cases, re-read them. Yes, smalltalk was really a precursor and we should find a lot of supporters for that.
  142. PLgC[ Go to top ]

    Mike, the trick to understanding Fleury-speak is to read it as-is and not try to add anything to what's not there. I'll give you an example:

    > > \marc fleury\
    > > Interception
    > > public Invocation invoke(Invocation);
    > >
    > > or something like that, and WE ARE DONE at the spec level, we are so close.
    > > \marc fleury\

    This literally means "JBOSS IS DONE" and has nothing to do with anything else, including AOP.

    > We disagree, we argue we don't need much more.

    This literally means that Marc(/JBoss) doesn't need much more. It has nothing to do with AOP.

    > It is the C# approach and purely a VM level feature.

    Which is irrelevant from the AOP perspective, but fits in perfectly given the above understanding of "WE ARE DONE".

    > If we have that *we can build JBoss* in a more native fashion by leveraging
    > the VM capability.

    This is quite explicit I think.

    > I recommend reading Gustavo Alonso's recent paper in the proceedings of
    > Middleware 2003 where he describes robot control with a microkernel + dynamic
    > AOP on JPDI, an approach very similar to JBoss 4. With just that we can do
    > stuff from robots all the way up to clustered routers on JBoss.

    Same here. Anything above is purely related to JBoss, and whatever ideas are concocted in there, as opposed to having anything to do with AOP.

    > listen to bill's talk, we _did_ read up on AspectJ a lot,

    Bill read and read and read and still didn't get it (see the misconceptions in this interview). But since he had read so much he thought he had gotten it anyway (since he's so experienced on the topic, having worked on CORBA so much).

    > we talk with Gregor a lot and the limitations are clear.

    The limitations with AspectJ compared to what kind of dynamic, free-for-all, anything-goes stuff Marc wants in JBoss, and not limitations as it relates to AspectJ being an implementation of AOP.

    > We prefer a C# like
    > light-tag, or no-tag approach rather than a new language.

    Note that it says "We", not "AOP".

    > That part is
    > trivially clear, these approaches are more manageable. Move on.

    .. in other words, it is trivially clear in terms of what Marc wants in JBoss, which has little or nothing to do with implementing AOP as such.

    Moving on..

    > right on. See the examples above where STATICALLY typing your systems
    > prevents you from doing the iterative monitoring for example, these are very
    > simple use cases, re-read them.

    I.e. very simple use cases of what Marc wants to do in JBoss, as opposed to very simple use cases of AOP.

    HTH

    /Rickard
  143. PLgC[ Go to top ]

    \marc fleury\
    We disagree, we argue we don't need much more. It is the C# approach and purely a VM level feature. If we have that *we can build JBoss* in a more native fashion by leveraging the VM capability. I recommend reading Gustavo Alonso's recent paper in the proceedings of Middleware 2003 where he describes robot control with a microkernel + dynamic AOP on JPDI, an approach very similar to JBoss 4. With just that we can do stuff from robots all the way up to clustered routers on JBoss
    \marc fleury\

    I believe we have a bit of a disconnect here. Perhaps, with an interceptor hook put into the VM, JBoss interceptors can be VM level (and "done"). This does not mean the VM has any true AOP support - it just means a codebase like JBoss can do dynamic interceptors.

    In case you missed it, I don't consider what JBoss is doing AOP - it something far more low level, far more powerful, and far more dangerous. The hook you are describing is not an AOP hook, it's a hook that's leading you toward something more like dynamically typed languages like Smalltalk.

    To paraphrase an old saying, if you want Smalltalk, you know where to find it.

    \marc fleury\
    listen to bill's talk, we _did_ read up on AspectJ a lot, we talk with Gregor a lot and the limitations are clear. We prefer a C# like light-tag, or no-tag approach rather than a new language. That part is trivially clear, these approaches are more manageable. Move on.
    \marc fleury\

    It has not been demonstrated that "these approaches are more manageable". In fact, see the AspectJ academic papers out there which show the constrainsts put into something like AspectJ are a good thing and exist for very good reasons.

    In fact, it's "trivially clear" that JBoss AOP is the new kid on the block, and is entering comletely untested waters, and is attempting to do something that's been technically feasible for a long time, but which many experts have considered a bad idea (for an equally long time). The JBoss all-dynamic, per-object AOP is not a tried and testing thing and so we can "move on". It's risky and new and it's up to _you_ and Bill and the rest of the JBoss team to convince the world that you have a viable approach. So far, you haven't done a convincing job of that.

    As an aside, I've had discussions with Bill about AspectJ, and it was starkly obvious from those conversations that he knows very little about AspectJ. His knowledge therein is _both_ shallow and narrow. Perhaps he read alot about it and talked to people about it, but he has not demonstrated that he understands what it's all about, how it truly works, and what the real semantics are.

    \marc fleury\
    right on. See the examples above where STATICALLY typing your systems prevents you from doing the iterative monitoring for example, these are very simple use cases, re-read them. Yes, smalltalk was really a precursor and we should find a lot of supporters for that.
    \marc fleury\

    Just because a thing is possible does not mean that it's reasonable, or that it's the best possible solution. In this case, JBoss AOP can probably do something like iterative monitoring with the least amount of code/configuration. This does not mean it's the best, it just means it's easy to flip on a switch. Whether that solution is managable, trackable, auditable, performs addequately, and does not induce hidden side effects is an entirely other matter, which you have not addressed at all.

    I can "flip a switch" right now to massively instrument a subset of my classes (or all of them) to do all sorts of things. Unfortnately, despite the ease in doing this, it doesn't work very well in practice. Intelligence has to be applied to decide where this makes sense, what specifically functionality is needed, what the side effects are, what the performance implications are, long-term maintenance, risks to operations and production-level guarantees, and the like.

    To summarize, I'm talking about serious software development (in my case, in the financial services arena), where risk analysis is a way of life, where designs have to be approved and analyzed, and where messages propogate in sub-millisecond time, and fault tolerance and recovery are set in stone, and everything _has_ to be right. It's a tough environment, but in all it's a combination of serious engineering and serious software development "art".

    What you are talking about, on the other hand, can perhaps be best summed up as "snake oil". Sorry for the derogative term, but I can't think of a better one which is more applicable. You give few real details, details which are given are often contradictory with one another, a relentless focus is shown on one thing your tool does well (little/no code), relentless ignorance is shown of real-life considerations of performance/operational integrity/etc, and in general there's alot of marketing rah-rah-rah.

    And the worst is assertions that your approach is blessed/correct/standard/whatever with zero references to back it up.

        -Mike
  144. Benchmark?[ Go to top ]

    I was interested to see Bill describe "An interesting benchmark was just done that is available on our AOP forum. Somebody did a benchmark with our DR1 release with AspectJ and the performance was very similar."

    I looked on the JBoss Forum and found this thread: httpttp://www.jboss.org/thread.jsp?forum=151&thread=34270&message=3785012. Is this the "benchmark" in question? If so, I'm surprised because the poster himself described his tests as "simple, unscientific timings." And because the code in question contains a lot of output and string operations that will obscure the relevant differences.

    It would also be interesting to see what AspectJ code and plain Java code was used for comparison.

    Likewise, when Bill claims "So with our DR2 release, we found we already in improved performance by a factor of 6", what tests were used to measure this? I hoped to look further but jboss.org isn't responding so perhaps Bill can enlighten me.
  145. Benchmark?[ Go to top ]

    I was interested to see Bill describe "An interesting benchmark was just done that is available on our AOP forum. Somebody did a benchmark with our DR1 release with AspectJ and the performance was very similar."

    >
    > I looked on the JBoss Forum and found this thread: httpttp://www.jboss.org/thread.jsp?forum=151&thread=34270&message=3785012. Is this the "benchmark" in question? If so, I'm surprised because the poster himself described his tests as "simple, unscientific timings." And because the code in question contains a lot of output and string operations that will obscure the relevant differences.

    My quote on AspectJ performance comparisons was not to say use JBoss AOP because performance is better, but more to say JBoss AOP has similar performance to other AOP frameworks. AOP will always have overhead as compared to a regular method call. The AOP "bashers" always attack this so it is stupid to give numbers against plain Java calls.

    >
    > It would also be interesting to see what AspectJ code and plain Java code was used for comparison.
    >
    > Likewise, when Bill claims "So with our DR2 release, we found we already in improved performance by a factor of 6", what tests were used to measure this? I hoped to look further but jboss.org isn't responding so perhaps Bill can enlighten me.

    There is a little benchmark test I wrote is in the JBoss AOP distribution under docs/benchmark. I think AspectWerks has done a similar benchmark. Check out Jonas Boner's Blog. That's where I found his numbers. Run the benchmark against DR1 and DR2 of JBoss to get the factor of 6. I think I've improved it within our current codebase to a factor of 12 better than our DR1 release.

    Bill
  146. AOP copyrights ![ Go to top ]

    Guys,

    Thank you all for this great content. I knows this is a very tech thread but I would like to get your attention to one BIG concern : Software and the law ! I am not a laywer, uff ! BTW, I prefeer Bill Burke's "pragmatic" AOP definition(sorry guys above of "average developer" level)...

    <Rickard >
    And just to state the obvious: do not use bytecode weaving, at load-time or otherwise, to modify .class files protected by license, without permission from the licensor
    </Rickard>

    It was a interesting point. The "licensor". Then I read http//www.infoworld.com/article/03/08/28/HNeupatent_1.html and now I am wondering : Who has the AOP patent here ;), hann ? Well, after thist I finally started to work.

    Have funny !!
  147. mediaplayer 9[ Go to top ]

    the screen is all messed up (flat) when you are ms using media player 9 for video playback, could this perhaps be fixed ?
  148. AOP at a Higher Level[ Go to top ]

    I'd like to put another slant on the debate by moving up a level to how AOP effects design...

    The AOP *CONCEPT* is really nothing to do with interceptors, pointcuts, advices and so on. These are just implementation details (although rather complex and highly interesting ones). IMHO, what AOP is about is enabling the separation of different areas of an application into clearly abstracted parts at the design level and then maintaining this clean separation down into the code. It's a way to ensure that low coupling at the design level is mirrored in the code that implements the design.

    The result should be cleaner, simpler, easier to maintain code that avoids the tangling of different concerns that it really doesn't need to be aware of. However, the design (or at a minimum the code/XML comments) will clearly document where AOP is being used to create advices that link between the different concerns.

    AspectJ (and similar) seems to provide the ability to achieve the above approach. I can turn my design into better, cleaner code but still fully understand and test the structure of my application. The specifically limited semantics of pure AOP systems are a way to stop me getting carried away in my code.

    JBoss AOP also allows me to achieve my above approach as far as I can see (although perhaps not as elegantly or purely if others are to be beleived). For me it is the ability to dynamically alter the interceptors and so on at runtime that is my major concern. This approach effectively allows me to create an application whose behaviour can be alted while it is actually running (this is not AOP in my opinion but some other concept all together).

    Such an approach is highly dangerous as the design may no longer reflect what the application is actually doing and thus both the design and any test cases created from the design immediately become invalid. It is impossible to prove that in every case that dynamically adding a new interception or introduction will not break the application in some subtle way without deriving test cases for each scenario. Perhaps in the future JBoss might be able to automatically create and run tests everywhere where it does some dynamic alteration (but I would think this sort of technology is still some way off). The dynamic interception/introduction part of JBoss AOP is therefore clearly an anti-pattern to sound design and testing principles as far as I'm concerned. In fact I would say that its the exact opposite of what I would consider AOP to be bringing to the party.

    I'd much rather stick to using AOP as a modularisation technology that I can represent in my designs rather than allow a free-for-all arm waving addition of features exercise by some administrator/consultant who may not understand the nuances and details of my system and as a result cause more chaos as a result.
  149. AOP at a Higher Level[ Go to top ]

    This approach effectively allows me to create an application whose behaviour can be altered while it is actually running

    Wow, you must hate JMX, then. I will change values in my JMX components in order to alter the behavior of my server applications while it is running. And it is impossible for me to write test cases to ensuere that every single possible value won't break the application.

    Hot deploy is out the window, too. Changes the behavior of a running application, and you can't write test cases to cover every single scenario.

    While you're at it, pass-by-reference and object inheritance are pretty scary, too. They don't alter the runtime behaviour of the application, but they could be abused by a careless programmer to produce unintuitive code that is out of sync with the design.

    I already have some ideas on how I can use per-instance advice to add powerful functionality in my server applications, while getting much better performance than I would if I were restricted to using per-class advice. And I believe that I can come up with a clean, maintainable design to implement these ideas.

    Am I right? Only JBossAOP will let me find out. The other 'vendors' have already decided that the risk of someone producing a confusing design outweighs any benefits that could be gained from using these features in a structured manner. And quite frankly, AOP is way too early into its infancy too make such determinations yet.
  150. Closure[ Go to top ]

    In a desperate attempt to reach closure, and to bring things back to the original arguments, I'll try to summarize at least the TxCache side of things here. I think this is probably somewhat representative of the other JBoss aspects. I won't discuss bugs, 'cuz bugs are just bugs, and this is a developer's release. You could say I have bigger fish to fry.

    1) By design, TxCache has READ_COMMITTED behavior on the reading side. For people not familiar with isolation levels, this means that as you're reading an object in a transaction, you can be picking up the results of other committed transactions. If you're going along reading an object, and 3 other transactions commit while you're doing that, you could be reading 3 seperate states of the object. There appears to be no way for user app code to detect this.

    2) Locks are very ephemeral, due to the optimistic locking policy. If you don't hit an optimistic locking failure, this will be very fast (_from a locking standpoint_ - see below for non-locking overhead details) and should not be able to deadlock if used only locally.

    3) When an object is placed in a TxCache, it acquires alot of TxCache memory overhead. Each such object, which we'll term Advisable, gets 6 objects allocated against it. Each field in such objects requires an additional 2 objects. This is recursive throughout the Object graph e.g. the objects referenced by the parent Advisable object. This is outside of a transaction. Each transaction adds 3 more objects, plus 2 extra objects per field _written_ (reads don't have this overhead, and again, this is applied recursively). These are back-of-the-napkin sort of calculations, I may be off by an object somewhere.

    Using the JBoss AOP example:

     class Address {
       public String street;
       public String city;
       public String state;
       
       public Address(String street, String city, String state) {....init...}
     }
     class Person {
       public String name;
       public int age;
       public Address address;
     }
     Address address = new ("55 street road", "Boston", "MA");
     Person person = new Person("Bill", 32, address);

    We assume "Person" is a guy we're going to cache insert, and both Person and Address is advisable (I've elided the hobbies ArrayList, as I've avoided the collections proxy stuff).

    Each fully filled in Person in the normal world will comprise 6 objects (Person, name, address [Street, City, State]).

    After cache insertion, outside of a transaction, Person will now have 6 + (2*6) + (6 * 2) = 30 objects (that's the original 6, plus 6 per Advisable, plus 2 per field). This does not include any AOP overhead - this is strictly TxCache overhead. Also, as I mentioned, this is back-of-the-napkin - the exact numbers may vary, but this is in the ballpark.

    If we add an extra plain-old-field into Address, that number increases to 32 objects. If we add an extra "Advisable" Object field with one field of it's own into Address, the plain-old-object count is 7. The TxCache object count becomes 7 + (3*6) + (8*2) = 41.

    The object count is higher in a transaction, and continues increasing per field written.

    3) When an object is placed in a TxCache, it acquires alot of TxCache runtime overhead. Discounting raw AOP overhead, the following is executed _per field read_:

          if (invocation.getType() != InvocationType.FIELD_WRITE
              && invocation.getType() != InvocationType.FIELD_READ) return invocation.invokeNext();

          // Don't need to worry if we're static or not because this is an instance interceptor

          if (invocation.getType() == InvocationType.FIELD_READ)
          {
             return manager.fieldRead(invocation);
          }
          --- fieldRead -----
       public Object fieldRead(Invocation invocation) throws Throwable
       {
          acquireReadLock();
          try
          {
             FieldReadInvocation fieldInvocation = (FieldReadInvocation)invocation;
             Integer index = new Integer(fieldInvocation.index);
             HashMap map = getTxState();
             if (map == null)
             {
                map = fieldMap;
             }
             DistributedFieldUpdate update = (DistributedFieldUpdate)map.get(index);
             Object val = update.getValue();
             return val;
          }
          finally
          {
             releaseReadLock();
          }
       }

    The above code is executed everytime you read a field (whether you're in a transaction or not). This does not include the AOP overhead. Reads in transactions have about the same overhead. Writes have slightly higher overhead out of a transaction, and even more overhead within a transaction.

    NOTE: this is not the commit/rollback overhead - this is the overhead per field read or field write. Normal Java int x = object.x stuff.

    4) Bela has, effectively, a competing cache implementation that works in a completely different manner. Someone else (I forget whom) creating TreeCacheAOP from Bela's TreeCache. This appears to be a much more complete cache implementation, but only does pessimistic locking right now. Bela has extensive (I do mean _extensive_) design docs to back up the semantics of this puppy, and it appears that TreeCache/TreeCacheAOP may be upgraded to have optional optimistic semantics as well. The TreeCache work does not appear to be officially documented on the JBoss pages - only TxCache is. It's anyone's guess which implementation will live on to future versions and in what form.

    5) Objects inside a TxCache and inside a transaction aren't aware of this (and aren't supposed to be). As such a Rollback can't be explicitly requested - at best, it can throw an exception which can result in a rollback. As previously mentioned, the code inside these objecs also can't be aware that they may be reading multiple object states from various concurrent transactions. I also have no idea how the transactional stuff might interact with synchronized methods or blocks within Advisable objects - do these get whacked by the TxCache instrumentation, can they result in thread deadlock that's not possible in the pure POJO design, or does it all just work? Beats me.

    6) There is no spec on any of this at the moment. If Bela's TreeCache stuff "wins", I'd say it's a fair bet that his extensive design documentation that backs it will make its way into some sort of spec/documentation. If Mr. Burke's TxCache "wins", it's anyone's guess what will be documented, guaranteed behavior, and what you just have to divine from the implementation of the day.

    7) I've discussed only the local variant. The Distributed variant, as you might expect, has even more overhead and many runtime implications. Bela has pretty extensively documented what those implications are, and how they work in various sorts of isolation and locking modes. The distributed TxCache's real semantics and runtime implications are anyone's guess - the docs just say that distributed DeadLock is possible, which will result in an exception.

        -Mike
  151. Closure[ Go to top ]

    In a desperate attempt to reach closure, and to bring things back to the original arguments, I'll try to summarize at least the TxCache side of things here. I think this is probably somewhat representative of the other JBoss aspects. I won't discuss bugs, 'cuz bugs are just bugs, and this is a developer's release. You could say I have bigger fish to fry.

    >

    Yes, you have a bigger fish to fry. You're need to spice up your own ego. But again I will take the time to respond anyways....

    > 1) By design, TxCache has READ_COMMITTED behavior on the reading side. For people not familiar with isolation levels, this means that as you're reading an object in a transaction, you can be picking up the results of other committed transactions. If you're going along reading an object, and 3 other transactions commit while you're doing that, you could be reading 3 seperate states of the object. There appears to be no way for user app code to detect this.
    >

    As I said in "Hibernate joins JBossGroup". This is easily added. If you can do READ_COMMITTED, with optimistic locking at the field level, you can easily expand it to higher isolations. As you said, this is a developer release.

    > 2) Locks are very ephemeral, due to the optimistic locking policy. If you don't hit an optimistic locking failure, this will be very fast (_from a locking standpoint_ - see below for non-locking overhead details) and should not be able to deadlock if used only locally.
    >

    That is correct. Even distributed wise, it will be hard to deadlock unless there is a node failure. Due to time constraints and wanting to release early, release often, I left node failures as a TODO item.

    > 3) When an object is placed in a TxCache, it acquires alot of TxCache memory overhead. Each such object, which we'll term Advisable, gets 6 objects allocated against it. Each field in such objects requires an additional 2 objects. This is recursive throughout the Object graph e.g. the objects referenced by the parent Advisable object. This is outside of a transaction. Each transaction adds 3 more objects, plus 2 extra objects per field _written_ (reads don't have this overhead, and again, this is applied recursively). These are back-of-the-napkin sort of calculations, I may be off by an object somewhere.
    >
    > Using the JBoss AOP example:
    >
    > class Address {
    > public String street;
    > public String city;
    > public String state;
    >
    > public Address(String street, String city, String state) {....init...}
    > }
    > class Person {
    > public String name;
    > public int age;
    > public Address address;
    > }
    > Address address = new ("55 street road", "Boston", "MA");
    > Person person = new Person("Bill", 32, address);
    >
    > We assume "Person" is a guy we're going to cache insert, and both Person and Address is advisable (I've elided the hobbies ArrayList, as I've avoided the collections proxy stuff).
    >
    > Each fully filled in Person in the normal world will comprise 6 objects (Person, name, address [Street, City, State]).
    >
    > After cache insertion, outside of a transaction, Person will now have 6 + (2*6) + (6 * 2) = 30 objects (that's the original 6, plus 6 per Advisable, plus 2 per field). This does not include any AOP overhead - this is strictly TxCache overhead. Also, as I mentioned, this is back-of-the-napkin - the exact numbers may vary, but this is in the ballpark.
    >
    > If we add an extra plain-old-field into Address, that number increases to 32 objects. If we add an extra "Advisable" Object field with one field of it's own into Address, the plain-old-object count is 7. The TxCache object count becomes 7 + (3*6) + (8*2) = 41.
    >
    > The object count is higher in a transaction, and continues increasing per field written.
    >

    I admit I have done absolutely no optimizations and that TxCache is a first iteration. JBoss AOP had the same object creation problem and I reduced it tremdendously (factor of 6 speed wise) from DR1 to DR2. TxCache will have the same kind of speedup/optimization(and functionality improvement) with a 2nd iteration.



    > 3) When an object is placed in a TxCache, it acquires alot of TxCache runtime overhead. Discounting raw AOP overhead, the following is executed _per field read_:
    >
    > if (invocation.getType() != InvocationType.FIELD_WRITE
    > && invocation.getType() != InvocationType.FIELD_READ) return invocation.invokeNext();
    >
    > // Don't need to worry if we're static or not because this is an instance interceptor
    >
    > if (invocation.getType() == InvocationType.FIELD_READ)
    > {
    > return manager.fieldRead(invocation);
    > }
    > --- fieldRead -----
    > public Object fieldRead(Invocation invocation) throws Throwable
    > {
    > acquireReadLock();
    > try
    > {
    > FieldReadInvocation fieldInvocation = (FieldReadInvocation)invocation;
    > Integer index = new Integer(fieldInvocation.index);
    > HashMap map = getTxState();
    > if (map == null)
    > {
    > map = fieldMap;
    > }
    > DistributedFieldUpdate update = (DistributedFieldUpdate)map.get(index);
    > Object val = update.getValue();
    > return val;
    > }
    > finally
    > {
    > releaseReadLock();
    > }
    > }
    >
    > The above code is executed everytime you read a field (whether you're in a transaction or not). This does not include the AOP overhead. Reads in transactions have about the same overhead. Writes have slightly higher overhead out of a transaction, and even more overhead within a transaction.
    >
    > NOTE: this is not the commit/rollback overhead - this is the overhead per field read or field write. Normal Java int x = object.x stuff.
    >

    Remember what we are doing here. Transparent, Concurrent transactional access to a POJO. You have to keep state per transaction, you have to intercept a field call. The field hash lookups can be turned into array access, there's a lot of optimizations to be done, but to do what we're doing requires overhead. It is as simple as that. We're doing a complicated thing here, whether it be local only or replicated, it will require a bit of code.

    Take away the persistence from Entity beans and/or Hibernate to just have in-memory objects, and they do similar things and have similar overheads.


    > 4) Bela has, effectively, a competing cache implementation that works in a completely different manner. Someone else (I forget whom) creating TreeCacheAOP from Bela's TreeCache. This appears to be a much more complete cache implementation, but only does pessimistic locking right now. Bela has extensive (I do mean _extensive_) design docs to back up the semantics of this puppy, and it appears that TreeCache/TreeCacheAOP may be upgraded to have optional optimistic semantics as well. The TreeCache work does not appear to be officially documented on the JBoss pages - only TxCache is. It's anyone's guess which implementation will live on to future versions and in what form.
    >

    Really doesn't matter who "wins" as we are on the same team and have the same goal. To have a transparent, transactional, replicated cache for POJOs. To have different configurable transactional isolation levels and locking policies. There are things I like and dislike about TreeCacheAOP and there are things Bela likes/dislikes about TxCache. The point is that we are iterating. I think both implementations have a good idea.


    > 5) Objects inside a TxCache and inside a transaction aren't aware of this (and aren't supposed to be). As such a Rollback can't be explicitly requested - at best, it can throw an exception which can result in a rollback.

    This is because it relies on the transaction manager and JTA to do this. Personally I like this better. Our AOP framework has transaction demarcation, or you can do user transactions or even have a session bean in front of cache access.

    >As previously mentioned, the code inside these objecs also can't be aware that they may be reading multiple object states from various concurrent transactions. I also have no idea how the transactional stuff might interact with synchronized methods

    synchronization happens before field access. Even in plain java code.

    >or blocks within Advisable objects - do these get whacked by the TxCache instrumentation, can they result in thread deadlock that's not possible in the pure POJO design, or does it all just work? Beats me.
    >

    Unless there is a bug, I designed it to avoid deadlock at the thread level as write locks are always ordered. (BTW, writelocks are used to protect the optimitic lock checks).

    > 6) There is no spec on any of this at the moment. If Bela's TreeCache stuff "wins", I'd say it's a fair bet that his extensive design documentation that backs it will make its way into some sort of spec/documentation. If Mr. Burke's TxCache "wins", it's anyone's guess what will be documented, guaranteed behavior, and what you just have to divine from the implementation of the day.

    It is an iterative process. Considering that I wrote an AOP framework, a distributed transactional replicated cache, AOP based remoting, clustered remoting, J2EE a la carte (tx and security) all within 6 months, I apologize the documentation I wrote is not up to par. This was a DR1 release. A stake in the ground, A first iteration. If it was an alpha, it would have been labeled so. If it was a beta, it would have been labeled so.

    >
    > 7) I've discussed only the local variant. The Distributed variant, as you might expect, has even more overhead and many runtime implications. Bela has pretty extensively documented what those implications are, and how they work in various sorts of isolation and locking modes. The distributed TxCache's real semantics and runtime implications are anyone's guess - the docs just say that distributed DeadLock is possible, which will result in an exception.
    >
    > -Mike

    All and all this has been good feedback. Let's leave the ego stroking behind next time.

    Bill
  152. Closure[ Go to top ]

    \Bill Burke\
    Yes, you have a bigger fish to fry. You're need to spice up your own ego. But again I will take the time to respond anyways....
    \Bill Burke\

    You'd be surprised how little ego factors into this sort of case with me. You may find it hard to believe, but I am simply intensely interested in certain types of development problems and solutions, and when there's a disagreement in areas like that I am _really_ intensely interested in whether my ideas/preconceptions/thoughts are out of whack or the other guy's are. As a side effect, I'm peripherally aware that there are other people that have the same interest, but perhaps not the same stamina.

    \Bill Burke\
    As I said in "Hibernate joins JBossGroup". This is easily added. If you can do READ_COMMITTED, with optimistic locking at the field level, you can easily expand it to higher isolations. As you said, this is a developer release.
    \Bill Burke\

    First, let me thank you for cleaning up my own terminology in this area. I hate it when other people get technical terms wrong, and it's galling when I slip and make the same mistake myself.

    Secondly, I'll stick to my guns and say that this sort of thing is rather important and should be documented for potential users.

    Third - yes, you can expand anything to be configurable. The question is - at what cost?

    \Bill Burke\
    I admit I have done absolutely no optimizations and that TxCache is a first iteration. JBoss AOP had the same object creation problem and I reduced it tremdendously (factor of 6 speed wise) from DR1 to DR2. TxCache will have the same kind of speedup/optimization(and functionality improvement) with a 2nd iteration.
    \Bill Burke\

    Forgive me if I'm skeptical. The entire strategy in the current DR2 release is to track things on a per-field level, and there's attendant overhead with that and with transaction tracking. To optimize it would be a complete re-write.

    \Bill Burke\
    Remember what we are doing here. Transparent, Concurrent transactional access to a POJO. You have to keep state per transaction, you have to intercept a field call. The field hash lookups can be turned into array access, there's a lot of optimizations to be done, but to do what we're doing requires overhead. It is as simple as that. We're doing a complicated thing here, whether it be local only or replicated, it will require a bit of code.

    Take away the persistence from Entity beans and/or Hibernate to just have in-memory objects, and they do similar things and have similar overheads.
    \Bill Burke\

    This comment isn't directed to you, so much as at JBoss in general. I understand what you're doing, and what the technical hurdles are. The question for _users_ is, "is it technically compelling?". "Is this J2EE a-la-carte thing worthwhile?". As I said in another thread, you're reducing user Java code, at the expense of increased configuration complexity, and at the cost of runtime efficiency. Alot of people are going to look at this and say "OK, if we take the POJO part away, what's the advantage compared to other approaches?". There are already other compelling implementations to do persistence, remoting, transactions, and people aren't going to be interested in the technical hurldes you have to tackle in your own rather unusual approach.

    \Bill Burke\
    Really doesn't matter who "wins" as we are on the same team and have the same goal. To have a transparent, transactional, replicated cache for POJOs. To have different configurable transactional isolation levels and locking policies. There are things I like and dislike about TreeCacheAOP and there are things Bela likes/dislikes about TxCache. The point is that we are iterating. I think both implementations have a good idea.
    \Bill Burke\

    Please keepin mind that what you're attempting is non-standard and will in fact lock people into your code base. You may not care who "wins", but users certainly will. Certainly anyone who starts using TxCache is going to be pissed as hell if TreeCacheAOP wins. And certainly anyone who admires TreeCacheAOP's distinguishing features is going to be pissed if TxCache wins.

    In short you're not painting a picture where a lot of people are going to be willing to come on board. I understand that there may be differences in approaches, but those differences in your case are public, and people are confused. And confused people will tend to ignore the whole kibosh and go somewhere else.

    \Bill Burke\
    This is because it relies on the transaction manager and JTA to do this. Personally I like this better. Our AOP framework has transaction demarcation, or you can do user transactions or even have a session bean in front of cache access.
    \Bill Burke\

    I think perhaps you missed the point. There are an awful lot of applications where developer's want to be part of the transaction, not an innocent bystandard informed about it after the fact.

    \Bill Burke\
    It is an iterative process. Considering that I wrote an AOP framework, a distributed transactional replicated cache, AOP based remoting, clustered remoting, J2EE a la carte (tx and security) all within 6 months, I apologize the documentation I wrote is not up to par. This was a DR1 release. A stake in the ground, A first iteration. If it was an alpha, it would have been labeled so. If it was a beta, it would have been labeled so.
    \Bill Burke\

    As a very good project manager once said to me "Your constraints are your problems, and I don't care about them. Our shared problem is your promises to me - and you'd better deliver on every damn one of them.". JBoss, as an organization, will find few sympathetic ears if they overpromise and under deliver. I can appreciate a developer who is tending multiple fires at the same time, but I can't appreciate a developer who brags about taking over 99% of the market and then making excuses about all he's done and lack of time for the rest. Perception is reality, and your public boasts about taking over the app server world are not matching what's being delivered. If you want to talk about spicing up one's ego, you might want to examine your own first before thinking about mine.

        -Mike

    P.S. You should look at that reading bug I mentioned. As I said the fix is trivially but it's nasty for a user at this point.