Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Mon, 1 Sep 2003 22:04:19 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: geronimo-dev@incubator.apache.org
Subject: RE: [newbie] JMX Console - where to start?
In-Reply-To: <001501c370fb$442a9750$75493d80@mkurjano>
Message-ID: <Pine.LNX.4.44.0309012200480.1974-100000@www.princetongames.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	That "middleware" was the gist of the question I added in the Q&A
section.  My hope would be that the JMX interface is clear enough that the
middleware layer wouldn't really add much.  But without an example to work
with, it's hard to know.  I'd say if the JMX interface is painful to work
with, we should implement the middleware, but if it turns out to be
strightforward, we should skip the middleware.  Again, my hope is that it
should be pretty straightforward.

Aaron

On Mon, 1 Sep 2003, Matt Kurjanowicz wrote:
> The Wiki looks good.
> I added a few sections, one about a Swing/SWT client, and another about
> abstracting the client layer out of JMX.  This would be kind of like
> creating a management middleware.  That way, the client would only
> become a front-end to this middleware, and it would be relatively easy
> to build a client for this middleware (be it Command Line, Web,
> Swing/SWT, Applet, whatever).  The command structure would actually be
> client independent.  This would facilitate a few things:
> * Any client could be built that would use this middleware to perform
> the commands of the server
> * A deployer of the Geronimo Server could write their own custom
> Management console (if they don't like what's been developed) without
> having to know the intricacies of the JMX and the Geronimo backend.
> * New clients, as needed, could focus on the presentation of the JMX
> data rather than the collection of it. * The abstraction of the
> management out of the direct hands of a developer.  This could allow
> Geronimo to employ stricter security.
> OR
> * The Client can still talk JMX to anything if it wants
> 
> A little more clarification:
> 
>                                       <-JMX-> OTHER ITEMS
> CLIENT <-CUSTOM CODE-> MANAGEMENT_API <-JMX-> COMPONENTS
>                                       <-JMX-> SERVICES
> 
> This looks an awful lot like rewriting JMX, but the way that this is
> different is by making it easy for the CLIENT to talk to the services
> and Geronimo components, without having to know exactly how they are all
> managed.  (something like
> (not exactly)
> ManagementCommunicator.startService("SERVICE_NAME");
> ManagementCommunicator.startServer();
> ManagementCommunicator.getServerStatus();
> ManagementCommunicator.getComponentStatus("COMPONENT_NAME"); )
> 
> What do y'all think about this?
> 
> I know some parts of this are redundant...sorry.
> -Matt
> mkurjano at cc.gatech.edu