||28 Jun, 2002
|Final Approval Ballot
||04 Jun, 2002
||17 Jun, 2002
|Proposed Final Draft 2
||15 May, 2002
|Proposed Final Draft
||10 Apr, 2002
||05 Sep, 2001
||05 Dec, 2001
|Community Draft Ballot
||17 Apr, 2001
||23 Apr, 2001
||23 Feb, 2001
||23 Apr, 2001
||01 Nov, 1999
||20 Dec, 1999
||24 Oct, 1999
||01 Nov, 1999
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0
The Java Metadata Interface specification will address the need for a pure Java metadata framework API that supports the creation, storage, retrieval, and interchange of metadata.
Please direct comments on this JSR to the Spec Lead(s)
||Distributed Systems Technology Centre (DSTC)
||Hyperion Solutions Corporation
||SAS Institute Inc.
||Sun Microsystems, Inc.
Original Java Specification Request (JSR)
Section 1: Identification
||Sun Microsystems, Inc.
|Name of Contact Person:
||+1 919 929 9926
||+1 919 929 8413
List of other Participants who endorse this JSR:
25725 Jeronimo Rd, MS 108, Mission Viejo, CA 92691
phone: +1 949 380 5692
555 Bailey Avenue, D164, San Jose, CA 95141
phone: +1 408 463 2319
Inline Software Corporation
751 Miller Drive, SE, Suite E-3, Leesburg, VA 20175
phone: +1 703 737 6121
Other companies who endorse this JSR:
Oracle Parkway, Thames Valley Park, Reading, Berkshire RG6 1RA, UK
phone: +44 118 924 5132
Section 2: Request
|2.1 Please describe the proposed Specification:
|The intended specification will address the need for a pure Java API
that supports the creation, storage, retrieval, and interchange of metadata.
|2.2 What is the target Java platform?
|The metadata specification is targeted to work with the JavaTM 2
Enterprise Edition (J2EETM) Platform.
|2.3 What need of the Java community will be addressed by the
|The Java community needs a standard way to specify, store, access, and
interchange metadata (data about data). The goal is to create a well-crafted
API that implements the functionality of the existing industry-standard for
metadata (the MOF, see below) in a way that will be compatible with the J2EE
platform. A metadata framework is necessary to simplify the integration of
applications, tools, services, and to enable interoperability and interchange
among disparate data sources.
|2.4 Why isn't this need met by existing specifications?
|There are currently no Java APIs for dealing with metadata. The existing
metadata APIs are either proprietary or are not Java-based. The Object Management
Group has standardized on the Meta Object facility (MOF) as its metadata
foundation for defining and managing distributed metadata. These specialized
APIs allow discovery of both programmatic metadata (a subset of which is
addressed by Java Introspection) as well as semantic metadata (relationships,
constraints, well formedness rules in object models) which is not addressed
by any other Java APIs. The OMG MOF API provides CORBA interfaces but not
a Java API that is compatible with J2EE.
|2.5 Please give a short description of the underlying technology
|There has been substantial standards-based work done through the OMG
to define the interfaces necessary to implement a metadata repository. These
interfaces (the Meta-Object Facility, or MOF) are specified in IDL, and although
the OMG has defined an IDL-to-Java mapping, the resulting Java code produced
is neither intuitive or stable. Such a mapping introduces ORB-specific features,
and it does not take advantage of any advanced features of the language.
In addition to addressing these problems, the specification will insure that
the API integrates with the Java 2 Platform, Enterprise Edition with respect
to security, transactions, and resource management.
We are anticipating that an implementation of the specification will connect
to the J2EE platform via the Connector Achitecture (JSR-000016).
Implementing the Java Metadata API using the MOF as a building block also
allows for the use of XMI (XML Metadata Interchange, a MOF to XML mapping)
as a mechanism to serialize metadata using W3C XML. This will allow metadata
interoperability between Java, CORBA and legacy environments. We anticipate
aligning our work with both JSR-000026 (UML/EJB Mapping) and JSR-000031 (XML
Data Binding) to insure compatibility and prevent duplication of work carried
out in those efforts.
|2.6 Is there a proposed package name for the API
|The working name for the package is javax.jmof. This name is
subject to a better proposal during the life of the project.
|2.7 Does the proposed specification have any dependencies on
specific operating systems, CPUs, or I/O devices that you know of?
|The proposed specification has no specific operating system or hardware
|2.8 Are there any security issues that cannot be addressed by
the current security model?
|This specification will exploit existing security mechanisms of both
the Java environment and the underlying data storage mechanisms that will
store the metadata.
|2.9 Are there any internationalization or localization
|The metadata API uses the I18N support in the Java 2? platform, Standard
|2.10 Are there any existing specifications that might be rendered
obsolete, deprecated, or in need of revision as a result of this work?
|There are no existing specifications or specification requests pending
that would be rendered obsolete by this specification. There are no existing
specifications that would need revision as a result of the specification.
Section 3: Contributions
|3.1 Please list any existing documents, specifications, or
implementations that describe the technology.
|This specification will be based on the Object Management Group Meta-Object
Facility 1.3 specification. This specification can be found on the OMG website
The Object Management Group has been appraised of this effort (both the President
of OMG and the Architecture Board Chair) are interested in seeing the OMG
MOF and XMI specifications applicable to both CORBA and Java environmentss.
The XMI specification is at
3.2 How will these items might be used as a starting point for the
|The OMG Meta Object Facility is composed of 3 main parts.
MOF Model, which is the abstract model, is used to describe all metadata
MOF Reflective Interfaces which are used to provide generic interfaces to
manipulate all metadata
MOF to IDL mapping, which is used to specify design patterns for CORBA IDL
interfaces to MOF meta objects.
This specification plans to introduce a MOF to Java mapping that parallels
the MOF to IDL mapping. Note that this JSR is a specific mapping of a particular
OMG specification. Should subsequent changes, revisions, or updates
in the underlying OMG specification take place, it will be up to the
Interpretation Guru to determine whether those changes merit a revision (either
minor or major) to this specification. Regardless, it is to be understood
that this JSR and the specification that results from it is independent from
the OMG processes governing the maintenance and evolution of the OMG
Section 4: Additional Information
|Once the MOF to Java mappings are produced, XMI, a MOF to XML mapping,
can be used as a standard stream based metadata interchange specification.
Also OMG standard metamodels such as UML and the emerging Common Warehouse
Metamodel (CWM), CORBA Component Model (CCM) can also be incorporated into
Java by applying the MOF to Java mappings for metadata interchange. The MOF
thus enables a smooth transition of OMG metadata specs (interfaces, metamodels
and XML streams) into the Java platform.
A web site for JMI has been established at java.sun.com/products/jmi. The site contains whitepapers, presentations, and additional collateral.