Reflections on MOF

Reflecting on the design and construction of a Repository as a Service in the last posting made me recall how the twists of fate in the OMG changed the nature of MOF and modelling in general.

When CORBA was the main game at the OMG, the increasing need for type information and other metadata about CORBA interfaces and infrastructure (CORBA Services & Facilities), made the need for a generic metadata service to augment the meagre reflection interfaces (often not supported by vendors) and Naming Service. Hence the RFP for a Meta-Object Facility (MOF) was issued in May 1996. In this sense, a "CORBA Facility" was a set of CORBA IDL-defined interfaces to provide access to ORB infrastructure, whereas a "CORBA Service" was an additional add-on to extend the capabilities of the ORB. The distinction was never that well defined... but MOF ended up with the 'F' at the end because of it.

Just after the MOF RFP was issued, the OMG announced that the UML Consortium, which had been working on unifying the 3 top object-oriented modelling frameworks would be submitted to OMG as a standard in Jan 1997.

The two pieces of work were conducted in separate task forces, and only as the commonalities became obvious during each of the standardisation processes, did the synergies start to emerge.

MOF was based on a textual syntax for models which was compiled into a Repository back end, supporting CORBA interfaces for type information to be queried. UML Class diagrams were a good graphical notation for expressing the models. Generated CORBA IDL being used as the interaction paradigm with MOF repositories meant that these were inherently distributed interfaces, and CORBA took care of marshalling the data into whichever programming language was being used to access them. I defined the first ever standardised MOF model as part of the CORBA Notification Service for getting at notification type metadata.

Conversely, the initial UML Class notation did not have sufficient expressive completeness to define all of the concepts in the 9 different notation types (of which Classes, Instances, State Charts, Activity Diagrams & Collaborations were the most used). So until UML 1.3 some of the structural semantics of UML were expressed only in natural language. But by UML 1.4, the MOF was used to capture a "physical metamodel", which was the basis of model interchange between tools.

By the time of the joint MOF 2.0 / UML 2.0 RFP, it was obvious that the object-oriented class formalism of both languages was so similar, that a merger was probably a good approach to allow UML finally to become self-expressing for the specification, as MOF had done from the first version onwards. All well and good - but given the rise of Web Services, and the low overlap between CORBA and UML vendors (IBM being perhaps the sole example), the notion of supporting distributed access via CORBA IDL to the MOF/UML 2.0 metamodels and their instances was quietly ignored, and the (flawed) XMI standard for generating XML interchange documents was taken to be sufficient to communicate between model tools and repositories.

Only one problem: The emerging WSDL & related standards for Web Services were diverging to allow Sun (Java/NetBeans), IBM (primarily their commercial Eclipse Variant called WebSphere) and Microsoft (.NET and all its languages) to implement non-overlapping subsets of the WS-* standards, thereby killing the kind of interoperability that CORBA once held as its pride and joy. (Aside: DSTC hosted a showcase called CORBAnet in the late 90s on behalf of OMG in which 12 ORB products all communicated with one another over IIOP with implementations of simple room booking application, implemented in at least 4 programming languages.)

Result: MOF was now unified with UML, but was no longer a distributed system, but an application-and-file paradigm - with significant XMI format interoperability problems, and no transport mechanism.

One more major difference between MOF 1 and 2 is that the simplest object-oriented notions which map very closely to O-O programming languages (Package, Class, Inheritance-and-substitutibility, Attribute, & Reference) were separated out by insistence of the IBM Eclipse group (thanks Ed Merks!) as Essential MOF (EMOF), and all the other stuff that was needed for fully featured associations, like changing their names cardinalities, which make the UML specification readable were placed in the superset called Complete MOF (CMOF). EMOF went on to be very closely represented in Eclipse EMF for Java, which is the most widely adopted MOF variant, with dozens (hundreds?) of useful open source projects around it.

Which finally brings me back to the Repository as a Service work, which aimed to take EMF object sub-graphs stuck in one JVM, which represented domain concepts, and re-enable their sharing via distributed interfaces - like in the CORBA-based MOF 1.0. The current implementation of RaaS (https://sourceforge.net/projects/raas4emf/) uses REST and XML or JSON for distributing EMF model sub-graphs ("domain objects"), which can be seamlessly re-integrated into a remote EMF application, or used as an XML or JSON document in any other environment. In the back end, the excellent CDO technology gives us generated OO-Relational storage (and it can do a lot more besides, which we don't really take advantage of - yet).