Upload
dorthy-copeland
View
216
Download
0
Tags:
Embed Size (px)
Citation preview
Modeling Highly DynamicSoftware Architectures
Research Proposal
Jonathan Aldrich
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?
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
Evolution vs. Dynamism
• Evolution: configuration time, versioning
• Dynamism: run-time
• Border may be unclear– What about evolving a running system?
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
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?
Static vs. Dynamic architecture
• Essential difference: state vs. execution
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?
Issues (1)
• Structural vs. Behavioral dynamism– Behavioral: Wright, Rapide– Structural: Wright, Rapide, Darwin, ArchJava
• Research Challenge: Combination– Wright, Rapide support only limited forms
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?
Issues (3)
• Abstraction mechanisms– Hierarchy in architecture – Darwin, ArchJava,
Rapide– Non-determinism in behavior – Wright
• Research challenge– Can we combine these?
Issues (4)
• Analysis support– Deadlock detection– Checking temporal properties– Simulating architectures– Verifying structural properties– Checking quality attributes
ADLs with some dynamism
• Darwin
• Rapide
• Wright
• Acme (optional components)
• C2 SADL/xADL
• ArchJava
• ArchWare
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
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
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
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
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)
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)
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
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?
Configuration
• Component– ID × CType × State × pList × bList × cList
• Port– ID × PType × State
• Bindings– ID × ID
• Connectors/roles are symmetric
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}
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}
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}
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
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
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}