Modeling Highly Dynamic Software Architectures

1. Modeling Highly DynamicSoftware Architectures Research Proposal Jonathan Aldrich

2. Motivation • Modern architectures are dynamic • Networked, Plug-in, Object-oriented, Service-oriented • Architectural notations quite limited • Acme/xADL: At most supports “optional” components • Wright: Fixed maximum # of components • ArchJava: Fixed pattern of connection • Research questions: • What is the state of the art? • What are the open questions? • What are interesting possible approaches?

3. Examples of Dyn. Arch. • Plugins/dynamic loading • At load/start time or run time • Dependent on versions? • Eclipse, Apache, EJB, Corba, Java class loading • Self-healing systems • Owen: videoconferencing • Evolving a running system • Linux services • Stop, upgrade, restart individual services • Telecom • Uses duplication/failover to keep track of call circuit states as software is upgraded • NASA spacecraft • Fail-safe mode: stop and wait for instructions from earth, maybe load new code • MDS upgrade scenarios

4. Evolution vs. Dynamism • Evolution: configuration time, versioning • Dynamism: run-time • Border may be unclear • What about evolving a running system?

5. Dynamism of Types/Instances • Types • Adding new types to a style • Changing a style • What does a type capture? • Behavior? Signature? Quality attributes? Identity? • Depends on modeling purposes • Structure • Adding/removing/changing components & connectors

6. Dimensions of Dynamism • Locus of control: external or internal? • Locus of control: centralized or decentralized? • May be different at design & impl time • Field of view: complete or partial? • What may change vs. how does it change • How can we abstract away from these decisions at the modeling level?

7. Static vs. Dynamic architecture • Essential difference: state vs. execution

8. Limitations of Previous Work • Limitations on dynamic configurations • Finite # of configurations (Wright) • Limited to statically-declared patterns of types (Everyone) • Cannot extend connections (ArchJava) or extension is limited to one component type (Darwin, Rapide) • Cannot delete components/connections/ports (ArchJava, Darwin) • Dynamically created components cannot provide services (Darwin) • Research Challenge • Can we build a modeling system without these limitations?

9. Issues (1) • Structural vs. Behavioral dynamism • Behavioral: Wright, Rapide • Structural: Wright, Rapide, Darwin, ArchJava • Research Challenge: Combination • Wright, Rapide support only limited forms

10. Issues (2) • Explicit vs. Implicit connections • Implicit connections are not really architecture • But often used in architectural formalisms, i.e. pi-calculus • Research challenge • Can we get the expressiveness of pi-calc while remaining explicit?

11. Issues (3) • Abstraction mechanisms • Hierarchy in architecture – Darwin, ArchJava, Rapide • Non-determinism in behavior – Wright • Research challenge • Can we combine these?

12. Issues (4) • Analysis support • Deadlock detection • Checking temporal properties • Simulating architectures • Verifying structural properties • Checking quality attributes

13. ADLs with some dynamism • Darwin • Rapide • Wright • Acme (optional components) • C2 SADL/xADL • ArchJava • ArchWare

14. Major Open Issues • Type dynamism • Modeling emergent systems • Does architecture have benefits here? • Modeling richer structural dynamism • Modeling structural & behavioral dynamism together • Dynamism and abstraction • Hierarchy, non-determinism • Multiple views: abstraction • Separation of concerns • How to reason separately about changes to the architecture that have different motivations, then compose them together • How to transition to implementation and/or check conformance • maybe more than one impl/more than one refinement • Field study of dynamism in applications today • What kinds of dynamism are needed? • What could be checked? • Richer analysis • Incremental progress towards goal/do no harm • Concurrency – what changes interfere with each other or with overall system functionality & quality attributes • Stability – can you guarantee that a fix to one problem doesn’t destabilize another, whose fix breaks the original problem

15. Reading Group Interest? • Several people interested • Some people want credit (3-6 units) • Once/week • Looking at different dyn. arch. Ideas • Reading papers from literature • Dynamic Wright • Wermelinger • CHAM? • Graph grammars • ArchWare • Magee & Kramer / Darwin • Formalisms for (state machine/petri nets) composite web services • Autonomic computing • Develop wiki wiki web as part of course to capture part of reading group • c2 wiki

16. A Proposal • Type dynamism • Modeling emergent systems • Does architecture have benefits here? • Modeling richer structural dynamism • Modeling structural & behavioral dynamism together • Dynamism and abstraction • Richer analysis

17. One set of goals • Support both structural and behavioral dynamism • No type dynamism • Avoid previous limitations on structural dynamism • Explicit connections • Support both hierarchical and behavioral abstraction • Control mechanism • Internal, centralized, view based on hierarchy • Analysis support • Typechecking, Structural constraints, behavioral constraints

18. Dynamic Architectural Changes • Goals • Allow arbitrary (well-formed) architectural changes • Avoid dangling ports or roles • Operations • let c = addComponent(CType) • let x = addConnection(XType) • let (p,r) = bind(c,PType,x,RType) • removeComponent(c) • removeConnection(x) • unbind(p,r)

19. Architectural Events • Includes all operations above • Operation sequences • op ; op • External port/role creation • Create(p), Create(r) • Remove(p), Remove(r) • Port/role communication • Communicate(p), Communicate(r)

20. Component State • Fixed set of states for each component • Name • Fixed # of element id parameters • Supports component behavior protocol • Also similar set of states for each port • Tracks port correlations • Supports port behavior protocol • Connectors/roles similar

21. Component Behavior • Transition relation • Initial state × action  final state • Semantics • Enumerate all transitions that apply • Corresponding actions must match • Communication on port and role • External/internal port/role addition/removal events • Choose one non-deterministically • Fairness criterion? • User-specified constraints?

22. Configuration • Component • ID × CType × State × pList × bList × cList • Port • ID × PType × State • Bindings • ID × ID • Connectors/roles are symmetric

23. Example: Eclipse Plugin Architecture component type Eclipse { begin × let c=create(Plugin) configure(c) configure(c:Plugin) × c2:Plugin.bind(c,ReqT,c2,ProvT)  configure(c) configure(c:Plugin)  begin } component type Plugin { external port type ProvT,ReqT; begin × create(p:ReqT)  begin begin  run run × create(p:ProvT)  run run × p:ProvT.comm(p)  run run × p:ReqT.comm(p)  run }

24. Example: Self-Healing Servers component type System { begin × let c=create(Client)  begin begin × let s=create(Server) begin begin × c:Client s:Server.bind(c,CT,s,ST)  begin begin × s:Server c:Client,cp:c.CT,sp:s.ST . unbind(c.cp,s.sp); remove(s)  begin } component type Client { external port type CT; begin × create(p:CT) request(p) request(p:CT) × comm(p)  reply(p) reply(p:CT) × comm(p)  request(p) _ × p:CT.remove(p)  begin } component type Server { external port type ST; begin × create(p:ST) begin begin × p:ST.comm(p)  reply(p) reply(p:ST) × comm(p)  begin reply(p:ST) × remove(p)  begin }

25. Example: Services with Discovery component type System { begin × let c=create(Client)  begin begin × let s=create(Server) begin begin × c:Client s:Server.bind(c,CT,s,ST)  begin begin × s:Server c:Client,cp:c.CT,sp:s.ST . unbind(c.cp,s.sp); remove(s)  begin } component type Service { external port type DiscT,ProvT,ReqT; begin × create(d:DiscT) register(d) register(d:DiscT) × comm(p)  run(d) run(d:DiscT) × comm(p),create(r:ReqT) run(d) run(d:DiscT) × create(p:ProvT) run(d) run(d:DiscT) × r:ReqT/ProvT . comm(r)  run(d) run(d:DiscT)× remove(d)  begin run(d:DiscT)× r:ReqT/ProvT . remove(r)  begin } component type Discovery { external port type DiscT; begin × create(p:DiscT) begin begin × p:DiscT.comm(p)  begin begin × p:DiscT.remove(p)  begin }

26. Research questions • Do we need to model data passed on ports? • How to define a well-formed state • And ensure that execution preserves well-formedness • Specification and verification of architectural constraints • Expressiveness • Almost certainly Turing-complete

27. Base for Future Work • Aspect-based architecture specifications • Enhance or restrict a base architecture • Cleanly combine two architectural views • Model unknown component & port types • For dynamic loading

29. Example: Self-Healing Servers component type System { begin × let c=create(Client); s:Server.bind(c,CT,s,ST)  begin begin × let s=create(Server) begin begin × s:Server  delete(s) delete(s:Server) × sp:s.ST,c:Client,p:cp.CT where bind(c.cp,s.sp) . unbind(c.cp,s.sp)  rebind(s,c) rebind(s:Server,c:Client) × s2:Server where s2 != s . bind(c.CT,s2.ST)  delete(s) delete(s:Server) × remove(s)  begin } component type Client { external port type CT; begin × create(p:CT) request(p) request(p) × comm(p)  reply(p) reply(p) × comm(p)  request(p) _ × p:CT.remove(p)  begin } component type Server { external port type ST; begin × p:ST.comm(p)  reply(p) reply(p) × comm(p)  begin reply(p) × remove(p)  begin }