----- Original Message -----
From: "marc fleury" <[EMAIL PROTECTED]>
To: "jBoss Developer" <[EMAIL PROTECTED]>; "Rickard �berg"
<[EMAIL PROTECTED]>
Sent: Sunday, December 03, 2000 7:33 PM
Subject: RE: [jBoss-Dev] Proxy classes for JMX
> |Before this I always thought that it is impossible to create a Proxy
class
> |on the JMX client side to deal with the remote MBeans without dealing
> |with JMX Connector etc.
> |But know the problem is that JMX does not send Interfaces to the client
> |but a JMX structure to reflect the MBeans on the server-side.
> |
> |NOW my question is how to create an Interface on the client-side to
> |create from this Interface the Proxy class or is there a way to create a
> |proxy without an Interface?
>
> You need an interface for the Proxy. The proxy is typed vis-a-vis the
> clients, that's the whole point.
See below.
> |The problem with JMX is that only standard MBeans have to implement
> |an Interface but for the other types there is no interface.
>
> the other interface for Dynamic MBeans is one with "invoke" so it would
map
> to the proxy invocation...
> but I am not sure I am seeing where you go with the "dynamic MBeans"...
There are two types of MBeans. The first is the standard MBean which
implements
the interface named <BeanClass>MBean. But the dynamic MBean implements
the DynamicMBean and then delivers an MBeanInfo object on (I think)
getMBean-
Info() method (declared in the DynamicMBean). But the MBeanInfo defines the
interface of the dynamic MBean and not the DynamicMBean interface. Therefore
the JMX Connector cannot get an Interface class because the MBean-Interface
structure is defined in the MBeanInfo.
In this case I cannot generate a proxy, or can I?
> |If this is doable I will change the JMX Connector on the client-side
> |therefore
> |that the client see the Proxy-Objects and deal with them instead of the
> |MBeanServer interface. What do you think?
>
> If you are proposing typed management of the server through java
programming
> I am hearing you.
>
> Ok, it is not very clear, I just want to make sure I understand what you
are
> proposing.
>
> All our management today is done with MBean interfaces declared in the
> server. Imagine these are seen by the client, it is then possible to
build
> a proxy that takes the calls under that interface and serves a "invoke" to
> an invocation handler that is basically a wrapper that can call the JMX
> Connector you have done.
The problem with JMX is that it does not offer the interface of the MBean
through a Java interface but through a MBeanInfo class and MBeanFeatureInfo
(and its subclasses) etc.
Yes, when I can deliver the Java Interface to the client or create a Java
Interface
on the client I can use this to create a Proxy class (and its Invoker which
just
use the JMXConnector and its methods to invoke the methods on the server-
side).
> I was thinking about that the other day for 3 reasons
> 1- I believe we ****need*** a typed approach to the management of J2EE
> 2- the JMX connector exports the "invoke" which would map nicely to the
> proxy stuff.
> 3- I need this for various reasons :)))
>
> mostly what I would like to see in JBoss is that we name all "connectors"
> with "JDBC instance myOracleDB" or something like that and what you get
back
> is the MBean interface for the static wrapper instrumentation of JDBC
> connections (we don't do that in JBoss, so imagine just turning on and off
> the loggind ;-). We could then bind this in JNDI and have tools come in
and
> get that Proxy, JUST LIKE WE GET A EJB TODAY, and perform management
> functions on these. Do you see the pluggable tools?
As I said above JMX works not with Interfaces and as far as I understand you
is
that you offer the Interface to the JNDI going around JMX. This is also a
way
to contact the client but it is not the JMX way. Do you want this?
> Also the Proxy needs not work solely with the RMI connector you have done
we
> could use the http protocol in there to actually carry the call...
uuuuuuuu
> the scalability... uuuuuuuu snmp what?
>
> <did I just come in my pants? oh my how embarassing />
>
> we need this.
There are two ways to communicate with the client:
- First you can use an Adaptor which supports a protocol dependent way to
access
the server (HTML, SNMP, CORBA etc.). For each protocol you have to deliver
its own Adaptor and the client has to understand this particular protocol.
The good
side is that the Adaptor needs no Java client-side code.
- Second you can use an Connector which supports a protocol INdependent way
to
access the server (RMI, JMS, CORBA etc.). The client must be able to work
with
Java but you can change the Connector without changing the client.
What I have in mind:
- JMX Connector uses any protocol
- JMX Connector does no offer the MBeanServer interface (as done now) but
delivers Proxy-classes to the client which he can work on like regular,
local Java
classes.
- The Connector's Invoker then is used to call the MBeanServer on the
server-side
by the low-level JMX Connector code.
IMO JMX has some advantages to just offering the MBean interfaces through
JNDI
because it is more secure, it is dynamic (can als be a disadvantage) and it
can be
used by an Adaptor and by a Connector (both together supports Java and
NON-Java
clients the same way). But in this case I am only taking about the JMX
CONNECTOR
because only a Java client can create and/or use a Proxy class.
Have fun - Mad Andy
