mof-compliant modeling of middleware

4th Workshop for TAO and CIAO

July 16, 2004

MOF-Compliant Modeling of Middleware

Jeff Parsons & Matt Emerson

ISISVanderbilt University

Nashville, TN

2

Jeff Parsons & Matt Emerson MOF-Compliant Modeling of Middleware

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

namedtype index

anonymoustypes

namedtypes

root

index entry "Engine"

"Carburetor"

"n_barrels"

index entry

index entry

"sequences"

"count" "00000000" "00000001" . . .

"bound""def_kind" "name"

"bound""def_kind" "name"

"element_path"

"element_path"

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)

metamodel

model

implementation

(source code, data, simulation)

M3 layer

M2 layer

M1 layer

M0 layer

6


GME-MOF: A GME Metamodeling Environment1. Provided GME-MOF metamodel

written using MetaGME.

2. Using GME-MOF, write models that represent some domain.

3. Using translator, transform domain-specific models (DSMs) into (MOF-compliant) domain-specific modeling languages (DSMLs).

4. Using DSMLs, write models that represent systems in the domain.

Future Work:• XMI translation tools• MOF counterpart to MetaGME

M3

M2

M1

MetaGME

GME-MOF

DSM

DSML

Translator

DSMDSM

DSM

pre-existing

by Matt Emerson hand-written

generated

DSML

MOF

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

XML

Java (EJB)

Modified IDL Compiler

Import into GME

Generate app. codeModify Model

IDL IDL

9


Future Work

metaGME

Modeling Environment

IDL

GME Model Repository

meta-I

I

to be written exists generated

Modeling Environment

IDL Java

MOF Model Repository

…..

I I

I

I interpreter / translator

IDL

First step: prototype

using GME

Next step: decoupling from GME

MOF Abstract Mapping (IDL)

MOF->IDL Repository IDL

inherit

implement

II

Java

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.

B DC

A E

middleware x

model

BA

x application

DE

y application

middleware y

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.

CCMEJB

Model

CCM Interface Definition Language

(IDL)

EJB Classes and

Deployment Descriptor

mof-compliant modeling of middleware

Documents