1. Modeling Highly Dynamic Software 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 Self-healing systems
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
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 Research challenge
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 Research challenge
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 Semantics
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 Port Bindings Connectors/roles are symmetric
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 }