Description
Expert Group Transparency
Stage timeline
| 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 | |
| Final Approval Ballot | View results | 18 Jul, 2000 | 31 Jul, 2000 |
| Proposed Final Draft | Download page | 18 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 |
Team
Specification Leads
- Staffan LarsenOracle
- Hinkmond WongOracle
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
Proposal
This JSR has been Withdrawn.
Reason: Withdrawn following Maintenance Review 6.
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
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
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.