geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Faiz <nick.f...@ce.com.au>
Subject RE: [newbie] JMX Console - where to start?
Date Tue, 02 Sep 2003 03:18:33 GMT
Hey guys,
	Calling the API for the configuration of the server a piece of
middleware is misleading; perhaps it's just inviting potential confusion for
a simple idea? The app. server is the middleware; the console is for
allowing its configuration, through an API.


r.e. a Swing/SWT client:
	Both ATG and BEA have GUI clients for the server, usually for
proprietary orientated configuration and development; portals, workflows,
scenarios, etc.. It's not a bad idea, but I'd opt for the simplest approach;
have it working through a browser as most J2EE developers are used to. Then,
add on other options, like a SWT alternative, as you want them.

	I haven't used JMX yet (which is partly why I want to participate in
Open Source). I do know that it's meant for this sort of thing; we shouldn't
make an exception to the rule.

Nick

P.S. This is just my two cents worth. :)
	
 

-----Original Message-----
From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu] 
Sent: Tuesday, 2 September 2003 12:04 PM
To: geronimo-dev@incubator.apache.org
Subject: RE: [newbie] JMX Console - where to start?

	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

Mime
View raw message