|
JMX is useful for systems that span a a single JMX agent, or
span a well defined system of JMX agents that can be trivially
linked via protocol adaptors and connectors. In ODP systems, this
level of pre-determined and stable state is not possible or even
always desirable. It is necessary for distributed components to
be able to query or "discover" their environment at
runtime as needed. There are current technologies that allow for
runtime configuration of systems such as directory services like
JNDI or LDAP or discovery services such as JINI's.
J4ONet
needs to be able to leverage these types of technologies. It also
needs to not rely on them being present. J4ONet should enable JMX
agents to discover each other and services running on the system
dynamically. It should have its own peer to peer element to
enable basic discovery services without reliance upon other
technologies. It should offer a straight forward path to
leveraging existing discovery and configuration services. It
should be able to use this information to build a cache or "world
view" of the existing system's state.
A client should be able to ask a JMX Agent to
discover, or "resolve" the location of specific classes
of MBeans or agents. This JMX Agent should be able to coordinate
a federation of resolvers to handle resolution requests. These
resolvers each would represent a different strategy: some could
leverage specific technologies, like use JINI or JNDI to
discovery JMX components; others may represent specific areas,
like gateway resolvers which each query a specific set of other
JMX agents over the network.
A MBean should be able to
announce its presence to the rest of the J4ONet system as it sees
fit.
A client should be able to access MBeans via a proxy
object that will provide location transparency. A client should
be able to get a proxy via some sort of factory object.
|
