Back to Article

Java MetaData Interface (JMI) by Benoy Jose   Introduction: With almost all of the major companies moving into to the computerized era we have most if not all data on computers. That sounds good as systems are now automated, fast and reliable. One of the biggest challenges the industry faces today is the integration of these systems, making different systems from different companies to talk to each other. All the data is already in machine-readable format, so what’s the problem? The problem is that the machine readable data exists in varying formats on different systems. This mismatch between the data formats prohibits companies from talking to each other electronically. Imagine a bank, which receives thousands of electronic transfer requests from different banks. Each bank it does business with would send in the data in a different format while the recipient bank would be storing the same data in a completely different format. Either the recipient bank has to do this process manually (Which could be very tedious) or have a Data extraction tool, which can do this job. Currently companies employ data extraction tools like DataJunction, Informatica etc that convert data from one format to another based on a set of defined rules. However these rules are some times so rigid that small deviations in the data can corrupt large sets of data. Moreover these tools are more of a fix and do not solve problems in the long run. The main reason for this problem is the absence of a common standard to define the data, which can be used by all these companies. The common standard could be through the use of the same standardized data types or by defining the way the data is defined in a system. The result of defining the data about the data is Metadata. A common example of metadata is the database schema. The schema does not show the actual data but shows the definition of the data and how the different entities are related. Another example of metadata could be an XML Document type Definition (DTD). The DTD defines the data about the different data elements within an XML document. The industry needs a long-term solution, which provides a common standard for Metadata. The OMG already defines a standard specification called the Meta Object Facility (MOF - discussed later), which defines rules for metadata driven systems. MOF defines abstract language to describe meta-models and define metadata. The language is closely related to UML, borrowing the best parts of UML and then extending it to include the principles of metadata modeling. This makes it easy for people with working knowledge of UML to start off with a meta-model design without any trouble. But unfortunately for us MOF does not provide a Java abstraction or a Java based API for defining metadata. MOF provides platform neutral CORBA and IDL interfaces to do modeling tasks. The Java Metadata Interface JMI is the Java version of the MOF. It is based on the MOF specification but provides Java specific interfaces for meta modeling and provides a unified API that can be used by independent vendors to provide access to the proprietary data structures they have. What happened to XML: XML was touted as the alternative for any two disparate systems that cannot talk to each other normally. XML can act as glue between the data of two different systems. XML also provides a common standards based Consider an example where we have a Product list which has a list of sub products within it. Now each product has a generic price and price associated with a location. To add more complexity to it, the location is defined in a similar hierarchical structure of continents, countries, regions etc. Added to this the product is defined for a particular location in the location structure. There is a derived relation between the locations, there is aggregation relation between products and there are association relationships between products and regions. XML can model this scenario but with a lot of limitations. XML does not have inherent capabilities to model complex relationships like inheritance, association and aggregations. Moreover an XML model designed to reflect this scenario might not be flexible enough to be used by other applications. MOF Overview: MOF provides a infrastructure to model data using a neutral language and allows the model to be represented in UML. It can use UML to define the complex relationships we discussed in the XML sample discussed above. MOF also provides a layered architecture consisting of data, models, metamodels and a single meta-metamodel. Each layer is an abstraction of the layer below it. The lowest level is the data layer, which comprises the actual data. Examples are database records, application objects. The second layer is the model layer, which describes the format and semantics of the actual data. Examples of model layer objects are database schema model, which represent data. The model layer is also called M1 or the metadata layer. The third layer is the metamodel Layer also called the M2 layer. This describes the semantics and structure of the metadata. An example of the M2 layer is a database system table that describes the format of a table definition. The meta- metamodel Layer or the M3 layer provides the last layer of abstraction. This layer describes the semantics and structure of the meta-metadata. Apart from providing the modeling infrastructure the MOF provides an IDL mapping interface to help in manipulating metadata. MOF provides an IDL mapping which in turn provides an IDL based API. The API can be used to manipulate data contained in the different instances of the metamodel. The MOF provides language neutral models that capture the semantics of the system that is being modeled. This helps system architects to work with complex systems by visualizing the metadata available for the system instead of knowing all the intricacies of the system. To add more flexibility MOF provides a set of reflective API's, which provide introspection services for manipulating complex information. The MOF reflective API works like the Java reflection feature of J2EE and allows information to be accessed dynamically. The Reflective API does not need to use the API generated by the MOF to perform IDL mapping. OMG defines the Model Driven Architecture (MDA) with the help of MOF. MOF provides the technology and domain metamodels that are the used in the MDA framework. These metamodels are represented in UML (Since MOF can use UML) and will define all aspects of the environment from different perspectives and levels of abstraction. The MDA can use these metamodels to model architectures using the MDA. What is JMI? As described in the introduction JMI is the Java version of the MOF. It provides a common Java API for accessing metadata. The JMI specification provides a framework to create a Java programming model for accessing metadata. Instead of defining a new standard, JMI leverages on the experience of MOF and provides a Java API that is based on the MOF specification. Features: JMI provides the metadata framework to capture system specific semantics. The JMI specification also provides rules for generating Java APIs for any MOF compliant model, which can be used to work with the information contained in the model. JMI can be used to model disparate systems, applications and services into a common model. This common model can now be used to integrate these disparate systems. Like EJBs, which mask the complexities of a system and allow the user to concentrate on the business logic, JMI can provide high level models of systems and business domains and hide the complexities of the systems. JMI can provide a common programming model, which is in the form of APIs automatically generated from the meta model. They can provide a common XML based interchange format. JMI provide APIs for stream-based exchanges between JMI services. These APIs use XML Metadata Interchange (XMI). JMI brings the OMG Model Driven Architecture (MDA) to J2EE. It also provides integration with the OMG modeling and metadata architecture. MOF to Java Mapping: JMI defines templates for generating Java APIs. These APIs are used for accessing and modifying metadata. The APIs are generated for a given MOF model. There are four kinds of metadata level metaobjects that JMI uses for mapping MOF to Java. They are package objects, class proxy objects, instance objects and association objects. A package object is like a directory, which gives access to the collection of other metaobjects. A package can roughly translate to a root object, which in turn contains all the other metaobjects like class proxy, instance, sub packages etc. A class proxy object provides factory methods for producing instance objects within a package and also acts as a container to store all these created objects. It also holds the classifier scoped attributes for a class and provides operations for the classifier scoped operations. An instance holds the state of the attributes and any other hidden states implied by the class specification. A package can contain multiple instance objects. The class proxy has factory methods to create instance objects and it stores these instance objects within the class proxy container when they are created. The instance object interface provides operations to modify and access classifier scoped and instance scoped attributes. It also provides operations to modify and access associations that are defined between the objects. An association object holds a collection of links. When two instances of classes are linked with an association a link instance is produced. The association interface provides operations to query the link set and return an entire link set or links within the link set. It also provides operations to add, modify and remove links from a set. MOF Reflection: Similar to the Java Reflection API the JMI specification provides a mechanism to discover objects at runtime. For this purpose JMI provides MOF reflective interfaces to create, modify and invoke operations on class proxy objects. It also allows navigating the MOF package structure and allows to query and update links using association objects. Conclusion: The JMI Specification provides a Java version of the MOF. The specification is led by Unisys and is backed by major industry players Sun, IBM, Oracle, and Sybase, who are part of the Expert group for this specification. The specification is in the final stage after it was approved by the expert group and is available for download from the Java Community Process site http://www.jcp .org/en/jsr/detail?id=40. JMI provides mappings for MOF 1.4 and is compatible with J2SE 1.3. Some existing specifications are already banking on JMI or are using the JMI technology. The JSR 69 Java API for OLAP, which defines a Java API for OLAP objects, uses JMI to generate interfaces. The Java Data Mining API discussed in a previous article on JavaBoutique uses JMI to generate the data mining APIs. Sun’s netBeans already implements the JMI specification in its Metadata Repository Project. SAP NetWeaver has a Metamodel Repository (MMR) which has a JMI implementation. As the need for integrating systems increase, the demand for common, unified modeling mechanisms like JMI and MOF will increase. Data extraction tools might solve the data integration problems today, but as the data volume increases and systems become more complicated metadata models might be the only way to integrate systems Benoy Jose is a web developer with over six years of experience in J2EE and Microsoft technologies. He is a Sun Certified programmer and enjoys writing technical and non-technical articles for various magazines.