 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 160: JavaTM Management Extensions (JMX) Remote API
This JSR has been Withdrawn Note that this JSR was completed under JCP 2.5, and moved to JCP 2.6 in Maintenance. The following changes have been made to the original request.
2013.10.10:
Specification Lead: Hinkmond Wong E-Mail Address: hinkmond.wong Telephone Number: +1 408 276 7618 Fax Number: - The Maintenance Lead has provided the public Issue list and communications channel for feedback.
Specification Lead: Eamonn McManus E-Mail Address: Eamonn.McManus@sun.com Telephone Number: +33 4 76 18 83 52 Fax Number: +33 4 76 18 83 50 2.1 Please describe the proposed Specification:The JMX specification (JSR 3) currently provides the means to create Java based management agents, through standardized techniques for instrumentation, and standardized agent services. But it does not standardize the means to access these agents remotely. This JSR will provide one mechanism for remote access by building on the JMX notion ofconnectors. A connector provides a remote client API for a JMX-based agent that is very similar to the local client API. This means that remote clients can call the familiarMBeanServer operations and can register for notifications using the NotificationListener interface. This JSR will define what the remote client API looks like and how it behaves. It will also define standard transport protocols that an implementation of the JSR must support, so that different implementations will interoperate. A standard format for JMX connector addresses will be introduced. Although this JSR will not invent a new discovery mechanism for finding connectors in a network, it will define how to advertise connectors in three existing systems: SLP, Jini, and JNDI. Details of how servers find classes referred to by clients, and vice versa, will be specified. This JSR depends on features introduced in the 1.2 version of the JMX API. Proxies simplify client-side programming. Per-MBean permissions provide fine-grained security control on the server side.
2.3 What need of the Java community will be addressed by the proposed specification?There is a requirement to standardize the way a Java Manager (local or remote) can connect to a JMX Agent. This can be achieved by defining a Client interface for communicating with the JMX MBean Server. The objective is to expose a single interface to the client, hiding and abstracting the underlying tunneling protocol. It is also required to define the way for such a Java Manager to discover the JMX Agents, and to have a standard naming scheme to identify each agent and resource (MBean). 2.4 Why isn't this need met by existing specifications?The Java Management Extensions (JMX) 1.0 Specification provided the definition of a JMX Agent, the JMX MBean Server. It has also introduced the concept of a JMX Connector that is used by a Java Client to communicate with a JMX Agent. A JMX Connector has both a Client and a Server part. Each JMX Connector uses a tunnelling protocol to transport the JMX requests, responses and notifications. But the JMX specification does not detail the API for connectors, nor does it define any standard transports for them.
2.5 Please give a short description of the underlying technology or technologies:This JSR will define how to look up connector servers for the three cases of SLP, Jini, and JNDI. Two connector protocols will be defined. One will be based on RMI (both RMI/JRMP and RMI/IIOP), taking advantage of RMI's existing optimizations and fitting into existing infrastructures that use RMI. The other will be a generic protocol based on any lower-level transport that is capable of transmitting Java objects in a full-duplex fashion. The standard instantiation of this generic protocol will use TCP as the lower-level transport. Security for the generic protocol will be based on JSSE, SASL, and JAAS. No security mechanisms will be added for RMI, since it is not appropriate for this JSR to invent an RMI security model.
2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)The JMX API uses the package prefix javax.management. It is proposed that this JSR use the prefix javax.management.remote.
2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?None.
2.11 Please describe the anticipated schedule for the development of this specification.
Initiation: November 2001 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.Primary form of collaboration will be via email and augmented by scheduled conference calls. Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Original Summary: This JSR is to extend the Java Management Extensions (JMX) 1.0 specification, by adding the Client APIs. These APIs provide to any Java Manager discovery and access to JMX Agents abstracting the underlying protocol. Section 1. Identification Submitting Member: Sun Microsystems, Inc. Name of Contact Person: Christophe Ebro E-Mail Address: Christophe.Ebro@sun.com Telephone Number: +33 4 76 18 83 83 Fax Number: +33 4 76 18 83 50 Specification Lead: Christophe Ebro E-Mail Address: Christophe.Ebro@sun.com Telephone Number: +33 4 76 18 83 83 Fax Number: +33 4 76 18 83 50 NOTE that this information has been updated from this original request.Initial Expert Group Membership: Sun Microsystems, Inc Supporting this JSR: Section 2: Request
2.1 Please describe the proposed Specification:NOTE that this information has been updated from this original request. The scope of this JSR is to define the following APIs to be used by any Java Manager: Discovery of existing JMX Agents (local or remote) Discovery of JMX Connector server parts running in JMX Agents (so the JMX Client can create the appropriate JMX Connector client to communicate with the JMX Agents), Access to MBeans located into a remote JMX Agent, i.e. perform read, set attributes and invoke requests and receive responses without caring about the underlying protocol. The JMX Agent is represented by a single access point in the JMX Client, making remote access similar to local one.
Reception of notifications coming from a JMX Agent (local or remote).
Proxy interfaces, allowing the development of Client proxies representing remote MBeans, making remote access similar to local one. Context handling, to pass additional data (for example for security, access control) from the JMX Client to the JMX Agent as part of a request.
Heartbeat, for a JMX Client to know if a JMX Agent is still alive and vice-versa. This JSR also defines a Naming scheme to allow a Java Manager to uniquely identify a JMX Agent (local or remote), and an MBean in this Agent. The following APIs will be defined as extension to the JMX 1.0 Agent/Server API: MBean Interceptor interfaces, providing a mean to insert functionality, such as security or monitoring components, into the invocation path between the JMX Agent and MBeans (similar to CORBA pattern).
Customisation of the behaviour of an MBean Server by implementing stackable MBean Servers. A higher-level MBean Server can handle one or more functions of the MBean Server, and also delegate all or some functions to lower-level MBean Server(s). Context checking, to be able to validate a context passed from a JMX Client. It defines a skeleton for implementing security, access control, etc.
The following JMX Connectors are identified as being in the scope of this JSR and will be defined as part of the protocol layer used to transport messages between a JMX Client and a JMX Agent: NOTE that this information has been updated from this original request.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)JavaTM 2 Standard Edition and JavaTM 2 Enterprise Edition platforms. 2.3 What need of the Java community will be addressed by the proposed specification?There is a requirement to standardize the way a Java Manager (local or remote) can connect to a JMX Agent. This can be achieved by defining a Client interface for tunneling to the JMX MBean Server. It is also required to define the way for such a Java Manager to discover the JMX Agents, and to have a standard naming scheme to identify each agent and resource (MBean). NOTE that this information has been updated from this original request.2.4 Why isn't this need met by existing specifications?The Java Management Extensions (JMX) 1.0 Specification has provided the definition of a JMX Agent, the JMX MBean Server. It has also introduced the concept of a JMX Connector that is used by a Java Client to communicate with a JMX Agent. A JMX Connector has both a Client and a Server part. Each JMX Connector uses a tunnelling protocol to transport the JMX requests, responses and notifications. NOTE that this information has been updated from this original request.2.5 Please give a short description of the underlying technology or technologies:The multicast technology is a proposal for the generic Discovery mechanism.
The RMI protocol is the natural candidate for JMX Connector. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)As this JSR is a natural extension of the JMX specification, the proposed package name is the one used by JMX, i.e.: javax.management NOTE that this information has been updated from this original request.2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?None 2.8 Are there any security issues that cannot be addressed by the current security model?None 2.9 Are there any internationalization or localization issues?None 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?None. This specification extends the JMX 1.0 specification. NOTE that this information has been updated from this original request.2.11 Please describe the anticipated schedule for the development of this specification.Initiation: November 2001 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.Primary form of collaboration will be via email and augmented by scheduled conference calls. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Documents describing JMX can be found at: 3.2 Explanation of how these items might be used as a starting point for the work.The JMX 1.0 specification has already defined some basis for the client side. |
