1 / 20

Supporting Architecture-Based Runtime System Management

This paper presents an innovative framework for architecture-based runtime system management, leveraging bi-transformation techniques. By addressing the challenges of heterogeneous structures and monitoring system states, we propose a method to dynamically reconfigure parameters and manage functions effectively. Through case studies, including the Java Pet Store on the JOnAS server, we illustrate how this approach facilitates incremental development and enhances maintenance. We also highlight common obstacles, such as dealing with various data formats and ensuring synchronization, and propose solutions for effective implementation.

jocelyn-mays
Télécharger la présentation

Supporting Architecture-Based Runtime System Management

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. Supporting Architecture-Based Runtime System Management --An application of bi-transformation Hui SONG (宋 晖) Peking University, China GRACE center, NII (visitor) (songhui06@sei.pku.edu.cn)

  2. Problem Origin Advantage: Abstract technical details Close to problem domain Reuse design information Difficulties: Heterogeneous structure Asymmetric information Monitor the state Reconfigure parameters Add/remove functions read manage Architectural Model Causal Connection Running System write maintain What’s going on? Environment changed? Requirement changed? Runtime Architecture Infrastructure read/write read/write What changes mean on the other side?

  3. Current Status • A hot research topic • ICSE 2008 ten years most influential paper award • Many approaches these years • From embedded to enterprise systems • Architecture styles for evolution, self-adaptation… • Different concerns • Infrastructures in these approaches • Manually constructed, specific infrastructures

  4. We need many infrastructures • M*N manual constructed infrastructure • Considering everything together • Commonality: propagating changes J2EE DBMS Fractal

  5. How about a framework J2EE DBMS Engine Fractal M*N Declarative Relations Powerful enough to deal withthe heterogeneity and asymmetry

  6. What we choose in our initial attempt • QVT relational • Specifying relations • QVT bi-transformation engine • Auto maintaining the relation • Can we directly use QVT language?YES. • Can we directly use QVT engine? NO! • Two obstacles • Corresponding solutions

  7. Obstacle 1 • Common Problem for Applying bi-transformation • Various data formats JMX interface Management mgt=… ObjectNameds=… Object obj=mgt.getAttribute( ds, “jdbcMaxConnPool” ) ? J2EE system QVT Engine

  8. Our Solution Standard MOF reflection interface Object get(), Object set(), Object create()… QVT Engine implement MOF Meta-model Classes, Attributes… Adapter get(){ ObjectNameds=… … } Code generation JMX interface Management mgt=… ObjectNameds=… Object obj=mgt.getAttribute( ds, “jdbcMaxConnPool” ) annotation J2EE System

  9. What does that mean MOF model J2EE QVT Engine MOF model DBMS MOF model Fractal

  10. Example Meta-model Generated code Specific method Standard method

  11. Obstacle 2 • Can we just execute bi-tr on these “models” • NO • Simultaneous change • System may change itself • Multi-view • Uncertain modification • Systems are always more complex for an outside observer!

  12. Synchronization Algorithm • Input: original and modified architecture • Side-effect: change the system state • Output: new architecture reflects • System changes (caused by itself, or other manager) • Actual modification result

  13. Original Arch Original Sys Arch adapter forward Empty Sys ori.xmi system adapter Modified Arch *$ Modified Sys *$ Actual Sys#$ forward Arch adapter Diff * arc.xmi diff FinalArch %#$ backward Modified Arch Desired Sys *#$ merge diff_i Original Arch check Final Sys %#$ diff_a Final Arch

  14. Case Study • Supporting a typical management case • Target system: Java Pet Store on JOnAS server • Architecture style: C2 • Effect of the constructed infrastructure • Monitor • Reconfigure parameters • Add new component • Re-link components

  15. Development under the Framework

  16. Advantages of the Framework • Productive • Clear and stable behavior, good for maintenance and incremental development • Separation of concerns, good for reuse

  17. Open Problems • Foundation • Properties of architecture-based management • Performance • Important for automatic management agents • Incremental transformation • Representation of modification • Static check • What can be changed on architecture • One architecture style for different systems

  18. For example • Derive access right on architecture level from system level and QVT relation JOnAS JMX & Ishmeal EJB : Class Meta-model for C2 style +name: String +jndiName: String (writable) Component : Class +name : String +address : String (writable?) java.lang.reflect JavaClass : Class +name: String +package: String (read-only)

  19. Conclusion • Architecture-based runtime management • A framework for architecture-based runtime management, supported by bi-transformation • Wrapping various data for bi-transformation • A model-to-runtime synchronization algorithm • Case study • Open questions

  20. Thank you!

More Related