> Goals:
> - has to work not only for JBoss
> - is transport protocol independent (WebSphere uses their OSE
> and Weblogic their T3)
> - a central admin console should work with different vendors and
> with different versions of a app. server -> versioning
>
> I would suggest the following concept:
> - the client has to be written in Java
Yes, but I'd prefer a servlet oriented one instad of a Swing one.
> - the client works through an Interface with the server
> - the connection is protocol independent
> - integrated support for versioning
> - client works independent from the server's implementation
> WebSphere uses EJBs and Weblogic I don't know
>
> Client interface:
> - support to lookup a server
> - navigation through the server service trees (WAS and WL display
> its services as a tree)
> - working on a service interface (getting and setting of attributes,
> invoking of methods and managing of notifications)
> - support for monitoring which should be separat from administration
>
> The server implementation of JBoss could look like:
> - either JMX MBeans or EJBs implements the server-side administration
> - are registered at the JNDI server
> - delivers the service interfaces to the client and map the request to the
> server-side components
> - I would suggest RMI as a transport protocol
So, like what we have now with the RMI connector then?
> Why not JMX ?:
> - I aggree with Marc that JMX is good when the client is not written in
> Java but ugly when it is
JMX syntax can be hidden with things like the org.jboss.util.MBeanProxy
though.
> - A good Admin. Console must be easy to use, fast and reliable and I
> think this could only be achieved when the Client is written in Java
So, no HTML then? Hm....
> - JMX offers a weak interface which means that the interfaces described
> must not implemented this way and this leads to a lot of runtime exception
> (you don't know if a method signature is correct until you call it)
Use the MBeanProxy to fix this.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
