The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 3

Find JSRs


Ad Banner





Community
Expert Group

Summary | Proposal | Detail (Summary & Proposal) | Nominations
JSRs: Java Specification Requests
JSR 3: JavaTM Management Extensions (JMXTM) Specification

Stage Access Start Finish
Withdrawn 05 Mar, 2014
Maintenance Release 4 Download page 04 Mar, 2014
Maintenance Review Ballot View results 10 Dec, 2013 16 Dec, 2013
Maintenance Draft Review 6 Download page 04 Nov, 2013 04 Dec, 2013
Maintenance Release 3 Download page 30 Nov, 2006
Maintenance Draft Review 5 Download page 22 Aug, 2006 26 Sep, 2006
Maintenance Draft Review 4 Download page 14 Jul, 2006 14 Aug, 2006
Maintenance Draft Review 3 Download page 21 Mar, 2006 24 Apr, 2006
Maintenance Release 2 Download page 05 Dec, 2002
Maintenance Draft Review 2 Download page 25 Jul, 2002 26 Aug, 2002
Maintenance Release Download page 31 May, 2002
Maintenance Draft Review Download page 04 Dec, 2001 14 Jan, 2002
Final Release Download page 07 Sep, 2000
Proposed Final Draft Download page 18 Jul, 2000
Final Approval Ballot View results 18 Jul, 2000 31 Jul, 2000
First Release 2 Download page 26 Jun, 2000
First Release Download page 10 Dec, 1999
CAFE 23 Dec, 1998 22 Jan, 1999
JSR Approval 14 Dec, 1998 23 Dec, 1998
Status: Withdrawn
Reason: Withdrawn following Maintenance Review 6.
JCP version in use: 2.9
Java Specification Participation Agreement version in use: 2.0


Description:
The JMXTM specification will provide a management architecture, APIs and services for building Web-based, distributed, dynamic and modular solutions to manage Java enabled resources.

Expert Group Transparency:
Public Communications
Issue Tracking

Team

Specification Leads
Staffan Larsen Oracle
Hinkmond Wong Oracle
Expert Group
Alcatel-Lucent
: Heather Ritchie Alcatel-Lucent
: Ron Traver Apache Software Foundation
: Federico Barbieri
BEA Systems
: Vadim Draluk BEA Systems
: Benjamin Renaud BEA Systems
: Steve Yellenberg
Borland Software Corporation
: Geoff Bullen Borland Software Corporation
: Cyndi MacDonald Bull S.A.
: Bill Bradley
Evidian
: Bernard Chuet Evidian
: Jean-Luc Richard Gemstone Systems, Inc.
: Phil Bride
Gemstone Systems, Inc.
: Chris Jacobson Gemstone Systems, Inc.
: Eric Odell Gemstone Systems, Inc.
: Darrel Schneider
IBM
: Michael Rowinski IBM
: Steven Wolfe IBM/Websphere
: Leigh Williamson
Lutris Technologies
: Keith Bigelow Lutris Technologies
: David Simons MGE UPS Systems
: Laurent Coussedi?re
MGE UPS Systems
: Jean-Marc Emonet MGE UPS Systems
: Dominique Louis Lallement Motorola
: Gregory Cannon
Oracle
: Staffan Larsen Oracle
: Hinkmond Wong Progress Software
: Brian Joyce
Progress Software
: Todd Keefe Progress Software
: Simon Pepper Schmid Telecom AG
: Rolf Frey
Schmid Telecom AG
: Harald Grov Schmid Telecom AG
: Marek Salwa Sun Microsystems, Inc.
: Jonathan Benoit
Sun Microsystems, Inc.
: Jim Davis Sun Microsystems, Inc.
: Rob Goedman Sun Microsystems, Inc.
: Hans Hrasna
Sun Microsystems, Inc.
: Philippe Lalande Sun Microsystems, Inc.
: Eamonn McManus Sun Microsystems, Inc.
: Sujit Panikatt
Sun Microsystems, Inc.
: Rebecca Searls Sun Microsystems, Inc.
: Mrudul Uchil Sun Microsystems, Inc.
: Simon Vienot
TIBCO Software Inc.
: Nicholas Antzoulis TIBCO Software Inc.
: Jon Dart TIBCO Software Inc.
: Bob Kyryliuk
TIBCO Software Inc.
: Caroline Phillips
Contributors

This JSR has been Withdrawn
Reason: Withdrawn following Maintenance Review 6.

Updates to the Original JSR

Note that this JSR was completed under JCP 2.1 and moved to JCP 2.6 in Maintenance.

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.

2012年03月21日:
Staffan Larsen is the new Maintenance Lead.
Maintenance Lead: Staffan Larsen, Oracle America

E-mail: staffan.larsen@oracle.com

Telephone: +46 8 506 309 00


Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

Submitting Participant:

Sun Microsystems
Consumer & Embedded
Embedded System Software Group
Director and General Manager: Jean Pierre Baudouin (baudouin@france.sun.com)
Engineering manager: Dave Hendricks (dave.hendricks@france,sun.com)
Marketing manager: Philippe Lalande (philippe.lalande@france.sun.com)

Endorsers of the JSR:

BullSoft
Computer Associates
Exide Electronics
Jyra Research
Lumos
Tibco
Tivoli

Section 2: Request

- Target Java Platform
 All platforms: Full Java, Personal Java and Embedded Java
 JMAPI will make it possible to add manageability to Java
 enabled equipment, from webphones and set-top boxes to network
 devices and servers.
- Needs of Java Community Addressed
 The Java Community needs a universal and modular Java
 management foundation which addresses the following
 requirements:
 + Allow rapid development of Java management solutions for
 the following markets: consumer, enterprise computing,
 telecommunications and datacommunications.
 + Provide a component-based architecture that scales from
 small footprint devices to large telecom switches.
 + Allow for portability of management applications, by
 supporting multiple hardware environments, protocols,
 information models, databases...
 + Allow for dynamic upgrade of management capabilities.
 + Provide integration with legacy management systems.
- Why need not already addressed
 No universal Java management foundation exists yet. The
 previous JMAPI draft has not reached the Specification stage
 and does not address the following market requirements:
 + Integration of the new trends for third generation
 Web-based distributed management.
 + Leveraging of up-to-date Java technology like JavaBeans
 and Jini.
 + Integration with legacy or non-Java environments (such
 as SNMP and CIM/WBEM).
- Specification to be developed
 JMAPI 2.0 will provide a management architecture, APIs and
 services for building Web-based, distributed, dynamic and
 modular solutions to manage Java enabled resources.
 The JMAPI architecture will be applicable to the creation of
 smart Java agents and management applications, and can also be
 integrated into legacy management solutions.
 JMAPI 2.0 will strongly leverage an existing product, and
 hence should lead in the short term to a mature Specification
 and to the availability of a commercial implementation.
- Underlying technologies
 The JMAPI Specification will leverage the Java Dynamic
 Management Kit technology. This product provides a core
 management framework which is a repository of Java Management
 Beans. Basically any Java bean can be registered in the
 framework and then expose management capabilities.
 Management operations can be performed either:
 + locally, from the same VM, or
 + from a remote VM, or
 + from a remote non-Java management application or
 browser.
 This product also provides a set of core distributed
 management services that can be deployed in manager, agent or
 agent/manager applications.
- Proposed package names
 JMAPI APIs and services will be divided into:
 + a set of mandatory services, which any conformant
 implementation will be required to implement.
 We propose to group all these services under the
 following package name:
 javax.management.core
 + a set of optional services, which any conformant
 implementation might choose or not to implement.
 We propose to define each of these services as a package
 named after the following scheme:
 javax.management.
 The JMAPI test suite will have the same modularity.
 When claiming for JMAPI compliance, implementations will
 have to provide the exhaustive list of optional services
 they support and will be tested against this "JMAPI
 implementation conformance statement".
- Possible platform dependencies
 The Reference Implementation will have a dependency on the
 JDK 1.2 release.
 The JMAPI specification will reference existing Java
 specifications such as JNDI, JDBC, JTS whenever needed.
- Security implications
 None.
 JMAPI will not incorporate security features.
- Internationalization implications
 The JMAPI APIs do not deal with the display of information but
 instead are handling storage and retrieval of information.
 These APIs rely on Java's built-in capability to manipulate
 locale-independent data, such as strings using Unicode
 multi-byte character set, and will hence allow the development
 of fully internationalized JMAPI-based applications.
- Localization implications
 None.
- Risk assessment
 JMAPI is not a required part of an existing Java platform.
 Therefore it does not jeopardize existing platforms and
 extensions or any other Java standardization project.
 Risk on the deliverables (Specification, Reference
 Implementation, Compatibility Test Suite) are minimal since
 the underlying technology already exists as a product, with
 associated QA test suites.
- Existing specifications rendered obsolete or deprecated
 This revision of the JMAPI specification will render obsolete
 the current draft 0.8 of JMAPI.
 There is no commercial product based on this draft available
 on the market today.
- Existing specifications needing revisions
 Not applicable.

Section 3: Contributions

- Existing documents, specifications, implementations &
 How they might be used
 + "Java Dynamic Management Kit - A white paper"
 + "Java Dynamic Management Kit 3.0 Programming guide"
 These two documents can be leveraged as a description of the
 concepts and architecture of the underlying technology, as
 well as a description of the core management services.
 + "Java Dynamic Management Kit 3.0 Reference Manual"
 This document can be used as a initial input to the
 definition of the APIs.
 + "Java Dynamic Management Kit 3.0"
 The product implementation will be leveraged to deliver the
 reference implementation. The next major release of the
 product will be JMAPI compliant and will provide a first
 commercial implementation of the Specification.
 + The test suite of Java Dynamic Management Kit 3.0 will be
 leveraged to deliver the Compatibility Test Suite.

AltStyle によって変換されたページ (->オリジナル) /