Download (direct link):
Enterprise software is becoming more and more metadata driven all the time. A lot of metadata will end up in IBM and Oracle databases, accessible via XMI and MOF APIs. There is a possibility that, within 2 to 3 years, applications that don't support MOF will be disadvantaged when they try to access the big metadata stores.
MOF is also wired into IBM's WebSphere software at a deep level. This fact isn't visible to the WebSphere user, since WebSphere uses MOF internally. IBM has defined metamodels for all of the different kinds of metadata that WebSphere uses at various abstraction levels and middleware layers. WebSphere represents this metadata in-memory as abstract syntax trees that are accessible via JMI APIs. Internally, WebSphere thus uses a consistent set of APIs to manipulate the different kinds of metadata.18
For example, when WebSphere transforms a Java object model into a relational data model, it reads an abstract syntax tree representing the object model and writes an abstract syntax tree representing the data model. APIs generated from a metamodel for Java represent the abstract syntax tree for the Java object model. APIs generated from a relational database metamodel represent the abstract syntax tree for the relational data model. The consistent use of APIs derived from metamodels for its internal manipulations endows WebSphere with efficiencies not otherwise achievable.
WebSphere uses XMI files for persisting metadata unless a conventional format is required for legacy reasons. The component that reads and writes XMI is driven by metamodels at runtime, so that WebSphere's developers don't have to write special parsers and writers for every kind of metadata.
Unisys also has a MOF engine that it is using internally in the development of new applications. This engine, too, is not necessarily visible to users of the applications. IBM and Unisys, to differing degrees, make their MOF technology available for license or purchasing.
18 WebSphere actually uses a somewhat more advanced version of MOF and JMI based on MOF 2.0 proposals to the OMG.
142 Chapter 5
Sun Microsystems is a relative latecomer, but there are now a number of MOF-oriented Java Standards Requests (JSRs) active in the Java Community Process (JCP), some of which I've mentioned already. Furthermore, at press time, Sun had recently released a beta version of a MOF repository that will be part of its Forte-NetBeans development environment.
MOF and the Resource Description Framework (RDF)
The W3C's Resource Description Framework supports the description of Web content, including "sitemaps, content ratings, stream channel definitions, search engine data collection (Web crawling), digital library collections, and distributed authoring, using XML as an interchange syntax."19 However, the W3C actually defines RDF in abstract terms and positions the RDF XML Schema as an encoding of the abstract semantics.
While there is overlap between RDF and MOF, they have somewhat different design centers. RDF is being applied to metadata about resources on the Web, although it is not theoretically limited to the Web. MOF has been applied primarily to enterprise software tooling, although this is not a technical limitation.
One approach to integrating MOF and RDF would be to define a MOF metamodel of RDF. This would allow RDF to leverage the MOF API mappings to produce JMI and CORBA interfaces to RDF metadata. It would make it easier for RDF metadata to coexist in integrated or federated repositories that include the enterprise metadata being created via MOF. All of this would add value to RDF metadata. Note that an XMI encoding of RDF derived from the metamodel would be somewhat different from RDF's current XML encoding.
Another approach, which is not mutually exclusive with the first approach, is to define a MOF-RDF mapping. This would make it possible to express any MOF metadata as RDF metadata and thus would add value to MOF metadata.
As of the time of this writing, there have been initial contacts between teams working on MOF 2.0 and RDF regarding these integration possibilities.
What You Can Do Now
Stop hand-coding XML DTDs, XML Schemas, and Java APIs for representing and managing metadata. Consider hand-coded DTDs, Schemas, and APIs to be legacy artifacts that will have to be integrated with standards later, and so avoid creating more of them.
MOF-based metadata management tools are now available. There are even free tools available that will generate XMI DTDs and JMI interfaces from a metamodel. When you have identified metadata you need to manage, define a metamodel for it and generate the DTDs and APIs.
19 [W3C RDF]
The Meta Object Facility (MOF) 143
Even if you don't use a full-blown MOF repository right away, if the DTDs and APIs you use conform to the XMI and JMI standards, you will have a much easier time transitioning the metadata to a MOF repository than would otherwise be the case. Furthermore, if your development group is savvy about MOF, it will be at an advantage when you need to access MOF-based metadata in the corporate metadata stores of the future.