avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: management GUI
Date Wed, 19 Jun 2002 07:41:02 GMT
On Wed, 2002-06-19 at 09:12, Ulrich Mayring wrote:
> Leo Simons wrote:
> > 
> > > So the advantage is simply that the stuff is there and working,
> > 
> > not to great within phoenix though =)
> Why not? What is missing?

last time I checked we needed to wrap some more stuff as MBeans, or wrap
it in a better way. FA, I did some stuff to Application a while back to
make it possible to export, which was very sub-optimal.

> > > 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...
> And why is that?

because nothing is ever as decoupled as it seems.

> > > 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?
> Everybody knows what XML and HTTP are, but no-one knows what Avalon is.
> If you'd tell me as a developer I'd have to use a custom protocol with
> Avalon, I'd turn away. No chance to sell it to my boss.

okay. You're saying avalon == support for XML over HTTP == sellable.


avalon == lots of stuff, like avalon framework = COP/SOP/SoC/IoC
framework. Only a small part of avalon (phoenix) has anything to do with
XML over HTTP, and then only in the form of pluggable management.

Avalon as a whole doesn't define any technology, other than java, with
which it is to be used.

> > 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.
> If JMX is popular, because it's easy to use, then it is obviously more
> useful than those other technologies :)
> What you can do with JMX is basically set and get values - and that's
> all you need in program-to-program communication. Everything else is
> just syntactic sugar.

the easy way is not always the best. Looking at recent Apache Axis
(SOAP) stuff, it's a lot easier to use for program-to-program
communication than JMX...

JMX is often in use as "glue" between applications. You don't just set
and get values...there's several complex ways of describing an app
(MBean, DynamicMBean, ...), a custom registry (MBeanServer), etc etc.

FA, we could modify the phoenix kernel to be completely based on JMX,
where you add a block by registering it with the MBeanServer, and put
metainfo in an MBeanInfo instead of a config file, etc etc. It'd work,
but there would be lots of "syntactic sugar" to deal with.


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

View raw message