Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 40: The JavaTM Metadata Interface (JMI) Specification

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

Submitting Participant: Sun Microsystems, Inc.
Name of Contact Person: Chuck Mosher
E-Mail Address: chuck.mosher@sun.com
Telephone Number: +1 919 929 9926
Fax Number: +1 919 929 8413

List of other Participants who endorse this JSR:

Sridhar Iyengar
Unisys Corporation
25725 Jeronimo Rd, MS 108, Mission Viejo, CA 92691
phone: +1 949 380 5692
e-mail: sridhar.iyengar2@unisys.com

Dan Chang
IBM Corporation
555 Bailey Avenue, D164, San Jose, CA 95141
phone: +1 408 463 2319
e-mail: dtchang@us.ibm.com

Jack Greenfield
Inline Software Corporation
751 Miller Drive, SE, Suite E-3, Leesburg, VA 20175
phone: +1 703 737 6121
e-mail: jack@inline-software.com

Other companies who endorse this JSR:

Peter Thomas
Oracle Corporation
Oracle Parkway, Thames Valley Park, Reading, Berkshire RG6 1RA, UK
phone: +44 118 924 5132
e-mail: pthomas@uk.oracle.com

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 proposed specification?
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 or technologies:
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 Specification?
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 dependencies.
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 issues?
The metadata API uses the I18N support in the Java 2? platform, Standard Edition.
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 at http://www.omg.org/pub/docs/ad/99-06-08.pdf. 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 http://www.omg.org/docs/ad/98-10-05 and http://www.omg.org/docs/ad/98-10-06.

3.2 How will these items might be used as a starting point for the work?

The OMG Meta Object Facility is composed of 3 main parts.
  1. MOF Model, which is the abstract model, is used to describe all metadata models.
  2. MOF Reflective Interfaces which are used to provide generic interfaces to manipulate all metadata
  3. 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 specification(s).

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.