Modeling Highly Dynamic Software Architectures Research Proposal Jonathan Aldrich.

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}