AOP to replace EJB. Jon and James are in the mood for some serious party wreckin':
I wish it was that simple. If I understood this correctly, using Rickards framework every object actually consists of a set of "implementations"/"target-objects" with state, a set of interceptors (with or without state) all implementing a set of interfaces and a big happy proxy keeping it all together. So basically the state of any object is the set of all fields in all the objects that keeps this state. If I've understood OJB correctly it populates and reads your fields using AccessibleObject and Field in the Reflection API, but only one object at a time. So to store this big-momma object it actually needs to read all these fields. Of course, OJB might be flexible and open enough to "plug-in" some other strategy to access the actual data to be stored. That would be really nice of it... But it's really very simple. Let's say you have modified field X in bean Y which is a piece of the "big momma object" Z. Then, you only have to store Y, and not the other parts of Z. So, the interface between the AOP framework and the persistence manager is simply "store this Y that has key Z". I.e. from OBJ's point of view it's just a plain JavaBean, business as usual. So, nothing to worry about.
Word up! Yeah, this is cool. I like this. I mean basically EJB was a set of aspects (you know, distribution, transaction, security, persistence) designed to solve a specific technical problem. Unfortunately it was not general and open enough from the beginning and eventually it got bloated by buearucratic spec-makers. This AOP stuff (if you do it the right way) is simple and elegant and open enough to implement all these nice things (and more). Quite correct.
Another thing I am concerned about though is not getting stuck in deployment-descriptor-hell again. Or rather, not getting stuck in deployment-hell. That was what my frustrated ramblings regarding "Testability - The Next Generation" was really about. There might be a simple way to solve this though... Let's try to keep it away from the JCP. They'll mess it up so bad we won't recognize it when it comes out. :-) Well, admittedly in the framework I've written there's a deployment descriptor in XML. Couldn't get around it. Had to be there. But, it only expresses those things which just isn't very nice to do in Java code, such as describing the "big momma" objects and declaring what services needs to be bound to them, and what interceptors to use (and in what order, which is important). That kind of stuff. But it's really quite manageable. Heck, I haven't even had to write an XDoclet plugin for it yet; it's that manageable.
Seriously, though. This is why I think things like XRAI and JSR-175 are so important. XDoclet was a good thing because it moved the deployment-descriptors back into your code. Problem is that this is only partly true, XDoclet generated the deployment descriptors instead. With real runtime-attributes and aspects that use these we might be able to get away from deployment-descriptors entirely or at least as much as possible.
I agree, if only XRAI and 175 would actually happen some time soon things do start to look seriously good. I mean, really nice. [Random thoughts]
Nanning already has a nice simple API to doclet attributes. As previously discussed in the blogsphere, I'd actually quite like this API to allow pluggable implementations and maybe moved over to be a reusable Jakarta Commons component.
Then Nanning, XRAI and JSR175 could all be pluggable implementations - in a similar way to commons logging which can work with log4j, Avalon LogKit and JDK1.4's logging mechanism.
So Rickard, when is your open source AOP framework gonna be available? :-)
Update: hey I've just noticed that Nanning is using Jelly - cool!
10:10:52 AM 
|
|
