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 doesnt 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 ccreate(Plugin) ? configure(c)
• configure(cPlugin) ?c2Plugin.bind(c,ReqT,c2,
  ProvT)
• ? configure(c)
• configure(cPlugin) ? begin
• component type Plugin
• external port type ProvT,ReqT
• begin create(pReqT) ? begin
• begin ? run
• run create(pProvT) ? run
• run ?pProvT.comm(p) ? run
• run ?pReqT.comm(p) ? run

24
Example Self-Healing Servers

• component type System
• begin let ccreate(Client) ? begin
• begin let screate(Server) ? begin
• begin ?cClient ?sServer.bind(c,CT,s,ST) ?
  begin
• begin ?sServer ?cClient,cpc.CT,sps.ST .
  unbind(c.cp,s.sp) remove(s)
• ? begin
• component type Client
• external port type CT
• begin create(pCT) ? request(p)
• request(pCT) comm(p) ? reply(p)
• reply(pCT) comm(p) ? request(p)
• _ ?pCT.remove(p) ? begin

component type Server external port type
ST begin create(pST) ? begin begin
?pST.comm(p) ? reply(p) reply(pST) comm(p)
? begin reply(pST) remove(p) ? begin
25
Example Services with Discovery

• component type System
• begin let ccreate(Client) ? begin
• begin let screate(Server) ? begin
• begin ?cClient ?sServer.bind(c,CT,s,ST) ?
  begin
• begin ?sServer ?cClient,cpc.CT,sps.ST .
  unbind(c.cp,s.sp) remove(s)
• ? begin
• component type Service
• external port type DiscT,ProvT,ReqT
• begin create(dDiscT) ? register(d)
• register(dDiscT) comm(p) ? run(d)
• run(dDiscT) comm(p),create(rReqT) ? run(d)
• run(dDiscT) create(pProvT) ? run(d)
• run(dDiscT) ?rReqT/ProvT . comm(r) ? run(d)

component type Discovery external port type
DiscT begin create(pDiscT) ? begin begin
?pDiscT.comm(p) ? begin begin
?pDiscT.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

28
(No Transcript)
29
Example Self-Healing Servers

• component type System
• begin let ccreate(Client)
  ?sServer.bind(c,CT,s,ST)
• ? begin
• begin let screate(Server) ? begin
• begin ?sServer ? delete(s)
• delete(sServer) ?sps.ST,cClient,pcp.CT
  where bind(c.cp,s.sp) . unbind(c.cp,s.sp) ?
  rebind(s,c)
• rebind(sServer,cClient) ?s2Server where s2
  ! s . bind(c.CT,s2.ST) ? delete(s)
• delete(sServer) remove(s) ? begin
• component type Client
• external port type CT
• begin create(pCT) ? request(p)
• request(p) comm(p) ? reply(p)
• reply(p) comm(p) ? request(p)
• _ ?pCT.remove(p) ? begin

component type Server external port type ST
begin ?pST.comm(p) ? reply(p) reply(p)
comm(p) ? begin reply(p) remove(p) ? begin