Hi
To make the description a little bit more clear I will from
now on add an "I" as a prefix to all the interface classes.
First I will explain my proposal in greater detail:
Server side:
- jBoss MBeanServer: containing all the jBoss MBeans inclusive
the Connectors and Adaptors MBeans
- IServerConnectorMBean: implements DynamicMBean and offer all
the MBeanServer services and its own attributes and operations.
This is in particular the creation of a NotificationListener
(see below) and its removal because the NotificationListener
needs a call back to the client (each NotificationListener is
on a per client bases). Therefore it contains a list of
IServerConnectorNotificator instances (one for each client
based on the given protocol).
=> Protocol independent
- IServerConnectorNotificator: implements Notification-
Listener and offers all Notification Listener services to the
client it has the connection to.
=> Protocol independent
- Implementations of both Interfaces above with respect to the given
protocol. The implementation maps the protocol dependent calls
to the protocol independent calls and also its exceptions.
At the moment we assume that the server side MBeans are loaded
on startup. But is this really necessary (dynamic loading) ?
What about dynamic loading of the desired connectors by client
demands ? In that case we can either use dynamic loading of the
agent (when in place) or we use a sever side connector factory.
Client side:
- JMX Client MBeanServer: contains all the client side connectors,
the Connector Factory MBean and all the Notification Broadcaster
MBeans.
At the very beginning there is only Connector Factory MBean
registered and the client can load the Connectors afterwards.
When there is a Connector in place the user can register a
Notification Listener MBean.
- IClientConnectorMBean: maybe is the same as IServerConnectorMBean
because the MBeanServer should be transparent to the client.
Represents a MBeanServer administration through a given protocol.
=> Protocol independent
- IClientConnectorNotificationMBean: implements DynamicMBean and
offers all notification services to the client.
Represent a MBeanServer Notification Broadcaster through a given
protocol but it depends on the IClientConnectorMBean
=> Protocol independent
- Implementations of both Interfaces above with respect to the given
protocol. The implementation maps the protocol dependent calls
to the protocol independent calls and also its exceptions.
- ConnectorFactoryMBean: implements DynamicMBean and offers the
lookup of MBean Servers (on different, remote computers) and its
protocols. If one is selected it will load the given Connector
on client side and register to the JMX Client MBeanServer.
Now the user can add/remove the Connector Notification Listener.
This MBean is loaded by the JMX Client MBeanServer during
initialization.
Ok, at the moment I am not quite sure if the IClientConnector-
NotificationMBean should be a MBean but it make it more usable
to the client if it is but the problem is that the Notification
MBean depends on the Connector MBean and can only be created and
by the Connector MBean and has to be removed when the Connector
MBean is removed.
> -----Original Message-----
> From: Rickard �berg [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 03, 2000 11:35 PM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] jBoss JMX Spec
>
>
> Hey
>
> "Schaefer, Andreas" wrote:
>
> > - RMIConnectorServer: RMI protocol dependent Interface for the
> > server side. More or less this Interface just offer the dynamic
> > MBean interface over the RMI protocol. Therefore this interface
> > offer an invoke() method without an Object Name as first parameter
> > because it is its own method invoke() to be called. This method
> > (in its implementation) will then call the MBeanServer invoke()
> > method where the first parameter will be considered as ObjectName
> > to determine which beans invoke() method should be called. This
> > could also be the ConnectorServer implementation itself. Thus
> > the client can call RMI server side invoke() method with the
> > ConnectorServer's object name as first parameter and "queryMBeans"
> > as second parameter and you will get back a list of beans.
>
> Hm.. this should be an exact copy of MBeanServer, but with
> RemoteExceptions added to all the methods. It doesn't sound like that
> from the above description.
>From my point of view it doesn't have to but why not.
>
> > - RMIConnectorServerImpl: implements both Interfaces above. Because
> > RMI calls throw a RemoteException this implementation has to
> > handle them in a protocol independent manner (wrap or convert them
> > into a ConnectorException). It also implements the notification
> > transfer back to the client(s ??).
>
> I think the RMIConnectorClientImpl should handle the conversion from
> RemoteException to ConnectorException. Look at the JNP JNDI
> implementation which works exactly this way: the remote interface is
> more or less Context with RemoteExceptions, and the NamingProxy (the
> client side of things) implement Context and converts the
> RemoteException's to NamingException. Use the same techniue here, but
> let the RMIConnectorClientImpl implement MBeanServer (which is
> impossible with the current code since it's an interface, but
> the final
> version will have it like this).
To map the exception was also my indention but I do not think that to
make the RMIConnectorClientImpl also an MBeanServer is a good idea
because the MBeanServer should be protocol independent and maybe there
is already a MBeanServer in charge and the user wants to plug-in our
services to it. Thus the ConnectorFactoryMBean can be loaded by the
clients MBeanServer and afterwards register the Connectors.
=> The MBeanServer should work with any number of remote clients and any
type of protocol underneath. It should also run with any type of
MBeanServer (not integration between Connector and Server but just
add it as MBean).
>
> > - ConnectorClient: looks nearly the same as ConnectorServer but has
> > additional attributes (about the protocol like it the protocol
> > is able to handle Notifications (HTTP is not)). It also defines a
> > way to register/deregister for a notification listening and to get
> > the notifications.
> >
> > - RMIConnectorClient: like RMIConnectorServer but the other
> direction
>
> This interface only holds a notification callback, right?
After a while I really think that my first approach is not going to work
because the Notification Listener on server side cannot be a MBean (it
is connected to a particular client), can it. Therefore I tried to
separate these two into two Interfaces and let the Notification Listener
be dependent on the Connector. On the client side it can be a MBean
but still here it depends on the Connector MBean.
>
> >
> > - RMIConnectorClientImpl: like RMIConnectorServerImpl but the other
> > direction
> >
> > - ConnectorFactory: it has to allow the client to look up for the
> > available protocols/connectors (on the server side) and if
> > necessary to download the client classes from the server. Maybe
> > the ConnectorFactory is also a MBean which provides you with the
> > information about the network (which servers are available and
> > with which connectors) and then let you add the server - connector
> > client bean you like.
>
> This is a tricky one. I don't know how the JMX guys wants to do this,
> since it should be a standard factory. I would propose to use a JNDI
> factory.
The Connector Factory is a MBean which lets you look up the remote
computers and their connectors/protocols. Then the Connector Factory
will use the JNDI factory to lookup for the available remote computers
and their Connectors. The Connector Factory enables the user to select
a Connector on a higher level.
In addition this factory make our client implementation independent from
the MBeanServer which let's our JMX implementation be plugged in on any
client MBeanServer.
Cool or what ?
> forwards them to the registered listener. Again, making it transparent
> to the client that the notifications really comes from a server
> someplace else.
Yes !!!!!!!!!
>
> Makes sense? I am not sure if we are really saying the same
> thing here.
> Are we?
I think the big difference is that I would like to separate the managing
of the MBeanServer through the Client Connector and Notification Listener
from the managing of the Client Connectors and Notification Listeners on
the client side.
Thus our implementation can be used as normal Connector from any type
of client management tool, registered in a MBeanServer as a normal type
of MBean or through the Connector Factory which ease the look up of the
connectors and their registration.
This makes it pluggable into any type of client (have a look at figure
1-1 on page 21 within the JMX Spec v1.0) with or without a MBeanServer on
the client side. I think the idea of the MBeanServer on client side is
a good idea because it let us collect several Connectors (with different
protocols) but it should also work w/o.
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
Have fun
"Mad" Andy, good pizza
