AOP on the Client, can we do it yet??

[hchirino]

Bill,

Can we do AOP on the client-side yet???

[crazybob]

> > The pointcut language is compositional. This
> means
> > that you
> > can take pointcuts and compose them to form other
> > pointcuts.
> > This means that you can build up crosscutting
> > structure in
> > a similar manner to what we know about building up
> > procedural
> > structure or class structure.
>
> Be precise makes little sense as is. Right now we
> have precise requirements for JBoss System that we
> must able to say 'on this method/field/constructor'
> please apply this set of interceptors. We can do
> dynamically.

Composition is more useful at the app developer level for "application aspects" although it definitely would be useful at the system level as well -- even though the specified sets at system level are predefined and therefore easily handled by other means.


> One of the things that would be nice is a more
> evolved language that enables us to provide multiple
> pointcuts in one sentence such as
> "apply these interceptors to methods having to do
> with CRUD operations" a "where get/set create/delete,
> intercept" kind of thing. Can you give me use cases
> of evolved languages?.

This is composition. First you have a definition of a set of methods/fields 'A' and for example two defined sets of interceptors; one stack 'M' of CMP persistence interceptors another stack 'N' for Tx/Locking.

You compose these definitions into a component contract 'X' by joining them to apply to a specific set of methods where you want the persistence and transaction/locking construct enforced. Essentially you define 'X' to say "if my objects contain signatures A I want to apply M+N". From that point on you can advice your POJO to fulfill contract X directly.

This is a point about giving more expressive power to the developer.


> hmmmmm, in the case of system AOP ala JBoss I am not
> sure I see a use for the named abstractions. I can
> say the above where the pointcut is a
> method/field/constructor/interface method but where
> do I need a more evolved language?

Have a look at the current standardjboss.xml file. About thousand or so lines of configuration that basically just repeats itself. And this is to cover just a few basic cases of fulfilling the EJB service contract. This is where composition (via inheritance) even at system level would be helpful although of more limited use compared to application level.

It might be that XML schema is enough -- although I have my doubts relying too much on the XML garbage files. Failure at component level already, who wants it at the object level?

Anyhow, composition at the application level would serve the developer quite well as we're unable to provide the defaults at that point.

> I don't see why 'type safety' brings you for AOP
> combination of behavior.

It is clear that the type safety requirements absolutely must be relaxed for "system aspects". The framework has no way of knowing at compile time the types of the components (since we want to do away with any kind of mandatory component contract). At system level giving up the type safety might not be that much of an issue anyway -- yes it may be painful for a while until all the wrinkles get ironed out but we can assume that eventually "we'll get it right". This code will be shared across so many different services that bugs related to non-typed invocations should surface fairly quickly.

Again, different picture at the app level. A simple case (so simple it might already have been adressed). I don't want to track down through all my interceptor stack definitions just because I decided to change a method name on my POJO and whatever configuration existed for that method does not apply anymore because of signature mismatch (btw, composition plays a large role in how much 'tracking' I would have to do).

On the other hand, we gave up partially on type safety with EJB component contract already (so even at app level) when the interfaces were separated from the implementation. And seeing that custom compilers would be difficult to get accepted and rather top heavy approach it may be that we need to rely on a similar 'verifier/xdoclet/etc' preprocessor strategy we used with EJBs.

> Some interceptors come typed, meaning they expose an
> interface for simplicity's sake and for end users
> (think standard mbeans). Dynamically composing that
> signature as a sum of the signature is what Dynamic
> Proxies used to do and what JBossAOP does today with
> Chiba's bytecode chirurgical kit.

This is fine if the intended advices, introductions and metadata can all be determined from the naming conventions of a statically typed interface. But it seems unlikely. So you still end up with part of the contract located outside the Java language (assuming no language extensions, JSR175) which naturally loses any type safety from the programmers point of view.

Of course, the same problem exists for EJBs as well (part of why the price of writing an EJB component contract is so high). There still doesn't seem to be a good solution for this (although XDoclet manages to relieve the nastiest symptoms) and I doubt there will be anything outside extending the language itself (via JSR175 or otherwise).

> I am worried about the "need for a language".

Need for language is always about adding abstraction and more expressiveness to the application developer (and less places to fuck it all up). Everything can be equally expressed with a "lower" level language. Turing complete. No point in arguing that.

[hchirino]

Hi Bill,

Your current aop stuff is heavily dependent on you being able to use a custom classloader to load the application classes. I still have not seen how that can be done transparently in all client side situations.

I guess the good news is that it seems like you have started some work to support using Dynamic Proxys to do the interception which would relax the need to do classloader tricks.

Right now, the Dynamic Proxy stuff in your framework is not closely coupled with Advice/PointCut based config that the rest of the aop system is based on. I think that it could be coupled tighter.

The way I see it, we could have a Dynamic Proxy equivalent of the ClassAdvisor. An InstanceAdvisor could be associated with each DP InvocationHandler. Etc. An application would instanciate a Proxy by calling:

public Object AspectManager.createProxy(Object xx);

The AspectManager finds a ProxyAdvisor that can advise xx and then it creates a DP using a new DynamicProxyIH(ProxyAdvisor pa). The DynamicProxyIH would implement the Advised interface for the xx object by interception.

The DynamicProxyIH would pass the method invocation to the ProxyAdvisor (Since the Advisor owns the interceptor chain). This would be similar to how your bytecode engineered calls pass method/field invocation to the ClassAdvisor.

Bill, what do you think?? Is this the direction you want the DP stuff in your aop to take??

Regards,
Hiram

[marc.fleury]

A/ DP vs Class

DP is fine, it is what we use today. The problem with DP is that there is the indirection call, always. Speed is one issue although I am not religious about it. I think that the class instrumentation, while tricky, allows us to do optimizations such as "no stack?" go native, meaning that we can instrument all the classes in the server.

Remember that the first application of this is mostly serverside ONLY. The first ones are cache and persistence. So this approach buys us speed and ease of use as we can port existing applications to our caches in production without modification of the code. That is an established fact that we need to nail fast.

Then for client side. Either we have the JMX on the client and we can do some magic, but it means we need to reconstruct what the DP serialization already does which is tricky. So when we have the remote aspect in there I would default to a interface based implementation. What does that mean? I am not sure :) essentially returning interface based stuff to clients is easy and we should somehow require that for clients. That means that on the server side the instrumentation uses the interfaces when available.

B/ JMX on the client.

I still believe in that. In fact more than ever. I think this is one of the most promising ways to push JBoss. Let's put a microkernel version for "light clients" where you have some of the services available to the client VM.

[hchirino]

> A/ DP vs Class
>
> DP is fine, it is what we use today. The problem
> with DP is that there is the indirection call,
> always. Speed is one issue although I am not
> religious about it. I think that the class
> instrumentation, while tricky, allows us to do
> optimizations such as "no stack?" go native, meaning
> that we can instrument all the classes in the server.
>

blah.. you still have not covered how we can do instrumention on the client side. Everybody including me can CLEARLY see the power we can get from instrumentation on the server-side. The problem this thread is trying to address is client side aop.

>
> Remember that the first application of this is mostly
> serverside ONLY. The first ones are cache and
> persistence. So this approach buys us speed and ease
> of use as we can port existing applications to our
> caches in production without modification of the
> code. That is an established fact that we need to
> nail fast.

Yes, needed, but it does not address the question this topic raises.

>
> Then for client side. Either we have the JMX on the
> client and we can do some magic, but it means we need
> to reconstruct what the DP serialization already does

Are you saying you want to do instrumentation on the client side?? How are you going to get this to work on say an Applet??

> which is tricky. So when we have the remote aspect
> in there I would default to a interface based
> implementation. What does that mean? I am not sure
> :) essentially returning interface based stuff to
> clients is easy and we should somehow require that
> for clients. That means that on the server side the
> instrumentation uses the interfaces when available.

Yes, I beleive that you are right. Client side objects will be DPs. Interfaces must be used.

>
> B/ JMX on the client.
>
> I still believe in that. In fact more than ever. I
> think this is one of the most promising ways to push
> JBoss. Let's put a microkernel version for "light
> clients" where you have some of the services
> available to the client VM.

Client enviorments cannot be controled as easily as a server enviorment. When you think about a client, allways think about the worst case: an Applet in security sandbox. Will be be able to run the micro-kernel there and how transparent will it be to the client??

Regards,
Hiram

[marc.fleury]

> Are you saying you want to do instrumentation on the
> client side?? How are you going to get this to work
> on say an Applet?

I am saying that state change tracking mechanisms at the bytecode level are clear constructs. I am saying that state change can be built for POJOS. And so we should.

You are correct in pointing out that this approach fails for client server communication. I think this clearly establishes that bytecode engineering is a server-side magic bullet whose domain of applicability goes from Caches/JBoss to CMP/JBoss.

blah.

Usage of the classes is best done through interfaces. This also allows us to define the type of the instance at runtime by adding all the interfaces through DP.

That says that user interaction with instrumented object should be interfaces. HOWEVER system interaction with instrumentation AT LEAST IN THE CASE OF CACHE/PERSISTENCE allows for implementations that track state changes at the bytecode level.

The kind of automation we can do is amazing, I am still thinking about that versioned snapshot.


> Yes, I beleive that you are right. Client side
> objects will be DPs. Interfaces must be used.

And it also happens that recreating the serialization of bytecode engineered classes to be rebuilt on the client side would mean extreme control of the client environment. You are right, using DP's is JDK standard.

But I believe that in fact using DP's should be the DEFAULT way to extend the "public faces" for applications in general.

Different view of the same data. User programmation == APIs, System state tracking == bytecode.


> > B/ JMX on the client.
> >
> > I still believe in that. In fact more than ever.

> Client enviorments cannot be controled as easily as a
> server enviorment. When you think about a client,
> allways think about the worst case: an Applet in
> security sandbox. Will be be able to run the
> micro-kernel there and how transparent will it be to
> the client??

blah blah blah, do not underestimate the power of unified network and tiny tiny microkernels everywhere :)

JMX=JMX is a peer to peer model methinks until we find a "tinyJMX" or maybe the current one is good. I will let Adrian speak on that if he trolls the forum :)

[hchirino]

Marc, I think we are on the same page. DPs will still be highly used (until we can control client enviorments better).

Bill, is it ok if I help you out and add better DP support to your aop framework?

Regards,
Hiram

[marc.fleury]

I just want to stress that you are completely right however it is not a "either/or" point. You NEED DP for application interaction. Interfaces are the right way to create the proxies at runtime with DP. Hardcoding that at the class level is a mistake.

By the same token you NEED bytecode engineering to do field interception for the caches and cmp applications. That much is established and easy to see.

Bottom line: The AOP framework requires both for different use cases and the proxy factory you had once put with the interfaces is needed.

By all means work towards enhancing the AOP framework with Bill.

[crazybob]

We can instrument classes on the server side and load them to the client via a URLClassLoader. As an added bonus, this will work for all Java versions whereas DPs require version 1.3.

[hchirino]

> We can instrument classes on the server side and load
> them to the client via a URLClassLoader. As an added
> bonus, this will work for all Java versions whereas
> DPs require version 1.3.

- Achiving this is not transparent to the client application.
If we can control the client enviorment to that point, we might as well instrument the class right on the cliet (use jmx and the hole deal). At point, the client is running in server type enviroment.

[hchirino]

> Bottom line: The AOP framework requires both for
> different use cases and the proxy factory you had
> once put with the interfaces is needed.
>

I totaly agree.

Regards,
Hiram

[adrian.brock]

Even to generate a proxy you need to get a classloader.
Which is potentially a secured operation.

Look at the javadoc for Class.getClassLoader();

Regards,
Adrian

[aloubyansky]

Can we define a special URL to download classes for applets?
Like this:



Where classloader is a, say, servlet that loads the applet and the classes it requires. Thus, we can instrument the classes the applet uses.

alex

[crazybob]

> Can we define a special URL to download classes for
> applets?
> Like this:
> codebase="http://localhost:8080/classloader"
> code="applet.MyApplet.class"
> width="500"
> height="500">
>
>
> Where classloader is a, say, servlet that loads the
> applet and the classes it requires. Thus, we can
> instrument the classes the applet uses.
>
> alex

That's exactly what I'm proposing.

[hchirino]

Um.. that would be cool.

Perhaps we can instrument on the client side after all. How about for the case of running a swing app. You normaly do not put a http url in a swing app's classpath. Would we just make the user boot the client app via a JBoss class??