Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon-Phoenix Developers List"
 <avalon-phoenix-dev@jakarta.apache.org>
Message-Id: <200202080826.g188Qa821654@mail008.syd.optusnet.com.au>
Content-Type: text/plain;
  charset="utf-8"
From: Peter Donald <peter@apache.org>
To: "Avalon-Phoenix Developers List" <avalon-phoenix-dev@jakarta.apache.org>
Subject: Re: Management Interface
Date: Fri, 8 Feb 2002 18:50:46 +1100
References: <3C62A634.7040802@apache.org>
In-Reply-To: <3C62A634.7040802@apache.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On Fri, 8 Feb 2002 03:07, Berin Loritsch wrote:
> In order to spark movement towards the management interface for Phoenix,
> let's get the ball rolling for discussion.  First, how would you prefer to
> see things organized? 

I have got some docs on it that I still got to type out but basically it goes 
like this.

For each Container we have an MBeanServer. The MBeanServer has all the 
Phoenix Container MBeans registered with it. It also has a facade MBean for 
each Application in the Container. The facade gives access to things like 
shutting down and starting up application and changing application status in 
other ways. It may also expose application-wide config settings (like 
security policy, logging management etc). There would also MBeans exposed 
that the application requests. 

So the MBean server contains such things as
* Container MBeans (fixed set of these)
* Application-wide MBeans (fixed set of these)
* Application specific MBeans (the number and type of these are determined by 
application and it's blocks)

Then we have an agent/adaptor. The agent is basically the thing that 
communicates with the outside world. In our case we have a HTTPAdaptor 
(defauly ugly sun version) and a RMI version (so we can manage it from 
another JVM).

> Second, what types of things are exposed via the
> MBeans? 

Anything we think that may be useful to an admin ;) (Hows that for a cop-out 
of an answer).

> Only being cursorily (is that a word?) familiar with the spec, I
> will rely on you guys for helping me out in my deficiencies of
> understanding.

I only know enough to use - no great detail unforunately.

> I guess the first question is: "Is the management interface in a separate
> VM from the Server?"

It can have a client to RMIAdaptor in another JVM but mostly it is in the 
same JVM.
>
> If the answer is yes, then we have the opportunity to have one interface
> manage multiple servers.

Yeppo!

> To that end, I threw together a simplified frame for what I think will be
> an efficient and easy to use interface.  It is included with this message. 
> There are three major areas:
>
> Control area
> SAR selection area
> MBean Control area
>
> The Control Area
> ----------------
> This consists of a drop box that allows you to choose the Server that the
> management application will connect to.  Along the same bar are the tabs
> used for the MBean selection (when we are modifying a SAR).
>
> The SAR Selection Area
> ----------------------
> Each SAR has an icon associated with it (even if it is a default SAR Icon),
> with one additional Icon for the server itself (i.e. the ability to remote
> start and stop an external server).  When the user clicks on one of the
> icons, the Block Control area has a tab for each MBean associated with the
> SAR.
>
> The MBean Control Area
> ----------------------
> This is the large empty space with the tabs above the pane.  The tabs are
> for the Main control (start and stop a sar), as well as one per MBean
>
>
>
> This modular approach is simple to use, and each MBean control would be an
> embeddable panel that is easily selected.  The interface is easily
> navigable, and provides a snapshot of what we may want.
>
> What is everybody's opinion on this proposal?

You may want to have a look at the mock HTML UI I put in CVS. I think you 
will find that the Control Area will end up having to display multiple MBeans 
(either of same kind or not at all) but other than that all is good.

-- 
Cheers,

Pete

-------------------------------------------------
"Sometimes its better to keep your mouth shut and 
let people think your an idiot, than to open it 
and remove all doubt." 
-------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>