Press Room  |  Get Java Here  | 

Printed: Apr 19, 2024
From: http://www.jcp.org/en/jsr/detail?id=160

Standard Format

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

Telephone Number: +1 408 276 7618

Fax Number: -

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

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

Java^TM 2 Standard Edition and Java^TM 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).

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.

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.

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

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.

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

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.

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.

Contact Us

© 2024, Oracle Corporation and/or its affiliates. Terms of Use. Privacy Policy. Trademarks