1 / 12

MOF-Compliant Modeling of Middleware

MOF-Compliant Modeling of Middleware. Jeff Parsons & Matt Emerson ISIS Vanderbilt University Nashville, TN. What’s MOF?. OMG defines the Meta Object Facility (MOF) as An abstract language A framework for technology-neutral metamodels Intended uses Software development

gitano
Download Presentation

MOF-Compliant Modeling of Middleware

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. MOF-Compliant Modeling of Middleware Jeff Parsons & Matt Emerson ISIS Vanderbilt University Nashville, TN

  2. What’s MOF? • OMG defines the Meta Object Facility (MOF) as • An abstract language • A framework for technology-neutral metamodels • Intended uses • Software development • Type management (repository) • Information management • Data warehouse management

  3. Why MOF-Compliant? • Platform-independent • No tie to one vendor • Easier vendor migration. • Model storage • Model reuse • Import/export with other modeling tools

  4. MOF Historical Context • Before MOF 1.4: • Modeling language for distributed middleware systems • CORBA-centric • Could represent all datatypes from CORBA 2.1 onward • Included TypeCode and Any to model datatypes and values. • IDL mapping for the automatic generation of program artifacts. • MOF 1.4: • OMG standard metamodeling language • Not CORBA-centric • Includes minimal set of technology neutral modeling concepts. • No direct analogues to CCM concepts. • IDL mapping now strictly to manage MOF (meta-)models.

  5. Canonical Layers of Abstraction meta-metamodel (self-descriptive) M3 layer metamodel M2 layer model M1 layer implementation (source code, data, simulation) M0 layer

  6. GME-MOF: A GME Metamodeling Environment • Provided GME-MOF metamodel written using MetaGME. • Using GME-MOF, write models that represent some domain. • Using translator, transform domain-specific models (DSMs) into (MOF-compliant) domain-specific modeling languages (DSMLs). • Using DSMLs, write models that represent systems in the domain. Future Work: • XMI translation tools • MOF counterpart to MetaGME M3 MetaGME MOF DSML DSML GME-MOF M2 Translator DSM DSM M1 DSM DSM pre-existing generated by Matt Emerson hand-written

  7. Interface Definition Modeling Language (IDML) • Platform independent, models components and all associated types. • Part of Platform Independent Component Modeling Language (PICML). • PICML is part of the CoSMIC tool suite.

  8. IDL Importer • Modular TAO IDL compiler. • Create pluggable back end. • Existing front end validates/parses IDL files. • New back end generates project in XML format. • Import into GME - • For further development. • For translation to non-CORBA middleware. IDL IDL IDL Modified IDL Compiler XML Import into GME Generate app. code Modify Model Java (EJB)

  9. Future Work First step: prototype using GME Next step: decoupling from GME MOF Abstract Mapping (IDL) metaGME meta-I inherit MOF->IDL Repository IDL implement Modeling Environment GME Model Repository I Modeling Environment MOF Model Repository I I I I I I IDL IDL Java ….. IDL Java interpreter / translator to be written exists generated I IDML to date

  10. Extra Slides

  11. Approach to Modeling Middleware (1 of 2) Context: Selecting metamodel elements. Problem: What will be best translatable to (platform-specific) models and to generated code? Forces: • Using intersection (only common features) - • Restricts developers. • Excludes many existing applications. middleware x middleware y model A E B D C B D A E x application y application

  12. Approach to Modeling Middleware (2 of 2) Solution: Use union of common middleware features. • CORBA Component Model (CCM) subsumes Enterprise Java Beans (EJB). • Need more complicated mapping for translation to EJB. CCM EJB Model CCM Interface Definition Language (IDL) EJB Classes and Deployment Descriptor

More Related