Jason Dillon wrote:
> > David Jencks wrote:
> > > I still don't understand how jini and jmx can relate. They seem to me to
> > > be unrelated and non-interoperable implementations of to a large extent the
> > > same functionality (as far as finding stuff, not failure recovery in a
> > > distributed environment).
> >
> > JMX handle the internal interface of a service (configuration,
> > lifecycle) whereas Jini handle the external (providing API, finding
> > other services' API's). Complementary. Also, some things in JMX can be
> > implemented using Jini, such as adaptors.
>
> What about events?
Same thing. I'd use JMX events for things related to lifecycle things,
but Jini events for implementing actual functionality provided by the
service.
> > MBean, which is mostly a local concept, whereas the API is/may be a
> > distributed thing.
>
> JMX could be used more like a Jini system too. The MBeanProxy stuff is a
> great example of that. The only difference is that JMX needs a name,
> dynamic proxy needs an interface.
Well, there's more to it than that, since Jini has better support for
the services behind the proxy going down at any time. The leasing system
is very very powerful. Handling this in JMX takes more thinking I
believe.
> The network is the computer, the computer is the network, who cares... java
> lets you do cool things. Admins across the planet (perhaps beyond) will be
> greatful for millenia to come. Assuming we can get of the planet before the
> sun goes red giant =)
Assuming that there will be a need in the first place to get off the
planet if the Sun goes red giant.. but that's another issue ;-)
> JMX provides a local namespace and flexibility for integration.
>
> Jini provides a network, global or rather grouped namespace.
>
> Jini is to packages, as JMX is to classes.
I believe that's an ok analogy, yes.
> > The way I see it the services themselves are packaged as JMX MBeans and
> > use JMX for internal stuff, such as configuration and lifecycle. Things
> > that relate to the service as being a service. The Jini stuff is more
> > for what the service actually *does*. The service API's it provides.
> > Because of this I don't really see a vs relationship between JMX or
> > Jini, although I guess you could adopt that standpoint if you wanted to.
>
> How does a JMX serivce interact? Throgh JMX api's or Jini API's. In other
> words, if service0 depends on service1 and service2, does it access them
> through the MBeanServer or by looking up the service interface ala jini,
> then use RMI semantics to process any reqests?
I'd prefer Jini lookups. Note that what you get from the lookup service
*does not have to be an RMI object*. Heck, it can just be a Plain Old
Java Object (POJO, tm Martin Fowler) that implements all of the stuff
locally. That's the beauty of Jini: it *can* be distributed, but doesn't
have to be. Having a method throw RemoteException only means that the
method *may* be remote, but it doesn't have to be.
> What about leasing? or events?
What about them?
> How could we replace the JMX event/notification fluff with something backed
> up by a topic? We could link JBossMQ instances via there group namespace,
> then configure links between groups and provide a routing mechanism. Now we
> have a distrubuted event system which we can use to provide os level
> services to the nodes in the cluster (configuration notices,
> node activation or rather when a node accepting client connections).
Yes, that could work. You could even use JBossMQ as the backbone for a
Jini event handler. Would work quite nicely I believe.
> How does Jini make JBoss a better platform for writing applications?
Because it makes servers aware of other servers more easily, and
services aware of other services more easily.
Plus, another very important question is: how does JBoss make writing
applications in Jini better? Looking at the Jini community, and having
talked to Jini folks on this topic recently, it is now very easy to
write clients and services in Jini, but it's still pretty awkward to
actually run the damn critters. Enter JBoss, which can provide all the
gory stuff (conf, lifecycle) that they need. Package the Jini services
as MBeans and off you go. Very very nice.
/Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
