From RaaS to Building Object Libraries

I've reminisced about MOF past and present, and helping build a meta-model and repository for service descriptions with Smart Services CRC at QUT (here's an initial paper that led to the USDL book work). But sadly SAP Research failed to get critical mass around the USDL service description language at W3C, so I started looking for other applications for RaaS.

We did an interesting experiment with a wrapper around LDAP for AARNet to unify their university stakeholders' academic contacts, using my concept of "live model pointers" (LMP) (here's a workshop paper from ASWEC). An LMP is a variation on a saved query, embedded in an EMF object, which fetches data from other information sources at the time an EMF object or attribute is accessed. (Here's an old diagram - the LMP seems to be pointing in the wrong direction - but I think I was using block arrows to indicate data flow, rather than logical "pointer" direction.)

We used the NYU LDAP server for prototyping, which is open to the public, but in the information security environment of the day, there was not a single Australian university on the AARNet network among the 6 or 8 that we contacted who would make their LDAP ports open to public query. So we were left with screen scraping HTML web pages of different formats that each university uses to publish their contacts. Screen scraping was not really viable, and there was no critical mass of interest in creating an AARNet-wide academic directory, so this idea was abandoned.

At the same time I was collaborating with Professor Robin Drogemuller's team at QUT on models for the construction industry. Robin wanted to get away from the expensive and proprietary IFC repositories that only provided C++ SDKs. My old DSTC colleague Jim Steel was doing some cool work with higher-order transformations (HOT, in the academic literature ;-) to get the excellent specification for buildingSmart's IFC, in the equally excellent, but hardly supported STEP-EXPRESS language, available as an EMF meta-model.  I got in on the tail end and helped get a paper written on the approach of using an EMF model of the EXPRESS language which could then read in the IFC specification in as EMF model instance. By "promoting" the IFC instance to a meta-model & combining it with an IFC file reading resource implementation, we suddenly had an EMF IFC Model & importer (and an approach to translate any EXPRESS spec into an EMF metamodel). Add on RaaS, and you have repository and "workbench".

I also started working on a metamodel for GDL (the ArchiCAD textual language for geometry definition) so that we could do a trial model transformation in Eclipse from IFC to GDL as a proof of concept to get buy-in from QLD government's Project Services agency, who had 20+ years of BIM experience, but were limited by what vendors were offering for integration of models.

My contract at QUT was reaching its end, and so I got together with Robin to organise a 3 way-funded project with QLD Govt, Smart Services and SBE NRC all contributing to fund Robin's vision for a building object (product) library... which was to be built on RaaS, and use model transformations to round-trip the CAD default windows, doors, beams and other products from the CAD tool to the Library, and replace them back in the CAD design with real product geometry and properties. The vision was to make this available as a not-for-profit service to the Australian construction industry.

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).

Services Modelling and creation of Model-based Repositories

Starting in 2008 I worked at QUT with Smart Services CRC - mostly on modelling "services" (surprise surprise). Much of the work I did went into an SAP initiative on a Unified Service Description Language - USDL, for which I wrote and edited chapters in a Springer book on that subject, and there are several conference papers out there as well.

To facilitate a repository of service descriptions my collaborators and I developed a model-driven repository technology - now an open source project called Repository as a Service - RaaS [I know - groan, the name was a joke that stuck]. Here's the basic idea (the RaaS now uses a different OO-Relational mapper, and lots of standard Java code generators).

Using this technology I lead the software side of a candidate Australian National [Building] Object Library with QUT, Queensland Government and NATSPEC under the auspices of a joint SBE NRC/Smart Services project. More on that next time...

Hello again - and intro to Distributed Models

For those of you who know me personally, you will be aware that I started a small company in early 2013 to do consulting and product development at the intersection of modelling and distributed applications: Distributed Models Pty Ltd.

I've been pretty busy since then working with a small team doing Building Information Models (BIM) and model-driven Health Records. I was unsure about whether a web presence would very useful for the company, given the specialised nature of our work ....but with a little idle time recently, I've decided to do it anyway - just so I have something to point to.

https://sites.google.com/a/distributedmodels.com/distributed-models/

I've been dithering about a final choice of hosting arrangements, and a domain redirect, so I thought I'd put up some plain old HTML on Google. I'll repost when I get a sexier template and hosting arrangements, but for the mean time, the page above is small clean summary of what the company does.

If you come at this from the main Blogger ModelWise page, then you'll see that this is the first post for 11 years!! So I'm going to follow up soon with some of the things I did, and results they had in that time.

...|<

Abstract Platforms & Interaction Design

I'm busy reviewing some journal papers, and (without pre-empting the contents) it's got me thinking.

There always seems to be a tension in MDD/MDA when designing abstract interactions. Some approaches assume that it's best to expose only the kinds of interactions available in a class of platforms in the PIM modelling language: e.g. "sychronous call" in the modelling langauge represents "method call" and "operation invocation", and other kinds of synchronous calls that behave much the same. Similarly, "async message send" can represent "oneway operation", "queued message", etc.

Other approaches like to have more abstract interactions in the PIM modelling language, and then map or refine these into more complex interactions in a lower level model, until finally the constructs in the implementation language can be used directly. It allows for an abstract design to be implemented in more diverse ways, on more classes of platforms. e.g. an interaction can be designed that results in values being shared by two or more components in the system without specifying who initiated the interaction, or how many messages are passed, or whether they are synchronous or asynchronous. This seems to me to be a better approach as it frees the designer from the fairly rigid paradigms imposed by platforms such as Java remote method calls, MOM, etc, while still allowing any of these platforms to be used for implementation (within limits - hopefully well specified or easily discoverable).

BUT, the drawback of this approach is that when one of the established platform paradigms (like transactional method call with user-defined and systems exceptions) is actually exactly what the designer wants. I'm talking about when its properties are what's needed by the application domain, not because the style of interaction is necessarily available in the target platform. In this case the abstract interaction paradigm is usually a pain in the butt, as a complex arrangement of messages and constraints on those messages is needed to "simulate" the required interaction.

The solution seems to be to allow patterns of simple abstract interactions which are equivalent to the common platform interaction constructs to be available as templates in the abstract language, so that (a) the designer who knows what they need can call it by name, and use it without construction from primitives, and (b) easy, reusable, perhaps formally proven, mappings can be made available to platforms that support this construct natively. And that (c) more complex, reusable, perhaps formally proven, mappings are available to platforms which do not support it natively. (And perhaps additional well-formedness rules that must apply to the abstract design need to be applied when the non-native mappings are used).

In short, let's not throw out the well-understood interactions styles that are directly implemented in some concrete platforms when we introduce abstract platforms, because sometimes they are an exact match for the semantics of the application.

Profile at SoftMetaWare

I'm in negotiations with SoftMetaWare to take on some consulting work. My profile is now on their site.

Softmetaware is a networked associates consulting company based in New Zealand, but with associates in Australia, Germany and other European companies. Their approach is to focus on model-based techniques in software projects, and custom tailor agile methodologies to teams where these approaches will be used.

They offer consulting services ranging from embedded mentoring to whole project outsourcing.

QVT nears completion

I'm off to Athens tomorrow to attend OMG, where myself and my cosubmitters will be presenting our (hopefully) final version of the merged MOF Query/View/Transformation spec.

QVT has become a bit of a misnomer, as Queries are dealt with by OCL expressions, and Views are not dealt with at all. Transformations, however, come in 3 favours:

Relations - the user-friendly declarative language, with patterns and templates and implicit traces between models,

Core - the lower level langauge which Relations map to, but which has the full semantics for multi-directional, incremental update, create and delete transformations. It is a thin layer above EMOF and OCL.

Operational Mappings is a set of extensions to OCL that have side effects, and provides a n "imperative" langauge for the transformation of models, which relies on the implicit trace generation of the Relations part.

Also, there's a way to use MOF operations to plug in black box implementations of any given Relation. This is viewed by some as a cop-out that destroys portability, but by others as a god-send that allows them to reuse libraries and algorithms that would be painful or impossible to re-express in one of the languages above.

ASWEC Tutorial: MDA - Reality vs Fiction

Michael Lawley and I will be presenting a tutorial entitled Model Driven Architecture - Reality vs Fiction at the ASWEC Conference on Tues 29th March.

Besides looking a lot, shall we say, older and wiser, than our ancient photos on the web page.... we'll also we adding a few extras to the tutorial overview, including the difference between MDA and MDE, and the relationship of those things to DSLs and Software Factories.