Hui Song songhui06@sei.pku

1. Adapting System States as Standard Models Hui Song songhui06@sei.pku.edu.cn

2. Model-based runtime system management • Runtime system management • Fix errors • Adapt to environment changes • Satisfy new user requirements • 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 management Model-driven apps and techs • A gap between model-driven tools and state processing • Model vs. Raw state • Go deeper? • Standard MOF reflection interface vs. ad hoc management API • Adapters • MoDisco project • ICSE 08 • … • Manual Adapter Management API State

4. SM@RT Approach • “Supporting Models @ Run-Time” • 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 models compliant with MOF

5. Overview

6. Contribution • 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 example context Server define: self.jdbcDataSource ->sum(e|e.currentOpened); OCL engine Adapter JEE Server, EJBs, Data Sources, current_opened_connection…

8. SM@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

9. Specifying state type • Directly using MOF Model

10. For JEE

11. Specifying invocation method • Extend MOF Model • Decorate the meta-model with pieces of code for invoking the management API

12. For JMX API of JEE systems

13. Properties of this language • Code based • Accurate and direct • Close to API study (code) • Directly generation code • Syntax centric (syntax directive) • Well structured • Supporting code reuse • Save effort

14. SM@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 a Java object (image) for each managed element • Images conforms to MOF reflection interface • Adapters forward the standard invocation on such images into the proper invocation on management API

15. Example

16. How it works

17. Technical discussion • Correlation between images and management elements • Attributes • Associations • Aggregation • The image pool

18. Implementation 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

19. Evaluation (experiment)

20. SM@RT in practice

21. Snapshots