avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <u...@denic.de>
Subject Re: management GUI
Date Fri, 14 Jun 2002 08:57:57 GMT
Leo Simons wrote:
> 
> > 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.

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

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

So the advantage is simply that the stuff is there and working, 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. 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 and give them an XML-Schema
for the exact format (instead of teaching them a custom protocol).

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

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), 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".

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

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


Mime
View raw message