Printed: Mar 29, 2024
From: http://www.jcp.org/en/jsr/detail?id=160
|
Specification Leads | |||
Eamonn McManus | Oracle | ||
Simon Vienot | Sun Microsystems, Inc. | ||
Hinkmond Wong | Oracle | ||
Expert Group | |||
BEA Systems : Richard Mousseau |
Simone Bordet | IBM : Ward Harold |
|
iPlanet : Kedar Mhaswade |
Lindfors, Juha : Juha Lindfors |
Novell, Inc. : Scott Marlow |
|
Oracle : Bruce Irvin |
Oracle : Eamonn McManus |
Oracle : Hinkmond Wong |
|
Pramati Technologies : Raja Prasad |
SAP SE : Gregor Karl Frey |
SAP SE : Reinhold Kautzleben |
|
Sethi, Manish : Manish Sethi |
Sonic Software : David Grigglestone |
Sun Microsystems, Inc. : Eamonn McManus |
|
Sun Microsystems, Inc. : Simon Vienot |
|||
Contributors | |||
This JSR has been Withdrawn
Reason: Withdrawn following Maintenance Review 3.
Updates to the Original Java Specification Request (JSR)
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:
JSR 3 has been moved to JCP 2.9.
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
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.
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).
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.
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.
The JMX API uses the package prefix javax.management. It is proposed that this JSR use the prefix javax.management.remote.
None.
Initiation: November 2001
Community Review: February 2003
Public Review: March 2003
Proposed Final Draft: May 2003
Reference Implementation: May 2003
Technology Compatibility Kit: May 2003
Final Draft: May 2003
Primary form of collaboration will be via email and augmented by scheduled conference calls.
A kick-off face-to-face meeting will occur in January. Some other face-to-face meetings will be planned at that time to ensure continuous efforts and involvement.
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
AdventNet, Inc.
BEA
Oracle
SAP
Schmid Telecom
ALLTEL
Supporting this JSR:
Section 2: Request
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).
As above, an object representing the remote JMX Agent resides in the JMX Client to receive JMX notifications.
Proxy interfaces, allowing the development of Client proxies representing remote MBeans, making remote access similar to local one.
It will abstract the underlying protocol used to communicate with the real remote MBeans.
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).
el.
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:
RMI
RMI/IIOP
HTTP
NOTE that this information has been updated from this original request.
JavaTM 2 Standard Edition and JavaTM 2 Enterprise Edition platforms.
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.
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).
NOTE that this information has been updated from this original request.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.The multicast technology is a proposal for the generic Discovery mechanism.
The RMI protocol is the natural candidate for JMX Connector.
HTTP is also required as it is able to cross firewalls.
RMI/IIOP is required to address J2EE.
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.None
None
None
None. This specification extends the JMX 1.0 specification.
NOTE that this information has been updated from this original request.Initiation: November 2001
Community Review: May 2002
Public Review: June 2002
Proposed Final Draft: July 2002
Reference Implementation: August 2002
Technology Compatibility Kit: August 2002
Final Draft: August 2002
Primary form of collaboration will be via email and augmented by scheduled conference calls.
A kick-off face-to-face meeting will occur in January. Some other face-to-face meetings will be planned at that time to ensure continuous efforts and involvement.
The planning is aggressive in order to enforce a JMX specification addressing both client and server sides for mid-2002.
Section 3: Contributions
Documents describing JMX can be found at:
http://java.sun.com/products/JavaManagement/
Documents describing JavaBeans can be found at:
http://java.sun.com/products/javabeans/
The JMX 1.0 specification has already defined some basis for the client side.