Hey
"Schaefer, Andreas" wrote:
> Here are more details about the spec (I created a UML class
> diagram but I could not send it therefore if you want to
> see it please send me an email and I will send it to you):
>
> - ConnectorServer: protocol independent Interface for a server
> side connector. It has a reference to the MBeanServer and
> delivers the necessary info from the server's registered beans
> and invokes the desired operation on them. The attributes and
> operations offered are defined how the beans are managed like
> query for beans, get bean info about a bean, get/set attributes
> on a given bean and invoke an operation on a given bean.
> In addition it must provide a way to register the ConnectorServer
> to listen for certain notifications.
Right on.
> - 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.
> - 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).
> - 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?
>
> - 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.
> What do you think ?
I'm not entirely clear on the above. Which classes are on the server,
and which are on the client? What does the client in the end talk to?
Please look at the current RMI/JMX code for example code.
If I were to use my own words on how this should work, it would go
something like this:
* RMIConnector - Remote interface with all methods in MBeanServer, but
with RemoteExceptions
* RMIConnectorMBean - MBean interface with management functions for
connector
* RMIConnectorImpl - Implementation of RMIConnector, which forwards
incoming RMI calls to the MBeanServer. This is the server side of the
connector. Also implements RMIConnectorMBean
* RMIConnectorProxyNotification - Remote interface with
NotificationListener methods (+RemoteException) to receive
notifications.
* RMIConnectorNotificationProxy - Implements NotificationListener, and
holds a stub to the RMIConnectorProxy to forward notifications to.
* RMIConnectorProxy - Implements MBeanServer and
RMIConnectorProxyNotification. Forwards all (except
add/removeNotificationListener) calls to a RMIConnectorImpl stub, and
converts all eventual RemoteExceptions to JMX exceptions. Registers a
RMIConnectorNotificationProxy /w its own stub with the RMIConnectorImpl
in order to tunnel notifications.
That should be all. So, on server:
RMIConnectorImpl, registered in MBeanServer
RMIConnectorNotificationProxy, registered with RMIConnectorImpl as
callback to clientside proxy, holding a stub to the RMIConnectorProxy
On client:
RMIConnectorProxy, holding a stub to the RMIConnectorImpl
Client talks to RMIConnectorProxy which forwards calls to
RMIConnectorImpl, which forwards calls to real MBeanServer. To the
client it really looks like the MBeanServer is *in the client*.
If a client registers a notification listener with the
RMIConnectorProxy, what really happens is that the RMIConnectorProxy
calls RMIConnectorImpl.addNotificationListener with a
RMIConnectorNotificationProxy, which is then registered with the real
MBeanServer. Any notifications from the MBeanServer gets to the proxy,
which forwards them through the callback to the RMIConnectorProxy, which
forwards them to the registered listener. Again, making it transparent
to the client that the notifications really comes from a server
someplace else.
Makes sense? I am not sure if we are really saying the same thing here.
Are we?
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
