> 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?
> > Lets say we do a jini service discovery/lookup with some entry to specify
> > just what kind of service we need. Well, we get back some way to use that
> > service through jini. How does this relate to any mbeans?
>
> MBeans can export service API's as Jini services. The service is an
For services which provide interfaces, else you would have to provide an
adapter service, which mapped onto the subjecated object.
> 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.
JMX is more powerful in this area in that it can simply execute arbitrary
methods... it is like high-level reflection. Tie in Jini and you have a
high-level network reflection system, which is highly adaptable and API
indenpendent.
Very, very cool.
The trick is configuration. How object x is liked to y and z. Deployment
descriptors which show how distributed objects collaborate.
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 =)
If only Java could make people think about what really matters...
> JMX is mostly a local thingy whereas Jini is mostly a distributed thingy
> (doesn't have to be though). Yes, the lookup is to some degree
> overlapping.
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.
> 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?
What about leasing? or events?
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).
How does Jini make JBoss a better platform for writing applications?
In my (not so) huble oppinon; I believe that a Jini enabled JBoss would be a
step twords the JBoss webOS. Perhaps if you replace the RMI stuff with soap
connectors you have a webOS... don't know.
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
