Invokers

[hchirino]

Repost from the JMS forum, originaly by Adrian:
=====================================================

The invokers shouldn't be tied to JMX.

They work by looking up a target in the Registry
and at the moment do a JMX invocation assuming the
target is an ObjectName.

Object mbeanServer(target, invocation);

JMX Decoupling is useful on the server.

The target could be an aspect invocation handler,
in which case the invoker does

Object handler(invocation);

This new method in the aspect invocation handler
is responsible for adding the new flow/metadata
to the already existing invocation.

In fact the MBeanServer implementation could have
a similiar method to add the extra decoupling.

The other JMX aspect of the invokers is the
service lifecycle and dependent MBeans.

If the invokers are POJOs these JMX aspects can
be added on the server and replaced with something
else on the client.

Should this be in the aspect forum? :-)

Regards,
Adrian

[hchirino]

Are you saying we should be able to setup an Invoker style chain from the server to client??

How can we do that?

Regards,
Hiram

[adrian.brock]

Yes, but I'm not sure I understand the question?

You already do this in the JMS invocation layer?

The client proxy can decide that an invocation
(or "session"/"connection" however you define it)
requires an async response.

The InvokerProxy/Invoker are then responsible for
delivering a client proxy to the server with the
invocation.

For bi-directional protocols, the client proxy
would talk back over the same socket.

As I said in the JMS forum, the client may decide
to use a different protocol for responses.
The client proxy could be created through a factory or constructed by hand.

This is not just a JMS thing.
This could be used be for updating/invalidating
client side cache.

Regards,
Adrian

[bill.burke]

> Repost from the JMS forum, originaly by Adrian:
> =====================================================
>
> The invokers shouldn't be tied to JMX.
>
> They work by looking up a target in the Registry
> and at the moment do a JMX invocation assuming the
> target is an ObjectName.
>
> Object mbeanServer(target, invocation);
>
> JMX Decoupling is useful on the server.
>
> The target could be an aspect invocation handler,
> in which case the invoker does
>
> Object handler(invocation);
>
> This new method in the aspect invocation handler
> is responsible for adding the new flow/metadata
> to the already existing invocation.
>
> In fact the MBeanServer implementation could have
> a similiar method to add the extra decoupling.
>
> The other JMX aspect of the invokers is the
> service lifecycle and dependent MBeans.
>
> If the invokers are POJOs these JMX aspects can
> be added on the server and replaced with something
> else on the client.
>
> Should this be in the aspect forum? :-)
>

Are we sure that JMX on the client is not feasible? Maybe it is lightweight enough. AOP is already doing reflection anyways, maybe AOP and JMX need to be merged into one?

Bill

[adrian.brock]

I am not saying it is not feasible,
only that it can be done without jmx.

There are two parts to the client proxy used in the
aysnc response.
1) The invocation processing at runtime
2) Construction/Config and management

Aspects can do 1
JMX does 2 and it is lightweight, but there is no reason
why something else can't do it.

When jre 1.5 arrives JMX will be everywhere in java
anyway.

Regards,
Adrian

[davidjencks]

I've implemented client side jmx, used for the trunk invoker. I think it is a great idea and will make many things on the client much easier.

[marc.fleury]

Actually guys,

I think the point originally raised by Adrian is really valid and simple. It says "I want to be able to remote POJO's with the detached invokers but I don't want to create a JMX object for all of it". I think it is a wonderful idea.

I think it is detached from the client side JMX. I truly believe that we should keep the AOP framework separate and lightweight. For most interceptors there is a service that goes with it. The services with their lifecycle under management by the server itself should definitely be under JMX control.

I think the JMX layer should not incorporate all the instances of the object, clearly. I mean already we expose the EJB container (I did that work) and I am divided over whether it is necessary. I mean it works but a simple object that has an ID that we can hook up to from the invoker is just as simple.

We need an 'identifier' of the instance. Possible the hashcode of the instance that has been AOP'ed. Then we need a map that has the the ID and instance map. We can make this map smart, for example we can break the map in a map of classes, for each class there is a map, in each map we map the hashcode to the instance.

Then when we construct the AOP proxy we put an interceptor that has the default invoker (RMI in our case) and the implementation on the server side has the logic to look up the stuff. And do the invoke(invocation) signature. I don't know if we want to keep the dynamic mbean signature for the invocation from invoker to target.

Adrian, you need to join Bill in the development of this. Our invokers are tied to JMX and it shouldn't be they should look up and emit a invoke(invocation) so we truly unify the invocation path throughout our stack.

marcf