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. Yup. however, 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. greetz, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
