Hui Songsonghui06@sei.pku.edu.cn

Generating Adapters for Reflecting

System

States as MOF-Compliant Models

2/

Model-based runtime system Model-based runtime system managementmanagement• Runtime system management

– Environments and requirements keep changing– Calls for efficient way to monitor and control

• Model-driven engineering• Model-based runtime management

– Regard the system states as models• Apply the existing model-driven approach and

techs• Integrate with the whole development process• Richer semantic base

– Hot for a long time• Architecture-based management• Models at runtime (a series of workshop)

3/

A big barrier to model-based A big barrier to model-based managementmanagement• A gap between model-

based approach and state processing– Model vs. Raw state

• Go deeper?– Standard MOF reflection

interface vs. ad hoc management API

• Adapters– MoDisco project– ICSE 08– …– Manual

Model-driven apps and techs

State

Mgmt API

Adapter

4/

SM@RT ApproachSM@RT Approach

• Automatically generating adapters– Wrapping the ad hoc management APIs into

standard MOF reflection interface– Enabling existing tools (like OCL engine) to deal

with runtime states in the same way as processing standard MOF-compliant models

• “Supporting Models at Run-Time”

5/

OverviewOverview

6/

ContributionContribution

• SM@RT Language– Supporting specifying the type of system state as

a MOF compliant meta-model– Supporting specifying the code-level invocation

method as a high-level “access model”

• SM@RT generator– Automatically generate the adapters

7/

A running exampleA running example

OCL engine

JEE

Adapter

context Server define: self.jdbcDataSource ->sum(e|e.currentOpened);

Server, EJBs, Data Sources, current_opened_connection…

8/

Structure of the paperStructure of the paper

• Specifying system states and management API

• Generating adapters• Experiment• SM@RT in practice• Related work

9/

SM@RT LanguageSM@RT Language

• Extended from MOF Model– MOF Model: The M3 layer modeling language, also

known as meta-meta-model

• State type -> state meta-model• Invocation method -> access model• Relation between the above two?

– The syntax rule and semantic action in Yacc

JEEServer, EJBs, Data Sources, current_opened_connection…

10/

Specifying state typeSpecifying state type

• Directly using MOF Model

11/

For JEEFor JEE

12/

Specifying invocation methodSpecifying invocation method

• Extend MOF Model• Decorate the meta-model with pieces of code

for invoking the management API

13/

For JMX API of JEE systemsFor JMX API of JEE systems

14/

Properties of SM@RT languageProperties of SM@RT language

• MOF compliant• Code based

– Accurate and direct– Close to API study (from sample code)– Directly generate code

• Syntax centric (syntax directive)– Well structured

• Supporting code reuse– Code composition– Flexible scope

Similar organization as an API document or tutorial!

15/

SM@RT generatorSM@RT generator

• Generating adapters from the specification– Enabling programs to manipulate system states in

the same way as processing a standard model

• Working principle in abstract:– Maintain an image for each managed element– Images conform to MOF reflection interface– Adapters forward the standard invocation on such

images into the proper invocation on management API

16/

ExampleExample

17/

How it worksHow it works

18/

19/

Technical discussionTechnical discussion

• Basic principle:– an adapter maintains a unique image for each of

the managed element

• What “maintaining” means:– The model grows from zero– System state may change itself– External tools may change the images– Synchronization!

• Discussion about synchronization (skip here)– Attribute– Association– Aggregation

20/

Implementation of the generatorImplementation of the generator

• Two parts– Runtime library

• Common classes• 3000 LOC Java

– Generation engine• Upon Eclipse EMF code generator• 1700 LOC JET code• 1000 LOC Java code for utility

• Generated adapters– Eclipse plug-ins

21/

ExperimentExperiment

• Discussion:– Reduce developers’ workload (besides the benefit

of declarative development)– Mature API needs less manual work– Currently the generated code is a little verbose,

but it is able to be improved

22/

SM@RT in practiceSM@RT in practice

23/

SM@RT in practiceSM@RT in practice

24/

Related workRelated work

• Model-based runtime management– Runtime architecture– Models at runtime– France’s survey on MDE

• Manually constructed adapters– Sicard-ICSE-08: states->Fractal models– MoDisco project: states->MOF compliant models

• Automatic generation of– Data processing tools– Framework completion applications

• Code generation for runtime management

25/

ConclusionConclusion

Thank you!Thank you!