AOP is still in its infancy in many ways, but it is being talked about more and more. CNET News.com has written a piece all about AOP. Their angle starts off viewing AOP as a way to compete with Microsoft, citing the work of IBM and JBoss. Then the article goes into the other open source initiatives, such as AspectJ, AspectWerkz, and JBoss AOP. BEAs move with their WebLogic Aspect Framework was also mentioned.

What is the killer app for AOP? The difficulty of programming J2EE systems, according to Ron Bodkin, an AspectMentor.

Read IBM, JBoss eye new Java plan

In an increasing sign of development, and maturation in the AOP space, there are now (at least) three organizations that provide AOP consulting, including training, mentoring, design, coding etc. The most recently announced is the AspectMentor consortium, led by Gregor Kiczales. Previously Dean Wampler announced AspectProgramming.com and Arno Schmidmeier announced AspectSoft.de.

Naaah - how could it be ?

Java is the best - do not listen to this rubbish.

Chameleon

Sun take note. Make Java THE AOP Language and lead so when I have to justify C# or Java I can point to one clear advantage.

Just my INPUT$

This theory didn't work in the Smalltalk days why should it now? Companies do not choose standards like this. If they did we would all be using Smalltalk and scratching our heads and asking why people just don't use the meta-object layer to do all this stuff... We would find it silly that Java doesn't have a meta-object layer.

But, sales are based on who looks the best... Not who is the best.

Later,
Greg

>
> Just my INPUT$

Yes that is what we are pushing with IBM as well. It will take time, but I think JSR175 is already a great move as it will enable the framework builders to make J2EE look a bit like .NET.

The .net remote framework is a good example where c# has a ease of use advantage.

I would clarify the article a bit (as martin did not print everything we told him but naturally went for the 'story' angle, which is very normal). We said C# the language has some advantages, mostly those tag driven .NET features.

The libraries and the server side services are better in J2EE and JBoss in particular. A real O/R mapping field (with hibernate) and a cache that actually doesn't need to be rebooted every night or so (as mandated in the web layers of .net).

In short the direction is right but the implementation is still lagging in .NET

we have such a lead in java but we should let C# advantages allow for better frameworks, it is a lot of the motivation in JBoss

marcf

The article is about JBoss and IBM pushing AOP and investing a lot to push it.

I agree with JBoss, but IBM??? Maybe I missed something, but the only "Big" comanies I know about investing in AOP are BEA and Xerox. And even BEA is based on AspectJ...

AspectJ (Xerox) joined the Eclipse project, but that could not be the big effort they are writing about...especially if OTI is going to be a independend company.

If I search the "Think-Tank" alphaworks from IBM with AOP i get 0 results...

So where are the IBM AOP efforts???

Mirko
:wq

HyperJ is from IBM. Just google "hyperj".

Lofi.
http://www.openuss.org

>
> I agree with JBoss, but IBM??? Maybe I missed something, but the only "Big" comanies I know about investing in AOP are BEA and Xerox. And even BEA is based on AspectJ...
>
> AspectJ (Xerox) joined the Eclipse project, but that could not be the big effort they are writing about...especially if OTI is going to be a independend company.
>
> If I search the "Think-Tank" alphaworks from IBM with AOP i get 0 results...
>
> So where are the IBM AOP efforts???
>
> Mirko

Yes, IBM. HyperJ, AspecJ is part of Eclipse. Dean Wampler (forget his title) is doing some AOP stuff with Rational. Marc spoke at a IBM research conference on AOP too.

Bill

<mirko> The article is about JBoss and IBM pushing AOP and investing a lot to push it.
>
> I agree with JBoss, but IBM??? Maybe I missed something, but the only "Big" comanies I know about investing in AOP are BEA and Xerox. And even BEA is based on AspectJ...
>
> AspectJ (Xerox) joined the Eclipse project, but that could not be the big effort they are writing about...especially if OTI is going to be a independend company.
>
> If I search the "Think-Tank" alphaworks from IBM with AOP i get 0 results...
>
> So where are the IBM AOP efforts???
>
> Mirko
> :wq

Mirko,

There is in fact a lot of work on AOP going on at IBM ***RESEARCH***. The presentation I recently did with Ivar Jacobson was at IBM Wattson, where all the AOPers of IBM were present. From the aspectJ crowd to the HyperJ ones, they call it 'hyperdimensional programming'.

There is a BIG gap between the research people and websphere the product. But trust me the IBM'ers know what they are talking about when it comes to AOP. I wish more would discuss here and I know they read TSS


marcf

I really cannot understand the article. While AOP is cool and helps developers a lot, I cannot understand how focusing on AOP is going to counter C#. These seem very orthogonal issues. It is unlikely to imagine how an AOP framework in C# is going to be any more or less difficult to implement than in java.

Maybe there is something I dont get :(.

Dhananjay

If anything, C# with its metatags already in place conceivably should have a jump on Java in terms of implementing a robust AOP framework. There has to be a solid metatag framework in place for AOP to be truely feasible, and we won't see that in Java until JSR 175 is implemented. IMHO using method signatures to define pointcuts is a bit too brittle.

On the flip side, using metatags has its own problems that more traditional pointcut mechanisms don't have. The most obvious is that your code now has knowledge that it's being used as part of a wider AOP system, and your code is also locked into specific aspects. You can avoid this with semantic tags that indicate only what the existing code does (as opposed to requesting an outside service), but most people proposing meta-tags don't mean this, they mean requesting a service (e.g. make me TX-REQUIRED, please!).

This sort of approach can sharply limit reusability, and in the end looks an awful lot like EJBs with fewer configuration files. What I'd call "real" AOP can operate on business domain objects directly, without their knowledge (if desired, it's not an absolute), and the same domain objects can be altered differently in different environments by varying AOP aspect code.

It sounds rather silly to some, but if you try a meta-tag approach for awhile it feels amazingly like EJBs sans deployment XML files, and you find that to achieve reusabilty you have to do the same sorts of tricks here as you do in EJB, with various facade and proxy objects artificially introduced.

    -Mike

>
That's why I am not particularly a big fan of XDoclet. I agree that metatags should not be geared toward any particular system (AOP or otherwise). The burden should be on the AOP-based framework to determine the proper course of action.

>

TX-REQUIRED is used in the exact same context as the 'transient' keyword. transient deals with serializations, tx-required deals with transactionality. Developers write serializable objects because they know the object will be serialized. They will do the same with transactionality.

The same analogy can be applied to synchronized. Think of Hashtable and HashMap. One can be concurrently accessed because it uses synchronized methods, the other cannot. You could apply the same pattern to transactionality. This class is transactional and cannot be access outside of a transaction. See what I'm getting at here? Where synchronized/transient are either on or off, transactions have different degrees of on/off.

So, I'm saying I don't agree that it is a bad idea for your code to have knowledge that it's being used as a part of a wider AOP system. I think it is situational. Some code needs to know exactly what is happening in order to be maintainable and readable. Other code needs the flexibility of not being tagged as it may be used in a variety of situations. TX-REQUIRED can fall into both catagories.

This brings me to my long standing point that metatags should be able to be applied to a class both explicitly in the code and implicitly via some other mechanism. Just as AOP can provide poitncuts to apply advices to a given Java class, it should also be able to do the same with metadata. Separation of concerns should not solely apply to functionality. It should be allowed for metadata as well.

This brings me back to some of my problems with JSR-175. It defines no way of applying metadata implicitly, nor does it allow for dynamic insertion of metadata at runtime so that a proprietary framework could take over this function. Instead we are forced to preprocess a Java file, bytecode manipulate pre-runtime, or at runtime when a class is loaded.


> This sort of approach can sharply limit reusability, and in the end looks an awful lot like EJBs with fewer configuration files.

The key word is "can" here. It can limit reusability.

It looks alot like EJB config via XDoclet, the key difference being that EJB is a finite set.

>What I'd call "real" AOP can operate on business domain objects directly, without their knowledge (if desired, it's not an absolute), and the same domain objects can be altered differently in different environments by varying AOP aspect code.
>
> It sounds rather silly to some, but if you try a meta-tag approach for awhile it feels amazingly like EJBs sans deployment XML files, and you find that to achieve reusabilty you have to do the same sorts of tricks here as you do in EJB, with various facade and proxy objects artificially introduced.
>
> -Mike

Allthough reusablity is a usual end goal for for frameworks and libraries, it does not hold true for most end-user applications where maintainability and readability are more desirable.

Bill

\Bill Burke\
TX-REQUIRED is used in the exact same context as the 'transient' keyword. transient deals with serializations, tx-required deals with transactionality. Developers write serializable objects because they know the object will be serialized. They will do the same with transactionality.
\Bill Burke\

This is one view of the world. Another view would be that your domain objects stay transactionally unaware, and another set of code - your Aspect code - applies transactionality as needed for a particular environment. In another environment using the same domain objects, transactionality might not be required, or may be applied using a completely different mechanism.

\Bill Burke\
The same analogy can be applied to synchronized. Think of Hashtable and HashMap. One can be concurrently accessed because it uses synchronized methods, the other cannot. You could apply the same pattern to transactionality. This class is transactional and cannot be access outside of a transaction. See what I'm getting at here? Where synchronized/transient are either on or off, transactions have different degrees of on/off.

So, I'm saying I don't agree that it is a bad idea for your code to have knowledge that it's being used as a part of a wider AOP system. I think it is situational. Some code needs to know exactly what is happening in order to be maintainable and readable. Other code needs the flexibility of not being tagged as it may be used in a variety of situations. TX-REQUIRED can fall into both catagories.
\Bill Burke\

Iff you don't mind your class being locked into one kind of behavior, I agree with you. But keep in mind that something like "synchronized" and "transient" are fairly low level constructs with extremely well-defined definitions in the language. Low-level and well-defined are good candiates for keywords, things tend to not have an inordinate performance hit, and they're understood by everyone.

Something like TX-REQUIRED is a much higher level concept, and somewhat ill-defined as well (at least compared to synchronized/transient). The danger here is "what does transaction=TX-REQUIRED mean, and when I say 'mean' I mean in detail down to the smallest concern?".

\Bill Burke\
This brings me to my long standing point that metatags should be able to be applied to a class both explicitly in the code and implicitly via some other mechanism. Just as AOP can provide poitncuts to apply advices to a given Java class, it should also be able to do the same with metadata. Separation of concerns should not solely apply to functionality. It should be allowed for metadata as well.

This brings me back to some of my problems with JSR-175. It defines no way of applying metadata implicitly, nor does it allow for dynamic insertion of metadata at runtime so that a proprietary framework could take over this function. Instead we are forced to preprocess a Java file, bytecode manipulate pre-runtime, or at runtime when a class is loaded.
\Bill Burke\

Once you break out of embedded tags in source, the entire meta-data concept breaks down as well. It serves no purpose. Certainly, you don't want every .java file to have a corresponding entry in an XML file (or whatever) - that's too much configuration to manage. In general, you don't want to enumerate each class' meta-data, unless you're inside the class itself. The power of pointcuts in something like AspectJ is that you don't have to enumerate each case, you can apply advice based on your code structure - not a list of 1,000 individual classes and methods.

As for JSR-175 and "dynamic" meta-data - there isn't a demonstrated need for it. If you need runtime meta-data, you can do that today. It's called a Map.

\Bill Burke\
The key word is "can" here. It can limit reusability.

It looks alot like EJB config via XDoclet, the key difference being that EJB is a finite set.
\Bill Burke\

I think the "can" part is overly minimized by people who are a little too over-zealous about meta-data tags. To me it's an important consideration that shouldn't be overlooked.

\Bill Burke\
Allthough reusablity is a usual end goal for for frameworks and libraries, it does not hold true for most end-user applications where maintainability and readability are more desirable.
\Bill Burke\

I've personally worked on several end-user applications where reusability was just as desirable as other considerations. And where the domain model was explicitly re-used in a variety of contexts. People writing relatively large applications do not write one application that runs in one given app server. There tends to be several cooperative applications, feeds, background processes, etc that all need to share the business domain objects but which are running in radically different container contexts (often without a container) and business contexts.

The reason why reusability is valued in applitions is mostly consistency - you want all your code, wherever it may be running, to share consistent behavior with respect to the data model and the business rules. It's a pecululiar arrogance coming out of JBoss that they consistently say "XYZ is only needed by containers and frameworks", and "app developers don't need that". You consistently underestimate your potential customers and their needs.

    -Mike

> This brings me to my long standing point that metatags should be able to be applied to a class both explicitly in the code and implicitly via some other mechanism. Just as AOP can provide poitncuts to apply advices to a given Java class, it should also be able to do the same with metadata. Separation of concerns should not solely apply to functionality. It should be allowed for metadata as well.
>
> This brings me back to some of my problems with JSR-175. It defines no way of applying metadata implicitly, nor does it allow for dynamic insertion of metadata at runtime so that a proprietary framework could take over this function. Instead we are forced to preprocess a Java file, bytecode manipulate pre-runtime, or at runtime when a class is loaded.
> \Bill Burke\
>
> Once you break out of embedded tags in source, the entire meta-data concept breaks down as well. It serves no purpose. Certainly, you don't want every .java file to have a corresponding entry in an XML file (or whatever) - that's too much configuration to manage. In general, you don't want to enumerate each class' meta-data, unless you're inside the class itself.

Enumerate when? How? This is what a pointcut is for. Add the TX-REQUIRED advice wherever there is a metatag of @TX_REQUIRED.

> The power of pointcuts in something like AspectJ is that you don't have to enumerate each case, you can apply advice based on your code structure - not a list of 1,000 individual classes and methods.
>

Which is what EJB does (1000 individual configurations to apply tx or security or persistence).

If we're talking JSR-175, then yes, it is lacking in this reguard. Which is what I said before, it has no way of implicitly defining metadata, nor a generic way to apply metadata to a set of classes.

If we're talking JBoss-AOP, then you can define metadata across code structure implicitly and via more generic expression.

> As for JSR-175 and "dynamic" meta-data - there isn't a demonstrated need for it. If you need runtime meta-data, you can do that today. It's called a Map.
>

And again, I state that you cannot implicitly apply metadata unless you want to preprocess Java files, preprocess bytecode, or bytecode manipulate at runtime.

As far as dynamic metadata there are many cases where a framework may want to tag a particular object instance with metadata at runtime. Sure, you could have an IdentityHashMap to apply metadata and lookup metadata, but then you have a global synchronization point, and you must also write a WeakIdentityHashMap. WeakReferences play havoc on your garbage collector. Add to that you would have to have 2 separate meta models. One standard, one proprietary.

> \Bill Burke\
> The key word is "can" here. It can limit reusability.
>
> It looks alot like EJB config via XDoclet, the key difference being that EJB is a finite set.
> \Bill Burke\
>
> I think the "can" part is overly minimized by people who are a little too over-zealous about meta-data tags. To me it's an important consideration that shouldn't be overlooked.
>
> \Bill Burke\
> Allthough reusablity is a usual end goal for for frameworks and libraries, it does not hold true for most end-user applications where maintainability and readability are more desirable.
> \Bill Burke\
>
> I've personally worked on several end-user applications where reusability was just as desirable as other considerations. And where the domain model was explicitly re-used in a variety of contexts. People writing relatively large applications do not write one application that runs in one given app server. There tends to be several cooperative applications, feeds, background processes, etc that all need to share the business domain objects but which are running in radically different container contexts (often without a container) and business contexts.
>

These types of end-user applications are built upon frameworks and libraries, either purchased, downloaded or written in-house.

I have seen shops that can't stand XDoclet(because of the reuse issue you state), and others that can't live without it(because it is more easily maintained).

JBoss AOP middleware aspects come in two catagories and really, it just ended up that way. Those that are applied via metatags, the others those that are applied dynamically at runtime.

Metatag based ones can be applied explicitly (via XDoclet right now) or implicitly through XML applied metadata, or if you so desire, by applying the interceptors directly. Flexibility.

Bill

/Mike/
Once you break out of embedded tags in source, the entire meta-data concept breaks down as well. It serves no purpose. Certainly, you don't want every .java file to have a corresponding entry in an XML file (or whatever) - that's too much configuration to manage. In general, you don't want to enumerate each class' meta-data, unless you're inside the class itself.
/Mike/

\Bill Burke\
Enumerate when? How? This is what a pointcut is for. Add the TX-REQUIRED advice wherever there is a metatag of @TX_REQUIRED.
\Bill Burke\

My point was referring to the meta-data. If it's not coming from elsewhere - usually enumerated on a per class or per method basis (just like the many deployment files for EJB). Oh, I understand something like JBoss AOP can do this sort of thing programmatically at runtime, but that wasn't where I was heading.

\Bill Burke\
Which is what EJB does (1000 individual configurations to apply tx or security or persistence).
\Bill Burke\

Yep.

\Bill Burke\
If we're talking JSR-175, then yes, it is lacking in this reguard. Which is what I said before, it has no way of implicitly defining metadata, nor a generic way to apply metadata to a set of classes.

If we're talking JBoss-AOP, then you can define metadata across code structure implicitly and via more generic expression.
\Bill Burke\

I wouldn't say that JSR-175 is lacking in this regard - I'd say it's way outside of its scope. Metadata is a useful addition to the language, but as I said elsewhere I don't think it's all that applicable to AOP. Sure, you can potentially utilitize it from AOP, but I don't think it has all that much to do with it. And from a more dynamic perspective, you can accomplish the same thing without enumerating tags using AspectJ-style pointcuts with alot less code or configuration.

\Bill Burke\
As far as dynamic metadata there are many cases where a framework may want to tag a particular object instance with metadata at runtime. Sure, you could have an IdentityHashMap to apply metadata and lookup metadata, but then you have a global synchronization point, and you must also write a WeakIdentityHashMap. WeakReferences play havoc on your garbage collector. Add to that you would have to have 2 separate meta models. One standard, one proprietary.
\Bille Burke\

The same runtime problems would apply to a standard implementation, and thereby complicate the JVM and/or Java object model. I'm rather glad the community at large does no have to pay that price.

And a universal dynamic meta-tag model is only useful if unconnected code bases are going to be accessing the same meta-data. I don't see that happening - most (almost all) times the dynamic pieces are only useful within one codebase - like JBoss AOP.

\Bill Burke\
These types of end-user applications are built upon frameworks and libraries, either purchased, downloaded or written in-house.

I have seen shops that can't stand XDoclet(because of the reuse issue you state), and others that can't live without it(because it is more easily maintained).
\Bill Burke\

You can't have it both ways - you just said application programmers don't care about re-use, in fact that was a fundamental basis of your argument, now you're saying some do and some don't.

\Bill Burke\
Metatag based ones can be applied explicitly (via XDoclet right now) or implicitly through XML applied metadata, or if you so desire, by applying the interceptors directly. Flexibility.
\Bill Burke\

As I said, there's nothing wrong with a meta-tag approach, but it's not the only approach that's appealing to developers. Some people will certainly use it, but it's not a universal panacea, and people who do use it will be constraining themselves in some ways (hopefully with their eyes wide open). My point is that it's not exactly revolutionary, and it's not going to be very useful for a large number of developers.

    -Mike

To put the result of the discussion ;-):

- AOP means "Aspect Oriented Programming" and "Attribute Oriented Programming".
- Both are important and useful.

Attribute Oriented Programming (meta data):
- You can use XML outside your Java code (like EJB) or tag @ directly in your code (like JavaDoc, XDoclet).
- It would be nice, if we can create our tags easily, without hassle in Java. Creating (!not! using) JavaDoc and XDoclet tags are too complicated for a small use.
- Example of use: JavaDoc, Design by Contract, User Input Validation, etc.

Aspect Oriented Programming:
- Non intrusive.
- You can use language like AspectJ or framework like AspectWerkz, JBoss AOP, HyperJ, etc.
- Example of use: Logging, Tracing, etc.

IMO, there are many ways to reach your target. Support on both AOP for Java would be nice. Just use the right tool for the right job.

Greets,
Lofi.
http://www.openuss.org
http://ejosa.sourceforge.net

To put the result of the discussion ;-):

- AOP means "Aspect Oriented Programming" and "Attribute Oriented Programming".
- Both are important and useful.

Attribute Oriented Programming (meta data):
- You can use XML outside your Java code (like EJB) or tag @ directly in your code (like JavaDoc, XDoclet).
- It would be nice, if we can create our tags easily, without hassle in Java. Creating (!not! using) JavaDoc and XDoclet tags are too complicated for a small use.
- Example of use: JavaDoc, Design by Contract, User Input Validation, etc.

Aspect Oriented Programming:
- Non intrusive.
- You can use language like AspectJ or framework like AspectWerkz, JBoss AOP, HyperJ, etc.
- Example of use: Logging, Tracing, etc.

IMO, there are many ways to reach your target. Support on both AOP for Java would be nice. Just use the right tool for the right job.

Greets,
Lofi.
http://www.openuss.org
http://ejosa.sourceforge.net

Lofi,

Logging is a bad example, because with the actual available AOP frameworks it seems to be impossible to implement a Logging mechanism.

What you can implement is a tracing mechanism that traces all method calls, variable assignment and thrown exceptions. (Except the methods calls etc. on the core Java API)
What you can't implement is a logging aspect that can be used by the developers to log custom messages, e.g. debugging messages everywhere in the code. So logging is indeed a cross cutting concern, but today it is not realizeable with AOP. Correct me if I am wrong, because I would like to implement it in my actual project...

Mirko
:wq

>
> Logging is a bad example, because with the actual available AOP frameworks it seems to be impossible to implement a Logging mechanism.
>
> What you can implement is a tracing mechanism that traces all method calls, variable assignment and thrown exceptions. (Except the methods calls etc. on the core Java API)
> What you can't implement is a logging aspect that can be used by the developers to log custom messages, e.g. debugging messages everywhere in the code. So logging is indeed a cross cutting concern, but today it is not realizeable with AOP. Correct me if I am wrong, because I would like to implement it in my actual project...
>
> Mirko
> :wq

It can be implemented as aspect:

ERROR RMI 14:01 2003.07.26 No route to host
ERROR SQL 14:21 2003.08.27 Too many connections
WARN IO 14:51 2003.09.20 File readme.txt not found
INFO APP 14:51 2003.09.20 void myMethod() returned nonsense without exeption
---------------------------------------------------------

 @error RMI(RemoteExeption)
 @error SQL(SQLExeption)
 @warn IO(IOException)
 @debug APP( ${result} > 0, "${current_method} returned nonsense without exeption" )

 void myMethod(){

   ......

}

I am not sure it is a good use case, but it is possible :)

>
> Logging is a bad example, because with the actual available AOP frameworks it seems to be impossible to implement a Logging mechanism.
>
> What you can implement is a tracing mechanism that traces all method calls, variable assignment and thrown exceptions. (Except the methods calls etc. on the core Java API)
> What you can't implement is a logging aspect that can be used by the developers to log custom messages, e.g. debugging messages everywhere in the code. So logging is indeed a cross cutting concern, but today it is not realizeable with AOP. Correct me if I am wrong, because I would like to implement it in my actual project...
>
> Mirko

Mirko,

right on again. You really need to start contributing to JBoss ;)

The reason logging is such a poor example is that it is contextual. Let me give a clear example:

Service: persistence.

problem: connection unavailable.

If you put a 'logging' interceptor before, all he can log is "I am going in with method "store(trade)". That is all the context you have (the method signature) but you have NOTHING ELSE, in fact you don't know if it will succeed or fail.
Suppose store fails because teh connections are un-available. the in-aspect doesn't know (the work isn't done yet), the 'out' aspect COULD know. He could know at least in JBoss because we return a "invocationResponse" that has an arbitrary payload of variables, i.e. a map. So the aspect would look like

public class loggingAspect
{
public invocationresponse invoke (invocation)
{ // JBoss style if the message

//in logic
log.println(invocation.getMethod());
log.println(invocation.getArguments());
// and that's it we don't knwo that the store will fail, it is not done yet
try
{
invocationResponse = interceptors.next(invocation);
// We are back from the target, what do we want to log?

log.println("success");
}

catch() {
log.println(invocationResponse.getVariable("INVOCATION_FAILURE"); // JBoss style will print ([ERROR] Connection unavailable)

or
log.println("FAILED"); // everyone else as we have no context, we don't know and it will print ([ERROR] FAILED, and nothing more

}

And the invocation failure is a STring PUT IN THE INVOCATION BY THE TARGET that is the only way we can pass contextual information. Logging is a BAD EXAMPLE of orthogonal stuff since there is so much context UNLESS USED IN A FRAMEWORK LIKE JBOSS where contextual information can be standardized in reifed invocations and generalized and arbitrary payloads. In that case it means that the convention or API really is saying "put your messages under the variable name "INVOCATION_FAILURE", that is a convention akin to defining the log4j API really.

very clear, good example.

The notion of contextual computing is a realy applicability question in research.

marcf

I like Rickard's idea of a single query API for deployment-oriented (defined in xml files or the way AspectJ defines pointcuts) and development-oriented @tags:

http://www.theserverside.com/home/thread.jsp?thread_id=20583&article_count=34#90632

Imho JSR175 should define a separate storage API for loading and saving attributes.

Ara.

>
> http://www.theserverside.com/home/thread.jsp?thread_id=20583&article_count=34#90632
>
> Imho JSR175 should define a separate storage API for loading and saving attributes.
>
> Ara.

And this is exactly what we have in JBoss AOP too. A way to define metadata outside the scope of the class.

Bill

> If we're talking JSR-175, then yes, it is lacking in this reguard. Which is what I said before, it has no way of implicitly defining metadata, nor a generic way to apply metadata to a set of classes.
>
> If we're talking JBoss-AOP, then you can define metadata across code structure implicitly and via more generic expression.
> \Bill Burke\
>
> I wouldn't say that JSR-175 is lacking in this regard - I'd say it's way outside of its scope. Metadata is a useful addition to the language, but as I said elsewhere I don't think it's all that applicable to AOP. Sure, you can potentially utilitize it from AOP, but I don't think it has all that much to do with it. And from a more dynamic perspective, you can accomplish the same thing without enumerating tags using AspectJ-style pointcuts with alot less code or configuration.
>

Let me give a better example of Metatags in use. We've totally beat on the transactional one, let's do another example.

Let's take a "oneway" tag. Those of you familiar with CORBA will be familiar with this. I want to be able to tag a method as that it can be run in the background. That it is a fire-and-forget method. Now there are many different ways that I may want to configure how the fire-and-forget, the background processing happens. Just spawn a thread? Put the invocation on a JMS queue? Use a thread pool? Maybe a JCA work manager?

So I mark the method as oneway

@oneway void someMethod() {...}

And define a pointcut that defines how oneway functionality will be applied to that method.

oneway is a useful construct, hint about the method. Use AOP to define how it it is implemented.

Bill

> \Bill Burke\
> As far as dynamic metadata there are many cases where a framework may want to tag a particular object instance with metadata at runtime. Sure, you could have an IdentityHashMap to apply metadata and lookup metadata, but then you have a global synchronization point, and you must also write a WeakIdentityHashMap. WeakReferences play havoc on your garbage collector. Add to that you would have to have 2 separate meta models. One standard, one proprietary.
> \Bille Burke\
>
> The same runtime problems would apply to a standard implementation, and thereby complicate the JVM and/or Java object model. I'm rather glad the community at large does no have to pay that price.
>
> And a universal dynamic meta-tag model is only useful if unconnected code bases are going to be accessing the same meta-data. I don't see that happening - most (almost all) times the dynamic pieces are only useful within one codebase - like JBoss AOP.
>
> \Bill Burke\
> These types of end-user applications are built upon frameworks and libraries, either purchased, downloaded or written in-house.
>
> I have seen shops that can't stand XDoclet(because of the reuse issue you state), and others that can't live without it(because it is more easily maintained).
> \Bill Burke\
>
> You can't have it both ways - you just said application programmers don't care about re-use, in fact that was a fundamental basis of your argument, now you're saying some do and some don't.
>
> \Bill Burke\
> Metatag based ones can be applied explicitly (via XDoclet right now) or implicitly through XML applied metadata, or if you so desire, by applying the interceptors directly. Flexibility.
> \Bill Burke\
>
> As I said, there's nothing wrong with a meta-tag approach, but it's not the only approach that's appealing to developers. Some people will certainly use it, but it's not a universal panacea, and people who do use it will be constraining themselves in some ways (hopefully with their eyes wide open). My point is that it's not exactly revolutionary, and it's not going to be very useful for a large number of developers.
>
>     -Mike

\Bill Burke\
[Info on fire-and-forget tag]
\Bill Burke\

This is an interesting idea for a tag, but it doesn't have much to do with AOP (or even with interception). You could easily write a post-compiler, custom class loader, or any number of other mechanisms to implement this functionality by re-writing the method(s) to have fire-and-forget semantics. AOP wouldn't be required.

What it comes back to is that this is a convenient, generalized mechanism for declarative programming. This may be hooked into by an AOP implementation, but since this is embedded in the code (in my terminology, this is a request-for-service by the programmer, in this case make-me-fire-and-forget,please) there isn't any seperation of concerns. The method doesn't know how it's being made fire-and-forget, but it knows that it is.

Your example also shows the limitations of a declarative model. In this example, you'd have to have some sort of error mechanism if someone tagged a method "@oneway" with a return type. Further, people who really liked the fire-and-forget semantics might want asynchronous-response semantics as well when they became more advanced in their approach - an example where several methods would be fired off asynchronously, and then their returns reaped by waiting on a common monitor object. And they'd find that while they can declaratively get @oneway, they can't get @async_response, because the semantics of that in a declarative language would be more complex than just writing code that does it. The lesson being that declarative programming has definite limits, and as you ratchet up complexity of semantics doing it declaratively becomes more of a burden than an advantage.

    -Mike

> declarative programming.

Yes, and the common denominator for all these uses of attribute programming as a way to control AOP-ish frameworks (and btw, we do this as well) is that the attributes are used to control the implementation of the class contract; they do not modify the contract itself, such as language keywords like "synchronized" would do. In other words, the attributes are more or less unimportant for someone who is *using* the class.

> This may be hooked into by an AOP implementation, but since this is embedded
> in the code (in my terminology, this is a request-for-service by the
> programmer, in this case make-me-fire-and-forget,please) there isn't any
> seperation of concerns. The method doesn't know how it's being made
> fire-and-forget, but it knows that it is.

Right. The method is no longer oblivious of the aspects used to modify the behaviour.

To sum it up, annotations(/metadata/attributes) are a handy way to declaratively modify the implementation, but it is not really related to AOP as such, and even working against the ideas of AOP since the code is no longer oblivious of the code that modifies it.

> Your example also shows the limitations of a declarative model. In this
> example, you'd have to have some sort of error mechanism if someone tagged a
> method "@oneway" with a return type.

Actually, if you use the 1.5 Annotations instead of plain Javadoc then I think such constraints can be added. However, constraints that are not solely related to the signature will be hard or impossible to enforce.

/Rickard

> > declarative programming.
>
> Yes, and the common denominator for all these uses of attribute programming as a way to control AOP-ish frameworks (and btw, we do this as well) is that the attributes are used to control the implementation of the class contract; they do not modify the contract itself, such as language keywords like "synchronized" would do. In other words, the attributes are more or less unimportant for someone who is *using* the class.
>
> > This may be hooked into by an AOP implementation, but since this is embedded
> > in the code (in my terminology, this is a request-for-service by the
> > programmer, in this case make-me-fire-and-forget,please) there isn't any
> > seperation of concerns. The method doesn't know how it's being made
> > fire-and-forget, but it knows that it is.
>
> Right. The method is no longer oblivious of the aspects used to modify the behaviour.
>

But separation of concerns != obliviousness.

> To sum it up, annotations(/metadata/attributes) are a handy way to declaratively modify the implementation, but it is not really related to AOP as such, and even working against the ideas of AOP since the code is no longer oblivious of the code that modifies it.
>

Attributes aren't related to AOP, but they are yet another handy way to apply an advice via a pointcut.

Bill

/Rickard/
Right. The method is no longer oblivious of the aspects used to modify the behaviour.
/Rickard/

\Bill Burke\
But separation of concerns != obliviousness.
\Bill Burke\

In the spirit in which AOP was originally created, it actually does. This pure spirit may be diluted to deal with the realities of development, and indeed most good AspectJ books show both "pure" aspects, and aspects which are tightly coupled to code and code which in turn is designed to accomodate the aspect(s).

Hopefully people will make the latter decision with their eyes wide open - which is part of the reason why I'm vocally disagreeing with you here on the subject. Developers should realize that the sort of development you're advocating - declarative programming coupled with an AOP mechanism - is side stepping a number of advantages you have with other, shall we say, purer AOP methods. In particular:

   - The primary concern in a given class will be littered with annotations that have nothing to do with the primary concern. This will tend to distract people who are only worried about the primary concern from the meat of the code.

   - The primary concern gets locked into one or more secondary concerns. Reusability of the primary concern/domain model is greatly diminished.

   - Global changes to policy in a certain secondary aspect may require touching many individual files. Since a given concern, as expressed in the sum of an application system's source files, is not centralized in one well-defined, encapulsated spot, a major change in the concern may mean manually changing a large number of "primary concern" source files.

I suspect the main difference between our opinions is that you see nothing but the upside in coupling AOP and meta-data - indeed your entire message is all about showing the advantages. My own view is a bit more nuanced - taking your approach has some advantages, but it will also extract some costs and sacrifices.

As an aside, if the new EJB model uses meta-data (almost identically to the way you've described, BTW), I suppose you will once again claim that EJBs are an expression of AOP, and thereby further confuse developers as to what AOP really means.

     -Mike

> Reusability of the primary concern/domain model is greatly diminished.

I have seen this problem in our own code, since we are using the same base classes on both the client and server. This has in many cases forced us to include deployment information into the attributes, such as "method foo has runtime attribute x but only on the server". The worst case so far is an attribute that describes the size of the cache used for the class. On the server it is ~100, and on the client it's infinite. That particular attribute has hence dual declarations, depending on where it's used. It gets a little messy.

The perks of using metadata to define pointcuts are still nice, but I wouldn't call it anywhere near perfect.

/Rickard

<rickard > I have seen this problem in our own code, since we are using the same base classes on both the client and server. This has in many cases forced us to include deployment information into the attributes, such as "method foo has runtime attribute x but only on the server". The worst case so far is an attribute that describes the size of the cache used for the class. On the server it is ~100, and on the client it's infinite. That particular attribute has hence dual declarations, depending on where it's used. It gets a little messy.
>

That's interesting rickard,

it means that JSR175 and dynamic download of configuration are one way to solve that. We needed to do that in JBoss 3 for generalized client containers. The way I solved it is with building truly stateless aspects and including "CONFIGURATION" in a map that is associated with the Invocation and build on the server and downloaded to the client as part of the serialization.

Meaning that mapping the xml information to a real class that gets associated with the interceptors is the way to circumvent that (you don't depend on external stuff on teh client). The downside/upside is purely stateless design. the downside of it being that it makes the code a bit more difficult to read.

marcf

> that. We needed to do that in JBoss 3 for generalized client containers.

Not following... how is "dynamic download of configuration" related to JSR175 considering that annotations are embedded in the class files? The only way I can interpret that is that "dynamic download of configuration" and JSR175 -> loading a class from a URL. Right?

> The way I solved it is with building truly stateless aspects

How does "truly stateless aspects" differ from plain old "stateless aspects"? Or are they the same?

> and including "CONFIGURATION" in a map that is associated with the Invocation
> and build on the server and downloaded to the client as part of the
> serialization.

Interesting. But how is that related to AOP? Or is it at all? I'm getting confused here.

> Meaning that mapping the xml information to a real class that gets associated
> with the interceptors is the way to circumvent that (you don't depend on
> external stuff on teh client).

Interesting. So how does this relate to JSR175 then?

/Rickard

> [Info on fire-and-forget tag]
> \Bill Burke\
>
> This is an interesting idea for a tag, but it doesn't have much to do with AOP (or even with interception). You could easily write a post-compiler, custom class loader, or any number of other mechanisms to implement this functionality by re-writing the method(s) to have fire-and-forget semantics. AOP wouldn't be required.
>

He he. You crack me up. YOu could do the same with any single one concept/aspect you wanted to apply to your code. AOP isn't required for any one thing if you want to post compile, or write a customer class loader.

AOP is a toolset to apply cross cutting functionality that doesn't exactly fit into the hierarchy/object model of every class. Separation of concerns isn't always about obliviousness. AOP is also about componentizing/grouping functionality and applying it in a orthogonal way. With the oneway and tx-required examples you still have separation of concerns, you just don't have obliviousness. You have componentized/defined asynch and transactional concerns in their own object model and have a nice way to apply this functionality in a seemless way. This seemless way is to apply a pointcut based on an attribute in this example.

> What it comes back to is that this is a convenient, generalized mechanism for declarative programming. This may be hooked into by an AOP implementation, but since this is embedded in the code (in my terminology, this is a request-for-service by the programmer, in this case make-me-fire-and-forget,please) there isn't any seperation of concerns. The method doesn't know how it's being made fire-and-forget, but it knows that it is.
>

Separation of concerns != Obliviousness.

Obliviousness is a choice. AOP is another way of organizing code that doesn't exactly fit together in traditional object models. It is a way to add another dimension to your code. You always choose to be oblivious, I do not always choose to be oblivious ;-p


> Your example also shows the limitations of a declarative model. In this example, you'd have to have some sort of error mechanism if someone tagged a method "@oneway" with a return type.

It does not show the limitation of the declarative model, it shows that the concept of oneway is limited. You're talking about an entirely different thing and trying to break the definition of @oneway. In CORBA there is an entirely different API for asynch communication that is totally separate from @oneway. Oneway is oneway. There is no response required. It can be highly optimized because it doesn't have to poll for a response.

As far as error handling goes? This can be define by the aspect itself.

Bill

\Bill Burke\
He he. You crack me up. YOu could do the same with any single one concept/aspect you wanted to apply to your code. AOP isn't required for any one thing if you want to post compile, or write a customer class loader
\Bill Burke\

I think you missed the point rather badly. With something like a "@oneway" tag, many implementation techniques could be used that have nothing whatsoever to do with AOP. To flip things around a bit, by your assertion anything that acts on meta-data tags could be considered AOP-ish - and so the javadoc tool is part of an AOP system.

You're blurring the lines so much that you've left no meaningful room for terminology and categorization.

\Bill Burke\
AOP is a toolset to apply cross cutting functionality that doesn't exactly fit into the hierarchy/object model of every class. Separation of concerns isn't always about obliviousness. AOP is also about componentizing/grouping functionality and applying it in a orthogonal way. With the oneway and tx-required examples you still have separation of concerns, you just don't have obliviousness. You have componentized/defined asynch and transactional concerns in their own object model and have a nice way to apply this functionality in a seemless way. This seemless way is to apply a pointcut based on an attribute in this example.
\Bill Burke\

What you have is an seperated, de-coupled implementation of transactions, or async, or what have you, and primary classes requesting to be hooking into them. This is not seperation of concerns - you've seperated implementations, yes, but the primary classes are participating.

Note that you could achieve the same thing with code within a method like:

   public void
   updateStuff ()
   {
      TM tm = cntxt.lookup ("TM");
      tm.setTransactionRequired();

      // Continue on with code
   }
   
(Assume the above code looks up a transaction manager and requests tran-required semantics). The above code snippet does exactly the same thing and achieves the same goals as a transction meta-tag. The difference is one of convenience - a one-line tag has far less boilerplate.

Either way, the writer of the code knows that this method is transactional, and is requesting for an external piece of unknown code to make it so.

If done in an AOP-ish manner, code/configuration requesting transactionality would not be in the primary class, but elsewhere, in a set of code concerned with transactionality (note: I don't think this is a great example of AOP, but this is how it would normally be approached).

\Bill Burke\
Separation of concerns != Obliviousness.

Obliviousness is a choice. AOP is another way of organizing code that doesn't exactly fit together in traditional object models. It is a way to add another dimension to your code. You always choose to be oblivious, I do not always choose to be oblivious ;-p
\Bill Burke\

You can, indeed, write code in an AOP manner which is cooperative. However - your example is a really, really poor one. Cooperative AOP code tends to have knowledge of the aspects being applied to it, and cooperating with those aspects. And it's tied together with some explicit code on both ends. There's nothing of the sort here - what you've got is a "@oneway" or "@transaction" tag hanging in the breeze. The code can request this sort of behavior from some system they are deploying into it, but the interaction stops there.

\Bill Burke\
It does not show the limitation of the declarative model, it shows that the concept of oneway is limited. You're talking about an entirely different thing and trying to break the definition of @oneway. In CORBA there is an entirely different API for asynch communication that is totally separate from @oneway. Oneway is oneway. There is no response required. It can be highly optimized because it doesn't have to poll for a response.

As far as error handling goes? This can be define by the aspect itself.
\Bill Burke\

Mr. Burke, you repeatedly get bogged down into implementation, and forget the abstract. In an abstract world, "fire-and-forget" and "asynchronous return" are very close, kissin' cousins, and are commonly used in tandem in systems that treat them as such. If "fire-and-forget" and "async return" have to be used in wildly different ways (in something like Corba, or your mythical @oneway tag world), then you're letting the implementation details take precedence over how concepts are normally applied. In English: Corba has a "@oneway" mechanism because it was easy to implement; they do not have an "@asyncreturn" mechanism that works in the same way because it's not easy to implement it. However, note that there are frameworks (non-declarative) where the difference between the two from a user's perspective are trivial. For one example, see Billy Newport's Async Beans in Websphere 5.0.

Don't keep falling into the trap of developing what's easy or natural given your current implementation details; true advances in software development come from focusing on what users want and can benefit from, not from what you can easily hack into a system over the weekend.

    -Mike

<bill> Let's take a "oneway" tag.

My personal favorite, saying @oneway:name"bla" instead of 100 lines of JMS+MDB crap :)

simplifying J2EE, btw this is in the plans but not coded yet (as a configurable interceptor) although most of the infrastructure (remoting framework) is there. Good little starting point for someone wanting to get in JBoss and start deep,

Deeper,

marcf

>
> Let's take a "oneway" tag. Those of you familiar with CORBA will be familiar with this. I want to be able to tag a method as that it can be run in the background. That it is a fire-and-forget method.

I think it is a good example. Metadata in source code helps to write/read code,
and AOP frameworks/languages use custom metadata:

1.
  public void oneWayTransactionalSendMessage(Message msg);

2.
  @oneway
  @transactional
  public void sendMessage(Message msg);


Both examples use custom metadata to declare the same. It can be in method declaration, "tag" interface, "RemoteExeption" or special package name, but I do not think somebody prefers this way to add tags for AOP, IDE, gode generator or container.
Metadata != AOP, but it helps to write aspect oriented code and can solve much more problems in "AOP enabled" frameworks. Metadata can be used for "aspect" itself: "introduce MetadataProvider for all clases with attribute @meta"

> Now there are many different ways that I may want to configure how the fire-and-forget, the background processing happens. Just spawn a thread? Put the invocation on a JMS queue? Use a thread pool? Maybe a JCA work manager?

Yes, it is a configuration. Configuration != AOP too, but it doe's not conflict with AOP. It can be used to configure "aspect" itself, "aspect" can be implemented for configuration too: "throw exception before to load classes in package "*.runtime" if there is no configuration file in classpath"


I think both "Metatags and Configuration are very useful to AOP" ant it is useful without AOP too.

On the flip side, using metatags has its own problems that more traditional pointcut mechanisms don't have. The most obvious is that your code now has knowledge that it's being used as part of a wider AOP system, and your code is also locked into specific aspects.

Ok, so attributes are intrusive and aspects aren't.

You can avoid this with semantic tags that indicate only what the existing code does (as opposed to requesting an outside service), but most people proposing meta-tags don't mean this, they mean requesting a service...
...
It sounds rather silly to some, but if you try a meta-tag approach for awhile it feels amazingly like EJBs sans deployment XML files, and you find that to achieve reusabilty you have to do the same sorts of tricks here as you do in EJB, with various facade and proxy objects artificially introduced.

Interesting.

\Brian Miller\
Ok, so attributes are intrusive and aspects aren't.
\Brian Miller\

I assume that's sarcasm :-)

The point of meta-tags is to embed control information directly into your "primary" source code. The point of an aspect system is to _not_ embed information in your "primary" source code, but to write aspects seperately that act against the primary code. The core of AOP is "seperation of concerns".

    -Mike

Mike, totally agree with you from a theoretical point of view. Practically though, there are many cases though, where you absolutely want to _explicitly_ set your tx_required right in the code, because it is crucial to fulfill the business requirements. Therefore, you need both implicit and explicit pointcutting.

From a reusability point of view, you would always favour external definition of your pointcuts over the use of metatags directly in the code. However, I also believe, that everything that you reuse heavily can/should be an aspect itself. So, the business code that remains to be written is pretty much a "one-off" (it serves exactly one business requirement, therefore does not need to be reused, therefore use of metadata tags is ok).

\Bob Farmer\
From a reusability point of view, you would always favour external definition of your pointcuts over the use of metatags directly in the code. However, I also believe, that everything that you reuse heavily can/should be an aspect itself. So, the business code that remains to be written is pretty much a "one-off" (it serves exactly one business requirement, therefore does not need to be reused, therefore use of metadata tags is ok).
\Bob Farmer\

I don't think there's anything wrong with meta-tags, and there are situations where they're useful. If nothing else they can be very convenient.

But I don't think they're really all that important of a feature, and they don't have very much to do with AOP.

   -Mike

<Mike>But I don't think they're really all that important of a feature,</Mike>

I think it is one of the most difficult things in AOP to decide how you define your pointcuts, so I guess it is important. But that has been discussed in
http://www.theserverside.com/home/thread.jsp?thread_id=20583 without result.

I think it is one of the most difficult things in AOP to decide how you define your pointcuts, so I guess it is important. But that has been discussed in
thread_id=20583 without result.

Expressing pointcuts would be trivial if the source language were XML -- just use XPath. And weaving would also be trivial -- just use XSL.

XML is very trivial to parse, transform, traverse, .... but I do not thing "everything is XML".
It is possible use XML to write pointcuts aspects and code and to transform it to aspectj or java, but I prefer human readable code not the parser friendly format.

XML is very trivial to parse, transform, traverse, but I do not thing "everything is XML".

I've alternatively used ANTLR or javac to emit XML from parsed Java. There's also JavaML. And then there's also Apache's JXPath which could be applied directly to the internal data structures of javac or BCEL. Any of these tools might be useful to a weaver implemented in XSL.

<juozas> Expressing pointcuts would be trivial if the source language were XML -- just use XPath. And weaving would also be trivial -- just use XSL.
>
> XML is very trivial to parse, transform, traverse, .... but I do not thing "everything is XML".
> It is possible use XML to write pointcuts aspects and code and to transform it to aspectj or java, but I prefer human readable code not the parser friendly format.

>

Ok it points to a deeper point on readability. Here is the main beef I have against user-land AOP as a basic construct.

You go from

class A
[
b.anExplicitMethod(withExplicitParameters);
}

class B

...anExplicitMethod(withExplicitParameters) {

..use explicit parameters

}
}

which makes simple sense from a reader standpoint "a calls b to do something explicit".

We then go to the more obscure

A{

putStuffInMessage(explicitParameters);
}

B{

public invocation invoke(invocation){ // or equivalent

... work from the invocation in indirected fashion

}

AND THEN YOU ASSEMBLE THEM IN "first A then B" by a language or really a "CONTROLLER" that controls the flow.

Now the example shows OOP really, it is not a good candidate for AOP since there is a clear dependency of state between the two. That means that AOP candidates are better assembled when there is complete separation of state (what AOP'ers call 'orthogonality of aspects' of which imho separate state domain are a sufficient condition to establish orthogonality and the reason why I believe combinatorial thereof are a simple human-feasible endeavour).

but the point is that even in purely orthogonal you go to expressing flow from OOP to a more obscure and indirected xml/language file. In JBoss what throws people off when they study the container is that we assemble it with xml files and thus static analysis of OOP code doesn't show that structure.

THAT IS ****GREAT**** for middleware, as it enables very generalized constructs of containers (add this custom security like the military do with JBoss or do client side caching as Wall Street does with JBoss). It is also ****GREAT**** for extending user applications and Ivar Jacobson's example at the IBM wattson talk was "adding new billing features" to an existing telco application. The point being that the app is OOP and then *extended* or 'patched' using AOP to say "before you do teh actual call, use this new billing system' and then all themessages MUST BE CONTEXTUAL IN THE MESSAGE PASSED (as in the logging example I give above).

The bottom line is that imho, that assembly for user app doesn't bring much and all the aspects you identify are mostly Objects, you lose readability imho. Now for extending YOU NEED AOP, and then you need to make sure that there is a detyped invocation flow (the Invocation object above) before these systems are really viable, that is standardization domain. Finally for middleware it makes COMPLETE SENSE as the stuff is 80% orthogonal and it allows for VERY dynamic containers and going back to IVAR's point all of middleware is 'extensions' to the applications, in a way it is.

Sorry to repeat myself but

here

marcf

<bob> I think it is one of the most difficult things in AOP to decide how you define your pointcuts, so I guess it is important. But that has been discussed in
 http://www.theserverside.com/home/thread.jsp?thread_id=20583 without result.

>

bob, no, it is one of the least interesting problems in AOP. I have been harping on that point for ever and it is the source of many ruffled feathers but the emphasis of languages like AspectJ that mostly serve that need, the definitions of the pointcuts is bullshit.

Let me explain before you guys turn on the flamethrowers.
Here are topics of RESEARCH in order of decreasing importance for me.

1- Applicability of AOP. What kind of problems are solved with AOP? in my mind insertion of really orthogonal concerns in the flow. That is why middleware is so relevant as an AOP enabled framework. AOP for applications? I will doubt until proven wrong (not to say that I am right on that point). EXTENSION of user applications with AOP etc

2- Taxonomy of relevant aspects in middleware, I am branching in the tree here as I focus on middleware AOP, some researchers may look at the brother branch. We have identified about 8 middleware aspects, plenty more exist in the academic research papers (NRMI and ROC come to mind). Note that most framework of AOP DO NOT BOTHER WITH THE ASPECTS. They don't ship "aspects" they define frameworks for them (including JBossAOP), which is why we all talk about the "logging" aspects which btw may not be the best candidate (it is very contextual) but that is another discussion. THE CROWN JEWEL OF AOP in MIDDLEWARE are the aspects themselves. JBoss 4 ships aspects.

3- interdependency of these aspects. See the AOP thread on bill stuff, man I really wish we had a permanent board as right now these discussions follow the "news" and it is not the best. But in any case, it seems most aspects have dependencies on TX, we understand these in most contexts (EJB being one) but exhaustive combinatorial research would be relevant as well as feasible DUE TO THE LIMITED NUMBER OF KNOWN MIDDLEWARE ASPECTS

4- pointcut definition. I argue everything should be pointcutable, got tremendous pushback from IBM on that feature from the VM guys but ok. Then weaving the aspects and what aspect to put where is what the AOP languages address, including XML binding, whether in file, XDoclet style or out of file ejb-jar.xml style or completely transparent (JBoss TreeCacheAOP style). That last point I argue should even be VISUAL, see drawing above in insertion of middleware aspects as a visual construct. UML would be the way at some point with some nice 'drag-and-drop' this aspect to this object frameworks.

On the number one point (applicability) I will try to expand on experimental data such as rickard's on the linear growth of aspects for apps (indicating OOP fit) to logarythmic growth of middleware aspects, also known as system aspects, which clearly points to AOP reuse.

Gregor Kickzales was kind enough to invite me to the AOSD selection committee for 2004, I will apply the above 'scale' as to what I want to see as papers.

marcf

\marc fleury\
bob, no, it is one of the least interesting problems in AOP. I have been harping on that point for ever and it is the source of many ruffled feathers but the emphasis of languages like AspectJ that mostly serve that need, the definitions of the pointcuts is bullshit.
\marc fleury\

I disagree rather strongly. The most interesting problems in AOP are:

  - What do your aspects look like? How do you go about coding them?

  - How do you hook your aspects into the rest of your code which implements your primary concerns (e.g. what's your pointcut model)?

If you get basics like these wrong, then the rest of your AOP implementation is pretty much doomed. The end result will be hard-to-write aspects that are hard-to-connect-to-primary-concern-code. Hey, wait - that's JBoss AOP!! Hmm, maybe _that's_ why you consider these pieces "bullshit" - because they're the weakest points in your own product?

\marc fleury\
1- Applicability of AOP. What kind of problems are solved with AOP? in my mind insertion of really orthogonal concerns in the flow. That is why middleware is so relevant as an AOP enabled framework. AOP for applications? I will doubt until proven wrong (not to say that I am right on that point). EXTENSION of user applications with AOP etc
\marc fleury\

Do some research on the AspectJ web site, and pick up some of the more recent AspectJ books. You have already been proven wrong. The action in AOP right now is in aspects defined by application developers in application code. The unproven domain is the one you're claiming - canned aspects provided by a vendor. The application world has already proven the worth of AOP (at least AOP implementations other than JBoss AOP). JBoss AOP, in contrast, is in unchartered waters with your implementation in several respects, and the burden of proving anything is in your court, not anyone else's.

\marc fleury\
THE CROWN JEWEL OF AOP in MIDDLEWARE are the aspects themselves. JBoss 4 ships aspects.
\marc fleury\

Perhaps you haven't checked with your people yet, but JBoss 4 isn't shipping. It's in Developer Release 2, and your own chief architect has indicated that there's a long way to go to a real release. So it'd be pretty tough for any aspects to be shipping, given that the product isn't, wouldn't you say?

\marc fleury\
3- interdependency of these aspects. See the AOP thread on bill stuff, man I really wish we had a permanent board as right now these discussions follow the "news" and it is not the best. But in any case, it seems most aspects have dependencies on TX, we understand these in most contexts (EJB being one) but exhaustive combinatorial research would be relevant as well as feasible DUE TO THE LIMITED NUMBER OF KNOWN MIDDLEWARE ASPECTS
\marc fleury\

I'm going to stop commenting on these bullets, because these bullets have nothing to do with AOP, and are in fact bullets for marketing the still-in-development, still-largely-vapor JBoss 4 product.

    -Mike

\marc fleury\
1- Applicability of AOP. What kind of problems are solved with AOP? in my mind insertion of really orthogonal concerns in the flow. That is why middleware is so relevant as an AOP enabled framework. AOP for applications? I will doubt until proven wrong (not to say that I am right on that point). EXTENSION of user applications with AOP etc
\marc fleury\

\mike\
Do some research on the AspectJ web site, and pick up some of the more recent AspectJ books. You have already been proven wrong. The action in AOP right now is in aspects defined by application developers in application code. The unproven domain is the one you're claiming - canned aspects provided by a vendor. The application world has already proven the worth of AOP (at least AOP implementations other than JBoss AOP). JBoss AOP, in contrast, is in unchartered waters with your implementation in several respects, and the burden of proving anything is in your court, not anyone else's.
\mike\

I tend to agree with Marc on this topic. I see no value adds to the Aspects in "domain oriented" application development. If you build a business application, you need to have "explicit" extension points. Why? Let's say, your business application will be upgraded with a new version. You want to be sure that your extensions will work smoothly without problems after the upgrade. Without explicit extension points this would be really difficult.

Using design patterns like: Registry, Factory, Proxy, Handler and Policy help a lot. But anyway, this is an old discussion, check this for more:
http://www.theserverside.com/home/thread.jsp?thread_id=20583

Lofi.
http://www.openuss.org

\Lofi Dewanto\
I tend to agree with Marc on this topic. I see no value adds to the Aspects in "domain oriented" application development.
\Lofi Dewanto\

And yet this is where most AOP work is being done at the moment, and it's where the success stories are.

\Lofi Dewanto\
 If you build a business application, you need to have "explicit" extension points. Why? Let's say, your business application will be upgraded with a new version. You want to be sure that your extensions will work smoothly without problems after the upgrade. Without explicit extension points this would be really difficult.
\Lofi Dewanto\

I don't follow you here. When you upgrade an application (as in fix bugs, add features, etc, I assume?), I'm hoping that you do a coverage test and functionality tests on it to assume that it works :-) Whether you're using meta-tags or traditional AOP pointcuts, mistakes can be made, and testing needs to be done to ensure that the right thing is being done. The probabilities are equivalent for a class/method being renamed and subsequently missed by a pointcut as it is for a developer to miss a few @transaction tags here or there. If a developer has a few neuron mis-fires and tags a bunch of methods as tx_supports, and realizes after the fact that they should be tx_requires, there's a high probability he's going to screw up one or more of the tags on his first attempt.

Certainly both methods have their downsides - using tags means you have to go around tagging everything, an arduous process if you have alot of code. Using AspectJ-style pointcuts mean that you can cover alot of classes/methods with pointcuts, but this ties your aspects to your primary concern code based on the structure of your code (including possibly package naming conventions, class naming conventions, etc). If you switch those conventions, you need to know to switch your pointcuts to match them. In either case, mistakes are possible, and there's no way to statically determine whether a developer did the right thing or not.

If by "extensions" you instead mean that middleware providers should have a bunch of standard aspects that you can hook into with application code - hey, this sounds great to me. But no one has as yet done this, and at the same time the value you can get from this does not detract from the value you can extract from AOP in using it within your own applications. Just because an app server has a number of neat services does not mean that I can't do some neat stuff on my own :-)

    -Mike

Mike: using tags means you have to go around tagging everything, an arduous process if you have alot of code.

I have been thinking a bit about this whole internal-tagging vs. external pointing, and it does seem that there is a category that clearly could be handled by specifying the desired aspect in a tag in the source code of the class to which the aspect will apply. However, that does seem rather limiting.

OTOH, if you have to select all the places to apply an aspect to from an external POV, that too seems a bit hard in any sufficiently complex application, hence some strange ideas like regex.

What if, however, you could use tags to indicate potential categorization, and later enumerate the categories and drill down through them, either automatically or manually selecting the classes/methods to apply the aspects to? In other words, "please show me all methods that are marked as transaction-capable and I will select those to which I wish to apply this aspect".

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

From a reusability point of view, you would always favour external definition of your pointcuts over the use of metatags directly in the code.

Yes, in the case where the source code is difficult to access programaticly, as with traditional procedural source code, such as Java. But if the source logic is expressed as XML, then for maintenance it makes no difference whether pointcutting is defined internally or externally. I say this since XSL transformations could easily allow toggling between internal and external definitions. A benefit of internal definitions is needing fewer files. With XML source logic, pointcuts can be expressed with XPath. And I suppose aspects could easily be applied to XSL. So an aspect framework implemented in XSL could weave itself. Dog food!

>
> Yes, in the case where the source code is difficult to access programaticly, as with traditional procedural source code, such as Java. But if the source logic is expressed as XML, then for maintenance it makes no difference whether pointcutting is defined internally or externally. I say this since XSL transformations could easily allow toggling between internal and external definitions. A benefit of internal definitions is needing fewer files. With XML source logic, pointcuts can be expressed with XPath. And I suppose aspects could easily be applied to XSL. So an aspect framework implemented in XSL could weave itself. Dog food!

Is it a new buzz word "Document Oriented Programming" DOP :)
But I agree all way are good for "separation of concerns", metatags and XML can help too.

<brian miller> Yes, in the case where the source code is difficult to access programaticly, as with traditional procedural source code, such as Java. But if the source logic is expressed as XML, then for maintenance it makes no difference whether pointcutting is defined internally or externally. I say this since XSL transformations could easily allow toggling between internal and external definitions. A benefit of internal definitions is needing fewer files. With XML source logic, pointcuts can be expressed with XPath. And I suppose aspects could easily be applied to XSL. So an aspect framework implemented in XSL could weave itself. Dog food! >

Guys, again let's collectively move away from 'defining the pointcuts: the return" it is a bad and boring movie. We got it, I am sorry that aspectJ puts so much importance on these as opposed to the aspects.

What fascinated me in java is not so much the syntax or grammar (and some will argue that C# has better grammar) but the wealth and richness of libraries or in the case of middleware AOP, the richness of the aspects.

marcf

> return" it is a bad and boring movie. We got it, I am sorry that aspectJ puts
> so much importance on these as opposed to the aspects.

It's like deja vu all over again. Funny thing is, you remind me of me a year ago. A year ago I thought AOP was about "interceptors" too. I suppose my EJB background can be blamed for that. However, as we started writing actual code I quickly realized that those darned mixins were kind of important as well. But now, a year later, when we have our advice and mixins written and all is well, I've realized that what is really truly important are the pointcuts. You know, the little suckers that define the cross-cutting points. Why? Because after you've gotten to the point where the aspects are non-trivial and you have lots of them (which is where we're at now), it becomes very important to be able to easily define where these suckers should go, or else the complexity of it all will just overwhelm you. And you can only really do that with a decent pointcut language (which admittedly we don't have in our in-house framework). Funnily enough, this insight is kind of hidden in plain sight as it is point 1a) in the AOP patent that Xerox owns. It states thusly:
"1. An aspect program operating in an aspect-oriented programming environment, the aspect program being stored on a medium readable by a computer system, the aspect program implementing aspect concerns that cross-cut a software entity, the software entity defining an overall functionality of a software application program stored on a medium readable by the computer system and comprising one of at least one program body and at least one object class, the aspect program comprising:

a) a cross-cut that comprises a point in the execution where cross-cutting behavior is to be included; and

b) a cross-cut action comprising a piece of implementaton associated with the cross-cut, the piece of implementaton comprising computer readable program code that implements the cross-cutting behavior; wherein the cross-cut action transparently forces the cross-cutting behavior on the software entity.
"

Go figure.

Marc, if you really truly believe that pointcuts are nonsense, then maybe what you are after isn't really AOP. Let's call it FOP instead (Fleury Oriented Programming, or Fantastic Orgasmic Programming, or whateveryouwantprogramming). Then, if at some point you decide that "ok, pointcuts are interesting", then you can rename it back to AOP and we will all be able to understand what you're saying. Coz currently it's (IMO anyway) all just fancy word saladery with little or no relation to the topic you're claiming to be talking about.

Marc: Guys, again let's collectively move away from 'defining the pointcuts: the return" it is a bad and boring movie. ...

Rickard: It's like deja vu all over again. Funny thing is, you remind me of me a year ago. A year ago I thought AOP was about "interceptors" too.

Uh, no. That isn't at all what we're getting at here. Actually the opposite: there are many kinds of aspects, not just interceptors, so pointcutting might have rich targets, not just opaque business methods. Almost any codebase artifact could theoreticly be woven. So pointcut expressions shouldn't be dismissed as easy or a solved problem. Anyway, Marc is bored.

Rickard: a) a cross-cut that comprises a point in the execution where cross-cutting behavior is to be included;

Ie, behavioral aspects, and not structural aspects. Very limiting, but still immensely complicated by the richness of Java's abstract syntax tree. Ie, worthy of a heavy duty tree navigation language, such as XPath.

I am not sure of the definition of "AOP/pointcut target" in the
abstract syntax tree. My understanding of syntax tree is it is
used to represent syntax ONLY. By visiting a syntax tree can you
find out whether a particular function is representing a numerical
algorithm for finding prime numbers? In other words how are you
deriving target/introduction semantics by looking at Java AST and
using XPATH on XML representation of AST?

How exactly you are proposing to find AOP/pointcut targets by visiting
pointcut targets -- I would be interested to know.

Soumen Sarkar.

Sorry, a correction:

How exactly you are proposing to find AOP/pointcut targets by visiting
AST or XMLAST -- I would be interested to know

<gregor> If anything, C# with its metatags already in place conceivably should have a jump on Java in terms of implementing a robust AOP framework. There has to be a solid metatag framework in place for AOP to be truely feasible, and we won't see that in Java until JSR 175 is implemented. IMHO using method signatures to define pointcuts is a bit too brittle.>


*precisely*
thanks, it seems we are not preaching in a desert and simple technology always prevails.

"We are the believers, we believe in technology that is simple and brilliant, and we believe it will prevail through that brilliance"
-- Poster in the lobby of IONA --

marcf

>
> Maybe there is something I dont get :(.
>
> Dhananjay

Dhananjay,

see
http://www.jboss.org/index.html?module=html&op=userdisplay&id=overview
Scroll to the bottom for the last drawing.

what we are showing is AOP APPLIED TO MIDDLEWARE greatly simplifies J2EE and allows for a la carte assembly. That is what .net allows. In C# .net remote you simply put a tag

@.net-remote:soap

(or something like that)

that defines a web service.

We are saying that tag driven AOP applied to middleware allows for the same simple constructs.

Part of our argumentation is that people like BEA are trying to solve the complexity of J2EE through GUI's. We prefer to simplify the framework itself so taht the resuilting GUI's are even simpler. You can use the tag driven stuff in eclipse (JBoss IDE) and do autocompletion.

So on all the objects you see you will be able to use tags to define what is in the front and what goes in teh back (namely remoteness and persistence respectively).

C# has the tag stuff, JSR175 will give it to us, but what we really need are VISUAL TOOLS to allow us to drag and drop SERVER SIDE SERVICES or rather their associated aspects onto simple java objects. You will notice that EJB's bundle ALL the aspects at once and that is the main criticism of the people of use them. Transpose EJB to the drawing above and you will see that fronting applications have remoteness and security, when you just want remoteness, and the back has transactions, security and persistence when you just want cache and persistence. This is EJB done right.

It is not a point on AOP in general but rather a point on AOP oriented middleware as the FUTURE OF MIDDLEWARE. Our role at JBoss Group is to "aspectize" all relevant research imho.

marcf

Marc

What's your rational for suggesting that "people like BEA are trying to solve the complexity of J2EE through GUI's"? The primary focus of BEA in this area is to standardize a series of tags via JSR 175, 181, 207, and 208 (with others to follow, I suspect) in order to simplify J2EE. That way, developers don't have to have advanced IDEs in order to write, compile, package, and deploy EJBs, Web Services, Web Apps, etc. They can just pass a simple Java file with annotations to the server and the server will build out the service. I think there is a pretty broad consensus, not only on this forum, but within the technical community as a whole (ISVs, SIs, etc.), that this is necessary.

The WebLogic Workshop GUI allows developers "to drag and drop SERVER SIDE SERVICES or rather their associated aspects onto simple java objects". This is the second part of what you see as a necessity for J2EE. I agree with you that there are still areas that could be simplified more, but this goes back to defining useful annotations. However, if we're talking about how to compete with Microsoft and C#, the biggest mistake we could make is present J2EE as a chaos of competing standards that reduce the ability of ISVs and SIs to support multiple platforms.

That is why it make sense for BEA is push standardization of the tags first and foremost, while also providing a GUI that helps developers get accustomed to the idea of annotations.

If you do not have clear understanding in regards to why .NET
attribute facility may be relevant to AOP, please visit

How .NET’s Custom Attributes Affect Design
http://www.martinfowler.com/ieeeSoftware/netAttributes.pdf

Soumen Sarkar

There is another AOP-related site:
AOP-Space at http://www.gopas-software.de/aopspace.
It provides current information (in German),
 support and (soon) a library of examples and reusable aspects.

Christoph Mathis
mathis@gopas-software.de

AOP to counter C#, if that's what it means for mainstream to recognise AOP then ... oh well. Anyway although there are definately some nice features in AOP, I'm not convinced yet that it is better than say MOM or meta constructs like the lisp people have had them for decades. I mean, for example, when I can set up a handler chain for an XML message (like in Axis or Cocoon) I have declarative pre and post processing or dispatching not only based on types and names of methods and classes but also on the data itself. That seems much more powerful to me. Maybe it'd make sense to include something like this into Java if that's really what we want.

Note that IBM subsequently clarified that they are not in fact working together with JBoss -- "to say we are working together is not true".

http://www.internetnews.com/dev-news/article.php/3083641

I thought it was rather odd that nobody from IBM was quoted from the article. It's rather odd that Marc Fleury or Bill Burke didn't comment on the inaccuracy of the article here.

    -Mike

You can find a link off of the java.net site:
http://today.java.net/pub/n/IBM_JBoss_Denial

Jin

> http://today.java.net/pub/n/IBM_JBoss_Denial
>
> Jin

As you can see, I clarified it to the press.

Dean Wampler, from IBM rational, spoke at our JBoss Two conference at Java one this year. (He was on our AOP panel).

Marc spoke very recently at an IBM research conference on AOP.

Bill

>
> http://www.internetnews.com/dev-news/article.php/3083641

Hehe,

We spent a week on the road with bob bickel doing a press and analyst tour, just came back and back out tomorrow, but I will at least set the record straight.

We got invited by IBM to meet with the "brass" meaning the guys that work directly for "steve mills" he is the CEO of all software at IBM. The meeting was mostly NDA but some parts are public knowledge. More interestingly the introduction was "we will never be friends but we can work together" and the 2 areas for "collaboration" identified by the IBM'ers were

1- KICK MICROSOFT. They see us as the best line of defense against the encroachement from .NET. Interestingly we never talked about BEA apart from one of them saying "so how much do you clobber them, we certainly do". In fact I get the feeling, this is my opinion, that we are all discounting BEA as almost dead and that it won't defend. I don't know, maybe, I am more optimistic BEA installed base is real.

2- ASPECT ORIENTATION. Following that meeting they invited me to talk at their internal AOP conference. That is when I met with IVAR. It was great to meet the HyperJ folks and teh AspectJ folks, we exchanged ideas, talked and it is always great to meet face to face takes some of the strong feelings out. (BTW mike spille, keep it up and stay away from personal insults and I will 1- respond to your points 2- invite you to LA for our next bootcamp so you can meet face to face with Bill ;)). Then we had a meeting with some of the VM folks at IBM, where we wanted to discuss what could be standardized. We can standardize the pointcuts in J2EE (trivial). I pushed for state tracking (they pushed back with "SUN don't move") and they seriously pushed back on generalized interception as it would screw hot spot style optimizations. I spent a good day there.

So I also met with the reporter at IDG that published the "denial" on friday as part of my PR tour in SF. They mentioned that they had talked to "some lady in PR" and that she didn't know anything about our collaboration. I asked they contact us before "denying" as it makes us look kinda bad. Oh well the realities of the press is that 'drama >> facts' and in fact is the best part of the news business ;)

we are collaborating not formally with PR and all but we are doing the same work and going for the same goals.

marcf

\Marc Fleury\
 (BTW mike spille, keep it up and stay away from personal insults and I will 1- respond to your points 2- invite you to LA for our next bootcamp so you can meet face to face with Bill ;))
\Marc Fleury\

Really really do ya _mean_ it Uncle Marc? If I'm really good can I have a lolly, too? And stay up past my bed time?

    -Mike

OK, this begs the questions:

  - How come the only IBM quotes are the ones emphatically denying any cooperation?

  - By the balls of the great goat god JuJuJaan, why on earth would IBM research contact JBoss about AOP? There are far more authorative people that IBM research would contact on such a subject. The authors of a DR2 AOP implementation which is the newest kid on the block would be the last on the list, I'd think.

  - Why would IBM research be focused on "Kick <Anybody>". This is not a research function, it's a marketing/sales function. Having dealt with IBM research people, I can say that they just plain don't work that way.

     -Mike