 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 262: Web Services Connector for Java Management Extensions (JMX) Agents
This JSR has been Withdrawn The following information has been updated from the original JSR:
2012.03.21:
E-mail: staffan.larsen Telephone: +46 8 506 309 00 2008.03.14: 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final. In addition to delivering the Reference Implementation (RI) and TCK pursuant to existing contractual obligations, if and where applicable, Sun will: (i) Deliver the RI in binary form, free of charge and under the Sun Microsystems, Inc. Binary Code License Agreement. Additionally, Sun will make the RI source code available under an open source license free of charge; and (ii) Make the standalone TCK for this JSR available at no extra charge to J2SE and J2EE TCK licensees, and for a flat fee of $50 K to other interested parties. In addition, Sun will grant access to the TCK to qualified individuals and not-for-profit organizations at no charge. The TCK license does not limit how a compatible implementation of the specification can be used or distributed, e.g., by limiting the hardware devices or operating environments that can be supported.
Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Sun Microsystems, Inc Name of Contact Person: Eamonn McManus E-Mail Address: eamonn.mcmanus@sun.com Telephone Number: +33 476 188 352 Fax Number: +33 476 188 282 Specification Lead: Eamonn McManus E-Mail Address: eamonn.mcmanus@sun.com Telephone Number: +33 476 188 352 Fax Number: +33 476 188 282 Initial Expert Group Membership: Sun Supporting this JSR: Sun Section 2: Request
2.1 Please describe the proposed Specification:The JMX API is the standard for management on the Java platform. This specification will define a way to use Web Services to access JMX instrumentation remotely. It will provide a way to use the server part of the JMX Remote API to create a Web Services agent exposing JMX instrumentation, and a way to use the client part of the API to access the instrumentation remotely from a Java application. It will also specify the WSDL definitions used so that the instrumentation will be available from clients that are not based on the Java platform, or from Java platform clients accessing the instrumentation directly using the JAX-RPC API. This JSR will also investigate connecting JMX to emerging web service management standards such as WSDM and WS-Management. The exact degree of support for these standards will be determined by the Expert Group based on factors such as the timing and maturity of applicable standards and by the overall needs of the Java community. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2SE 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.The J2EE platform includes a specification (JSR 77) based on the JMX API, and most if not all implementations of this platform use the JMX API extensively. Greater accessibility to JMX instrumentation will therefore be useful on the J2EE platform in addition to the J2SE platform. Although some investigations have been done concerning the use of the JMX API on certain configurations of the J2ME platform, there are no current plans to standardize that, so that platform is not targeted by this JSR. 2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?Access to management and monitoring of Java applications and of the Java Virtual Machine itself from clients not using the Java platform and in network configurations where the existing JMX connector protocols are inappropriate (for example because of firewalls). 2.6 Why isn't this need met by existing specifications?The JMX Remote API specified by JSR 160 defines a way to access JMX instrumentation remotely. It defines client and server APIs for the Java platform, and standard protocols. However, these standard protocols are not easily accessible from clients that are not based on Java technology, for example C++ programs or perl scripts. Also, these protocols are specific to JMX technology and so cannot easily take advantage of network configuration that might already be in place for HTTP. 2.7 Please give a short description of the underlying technology or technologies:JSR 3 (JMX API) defined a way to create named objects called MBeans (managed beans) or managed objects, and to store those objects in a repository called the MBean Server. Access to the objects is then exclusively through the MBean Server. MBeans have attributes (properties), operations (methods), and can emit notifications (events). The API provides services, which are themselves MBeans, that allow MBean attributes (properties) to be monitored periodically; notifications to be sent at a scheduled time or times; new MBeans to be created from dynamically loaded classes; and relations to be defined between MBeans.
JSR 160 (JMX Remote API) defined a framework for remote access to an MBean Server, and standardized an access protocol based on RMI. SOAP is the standard protocol for Web Services. In its most usual form, it consists of XML documents exchanged over HTTP. The JAX-RPC API defined by JSR 101 is the standard way to code clients and servers for XML-based protocols such as SOAP on the Java platform. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)Since the existing RMI connector is in the package javax.management.remote.rmi, the most logical home for the Web Services connector is javax.management.remote.ws. 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 2.11 Are there any internationalization or localization issues?No 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.The exact schedule will depend on Expert Group decisions, but we would expect to have the final draft in late 2005. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The primary form of collaboration will be e-mail. Conference calls will be used as required. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.Draft specifications will be uploaded to the community page for this JSR with at least monthly frequency. Open issues will be signalled on the observer alias for this JSR. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.This JSR will be delivered stand-alone based on version 5.0 (Tiger) of the J2SE platform. It is planned for it to be bundled into a future J2SE release. It is anticipated that subsequent revisions of this JSR will only be available as part of J2SE. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The Reference Implementation (RI) will be delivered in binary form free of charge. Licensing for the RI will be under the Sun Microsystems, Inc. Binary Code License Agreement. The TCK will be made available at no extra charge to J2SE and J2EE TCK licensees. In addition, qualified individuals and not-for-profit organizations will receive access to the TCK at no charge. Note that this information has been updated from the original JSR. 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.The Open Source MX4J project implements the JMX API and includes a SOAP connector. OASIS defines Web Services Distributed Management (WSDM), which covers management both of and using Web Services. A framework for management using (but not of) Web Services called Web Services Management (WS-Management) has been submitted to the DMTF. 3.2 Explanation of how these items might be used as a starting point for the work.See section 2.1. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.
|
