1 / 26

Hui Song songhui06@sei.pku

Generating Adapters for Reflecting System States as MOF-Compliant Models. Hui Song songhui06@sei.pku.edu.cn. Model-based runtime system management. Runtime system management Environments and requirements keep changing Calls for efficient way to monitor and control Model-driven engineering

gwen
Download Presentation

Hui Song songhui06@sei.pku

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. Generating Adapters for Reflecting System States as MOF-Compliant Models Hui Song songhui06@sei.pku.edu.cn

  2. Model-based runtime system management • 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 management Model-driven apps and techs • 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 Adapter Mgmt API State

  4. SM@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. 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. Structure of the paper • Specifying system states and management API • Generating adapters • Experiment • SM@RT in practice • Related work

  9. 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 JEE Server, EJBs, Data Sources, current_opened_connection…

  10. Specifying state type • Directly using MOF Model

  11. For JEE

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

  13. For JMX API of JEE systems

  14. Properties 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 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. Example

  17. How it works

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

  19. 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

  20. Experiment • 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

  21. SM@RT in practice

  22. SM@RT in practice

  23. Related 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

  24. Conclusion

  25. Thank you!

More Related