Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 160: JavaTM Management Extensions (JMX) Remote API

Stage Access Start Finish
Maintenance Release 2 Download page 04 Mar, 2014  
Maintenance Review Ballot View results 10 Dec, 2013 16 Dec, 2013
Maintenance Draft Review 3 Download page 04 Nov, 2013 04 Dec, 2013
Maintenance Release Download page 30 Nov, 2006  
Maintenance Draft Review 2 Download page 14 Jul, 2006 14 Aug, 2006
Maintenance Draft Review Download page 21 Mar, 2006 24 Apr, 2006
Final Release Download page 23 Oct, 2003  
Final Approval Ballot View results 30 Sep, 2003 13 Oct, 2003
Proposed Final Draft Download page 06 Jun, 2003  
Public Review Download page 25 Mar, 2003 24 Apr, 2003
Community Draft Ballot View results 11 Mar, 2003 17 Mar, 2003
Community Review Login page 14 Feb, 2003 17 Mar, 2003
Expert Group Formation   11 Dec, 2001 13 Dec, 2002
JSR Review Ballot View results 27 Nov, 2001 10 Dec, 2001
Status: Active
JCP version in use: 2.9
Java Specification Participation Agreement version in use: 2.0


Description:
This API extends the JMX 1.2 API to provide remote access to JMX MBean servers.

Expert Group Transparency:
  Public Communications
  Issue Tracking

Team

Specification Leads
  Eamonn McManus Oracle
  Simon Vienot Sun Microsystems, Inc.
  Hinkmond Wong Oracle
Expert Group
  BEA Systems
: Richard Mousseau
Bordet. Simone IBM
: Ward Harold
  iPlanet
: Kedar Mhaswade
Juha Lindfors Novell, Inc.
: Scott Marlow
  Oracle
: Bruce Irvin
Oracle
: Eamonn McManus
Oracle
: Hinkmond Wong
  Pramati Technologies
: Raja Prasad
SAP AG
: Gregor Karl Frey
SAP AG
: Reinhold Kautzleben
  Manish Sethi Sonic Software
: David Grigglestone
Sun Microsystems, Inc.
: Eamonn McManus
  Sun Microsystems, Inc.
: Simon Vienot

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@oracle.com

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
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

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.
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

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).
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.

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.
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.

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.
HTTP is also required as it is able to cross firewalls.
RMI/IIOP is required to address J2EE.

NOTE that this information has been updated from this original request.

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
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

NOTE that this information has been updated from this original request.

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.
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.

NOTE that this information has been updated from this original request.



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:
http://java.sun.com/products/JavaManagement/
Documents describing JavaBeans can be found at:
http://java.sun.com/products/javabeans/

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.