-
1. Re: JMX Connectors vs. JBoss Invokers
adrian.brock Apr 14, 2003 12:50 PM (in response to sugramoin)My arguments are purely technical,
we know JMX will work but...
Decoupling is an aspect
For a service, it makes sense to wrap the POJO
(Plain Old Java Object) in an {X}MBean to decouple the
client from the service.
Decoupling has overhead
Every access goes through the MBeanServer with a
lookup into the registry to find the mbean
using the ObjectName.
In general we are talking about a POJO which we want to
make "remote". Do we wrap it in an XMBean, give it an
ObjectName and register that with the MBeanServer?
What if there are 1000 of these POJOs
each representing a jmx notification listener,
subscription to a jms topic or a client side cache
invalidator?
To avoid the 1000 mbeans, do we use an AOP remoting
service MBean instead?
That would have three indirections:
Invoker -- Registry --> AOP remoting ObjectName
MBeanServer -- MBeanRegistry --> AOP remoting MBean
MBean -- object id --> AOP wrapped POJO
What about optimizing local access? It now goes through
the extra layer of the MBeanServer, only because the
invokers must talk JMX.
Remember I don't need the additional decoupling,
just the ability to hand the invocation over to the
correct flow/POJO.
Why not the more direct
Invoker -- Registry (object id) --> handler --> POJO
if my config includes the decoupling
handler -- MBeanServer (objectname) --> MBean/POJO
That way we don't pay for what we don't use/need.
Ideally, the payload marshalling and registry access
should be optimized away locally, but I don't understand
the implication this has for the current interceptors
that assume the transaction/principal/etc are in the
invocation.
I started this by talking about clients generating
a remote proxy allowing the server to asynchronously
respond.
What if the client is running in a sandbox (e.g. an applet)?
We might not have the correct priviledges to create
an MBeanServer or register in an MBeanServer that is
already present.
There are other problems with sandboxes.
And finally, in remote mode, the invoker/handler has to
know the correct classloader before it tries to unmarshall
the payload.
RMI does a bad job at this, assuming the classloader is
where it loaded the stub, rather than the TCL of
the application that exported the object.
It looks like jmx1.2 is making a similar mistake with
MBeanServer.getClassLoaderFor(ObjectName)
Regards,
Adrian