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>
Subject: Re: management GUI
From: Leo Simons <leosimons@apache.org>
To: Avalon-Phoenix Developers List <avalon-phoenix-dev@jakarta.apache.org>
In-Reply-To: <3D09B015.BFC80E5F@denic.de>
References: <8097298F8B57D5119F87000102C3D61106513D@mail.infogation.com>
	<1023919498.1820.523.camel@lsd.bdv51> <3D07C5C3.7060904@apache.org>
	<3D084C04.55B316F5@denic.de> <1023986789.1417.6.camel@lsd.bdv51>
	<3D087F4B.C82F329F@denic.de> <1023981438.2124.52.camel@lsd.bdv51>
	<3D08BB35.3038B16B@denic.de> <1023983620.2115.66.camel@lsd.bdv51>
	<3D09B015.BFC80E5F@denic.de>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 14 Jun 2002 22:47:03 +0200
Message-Id: <1024087628.2570.15.camel@lsd.bdv51>
Mime-Version: 1.0

> > > If I understand JMX and MX4J correctly, there is no need for yet another
> > > communication protocol. Your GUI could make a HTTP request to a certain
> > > URL (see MX4J API for this) and get back a real XML document. This
> > > procedure already works today and what more could you want?
> > 
> > - speed (!= http)
> 
> You mean http is slow? Or do you mean the problem is that it's stateless
> and connections not persistent? But such a decoupling has advantages,
> too.

primarily the last one. For stuff like DB access a dedicated socket is
best.

> > - sensible protocol (I know too much about JMX to like it, one thing I
> > know about it is that it is not really compatible with non-java, whereas
> > SOAP is buzzword number one in serverland)
> JMX doesn't come into the equation in the communication between client
> and server. It's HTTP and XML all the way - and you could put SOAP on
> top of that, because that's also just XML over HTTP. JMX (if I
> understand it correctly) is internal to Avalon / Phoenix, there's an
> MBean-Server that communicates with your blocks. But external
> communication is handled via adaptors, not via JMX.

true, but writing an adaptor to an MBeanServer is probably as much work
for me as it is to write an adaptor for the phoenix management setup.

oh, and SOAP is transport-independent (it's not limited to HTTP), but
that's beside the point =)

> > java webstart might be cool though. But why have your app served up by
> > MX4J? Is there an advantage there?
> 
> MX4J comes with an HTTP adaptor (which also supports SSL) and an RMI
> adaptor, so you have two methods to communicate with your MBeans. If you
> prefer something else like SNMP, you can write your own adaptor.

I took a look at MX4J, and it's come a very long way.

> So the advantage is simply that the stuff is there and working,

not to great within phoenix though =)

> plus it
> uses established standards (HTTP for non-Java access and RMI for Java
> access). If at some point in the future MX4J turns out to be too slow or
> otherwise not appropriate, you would not have to change the client and
> the communication protocol, you'd just have to implement a new and
> better server.

probably wouldn't work that way in real life...

> Also, in the future there may be people, who want to
> connect their clients to an Avalon/Phoenix server and they might not
> have the slightest idea of Avalon/Phoenix. It would be cool to be able
> to tell them that it's just XML over HTTP

? Just don't follow here. Spell out for me please? Why is it cool that
avalon == XML over HTTP?

> > Also, I recognize the speedup in delivery time (as you say, it already
> > works today), and have in no way made up my mind yet. Regardless of all
> > that, I don't have cycles to write this anyway.
> 
> But you have cycles to discuss it and that is the first step to
> implementation ;-)

that's just because I can directly translate input I get from this
discussion into products I'm developing for our company, so I can do so
on company hours. Similarly, I can do avalon support and discussion on
company hours ('we' recognize broad distribution of avalon is good for
us), but not code ('we' don't recognize the value of making our code
open source). It sucks, but I live with it =)

> We are actually going to put this idea to the test. Our users want two
> things from our Avalon/Phoenix based apps: they want a nice point and
> click frontend, where they can manually control and configure the apps,
> and they want some kind of universal API for programmatic access. For
> example, they want to be able to write a shell script that periodically
> connects to the server and checks if the various blocks are still alive.
> Or they might want to gather statistical data or even programmatically
> pause and resume a particular block. MX4J gives us both - a nice Web
> frontend and programmatic access via XML over HTTP. On the client-side I
> don't have to parse a large XML-monster (or even an HTML page as in the
> case of Sun's JMX implementation)

hey, that's only about the default adapter -- which is not really ment
for use. I believe they mark it as a demo rather than a production
implementation - a fair enough assessment ;)

> , instead I can ask for specific
> values. If I want I can ask "give me everything you know about block XYZ
> and filter out what I don't need with this custom stylesheet", but I can
> also ask "give me the exact processing time of customer request 1234".

yup. It's pretty useful, innit?

What you should keep in mind that JMX is very useful as a management
protocol (ie designed with stuff like SNMP in mind), but not so much for
more generic program-to-progam communications (that'd be JMS, RMI,
CORBA, SOAP, ...). It is just so popular because it is easy to also use
it for stuff like that. I'm not saying you don't get that (think you do)
-- just that there's quite a few people that don't get it.

g'night,

- Leo


--
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>