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.
> 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
MBean, which is mostly a local concept, whereas the API is/may be a
distributed thing.
> If we do a jmx query on object names, we can specify all sorts of things
> about what kind of mbeans we want. We get back a list of ojbect names,
> which we can examine and pick the one we like the most. How does this
> relate to jini?
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.
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.
/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
