Charles Young

  Home  |   Contact  |   Syndication    |   Login
  198 Posts | 64 Stories | 512 Comments | 373 Trackbacks

News

Twitter












Article Categories

Archives

Post Categories

Image Galleries

Alternative Feeds

BizTalk Bloggers

BizTalk Sites

CEP Bloggers

CMS Bloggers

Fun

Other Bloggers

Rules Bloggers

SharePoint Bloggers

Utilities

WF Bloggers

Warning:  At the time of writing, I assumed that 'Oslo' was intended as a general purpose suite of tools and technologies for all aspects of modelling and DSL creation on the Microsoft platform.   Many months later, it now seems that this is not the case.   'Oslo' eventually found 'a home' as part of SQL Server, and became 'SQL Server Modelling'.  According to Doug Purdy at PDC 2009, both 'M' (which incorporates MSchema and MGrammar) and Quadrant will ship with a future release of SQL Server.   Doug's presentation addressed only SQL Server database design, implementation and access.   He appeared to speak of 'Oslo' technologies primarily as a way of promoting Microsoft's database product.   In my opinion, this much-reduced role is to be regretted, and the following article should be read in the knowledge that, although the technologies remain the same, the scope of their expected use appears to have been significantly reduced.

Over the last few weeks, I’ve had the opportunity to look in some depth at Microsoft’s emerging ‘Oslo’ modelling technologies.    At this very early stage, ‘Oslo’ consists of ‘pre-alpha’ and CTP implementations of a  technology and tooling stack that includes an initial implementation of a SQL Server-based model repository, the ‘MSchema’ and ‘MGrammar’ languages and the ‘Quadrant’ model visualisation tool.     There is still a great deal of work to be done.   The technologies and tools will evolve significantly over the next year or so, and Microsoft has yet to decide or announce the full scope of the first release.   Nevertheless, the major themes of this emerging technology are in place and have been made public.

One of the best ways to understand the concepts that lie behind a new technology is to compare and contrast it with similar technologies provided by other communities.   ‘Oslo’ addresses the modelling domain which has enjoyed a great deal of attention over several years.    This article is an attempt to articulate something of the nature of Oslo by relating it to the wider world of modelling, especially as envisaged by the OMG (Object Management Group).   The OMG are responsible for various modelling specifications, including the Unified Modelling Language (UML), various additional metamodels and the Meta Object Facility (MOF).

What is a model?

Before I discuss Oslo in respect to OMG specifications, I need to lay a little groundwork.   It is all too easy to use common terms like ‘model’ without specifying what we mean.    One common approach to defining the term comes from the General Model Theory (GMT) of Herbert Stachowiak.    Stachowiak states that "[all] cognition is cognition in models and by models", implying that humans cannot understand reality except through the use of models.   He identifies three characteristics of a model as follows:

 

 

 

 

·         Simplification (Reduction): A model only maps attributes of interest, and ignores other attributes of the original.   In this way, the model removes complexity and provides an abstraction of the original.

·         Pragmatism: A model has a practical use within some given context.   It doesn’t exist for its own sake, or have any meaning solely in reference to the original.    Rather, its meaning is bound up with representing the original when used for some practical purpose.

 

The original ‘thing’ represented by a model may have existed in the past, may currently exist, or may be something that does not yet exist but could exist in the future.    Models represent ‘originals’ regardless of their location in time.

Consider a city street plan.   In this case, the city is the ‘original’.   The street plan is a model that represents the city.   The various features of the plan map directly onto attributes of the city.    However, the plan does not try to capture every attribute.   Instead, it provides a simplified representation by only capturing some of the city’s attributes – its roads, railways, public buildings, etc.   It ignores attributes such as telephone cables, sewers, etc.    The street plan is created for a pragmatic purpose – to allow humans to navigate their way through the streets to some destination.

What is a metamodel?

A metamodel provides a ‘language’ used to describe the structure and semantics of a model.   It is, itself, a model with the specific purpose of describing how a model is structured.    It does not map directly onto the attributes of the original, but onto attributes of the model of the original.

Extending the street plan example, consider the legend printed on the inside cover of the plan.   This defines the graphical ‘language’ in which the map is written.   Items within the legend map onto attributes of the plan.    For example, the legend may define the graphical representation of roads, parks, buildings etc.    These definitions map onto various attributes of the plan and allow us to interpret the plan correctly.    Without this metamodel, we might not be able to properly understand the plan or the semantics of the symbols it uses.

What on earth is a meta-metamodel?

In the world of modelling, it is sometimes useful to add another layer of meta-modelling.    Meta-metamodels are models of metamodels.   They provide a language used to define the structure and semantics of metamodels.

The most common purpose of a meta-metamodel is to provide a unified context for handling many different metamodels and their associated models.    Consider a company that publishes many different types of plan.   Their plans may be drawn to different scales, may be published in different languages and may target a variety of specific needs - e.g., specialised maps for cyclists, maps showing administrative areas, tourist maps, integrated public transport systems etc., etc.    The company may well use cartographic software that captures all relevant information within a common data base.   Different types of plan for the same area may be extracted from this common set of data.    In order to enable this, the cartographic software would probably define some internal meta-metamodel that describes a foundational set of concepts.   Attributes of this common model will map onto the symbols used within specific plan types.   For example, the meta-metamodel may define the foundational concepts of roads, buildings, rivers, geographical co-ordinates, etc.   Different plan types may represent these concepts in different ways with a variety of specialisations - e.g., distinguishing hospitals from other types of building.   The meta-metamodel may define some extensible generic approach to capturing specialisation information in a way that can be searched, queried and processed.

The purpose of the meta-metamodel will be to allow cartographers to store and manipulate all the relevant map data in a unified and efficient manner, eliminating ambiguity and duplication while supporting evolving requirements.    Building on this basis, cartographers will be able to ensure consistency between different plan types built on a common ontological foundation of base concepts and semantics and a common set of data.   It would be particularly valuable if the meta-metamodel represented some well-defined standard.   In this case, we would have a solid basis for allowing interoperability and metadata exchange between different systems.   Models captured in other systems could be reliably imported and transformed on the basis of standardised specifications at the meta-metamodel level.

OMG Four-Level Metamodel Architecture

One of the core concepts that underpins the OMG’s work on modelling is the ‘classic’ four-level metamodel architecture.    This is described as follows:

Layer

Name

Description

M3

Meta-Metamodel

Core languages for describing the structure and semantics of metamodels

M2

Metamodel

Languages that describe the structure and semantics of user models

M1

User model

Models that describe system data, behaviours and information

M0

User object

System data, behaviours and information

 

 

 

 

 

Some descriptions of the four-level metamodel architecture make a distinction between M0 and the real-world ‘things’ that the system data and behaviours represent.   However, this distinction is not well-defined and will only have specific meaning within a given context.   For example, if an instance of a programmatic class is created at runtime, does this object exist at M0 or beyond?   Should we consider real-world ‘things’ to be the objects we instantiate at run-time or the entities in the real world that these object represent?   There is no one definitive answer to such questions.

UML, metamodels, MOF and MDA

The OMG defines UML in terms of a formal metamodel which resides at M2.    This is just one of a family of metamodels for which the OMG have responsibility.    Others include Common Warehouse Metamodel (CWM), Ontology Definition Metamodel (ODM) and Software Process Engineering Metamodel (SPEM).   The OMG’s specification states that the UML metamodel provides “...the abstract syntax of the UML. The abstract syntax defines the set of UML modeling concepts, their attributes and their relationships, as well as the rules for combining these concepts to construct partial or complete UML models.”   It is a fairly complex specification that underpins all the various UML diagram types.

Each of the OMG metamodels, including the UML metamodel, is compliant with a metamodelling language called Meta Object Facility (MOF).    MOF is typically described as residing at M3 because it is used as a meta-metamodel that underpins the various OMG metamodels and any other MOF-compliant metamodels.   However, some care needs to taken here in understanding the true nature and role of the MOF specification.   MOF defines a metamodelling infrastructure that can be used to support systems that exhibit as few as two layers (e.g., M0 and M1), or an arbitrary large number of layers.   This is stated explicitly in section 7.2 of the MOF 2 specification which is titled “How Many ‘Meta Layers’?”.    The specification points out that MOF has always had the ability to support traversal of an arbitrary number of metamodel layers.   Hence, it is not intrinsically an M3 meta-metamodel, even though the OMG use it in this role.   Rather, we can think of MOF as a metamodelling language and infrastructure, based on core UML 2.0 packages, which happens to be most widely used at the M3 level.

MOF was originally strongly associated with CORBA, and the OMG provides a specification for mapping MOF to CORBA IDL.   Standardised CORBA interfaces can be created for the purpose of reflection and other interactions with metadata.    In addition, the Java Metadata Interface (JMI) specification provides MOF to Java mappings (currently only for version 1.4 of MOF).   MOF is also used to define the XML Metadata Interchange (XMI) standard for metadata exchange.

MOF, UML, XMI and other OMG specifications underpin the OMG’s Model-Driven Architecture (MDA) standard.    MDA (an OMG trademark) specifies a platform-independent model-based approach to system and software design, and also provides an approach to platform-dependent model-driven software generation.   The general concepts involve creating PIMs (Platform Independent Models) which can then be translated into PSMs (Platform-Specific Models) as required.    PSMs can be used to drive code generation and other model-driven development approaches on a target platform.

A number of vendors provide MOF repository technology.    Broadly speaking, MOF repositories are structured to handle MOF-compliant metamodels and models defined using those metamodels.    MOF is used at the M3 level to support interoperability across a range of model types and modelling tools.    JMI is typically supported as a common API for reflecting on model metadata and interacting with models.   XMI is used to exchange metadata between tools and repositories.

MOF repositories are typically used by companies and organisations that have the motivation and resource to manage the centralisation of many different models and model types.   For example, a larger organisation will probably invest heavily in the formal definition and management of its enterprise architecture.    This architecture may be represented from several different viewpoints using a number of different modelling tools, technologies and techniques.   Having established a detailed enterprise architecture, the organisation may wish to enforce architectural policy and track compliance across multiple projects and development, infrastructure, data management and operational teams.   Again, this will typically require integration of many different model types with a wide range to tools and technologies.   A MOF repository exploits the concept of meta-metamodelling to enable this level of integration and interoperability, and provides a core piece of the enterprise infrastructure that enables the use of Model-Driven Architecture across the software development and application lifecycles.

I think it is fair to suggest that MOF-based model repository technologies have yet to generate a significant and wide-spread following in the wider ecosystem of software development environments.   While researching MOF, I was struck by the number of times I read statements to this effect in articles generated by the MDA community.    There appears to be something of a consensus that the OMG metamodelling specifications have relevance today mainly in environments that are large and complex enough to warrant the heavy investment and costs involved in adopting a full-blooded repository-based MDA approach.    There is, however, clear evidence of a strong desire to see support for modelling and model-driven approaches become a far more mainstream withing software development.   For example, as I have been reminded, Eclipse makes extensive use of EMF (the Eclipse Modelling Framework).   The Ecore specification provides a metamodel specifiation for EMF, and is very similar to MOF.

A Lesson from History: The Microsoft Repository

So much for OMG.   We could easily forget that Microsoft has its own history of involvement in UML-centric metamodeling.   Back in 1997, Microsoft announced the Microsoft Repository for SQL Server 7.   They renamed this technology as 'Microsoft Meta Data Services' when SQL Server 2000 shipped.   The repository implemented a Microsoft specification called the 'Open Information Model' (OIM) which was submitted to the Metadata Coalition (MDC) for standardisation.  The MDC took ownership of OIM, removed dependencies on the COM API and ratified it as "a non-proprietary and technology-neutral, and extensible specification" in 1999.   OIM defined a collection of metamodels (‘information models’), including a UML 1.0 metamodel, aimed principally at data warehousing and component application development.   OIM therefore addressed the M2 level of the four-level architecture, but also included an M3 meta-metamodel specification called 'Repository Type Information Model' (RTIM).   RTIM, however, was closely aligned to Microsoft's COM (Component Object Model) in much the same way that MOF was originally aligned to CORBA, and was never adopted as part of the open standard by the MDC.

Building on the data warehouse metamodel support in OIM, MDC worked with the OMG to align the specification with the OMG's Common Warehouse Metamodel (CWM), and MDC subsequently merged with the OMG in 2000.   Since then, OIM has disappeared from view, although the CWM documentation still contains a section discussing the specification.   If OIM had survived, it is likely that MOF would have been used in place of the old RTIM specification.   CWM is, of course, built on the foundation of MOF, so in a sense this did happen indirectly though the alignment of OIM data warehousing information models with CWM.

Unlike MOF, RTIM was not defined using UML.    However, in other respects, OIM was heavily orientated towards UML, much in the same way as the various relevant OMG specifications.   In the late 1990's Microsoft made a significant effort to support UML-based model-driven development on their platform. In 1998 they released the Visual Modeler with Visual Basic 5 and Visual Studio 6 (C++).   This was a light-weight version of Rational Rose integrated into the Visual Basic and Visual Studio IDEs (they were still separate at that stage), and Microsoft worked closely with Rational on this technology.   Visual Modeler supported an approximation to round-trip engineering, and was integrated with the Microsoft Repository.   In addition, Microsoft built support for UML into Visio 2000, and again integrated this with their model repository technology.   However, Visio support for the Repository was dropped in Visio 2002.   The Microsoft Meta Data Services SDK was built with dependencies on Rational Rose, and there was some speculation about the possibility of Microsoft purchasing Rational.   Ultimately, however, Rational was acquired by IBM in 2003.  Microsoft subsequently dropped Microsoft Meta Data Services from SQL Server 2005.

In the Visual Studio world, then, we had integrated modelling and model repository tools with strong UML support a decade ago.   OIM's RTIM specification played a similar role to MOF at the M3 level, and the Microsoft Repository was broadly equivalent to modern MOF repositories.   However, Microsoft's technology never found universal or widespread acceptance amongst their customers.   There are many reasons for this.   One crucial consideration was the failure to attract wide-spread support within the ISV community. This was, no doubt, bound up with the emergence of MOF as the dominant metamodelling specification and ever-increasing support for MDA, chiefly in the Java community.    

I believe there is a more prosaic reason why ISVs were slow to adopt the Microsoft Repository.  Implementing metadata models within an M3 repository requires significant effort, especially if you need to define transformations between existing custom metamodels and the repository schema.   Without a compelling business case, many ISVs would not have had the motivation to undertake this task, let alone build the necessary supporting tooling and visualisation to support repository-centric modelling.    Other problems include concerns about run-time performance and scalability issues when navigating the graphs contained within such stores.  An M3-based approach does not necessarily lend itself to exploiting the raw power of a relational database system.   In any event, the COM-centric nature of the Microsoft Repository ruled out any realistic use as a mainstream technology on the .NET platform, despite .NET's COM interoperability features.

Introducing Microsoft’s ‘Oslo’ Model Repository

Since the acquisition of Rational by IBM, and the retirement of the Microsoft Meta Data Services, Microsoft has made little public progress on metamodelling, although one notable exception is its DSL (Domain-Specific Language) toolkit for Visual Studio.   This forms a key part of Microsoft’s strategy for promoting the concept of ‘Software Factories’, which is often characterised as an alternative approach to OMG’s MDA.  However, it is not a repository-based technology.    This general state of affairs has changed, however, with the announcement of Microsoft ‘Oslo’.

The Oslo repository stores model data within a SQL Server database.   It exploits a number of features (e.g., Change Data Capture, Resource Governor) introduced with SQL Server 2008 and therefore does not work with previous versions of SQL Server.   It takes a radically different approach to the Microsoft Repository.   Whereas this old technology was an M3-based repository designed to store models in relation to M2 ‘information models’, the Oslo repository is simply a model store.   User models are represented directly as relational tables that store user object data.   You will look in vain for a predefined data schema that stores abstract metadata definitions at the M2 level or that represents M3 meta-meta models.   This is actually an overstatement.   We will see that Microsoft does intend to provide support for storing M2 metamodels directly within Oslo, but this is something I will discuss later.

Oslo offers much more than the repository.   In particular, MSchema is provided as a textual (rather than graphical) metamodelling language.    Instead of concentrating on a repository data schema designed to capture models in accordance with metamodels, Microsoft provides a formalised definition of mappings from MSchema to T-SQL, and tooling that implements these mappings.   Currently, this definition is a draft document running to almost 40 pages, and is included with the Oslo SDK.   While it is natural for Microsoft to support mappings to T-SQL, other equivalent mappings can be defined.   MSchema, itself, is agnostic with regard to any specific repository technology or platform.

Compare and contrast this with the MOF 2 specification.   As I pointed out earlier, although MOF is generally considered to be an M3 meta-metamodelling language, the OMG explicitly states that it can be used in scenarios that involve traversal over as few as two metalayers.    From this perspective, MOF can be considered to be a metamodelling language, rather like MSchema, that is typically used at the M3 level in four-level metadata architectures to model metamodels.

I’m labouring this point about MOF because it is important not to fall into the trap of thinking that Oslo simply ignores four-level metadata architecture and the role of meta-metamodelling.    It is more correct to suggest that Oslo is agnostic about the number of metalayers required in different scenarios.   This means that Oslo retains the potential to act as a good citizen in the wider world of metamodelling while avoiding some of the practical pitfalls that prevented the earlier Microsoft Repository from becoming a mainstream part of Microsoft’s platform.   Oslo is a spirited attempt to show how meta-modelling can increase its reach beyond larger organisations and appeal to a much wider audience of ISVs, development teams, operations groups, etc.

The MSchema language deliberately takes the form of a data definition language, albeit with a different approach to typing than that found in SQL DDL, and a more explicit separation of 'intension' and 'extension'.   Building MSchema definitions feels natural to many developers and is straightforward.   This is vital if Oslo is to succeed in attracting widespread support.   For so many existing applications, user data is stored within custom data stores.   Those data stores are most often structured to represent user models at the M1 and M0 levels.   By providing a general-purpose metamodelling language that can easily and naturally be used to express the shape of existing data schemas Microsoft is significantly lowering the bar for ISVs and development teams who wish to support and exploit the Oslo repository.

Retrofitting Oslo – An Example

Let’s consider an example of ‘retrofitting’ Oslo to an existing model-driven system by conducting a thought experiment that investigates how this might be done in the Microsoft BizTalk Server world.    BizTalk Server has a high dependency on SQL Server and uses a number of databases at runtime.   Together with the Message Box, the most central of these databases is the BizTalk Management database.   This database stores metadata that defines, describes and configures runtime objects and artefacts such as messaging ports, orchestrations, pipelines, etc.   In essence, it holds model data at the M1 and M0 levels that describe BizTalk applications and the physical runtime environment in great detail.    The data schema implemented within this database directly reflects these runtime entities.   Indeed, a good way of researching and understanding BizTalk Server in depth is to investigate the entities and associations that make up this data schema.

A decision would have to be made about the level of detail captured within the Oslo repository.   At one extreme, the schema of the Management database could be replicated in entirety within the repository, and perhaps even extended to capture additional information (e.g., explicit data about message flows).    In this case, we might reasonably ask about the value of such models.   Unless BizTalk Server was re-written to use the model repository rather than its own database (a prospect which might cause real concern to existing BizTalk users), we could easily find ourselves entering a world of pain in terms of synchronisation of data between two different data stores without a clear understanding of what value this comprehensive data replication truly provides.    At the other end of the spectrum, the repository models might capture significantly reduced models of BizTalk Server applications for very specific purposes.   For example, we might store models in the Oslo repository which we then use to enable ‘software factory’ approaches for one-way code generation.    The models would store considerable less detail than the Management database, and would not need to support two-way synchronisation.

Whichever direction we choose to go in, we would want to ensure that models in the repository bear a strong correspondence and conformance to the models already contained within the Management database.    It would be reasonable to expect a direct mapping from repository model entities to entities in the Management database.   We would want to avoid unnecessary work and re-invention, and ensure that our repository models maintain a high degree of fidelity in describing BizTalk applications and runtime environments.

In this thought exercise, we are capturing models which are specific to a given technology.   We need to be able to specify the metamodel very precisely in order to ensure that our models are valid and well-formed in respect to BizTalk Server.    However, we will probably be less interested, in this scenario, in ensuring that our metamodels conform to some meta-metamodel.   One reason for this is that we probably won’t have a compelling need to exchange BizTalk-specific metadata with other systems and applications.    This could change over time, however.   For example, as BizTalk Server evolves further, future versions may exhibit much closer integration with platform-level technologies such as WCF and WF, or standards such as BPEL4WS and BPMN.   They may be more deeply integrated into platform-level host environments (this is already the case with regard to IIS-based ‘isolated’ hosts in BizTlk Server).   In this case, the ability to exchange and transform metadata on the basis of some meta-metamodel could become an important consideration.   Even here, though, we might wish to our meta-metamodelling to address a specific technology platform.

A major theme in Oslo is the reduction of the bar that ISVs and development teams face when seeking to support rich modelling approaches to software development and runtime configuration.   Oslo is agnostic with regards to the number of metalayers that are required in any given scenario and makes no assumptions with regard to how platform/technology-specific or independent a particular model needs to be.    It avoids forcing conformance to any abstract M3 specification and provides a general-purpose metamodelling language that minimises the learning curve for developers.    To all this, Microsoft adds pre-defined mappings to T-SQL and is building additional tooling for generalised visualisation of models and parser generation tools for creating domain-specific modelling languages.   They also provide many pre-defined models (e.g., for WF workflows) out of the box.

In our BizTalk Server example, the bar is now set very low.     MSchema is a natural choice for defining model specifications whose conformance to the models in the BizTalk management database can be verified, but which can reduce the amount of detail to an appropriate level.    The Oslo tooling can be used to create tables in the repository which correspond directly to the tables in the Management database.   Access to models in the repository can be via any appropriate and familiar data access technology that can connect to SQL Server.    There is no need for developers to engage in a steep learning curve in respect to meta-metamodelling, no need to conform to unfamiliar APIs and no need to inject an unnecessary level of platform independence in the way models are specified.

But surely...

I have no doubt that for some advocates of MOF and MDA, the last paragraph will leave them in a state of disbelief.   Be careful, though, to understand what I am expressing here.    Oslo does not force developers to adopt an MDA-like approach.   This does not imply, however, that an MDA-like, or even an MDA-conformant, approach is invalid within the Oslo world.   Nor, I believe, should anyone casually claim that OMG’s MDA is without merit.    It is true that several influential voices have questioned the universal application of MDA within the broader IT community, sometimes quite forcibly.    Some of these voices have found a home in recent years within Microsoft, and Microsoft is therefore now associated with ‘alternative’ concepts of Software Factory design.   However, we should keep in mind that MDA has built considerable momentum and has gained a significant following.    This indicates that it is addressing real-world needs for its users.  

Many questions remain about how Oslo will handle issues which are emphasised in the OMG world.   These include enterprise-level metadata exchange, standardised APIs for tooling purposes, robust validation of metadata conformance, etc.    It is very early days for Oslo, and Microsoft clearly hasn’t worked out all the answers yet.   It is worth noting a few pertinent facts, however, which indicate the direction Microsoft is taking.

OMG Membership and Commitment to UML and XMI

A couple of months ago, Microsoft announced that it had formally joined the OMG.    This announcement should absolutely be seen in the context of Oslo, and is, I believe, very welcome (and long overdue) news.    Of course, we can expect the usual tedious reactions from those who see conspiracy in all that Microsoft does.   However, Microsoft will operate within the OMG on exactly the same basis as any other member.   Membership will certainly allow them to influence the future of various specifications, but they will not be able to undermine the OMG world or dominate the standards process.   Why would they wish to do so?    Microsoft has a strong history of UML adoption, albeit with little momentum in recent years.   Perhaps more importantly, they share a common overall goal with the OMG – namely to change the IT world for the better by figuring out how to exploit modelling at every stage of the development and application lifecycles, and to support modelling across a wide spectrum of activity.   True, they will probably not be strong advocates of MDA.   However, the lessons they learn from Oslo over the next few years, together with their efforts in the area of software factories and domain-specific languages, will be fed directly back to the wider modelling community within an open forum, and that community can, in turn, influence Microsoft’s thinking as Oslo evolves and matures.   This is surely of benefit to us all.

Alongside its new membership, Microsoft has publically announced two important commitments.   The first is to undertake a renewed effort to support UML within its tools and technologies, and specifically in relation to Oslo.   The details of this are not yet in the public domain, but Bill Gates himself spelled out the strategy in his last keynote speech before leaving full-time employment at Microsoft.

The second commitment is to support XMI as a standard method of metadata interchange within Oslo.   XMI is strongly associated with MOF, and is a core enabling specification in the OMG family.    This one announcement alone shows that Microsoft does not view Oslo as some kind of parallel universe that stands in opposition to the OMG world.   Again, we must wait for the details of exactly what will be provided.   However, interoperability and interchange between Oslo and existing repositories and modelling tools looks set to be a feature of the Microsoft platform.

Reflection Support

One of the motivations for MOF is to support reflective approaches to discovery and manipulation of metadata.    It is difficult to see how this can be achieved in the Oslo world without a standardised way of storing metamodel information within the repository.   This has not escaped Microsoft’s attention.    The CTP version of the repository provided at the PDC in October contains a number of out-of-the-box model schemas which are expected to form part of the Oslo offering when it ships.   Amongst these is Language.Schema which, together with Repository catalogue, ‘folders’, globalisation support and various other schemas, constitute a ‘core’ set of pre-defined Oslo models.   Microsoft’s documentation for Language.Schema is currently incomplete, but the introduction states that “... the Language.Schema model schema...contains data types, relationships, and constraints that together represent the stored concepts of the [MSchema language] itself, allowing for introspection of [MSchemas] used to describe other problem domains.”   In other words, Languge.Schema is used to model Microsoft’s MSchema metamodelling language.

Like any other schema, Language.Schema is, itself, defined using the MSchema language.    In this case, then, MSchema is being used as a meta-metamodelling language.    So, after all that we have discussed above, it turns out that Oslo will (probably) provide explicit support for the M3 layer and the capture of M2 metamodels within the repository.   Of course, at this early stage, there are still many questions left unanswered.   I’m not aware of any tooling in the current CTP to populate the Language.Schema tables, and have no idea how widely Microsoft intends to use this feature.   Will they automatically capture metamodels by default, or will this be a purely optional feature?   Will Microsoft provide functionality to perform introspection or will they leave that to ISVs and the .NET community?   Who knows?   Probably not even Microsoft at this stage.   The point to grasp here is that Oslo is perfectly capable of supporting traversal over multiple metalayers.    This naturally leads to consideration of how MOF-based approaches, and MDA itself, might be supported within the Oslo framework.   I can see no practical or technical barrier to capturing MOF-compliant metamodels within Oslo.   More interesting questions may surround the feasibility of translation directly between MOF and MSchema, and how useful such translation would prove in the Oslo world.    Such questions will have to wait until Microsoft has done a lot more work on developing this emerging technology.

BPMN

One of the recurring questions asked in the wake of Microsoft’s announcement of membership of the OMG is about their intentions in regard to Business Process Modelling Notation (BPMN).    BPMN is a standardised specification maintained by the OMG.   It is designed to be used as a modelling language in ways not dissimilar to the intended role of the Visio-based ‘Orchestration Designer for Business Analysts’ (ODBA) that targets BizTalk Server.    BPMN aims to provide an intuitive approach to modelling business processes that supports collaboration between both technical and business stakeholders.    Like ODBA, it is intended for use in generating executable process definitions and provides mappings to BPEL4WS.   Another interesting aspect of BPMN is that, since taking control of the specification, the OMG has retrofitted a MOF-compliant metamodel (Business Process Definition Metamodel), bringing BPMN in line with other OMG modelling standards.   BPDM is interesting from a BizTalk perspective because it actively seeks to exploit the notions of orchestration and choreography as two complementary viewpoints of the same thing – an approach which, as a BizTalk developer, is dear to my own heart.

The answer to the question is ‘yes’.    Microsoft does intend to support BPMN in the Oslo world.   To this end they have already created a preliminary BPMN schema which they implement within the current CTP version of the Oslo repository and which is documented in the SDK.     Obviously we will have to wait to see what tooling they plan to provide, beyond Quadrant, and how BPMN will be supported in BizTalk Server and WF.   Microsoft already offers support for BPEL in both these technologies, so BPMN support will be a natural extension.

Open Specification Promise

Microsoft plans to release the ‘M’ language specification (MGraph, MSchema and MGrammar) under their Open Specification Promise (OSP).   The OSP, launched in 2006, follows the lead taken by Sun in their 2005 ‘OpenDocument Patent Statement’.   IBM published a very similar ‘Interoperability Specifications Pledge’ in 2007 having previously made a more informal public promise all the way back in 2004.    The OSP is a legally-binding and irrevocable covenant that extends automatically to anyone who wishes to implement any of the specifications identified by the OSP.   Microsoft promises that it will not sue for patent infringement in any circumstances, with the sole exception of situations where the user is involved in a patent infringement lawsuit against Microsoft concerning the same specifications.

The OSP, and other similar covenants, are principally designed to remove barriers to the open use of key specifications.   There is a healthy debate about how compatible these covenants are with the GPL, but that is another matter.   The point, here, is that Microsoft is taking an industry-standard route to ensuring that their ‘M’ specification can be freely and widely implemented.   They state on their website that they currently have no plans to seek standardisation of the ‘M’ specification.

Conclusions

I’ve attempted, in this article, to explore the Oslo repository from a wider industry perspective informed chiefly by the OMG standards.    My plea is that we avoid thinking of Oslo as a rival to MOF-compliant approaches, including MDA.    The Oslo vision is about building pragmatic support for modelling practices into a particular platform, and to do so in a way that sets the entry bar as low as reasonably possible for ISVs and development teams.   Almost by definition, therefore, Oslo cannot afford to be constituted as a rival to a widely supported set of industry modelling standards.   Microsoft must, instead, ensure that Oslo remains ruthlessly agnostic about such matters so that it can be used to support any relevant standards and specifications as and where necessary, and also appeal to those who’s modelling needs are not conformant to specific standards.

We can reasonably speculate that Microsoft will probably use Oslo to extend their offerings around the notion of Software Factories, and will certainly use it to revive momentum in regard to their support for UML.   They are less likely to provide MDA-based support, despite their membership of the OMG.    However, for Oslo to be a success, it will need to attract broad and active participation from a wide community of ISVs.    For some of those ISVs, the challenge will be to build MOF-compliant MDA tooling alongside the Oslo repository, and to work out how to map appropriately between MOF and MSchema.   For other ISVs, MOF and MDA will, I suspect, continue to have little direct relevance in the foreseeable future.

Ultimately, the measure of success for Oslo will be the extent to which, say five years after its launch, it underpins the use and exploitation of models on the Microsoft platform, and the value it adds through centralisation, management, composition and discoverability of those models.   We use models everywhere today.    For Oslo to be deemed a success, it will need to become a foundation and framework of choice for a broad spectrum of ISVs and development teams when handling those models.

 

The OMG is perhaps best known for managing the UML (Unified Modelling Language) specification.   They relate UML and other specifications directly to the four-level metamodel architecture.   UML defines a number of diagram types such as use case, collaboration, sequence and class diagrams.   Each of these can be considered a type of graphical model.    Individual diagrams reside, therefore, at the M1 level.   System data and behaviour that conforms to these models resides at the M0 level.    For example, consider a class diagram that defines a set of classes and associations for some application.     Developers may implement programmatic classes that conform to these models (they transform the class diagram into a different type of model).   The objects that are instantiated ar runtime reside at M0 while the classes reside at M1.

·         Representation (Mapping):    A model represents some ‘original’ thing.    Attributes of the original are mapped onto attributes of the model.    In GMT, the original may, itself, be a model.

posted on Monday, January 5, 2009 5:52 PM

Feedback

# re: Oslo and the OMG 1/11/2009 9:54 PM Charles Young
Thanks to Keith Short for his kind words on his blog http://blogs.msdn.com/keith_short/archive/2009/01/09/oslo-makes-the-top-ten.aspx. Keith was involved in development of the original Microsoft Repository (he came from Texas Instruments who worked jointly on the repository with Microsoft back in the '90s), so I was amused by his comment that I have missed some of the ‘critical shortcomings’ of that old technology stack. I've had occasion a few times over the years to mention to people my experience with the Microsoft Repository, circa 1998. It amounted to opening up box with some anticipation, taking a good look at what was on offer, and then firmly closing the box again, vowing to myself never to touch the technology!!
I definitely do not react the same way when I lift the lid on Oslo :-)


# re: Oslo and the OMG 4/16/2009 2:32 AM Ben Gillis
My mantra has always been to remain technically objective, these questions are not anti-msft:

> The Oslo vision is about building pragmatic support for [modeling] practices into a particular platform, and to do so in a way that sets the entry bar as low as reasonably possible for ISVs and development teams.

What "entry bar"? I can see Microsoft as lowering the bar for skills required. But, how else? Open source alternatives are about as low as the bar gets, except the skills required. Microsoft will definitely enable non-techies in ways the open source alternatives can't. (But, MetaCase is a rather good low skills entry bar. So, why not work with them)?


> Almost by definition, therefore, Oslo cannot afford to be constituted as a rival to a widely supported set of industry modelling standards.
I totally don't get how you jump to this conclusion. By its very definition, ground up without embracing open source modeling standards, it is exactly a rival. It appears all the open source types would definitely see it as a rival. Sure, the UML, MOF, et. al. have their problems.

# re: Oslo and the OMG 4/16/2009 12:37 PM Charles Young
Thanks Ben.

From my perspective, the main issues I had in mind with respect to 'entry bars' are not to do with programming skills or tools. Rather, they are about a general lack of conceptual understanding amongst developers and architects about metamodel abstraction, its purpose, role and benefits, and the natural resistance that people have to catering for multiple layers of abstraction when they can't see the point.

Imagine an ISV which has spent years developing and evolving some application. At runtime, their application loads data from a database, uses it to instantiate and initialise a set of corresponding run-time objects which then execute the application's logic. We might reasonably say that the data represents models at M1, and that the run-time objects exist at M0. Let's say that the dev team recognises that their application already captures and uses models and, while planning a new version of their application, start thinking about how they might exploit 'Oslo'. They work out that there is some benefit to them in migrating some or all of their data to a shared repository in order to exploit tools like 'Quadrant' and to integrate modelling with other applications in their, and/or others' technology stack(s).

Now, imagine what would probably happen if they opened the 'Oslo' repository and discovered that, in order to migrate things over to the repository they must first define and implement a whole lot of abstract metamodel stuff at M2 based on an even higher level of abstraction defined at M3. Imagine that the repository was structured to enforce this and implemented an abstract entity schema that has nothing specifically to do with their application, but which they must comprehend, navigate and populate in order to store their existing models. This is exactly what ISVs were faced with in the Microsoft world many years ago when MS introduced the Microsoft Repository. I remember, myself, opening up the databases, spending hours looking at the schema, reading the help files, etc, etc, and finally giving up. I didn't understand what I was looking at and I couldn't see the point. After several years experience under my belt, I now would. However, I hope you see my point. This is the kind of 'entry bar' I chiefly had in mind.

I totally get the general point about open source but a) that's not really where I was coming from and b) I really don't want to get into the whole 'why doesn't MS embrace open source' debate (to be fair, they have made some positive movement in this direction in recent years). Hopefully, the Oslo stuff will be just 'there in the platform', so there won't be a cost barrier for people who already invest in the MS platform (a weak argument, I admit). I do think, though, that there are some other aspects of Oslo which are to do with lowering the 'entry bar' in terms of skills, learning curves and development effort. This, again, is where I was coming from. So, for example, while there is nothing new about lexer/parser technology (far from it), and there are plenty of open source tools out there, Microsoft is demonstrating a degree of innovation in terms of the fine print. MGrammar provides an interesting take on the idea of 'labelled' grammars which, to the best of my knowledge, is not really reflected by other mainstream grammar parsers. This is important. The focus on the production of MGraph is all about reducing the amount of work required in building execution environments for DSLs, and hopefully, as Oslo evolves, we will see more exploitation of this aspect of the technology. MSchema, also, has been designed very much with the idea of providing a 'natural' language for metamodelling.

.../continued

# re: Oslo and the OMG 4/16/2009 12:38 PM Charles Young
/continued...

With regards to your point about standards rivalry, I don't agree. Historically, the 'rift' between Microsoft and the OMG arose because of the perception of head-on competition between CORBA and COM. It seems a little strange to relate this to modelling, but MOF, of course, was originally all about CORBA-based reflection on metadata, and Microsoft had their own COM-based equivalent. That has all changed, and we live in a very different era. My point is that, for example, an ISV who has invested heavily in creation of MOF 2-compliant repository-based modelling tools, and who wishes to exploit the opportunities afforded to them by 'Oslo' is not faced with some alternative universe that requires them to adopt and implement an entirely different, but fundamentally equivalent, set of rival standards and specifications. 'Oslo' is perfectly capable of supporting MOF compliance if that is what is needed. It doesn’t force the issue, though. Microsoft themselves plan to go a long way down the MOF-compliance route by providing fulsome UML and XMI support as part of the offering, and have joined the OMG in relation to their ‘Oslo’ effort. My take on this is that, while MOF, UML, MDA etc., etc., may well have perceived problems, they are, nevertheless, the most widely accepted and used set of specifications out there, and have, I think, more than proved their worth in many contexts. Some specs have a wider, more universal application than others. However, Microsoft’s platform would benefit from being able to plug directly into all that is on offer in that world. The last thing we need is yet another Microsoft mirror-universe. I don't see that 'Oslo' constitutes such a universe.

By the way, it would not have occurred to me to regard you comments as anti-MSFT in any way. Thanks for the feedback.

# re: Oslo and the OMG 4/19/2009 6:25 PM Pete Rivett
Firstly, compliments on a great explanation of meta-levels - I will refer others to it! And an extremely comprehensive (and mostly accurate) survey of both past and current activities.

However one area you got it wrong (and I was one of the authors of MOF) was with respect to the code: code would be at M1 - the same layer as the class model. Since the class model can be seen as a representation of the code (indeed some tooling allows you to directly execute UML models). M0 would be the 'instance of' the class model/program - for example the classes residing in the memory space of the running program.

You're also somewhat wrong to say 'MOF was originally strongly associated with CORBA'. The only reason the CORBA binding was included in MOF was OMG's rule at the time that any specification had to include one! Believe it or not UML also had a CORBA binding for the same reason (which was auto-generated from its MOF metamodel) - would you also say that 'UML was strongly associated with CORBA'?.

Another area where I'd have to disagree is "I think it is fair to suggest that MOF, MDA and model repository technologies have yet to generate a significant following in the wider ecosystem of software development environments. " By far the most popular software development environment is Eclipse, and MOF, in the shape of its implementation in the Eclipse Modeling Framework (EMF) is at the heart of it. Although MOF can be used for the sort of enterprise repository you describe (indeed my company produces one), EMF provides a backbone and a bunch of reusable components for implementing any sort of tool in a model-driven fashion, not just 'modeling' tools - since just by describing the structures to be managed (which could be via a UML-style metamodel but also XML Schema or Java) - you get a lot of the basics for your tool generated for free, including integration into the Eclipse enviornment. BTW Eclipse also has projects building on EMF that implement most of the OMG modeling standards.

Finally, OMG is on the verge of approving BPMN 2 which will include a metamodel more closely aligned to the notation than the more abstract BPDM.

# re: Oslo and the OMG 4/20/2009 1:56 AM Charles Young
Thanks, Pete. Your comment arrived while I was sitting with my 14 yr old daughter in A&E (ER) at my local hospital, she having fallen off her bike. Luckily just some muscular damage, and no bones broken. She'll be OK in a couple of days. Your comment gave me something to ponder while we waited to be seen.

I really appreciate the feedback, and have spent a little time this evening thinking through my response. So, taking your points in turn. First, there is the issue of M0. This is an interesting one. I don’t believe there is, or could be, one unanimous perspective on which layer specific artefacts such as source code, compiled code or runtime objects exist or, indeed, the entities in the real world that those objects and classes represent. Give the specific example I use, I can understand why you disagree with the sentence “This code resides at M0 while the class diagram resides at M1.”, and in hindsight, it would probably be better to re-word this. However, if you read the next paragraph, you can see that I attempt (without getting bogged down in a very esoteric argument) to directly address the issue you raise, though in a very lightweight fashion and possibly not reaching a conclusion you will agree with. I wrote “For example, if an instance of a programmatic class is created at runtime, does this object exist at M0 or beyond? Should we consider real-world ‘things’ to be the objects we instantiate at run-time or the entities in the real world that these object represent? There is no one definitive answer to such questions.”

My own perspective is that four-level metamodel architecture is itself, like any architectural pattern, an abstraction, and therefore does not fully specify the semantics associated with the ‘thing’ we are modelling or the models, meta-models and meta-metamodels associated with that ‘thing’. If that is correct, we have to allow the possibility that the same architectural concept can have more than one valid concrete manifestation. The MOF 2 specification states that “key modeling concepts [in n-layered metamodel architecture] are Classifier and Instance or Class and Object. From that perspective, it is natural to adopt the position you state – if a model at M1 represents a class, it is objects instantiated from that class that reside at M0. You relate this to executable models, and clearly this perspective is key to fostering such executability. However, I believe it would be a mistake to interpret this statement in the MOF specification in too rigid a fashion. Models are often not executable. The ‘thing’ we are modelling may not be a set of runtime objects. Often it may be a matter of genuine debate as to whether we are traversing meta-model layers or simply transforming one model into another. Sometimes the real world is a little too big and messy to fit neatly into a clean architectural abstraction.

As I say, I think, on reflection, that it would be wise to reword the sentence I quoted above. I gave a specific example, and with respect to that example, a mainstream approach would be to consider runtime objects as residing at M0, especially if we are pursuing executability of models. I have therefore decided to make that change.

.../continued

# re: Oslo and the OMG 4/20/2009 1:57 AM Charles Young
.../continued

With regard to CORBA, the main point I really wanted to communicate concerns ancient politics. There was a time (12 years ago or more) when Microsoft was busy building its own alternative world to MOF, and a major driving force for this was, I believe, the CORBA vs. COM 'battle' of yesteryear. That battle is well and truly consigned to the history books. The MOF 2 specification talks about lessons learned from MOF 1 regarding "orthogonality...of models and the services...applied to models" and states that "MOF was overly influenced and constrained by the assumed lifecycle semantics of CORBA based metadata repositories." The same (and worse) could be said about RTIM and the old Microsoft Repository in regard to COM. I note, however, that the MOF 2 specification also states, in regard to platform independence, that "the experience gained in the definition of the MOF, XMI, and JMI specifications, which already define many technology mappings from and to the MOF model, has been a solid foundation for this effort". So, I accept that I certainly exaggerated in a previous comment to the article where I said that "'MOF, of course, was originally all about CORBA-based reflection on metadata". That is clearly overstated to the point of inaccuracy, and I therefore take that back. As far as the article is concerned, I was a little more circumspect, and simply said that "MOF was originally strongly associated with CORBA" and that "RTIM...was closely aligned to Microsoft's COM (Component Object Model) in much the same way that MOF was originally aligned to CORBA". In reality RTIM's 'alignment' to COM was stronger and more constraining. However, broadly speaking, I think these are not unfair comments, so I will let them stand.

As to the issue re. Eclipse, I had to laugh. I do live on the dark side after all. Eclipse...what's that??? I thought everyone used Visual Studio ;-)

Seriously, though the point you make is entirely valid. I'll have to ask you to accept that I had repositories firmly in mind when I wrote that, and also that, although I am not a regular Eclipse user, I am not totally ignorant of the role of EMF. Interestingly, I was mildly taken to task by a member of the 'Oslo' team a couple of days ago after publishing a diagram that is too 'repository-centric' in terms of what they are planning (I had already pointed this problem out myself in regard to that diagram). In some of the very early previews, 18 months ago now, the repository featured at the absolute centre of the 'Oslo' world, but since then, Microsoft's thinking has evolved, and by the time they publically announced 'Oslo' last year, it had shaped up to be as much about tooling for 'model-driven applications' and DSLs as about repository-based technology. Maybe more so. My wording in the article is bad, and I have therefore decided to amend the sentence to make it more acceptable.

Thanks for the point about BPMN 2. I have a growing suspicion that BPMN will prove to be ‘all we need’ in terms of modelling and exchanging business processes, and that we may even see significant headway made regarding transformation of BPMN into executable models. I could be wrong, but BPMN certainly seems to have real momentum behind it.

All in all, I see broad convergence between different communities on many aspects of modelling. I am hopeful that 'Oslo' will represent a valuable contribution which will be accepted in good spirit by a wider community than Microsoft's traditional constituency. We will have to wait and see, of course. Thanks for your comments. I hope you won't mind me making a couple of amendments to the original article, and am grateful for the help in improving it.



# re: Oslo and the OMG 4/23/2009 8:53 PM Ben Gillis
Hi Charles,

thanks for the reply.

> 'entry bar'
> there are some other aspects of Oslo which are to do with lowering the 'entry bar' in terms of skills, learning curves and development effort.

Most definitely. It's been my shop's niche for 10 years to build deliverables with DSL-based automation. It was a good niche because mainstream
modeling had an uncomfortable barrier-to-entry wrt to skills, time, and concepts issues pretty much what you described. We kept things zero-to-transparent and very simple, e.g. http://bengillis.wordpress.com/2009/04/18/a-variety-of-dsls-in-real-world-examples/

I think Oslo will go over quite well with this, because the approach was so appealing with every shop we worked with. (It actually won us contracts in many cases to come in with this approach. I thought it would've been mainstream as much as 10 years ago. Surprised it's taken this long).





# re: Oslo and the OMG 4/23/2009 8:54 PM Ben Gillis
/...continued/

> there are plenty of open source tools out there

Yeah, but I'm pondering they'll need to raise the bar in response to Oslo. And, not just with the 'entry bar' issues, but scope of coverage, e.g...
One area that's quite effective is DSL'ing the *functional* realm, i.e. storyboarding, requirements and use cases. With these in the repository alongside technical DSL input, it's powerful.

I'm looking around for openArchitectureWare/XText equivalents, but haven't found any. If they don't exist, they'll need to IMHO. Microsoft's Team System and 'architecture explorer' should eventually associate functional with technical via modeling. And, that's a huge advantage over technical-only modeling. One example, "automated documentation" or "automated analysis" (for lack of a better term): http://bengillis.wordpress.com/2009/04/14/where-is-microsoft-oslo-going/

I've built a couple of these in commercial space. It's much harder w/o model data, and even more difficult w/o patterned architecture. I'm not going to adapt what I have, b/c I'd expect Microsoft to absorb my functionality with out-of-the-box in too short a product lifecycle for me to be interested. But, I've used this approach to make sense out very complex apps and I see Oslo enabling this so that's it's a de facto standard to autodoc/auto-analyze like never before.

btw, there's MetaCase. And, there are a lot of niche tools. I'm most familiar with process control types, e.g. oil refineries, manufacturing, etc. where you can configure mock-up's of the plant/refinery graphically with plug-in/configurable modules and some are repository-driven. These are much stronger than any open source modeling I've seen (but, I may be missing some, ???), and I'd expect Oslo will have some capabilities of these tools, too.





# re: Oslo and the OMG 4/23/2009 8:55 PM Ben Gillis
/...continued /

> 'labelled' grammars which, to the best of my knowledge, is not really reflected by other mainstream grammar parsers
What about ANTLR? See ANTLRWorks, too. I use it, including backed with .Net generators and repository. It's a very good tool. Oslo will have a more sophisticated suite of backend tools than ANTLRWorks, though. This is another area that has to raise the bar in response to Oslo IMHO.

(btw, your comment elsewhere has anybody noticed LBNF? Yes. I asked via Oslo wiki why the Oslo specs couldn't have been ABNF'd (or similar). That way, prosumers can automate consumption. The specs currently require manual cognition, in the spirit of modeling, productivity, etc. the specs should be released in a fashion that enables automated consumption ;-).


> OMG, UML, et. al.
We've had to support UML through the years. We relied heavily on sequence diagrams coupled with DSL approaches to get as much behavior as possible spec'd in an "automated spec" way. The UML world should have expanded "upstream" in the SDLC to functional modeling by now. I've seen far more UML-based tools on the shelf than in actual practice, too. In the shops I serviced, the UML was held back due to barrier-to-entry per skills, it's technical-realm only, and too much training or side-tracking from the main goal for most clients we ran into. (I'm well aware of pro-UML arguments against that. But, I think Microsoft picked up on this per the 'entry bar' issues we've discussed and is going to cover roles and skills sets not covered under typical products I've seen in this space.




# re: Oslo and the OMG 4/23/2009 8:58 PM Charles Young
Thanks Ben. Will digest over the weekend, due to pressure of work.

Post A Comment
Title:
Name:
Email:
Comment:
Verification: