Hui Song ( 宋晖 ) songhui06@sei.pku

1. Reflecting Running Systems as Standard Models A series of small applications of model-driven techniques Hui Song (宋晖) songhui06@sei.pku.edu.cn

2. From the very beginning • Future Software • Dependent on the Internet • Always running • Long life-cycle and unstable • We have to manage them at runtime Abstract! automated mgmt agent Topological diagram of the Internet http://orbitalteapot.blogspot.com/2007/10/how-universe-looks-like-brain.html human administrator

3. Model-based runtime management • How to take control of complex systems • Models! • A long history • Architecture-based runtime management (abstract) • models@run.time workshop (model-based approaches) • Runtime model as a part of MDE (integration) • Benefits • Abstract and separation of concerns • Richer semantics basis • Integrated with whole development process • Many reusable approaches and tools

4. Some stories about the last benefit • Xiangping’s work: analyzing systems • Some situation means something • Identify situations, do something • Model transformation, ATL! • Franck’s work: Goal-driven self-adaptation • Calculate a configuration -> deploy it • Compare, execute the changes • Model comparison • My own work: runtime architecture view • Monitor systems on arch, control system through arch • Synchronization between them dynamically • QVT bidirectional transformation

5. A big barrier to model-based runtime mgmt Model-driven apps and techs • Model guys at model level • Everything is model • Everything could be resolved in a model based way • Standard model processing interface • System guys at system level • Care more about mechanisms • Management APIfor flexibility Mgmt API How to invoke JMX interface? Management mgt=… ObjectName ds=… Object obj=mgt.getAttribute( ds, “jdbcMaxConnPool” ) System

6. Asking system vendors to change their minds? Hey, why not provide a model-like interface for your system. Seemed everyone’s talking about model-based management. I don’t wanna waste my time on such a toy…

7. An alternative solution Model-driven apps and techs Standard model processing interface Adapter Ad hoc mgmt API State

8. Roadmap Model-based runtime mgmt gap between model and API -Adapters to wrap APIs 1. JADE 2. MoDisco Fractal ADL Fractal reflection intf Self-healing MOF meta-model MOF reflection intf Anything

9. The first work: Jade • Jade: a framework for autonomic management • part of the ObjectWeb Jasmine project • an administration tool facilitate the job of administrators • related to Fractal • Representative work • S. Sicard, F. Boyer, and N. D. Palma. • Using components for architecture-based management: the self-repair case. • In ICSE, pages 101-110, 2008.

10. Sicard-ICSE-08: Motivation • A basic pattern for self-repair: Substitute the failed components by new ones • A mature algorithm for • identifying failures, • removing failed components, safely, • starting new ones • Seemed applicable to many systems

11. But, … Self-repair Anything in common? JMX cfg file who knows JEE Apache …

12. Anything in common? Yes, of course. • Managed system is constituted of managed elements • EJBs, data sources, middleware services; • apache servers, tomcat servers • ... • Features sufficient for managed elements • Local state • Life cycle state • Functional dependency • Connection • Composition • Just mapped to the Fractal component model ()

13. Fractal component model • Component : runtime entity • Interface : access point to component • Binding : interaction, communication • Special interfaces for management (controller): • Life-cycle controller • Attribute controller • … • Fractal ADL • Specify structures • Fractal API • Standard way to invoke

14. Idea: Wrap all the mgmt APIs as Fractal API • This ICSE paper talks about the wrapping Apache-JEE-Mysql systems under Fractal, manually!

15. Effect Fractal ADL: Apache conn_pool Tomcat MySQL

16. The second work: MoDisco

17. The pusher behind MoDisco • INRIA, Nante University • Some publications aboutmodel driven engineering • The chief of ATL group! • ATL: the de facto model transformation standard • ATL group: an important participant of Eclipse Modeling Project (EMP) • EMP: currently a relatively successful MDE implementation

18. MoDisco: motivation • The work of ATL group • Model transformation: ATL • Based on OMG’s Meta Object Facilities (MOF) • Mega-model: Use ATL, OCL … to manage many models together • Design model, • Code, • Deploy model • Developer role model • It seems that something is missing • Runtime system • How to achieve handling running systems as MOF compliant models

19. Solution

20. One of the use cases: JarToUML • A Jar package • Many java classes • Complex class structures • Visualization may be useful • How to visualize the structure • Eclipse UML2 class diagram • How to get these structure • apache.bcel • API! • Gap, again! InputStream input=jarFile.getInputStream(entry); ClassParser parser=new ClassParser(input, entry.getName()); JavaClass clazz=parser.parse(); Field[] fd=clazz.getFields(); Method[] md=clazz.getMethods();

21. JarToUML

22. JarToUML UML2 class diagram generator Discoverer Write: Class Attribute Operation Generalization … In UML2 Read: JavaClass Fields Methods … By bcel

23. Roadmap of MoDisco • 1. Creation and initialization of the project • 2. Elaboration of several use cases • 3. Common toolbox and initial framework for building model discoverers. • 4. Improvement of the framework as additional use cases are built and contributed. • Currently blocked at step 2: • Manually coding a discoverer for each of the cases

24. Look back Jade and MoDisco • Difference • Fractal vs. MOF • “If all you have is a hammer, everything looks like a nail.” • Similarity • Specify system structure (Fractal ADL vs. MOF meta-model) • Manually wrap the different APIs (wrapper vs. discoverer) • Enjoy model-based management (reusing self-repair algorithms vs. reusing ATL)

25. The idea of “specify-wrap” • Really useful • Shown by the cases • Widely accepted • ICSE, INRIA, ObjectWeb • Eclipse, IBM • Still an initial attempt • Manually develop the adapters by ordinary languages

26. Roadmap Model-based mgmt - Gap between mgmt API and model intf Adapters to wrap APIs 1. JADE 2. MoDisco 3. Data processing 4. Code composition DSL to specify data structure Generate data processing tools DSL, with pieces of code Code generation to compose the code Wrapping mgmt APIs Hand-coding to construct adapters high-level specification & auto generation

27. Packet Types • Abstract Specification of Network Protocol Messages • Peter J. McCann and Satish Chandra • Bell Laboratories • SIGCOMM 2000 • Motivation • Protocol analyzing is a very common work • Corresponding programs are not easy to write • So, • A new language for high level specification of protocol types • A generator for protocol (pre-)processing tools

29. Compiler • Proper C structs for the specified types • Utility programs for parsing a packet, and instantiate proper variables of the structs • Further protocol analyzing • Operating these variables • Untyped (binary package) -> typed (a variable of the struct)

30. PADS: Processing Ad hoc Data Sources • Kathleen Fisher • AT&T Labs • Chief of Sig-PLAN • PADS project • http://www.padsproj.org • PLDI 2005, POPL 2006, POPL 2008…

31. Ad hoc data: web logs 207.136.97.49 - - [15/Oct/2006:18:46:51 -0700] "GET /turkey/amnty1.gif HTTP/1.0" 200 3013 207.136.97.49 - - [15/Oct/2006:18:46:51 -0700] "GET /turkey/clear.gif HTTP/1.0" 200 76 207.136.97.49 - - [15/Oct/2006:18:46:52 -0700] "GET /turkey/back.gif HTTP/1.0" 200 224 207.136.97.49 - - [15/Oct/2006:18:46:52 -0700] "GET /turkey/women.html HTTP/1.0" 200 17534 208.196.124.26 - Dbuser [15/Oct/2006:18:46:55 -0700] "GET /candatop.html HTTP/1.0" 200 - 208.196.124.26 - - [15/Oct/2006:18:46:57 -0700] "GET /images/done.gif HTTP/1.0" 200 4785 www.att.com - - [15/Oct/2006:18:47:01 -0700] "GET /images/reddash2.gif HTTP/1.0" 200 237 208.196.124.26 - - [15/Oct/2006:18:47:02 -0700] "POST /images/refrun1.gif HTTP/1.0" 200 836 208.196.124.26 - - [15/Oct/2006:18:47:05 -0700] "GET /images/hasene2.gif HTTP/1.0" 200 8833 www.cnn.com - - [15/Oct/2006:18:47:08 -0700] "GET /images/candalog.gif HTTP/1.0" 200 - 208.196.124.26 - - [15/Oct/2006:18:47:09 -0700] "GET /images/nigpost1.gif HTTP/1.0" 200 4429 208.196.124.26 - - [15/Oct/2006:18:47:09 -0700] "GET /images/rally4.jpg HTTP/1.0" 200 7352 128.200.68.71 - - [15/Oct/2006:18:47:11 -0700] "GET /amnesty/usalinks.html HTTP/1.0" 143 10329 208.196.124.26 - - [15/Oct/2006:18:47:11 -0700] "GET /images/reyes.gif HTTP/1.0" 200 10859

32. Data description language • Ad hoc data is difficult to manage • Data arrives “as is” in a wide-variety of encodings and formats. • Documentation is out of data or non-existent. • Data sources often have high volume. • Existing solutions are insufficient • Hand-coded C/Perl programs are time-consuming to produce, brittle with respect to changes. • Data description languages (DDLs) address these issues • Data expert writes declarative description rather than a parser. • Description serves as living documentation. • From declarative specification, compiler can generate auxiliary tools. • Processing data as if they are XML, guided by the specification Data description languages facilitate managing ad hoc data.

33. Parray Phostname{ Pstring_SE(:"/[. ]/":) [] : Psep('.') && Pterm(Pnosep); }; Punion host { Pip ip; /- 135.207.23.32 Phostname host; /- www.research.att.com }; Punion auth_id { Pchar unauthorized : unauthorized == '-'; Pstring(:' ':) id; }; Penum method { GET, PUT, POST, HEAD, DELETE, LINK, UNLINK }; Pstruct version { "HTTP/"; Puint8 major; '.'; Puint8 minor; }; int chkVersion(version v, method m) { if ((v.major == 1) && (v.minor == 0)) return 1; if ((m == LINK) || (m == UNLINK)) return 0; return 1; }; Pstruct request { '\"'; method meth; ' '; Pstring(:' ':) req_uri; ' '; version version : chkVersion(version, meth); '\"'; }; Ptypedef Puint16_FW(:3:) response : response x => { 100 <= x && x < 600}; Punion length { Pchar unavailable : unavailable == '-'; Puint32 len; }; PrecordPstruct entry { host client; ' '; auth_id remoteID; ' '; auth_id auth; " ["; Pdate(:']':) date; "] "; request request; ' '; response response; ' '; length length; }; PsourceParray clf { entry []; } Common Log Format in PADS A complete PADS/C description of the web server log data shown in the box: 207.136.97.50 - - [15/Oct/1997:18:46:51 -0700] "GET /turkey/amnty1.gif HTTP/1.0" 200 3013 PADS allows concise, precise, and intuitive data specifications.

34. PADS compiler • Converts description to C header and implementation files. • Code organization • For each built-in/user-defined type: • C structs • Functions (read, write, auxiliary functions) • Runtime organization • Variables of C structs • In-memory representation

35. Generated representation Pstruct http_request { '\"'; http_method meth; /- Request method ' '; Pstring(:' ':) req_uri; /- Requested uri. ' '; http_version version : check(version, meth); '\"'; }; typedefstruct { http_method meth; /* Request method */ Pstring req_uri; /* Requested uri */ http_version version; /* check(version, meth) */ } http_request;

36. Leverage! • With the generated parser, people can manipulate the ad hoc data, as if the data is in XML • 1.Generated code implements a “PADS” interface • 2.Strict map between data format description and the invocation of PADS interface • 3.Re-implementation of XML tools on PADS • XQuery interpreter • XPath interpreter • … • Quite similar to meta-modeling (EMF implements MOF) • 1.EMF, 2. Ecore, 3.EMF version of QVT and OCL

37. About auto-generation of data process tools Untyped -> typed Data description language -High-level language to define “types” -Code: structs corresponding to types -Runtime: variables of structs as an in-memory representation Systems are not data -Structure: graph vs. tree -Operation: standard ASCII vs. ad hoc mgmt APIs 3. PacketType & PADS 4. Code composition For data processing DSL to specify data format Generate dataprocessing tools DSL, with pieces of code Code generation to compose the code Application Programming Interface: Only code could specify it precisely

38. AHEAD • Algebraic Hierarchical Equations for Application Design • Scaling Step-Wise Refinement • TSE 2004 • Basic Idea • Traditional refinement: m++ • Scaling refinement: m+n • Basic solution • A program is constituted of features • A feature corresponds to a piece of code (constance) or a composition of other features • High-level: an algebra of features (for developers) • Low-level: composition of code according to the algebra (automated)

39. Feature Algebra • Constants • Functions • Applications

40. Calculation

41. generation k1 k1 ● k2 mixin k1 ● k2 jampack k2

42. FSML: Framework-Specific Modeling Language • Framework completion: developing applications on frameworks • Michal Antkiewicz, Krzysztof Czarnecki • Representative work • MoDELS06 (best paper) • ASE07 (ACM distinguish paper)

43. Overview • Object-oriented application framework • Java Applet, eclipse workbench, Struts • A widely used software reuse technology • Coding upon framework: framework completion • Instantiate several framework specific concepts • Following the specific ways to invoke the API • Can be challenging • A declarative approach to framework completion • Framework experts define the concepts and the invocation method, as a feature model (Domain Engineering) • Common developers specify what concepts to instantiate, and how many (Application Engineering) • A tool automatically generate the code to realize framework-based applications

44. Example: Java Applet • Overview: small Java app, embedded in web pages • Framework specific concepts • Applet (name, listen to mouse, show status message) • Reused logic behind the concept: JApplet class • Interaction between Applet and browser, etc • Framework completion (programming an Applet) • class MyApplet extends JApplet { shows=“…”; listens=new XXX(); …}

45. Applet FS Modeling Language and a FS model Domain Engi App Engi

46. Using their development environment

47. Summary • What we learned? • Small pieces of code behind a high-level model • For users: modeling and single-purpose coding • Hidden from users: code generation to compose the pieces of code together • How about management API? • Pieces of code for a single function • A model to organize them together • Auto-generation of the adapters

48. Roadmap Developing mgmt tools - Implicit structure - Ad hoc invocation - Specify structures - Wrap APIs 1. JADE 2. MoDisco Wrapping mgmt APIs Hand-coding adapters high-level specification & auto generation 3. PADS 4. FSML Specify system structure Specify API invocation Auto-generate adapters for the specific API Our work: 1. language to specify structure and API, 2. generate adapters

49. SM@RT: Supporting Models at Run-Time Specification Access Model System Meta-Model automatically generates specifiedas System Adapter Runtime Model MOF Reflection Interface Mgmt API

50. SM@RT: Supporting Models at Run-Time • SM@RT Modeling Language • Supporting specifying the system structure as a MOF compliant meta-model • Supporting specifying the code-level invocation method as a high-level “access model” • Small pieces of code for single function • Organized along system structure • Code reuse • SM@RT generator • Automatically generate the adapters • Other programs could manipulate the systems as if the systems are MOF compliant models