Architecture and
Mobile/Embedded Systems:
An Uneasy Alliance or a Marriage Made in Heaven?
Nenad Medvidovic
CSSE and Computer Science Department
Viterbi School of Engineering
University of Southern California
Los Angeles, USA
March 18, 2009
Outline
• Motivation
• Some terminology
• Relating architectures and mobility
– Design
– Modeling
– Implementation
– Deployment
– Dynamic adaptation
• Verdict
Outline
• Motivation
• Some terminology
• Relating architectures and mobility
– Design
– Modeling
– Implementation
– Deployment
– Dynamic adaptation
• Verdict
Characteristics of Mobile Systems
[Mascolo, Capra, Emmerich 2002]
• Device
– Fixed
– Mobile
• Network connection
– Permanent
– Intermittent
• Execution context
– Static
– Dynamic
• How does this relate to embedded systems?
Embedded Software
• Interaction with physical world
• Executes on machines, not “computers”
• Written by engineers who are domain
experts
• Current methods offered by computer
scientists are not always satisfactory
• Complexity and size of embedded software
are growing rapidly
– From 10,000s SLOC to 10,000,000s SLOC in the
past 30 years
Properties of Embedded Software
(per Edward Lee)
• Timeliness
• Concurrency
• Liveness
– Non-terminating
• Interfaces
• Heterogeneity
• Reactivity
Problem Space
• Novel computing platforms
–
–
–
–
Smart phones
Mobile robots
Motes
Sensors
• Novel usage scenarios
–
–
–
–
–
–
Search-and-rescue
Environment exploration
Traffic management
Medicine / Assisted living
Wireless sensor nets
Mobile grids
• Challenges
–
–
–
–
–
–
–
Distribution
Decentralization
Heterogeneity
Resource constraints
Context awareness
Real-time requirements
Mobility of users, hardware, computing, data
Outline
• Motivation
• Some terminology
• Relating architectures and mobility
– Design
– Modeling
– Implementation
– Deployment
– Dynamic adaptation
• Verdict
Some Terminology
• Adopted from
Some Terminology
• Software architecture – set of principal design
decisions P about a software system
– a.k.a. architectural design decisions
• Architectural style – named collection of
architectural design decisions that
– are applicable in a given development context
– constrain architectural design decisions that are
specific to a particular system within that context
– elicit beneficial qualities in each resulting system
“As designed” vs. “as implemented”
• Prescriptive architecture – set of architectural
design decisions P made at time t that reflect
architects’ intent
• Descriptive architecture – set of artifacts A that
realize the design decisions P
– Refinements of design decisions in a modeling
notation
– Models of employed architectural styles and patterns
– Existing OTS components
– Implementation frameworks and middleware
Why Do We Care?
Prescriptive Architecture
Why Do We Care?
Prescriptive Architecture
Descriptive Architecture
Why Do We Care?
Prescriptive Architecture
Implemented System
Descriptive Architecture
So, Why Do We Care?
• Architectural drift – introduction of principal
design decisions into a system’s descriptive
architecture that
– are not included in, encompassed by, or implied
by the prescriptive architecture
– but which do not violate any of the prescriptive
architecture’s design decisions
• Architectural erosion – introduction of
architectural design decisions into a system’s
descriptive architecture that violate its
prescriptive architecture
More Terminology
• Architectural perspective –
non-empty set of certain
types of architectural
design decisions
More Terminology
• Architectural perspective –
non-empty set of certain
types of architectural
design decisions
– Example perspective:
deployment
• Deployment – outcome of
the activity of placing a
system’s software
components on its
hardware host
And, Finally
• Migration – relocation
of software system’s
modules across hosts
at runtime
– a.k.a. redeployment
– A form of mobility
And, Finally
• Migration – relocation
of software system’s
modules across hosts
at runtime
– a.k.a. redeployment
– A form of mobility
And, Finally
• Migration – relocation
of software system’s
modules across hosts
at runtime
– a.k.a. redeployment
– A form of mobility
And, Finally
• Migration – relocation
of software system’s
modules across hosts
at runtime
– a.k.a. redeployment
– A form of mobility
• Preserves functionality
• Changes QoS
Outline
• Motivation
• Some terminology
• Relating architectures and mobility
– Design
– Modeling
– Implementation
– Deployment
– Dynamic adaptation
• Verdict
Design and Mobility
• Architectural abstractions
– Resources
• Data
• Code
– Computational threads
– Interactions
– Sites
• Architectural styles
–
–
–
–
Client-server
Peer-to-peer
Publish-subscribe
Event notification
• What do they have to say about mobility?
Designing for Mobility
• Many design guidelines
–
–
–
–
–
–
–
–
Decouple components
Avoid shared memory
Insulate components from execution context
Use implicit invocation
Interact asynchronously
Use stateless components
Make interaction stateless
…
• What about using “mobility styles”?
Mobility Styles
• Carzaniga, Picco, Vigna 1997, 2007
– Client-server
Mobility Styles
• Carzaniga, Picco, Vigna 1997, 2007
– Client-server
– Remote evaluation
Mobility Styles
• Carzaniga, Picco, Vigna 1997, 2007
– Client-server
– Remote evaluation
– Code on demand
Mobility Styles
• Carzaniga, Picco, Vigna 1997, 2007
– Client-server
– Remote evaluation
– Code on demand
– Mobile agent
Architectural + Mobility Styles
• One does not seem to constrain the other
• Some architectural styles may be well suited
to mobility
– This is a function of appropriate design heuristics
• In principle, anything can be “designed”
• The challenge is to provide appropriate
analysis and implementation support
And the Conclusion Is?
• Optimist says
– Use the mobility styles in concert with
architectural styles’ design guidelines and things
will work out
• Pessimist says
– There is no guidance, and perhaps even an
intellectual disconnect, when using architectural
styles and mobility styles
• Realist says
– Well, this is software engineering and there rarely
are easy answers, but something is better than
nothing
And the Conclusion Is?
• Optimist says
– Use the mobility styles in concert with
architectural styles’ design guidelines and things
will work out
• Pessimist says
– There is no guidance, and perhaps even an
intellectual disconnect, when using architectural
styles and mobility styles
• Realist says
– Well, this is software engineering and there rarely
are easy answers, but something is better than
nothing
And the Conclusion Is?
• Optimist says
– Use the mobility styles in concert with
architectural styles’ design guidelines and things
will work out
• Pessimist says
– There is no guidance, and perhaps even an
intellectual disconnect, when using architectural
styles and mobility styles
• Realist says
– Well, this is software engineering and there rarely
are easy answers, but something is better than
nothing
Outline
• Motivation
• Some terminology
• Relating architectures and mobility
– Design
– Modeling
– Implementation
– Deployment
– Dynamic adaptation
• Verdict
Modeling and Mobility
• Several mobility languages
• A few with an architectural focus
– CHAM [Inverardi et al. 1995]
• Chemical solutions, reactions, molecular migration
– CommUnity [Fiadeiro et al. 2004]
• Formal modeling of coordination primitives (distribution
connectors) for mobility
– FarGo [Holder et al. 1999]
• Dynamic layout constraints in support of “complet” mobility
– Computing with tiles [Brun et al. 2007]
• Mobility as molecular self-assembly
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
Host A
– Link
α
β
Host B
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
Host A
– Link
α
β
Host B
α
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
Host A
α
β
Host B
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
Host A
α
β
Host B
α
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
Host A
α
β
Host B
α
β
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
Host A
α
β
Host B
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
Host A
α
β
Host B
α
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
Host A
α
β
Host B
α
β
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
α
β
Host B
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
Host A
α
β
Host B
β
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
Host A
α
β
Host B
α
β
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
– Duplicate
Host A
α
β
Host B
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
– Duplicate
Host A
α
β
Host B
α
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
– Duplicate
Host A
α
β
Host B
α
β
copy
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
– Duplicate
– Stamp
Host A
α
β
Host B
β'
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
– Duplicate
– Stamp
Host A
α
β
Host B
α
β'
Dynamic Layout
• Holder, Ben-Shaul, Gazit 1999
– Link
– Pull
– Bi-directional pull
– Duplicate
– Stamp
Host A
α
β
Host B
α
β'
Computing with Tiles
• A tile:
1
1
• Tiles attach
1
0
– when labels match
1
0
– a square
– labels on 4 sides
1
0
[Winfree 1998]
Computing with Tiles
• A tile:
1
1
– when labels match
1
0
• Tiles attach
0
– a square
– labels on 4 sides
1
0
[Winfree 1998]
Tile Interaction
#5
0
#3
#2
0
1
#0
#4
0
#2
#1
0
1
#3
0
#1
#0
0
1
#2
0
#0
0
0
1
#1
0
1
0
0
0
#0
0
1
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
#0
0
1
0
1
1
#2
0
1
0
#3
#1
0
1
1
0
#2
#0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
#5
0
#1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
#4
0
#0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
1
1
#3
0
1
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
0
0
#2
0
1
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
#1
0
0
0
1
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
0
0
0
0
0
0
0
0
#0
1
1
1
0
0
• Tiles can stick to assemblies:
Tile Interaction
#5
0
#3
#2
0
1
#0
#4
0
#2
#1
0
1
#3
0
#1
#0
0
1
#2
0
#0
0
0
1
#1
0
1
0
0
0
#0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
#0
0
1
0
1
1
#2
0
1
0
#3
#1
0
1
1
0
#2
#0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
#5
0
#1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
#4
0
#0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
1
1
#3
0
1
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
0
0
#2
0
1
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
#1
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
0
0
1
1
1
1
0
0
0
0
0
0
0
0
#0
1
• Tiles can stick to assemblies
What Can Tiles Do?
• Assemble
– linear polymers [Adleman et al. 2001]
– squares [Rothemund et al. 2001, Adleman et al. 2001, 2002]
– arbitrary computable shapes [Soloveichik et al. 2004]
• Count
[Winfree 1998, Moisset et al. 2005, Barish et al. 2005]
• Compute binomial coefficients
[Winfree 1998, Rothemund et al. 2004]
• Emulate Turing machines
[Winfree 1998]
• i.e. Compute
[Brun 2006, Brun 2007, Brun 2008]
–
–
–
–
Add
Multiply
Factor
Solve NP-complete problems
Solving 3-SAT with Tiles
(x2¬x1¬x0)(¬x2¬x1¬x0)(¬x2x1x0)
1
0
0
?
v
v
0
0
0
1
1
1
1
?
¬v
¬v
¬v
¬v
0
0
0
*0
0
0
c
*v
0
0
*0
0
0
*0
0
c
?
v
v
v
v
v
v
v
0
c
v
0
||
1
*0
0
1
¬v
0
0
v
0
|
1
v
0
1
¬v
0
0
v
v
c
v
*0
0
c
v
0
0
*v
|
0
v
0
1
¬v
0
0
v
v
1
*1
0
v
0
1
¬v
0
0
1
|
1
*0
v
0
*1
¬v
0
0
v
0
v
c
v
0
*0
c
v
0
OK
v
1
0
||
1
0
v
0
1
¬v
0
0
v
¬v
v
1
0
¬v
||
1
0
v
0
1
¬v
0
0
v
0
1
0
¬v
0
||
1
0
v
0
1
¬v
0
0
v
1
0
¬v
0
1
||
1
0
v
0
*1
¬v
0
0
v
c
*¬v
0
1
c
||
1
0
v
0
1
¬v
0
0
v
¬v
0
1
c
¬v
||
1
0
v
0
1
¬v
0
0
v
0
1
c
¬v
0
||
1
0
v
0
*1
¬v
0
0
v
0
c
¬v
0
0
|
1
0
v
0
1
¬v
0
0
v
¬v
*¬v
0
0
¬v
|
1
0
v
*0
1
¬v
0
0
v
1
0
0
¬v
1
|
1
0
v
0
*1
¬v
0
0
v
0
0
¬v
1
0
|
1
0
v
0
1
¬v
0
0
v
¬v
*¬v
1
0
¬v
|
1
0
v
0
1
¬v
0
0
v
0
1
0
¬v
0
|
1
0
v
0
1
¬v
0
0
v
v
1
0
¬v
0
1
||
1
0
v
0
*1
¬v
0
0
0
c
*¬v
0
1
c
||
1
0
v
0
1
¬v
0
0
¬v
0
1
c
¬v
||
1
0
v
0
1
¬v
¬v
0
1
c
¬v
0
||
1
0
v
0
*1
1
0
c
¬v
0
0
|
1
0
v
0
*0
¬v
*¬v
0
0
¬v
|
1
0
v
v
1
0
0
¬v
1
|
1
0
0
0
|
1
1
v
|
|
0
0
¬v
1
0
v
1
*v
v
v
v
|
0
*¬v
1
0
0
1
v
*0
0
0
|
*0
1
0
0
1
v
0
*0
0
|
0
0
¬v
1
v
¬v
¬v
¬v
|
0
c
*v
0
OK
c
v
0
OK
v
v
*0
OK
v
1
0
OK
*v
1
0
OK
v
1
0
¬v
v
1
0
¬v
0
1
0
¬v
0
1
0
¬v
0
1
c
¬v
0
1
c
¬v
0
1
c
¬v
0
1
c
¬v
0
0
c
¬v
0
0
¬v
¬v
0
0
¬v
*1
0
0
¬v
1
0
0
¬v
1
*0
¬v
¬v
1
OK
¬v
0
1
OK
¬v
0
1
OK
¬v
0
1
c
¬v
0
1
c
¬v
0
1
c
¬v
0
1
c
¬v
0
0
c
¬v
0
0
¬v
¬v
0
0
¬v
*1
0
0
¬v
1
0
1
1
v
1
1
1
|
0
0
¬v
1
*0
0
1
v
0
0
0
|
0
¬v
1
OK
v
1
*v
v
v
v
|
0
1
OK
0
1
v
*0
0
0
|
*0
OK
1
1
v
1
*1
1
|
0
||
*1
||
||
||
|
v
c
Solving 3-SAT with Tiles
(x2¬x1¬x0)(¬x2¬x1¬x0)(¬x2x1x0)
1
0
0
?
v
v
0
0
0
1
1
*1
1
?
v
v
v
v
0
0
0
*0
0
0
c
*v
0
0
*0
0
0
*0
0
c
?
v
v
v
v
v
v
v
0
c
v
0
||
1
*0
0
1
v
0
0
v
0
|
1
v
0
*1
v
0
0
v
v
c
v
*0
0
c
*v
0
0
*v
|
0
v
0
1
v
0
0
v
v
1
*1
0
v
*0
1
v
0
0
1
|
1
*0
v
0
1
v
0
0
v
0
v
c
v
0
*0
c
v
0
OK
v
1
0
||
1
0
v
0
1
v
0
0
v
¬v
*v
1
0
¬v
||
1
0
v
0
1
v
0
0
v
0
1
0
¬v
0
||
1
0
v
0
1
v
0
0
v
1
0
¬v
0
1
||
1
0
v
0
1
v
0
0
v
c
¬v
0
1
c
||
1
0
v
0
1
v
0
0
v
¬v
0
1
c
¬v
||
1
0
v
0
1
v
0
0
v
0
1
c
¬v
0
||
1
0
v
0
1
v
0
0
0
c
¬v
0
0
|
1
0
v
0
1
v
0
v
¬v
¬v
0
0
¬v
|
1
0
v
0
1
v
0
v
1
0
0
¬v
1
|
1
0
v
0
1
0
0
v
0
0
¬v
1
0
|
1
0
v
0
v
0
0
v
¬v
¬v
1
0
¬v
|
1
0
v
1
v
0
0
v
0
1
0
¬v
0
|
1
0
0
1
v
0
0
v
1
0
¬v
0
1
|
1
v
0
1
v
0
0
v
v
c
¬v
0
1
c
|
0
v
0
1
v
0
0
0
¬v
0
1
c
¬v
1
0
v
0
1
v
0
0
0
1
c
¬v
0
1
0
v
0
1
v
v
0
c
¬v
0
0
1
0
v
0
1
1
¬v
¬v
0
0
¬v
1
0
v
0
0
1
0
0
¬v
1
1
0
v
v
0
1
0
0
v
1
1
0
0
¬v
1
0
v
1
*v
v
v
v
|
0
¬v
1
0
0
1
v
*0
0
0
|
*0
1
0
0
1
v
0
*0
0
|
0
0
v
1
*v
v
v
v
|
0
c
*v
0
OK
c
v
0
OK
v
v
*0
OK
v
*1
0
OK
*v
1
0
OK
v
1
*0
¬v
v
1
OK
¬v
0
1
OK
¬v
0
1
OK
¬v
0
1
c
¬v
0
1
c
¬v
0
1
c
¬v
0
1
c
¬v
0
0
c
¬v
0
0
¬v
¬v
0
0
¬v
1
0
0
¬v
1
0
0
¬v
1
0
¬v
¬v
1
0
¬v
0
1
0
¬v
0
1
0
¬v
0
1
c
¬v
0
1
c
¬v
0
1
c
¬v
0
1
c
¬v
0
0
c
¬v
0
0
¬v
¬v
0
0
¬v
1
0
0
¬v
1
0
1
1
v
*1
1
1
|
0
0
¬v
1
0
0
1
v
0
0
0
|
0
¬v
1
0
v
1
*v
v
v
v
|
0
1
0
0
1
v
*0
0
0
|
*0
0
1
1
v
1
*1
1
|
0
|
*1
|
no tile can attach
|
v
c
Mapping the Model to a System
• Each node deploys
tiles of a single type
• Initial mapping
• Node discovery
• Replication of seeds
• Recruitment of new
nodes to complete
the crystal
Client
Network
`
problem
in1, in2, ...
`
out1, out2, ...
`
`
Challenges
• Doing this in an actual system
– Fault tolerance
– Security
•
•
•
•
•
Active components
Active state
Scale
Overhead of explicit connectors
Ensuring adherence to the model
Outline
• Motivation
• Some terminology
• Relating architectures and mobility
– Design
– Modeling
– Implementation
– Deployment
– Dynamic adaptation
• Verdict
Implementation and Mobility
• Give me middleware or give me death!
• Categories of mobile middleware platforms
[Mascolo, Capra, Emmerich 2002]
1. Traditional
• ALICE, DOLMEN, Mobile DCE
2. Context-awareness
• UIC, Gaia, Nexus
3. Data sharing
• Coda, Odyssey, Xmiddle
4. Tuple spaces
• Lime, Tspaces, L2imbo
5. Service discovery
• UPnP, Jini, Salutation
What about Architecture?
• Does your mobile middleware enforce architectural
design decisions?
–
–
–
–
–
Computation
Data
Interaction
Interfaces
Styles
• If so, how?
– Shoot first, ask questions later
– Gentle persuasion
– Explicit constraints
• Another category of mobile middleware platforms
6. Architectural
• Aura, Prism-MW
The Mapping Problem Redux
• Components

?
– classes, packages, modules, …
• Connectors

?
– software buses, message services; what else?
• Interfaces

?
• Configurations

?
• Design rationale

?
• Behavior

?
• NFPs

?
– API signatures; what about protocols?
– interfaces, function pointers, reflection
– comments, documentation
– how do we translate FSP, StateCharts, Z, etc. to code?
– indirectly via rationale, inspections, testing, user studies, …
© Malek, 2007
SWE 622 – Distributed Software Engineering
64
What Gentle Persuasion May Look Like
More Specifically
Priority Dispatch
RRobinDispatch
EDF Scheduler
Scaffol d
IDispatch
Evt Frequency
Monitor
Rat eMonotonicSchedul er
IScheduler
Connection
Brick
FIFOScheduler
0..n
1..n
Security
IMonitor
IScaffold
RealTimeE
Architecture
Connector
Event
Socket
Distribution
IConnector
0..n
ISecurity
Component
IComponent
IRealTimeEvent
IArchitecture
Extensible
Event
IDistribution
Admin
IRDistribution
Extensible
Connector
Extensible
Component
I Compr essi on
Huffm an
Com pression
IAdmin
ArchRuntime
Analysi s
IRuntimeAnalysis
IConn Delivery Guarantees
Delivery
Guarantees
IConversion
XML
Converter
Serializable
I DeliveryGuarante esEvent
Del ivery
GuaranteesE
Architectural Structure
Comp A
Comp B
Connector D
Comp C
Architecture - DEMO
Comp A
Comp B
Comp C
class DemoArch {
static public void main(String argv[]) {
Architecture arch = new Architecture (“DEMO”);
// create components
Component a = new Component (“A”);
Component b = new Component (“B”);
Component c = new Component (“C”);
// create connectors
Connector d = new Connector(“D”);
// add components and connectors
arch.addComponent(a);
arch.addComponent(b);
arch.addComponent(c);
arch.addConnector(d);
// establish the interconnections
arch.attach(a, d);
arch.attach(b, d);
arch.attach(d, c);
}
}
Connector D
Architectural Interaction
Comp A
Send (e1)
Component C sends an event
Comp B
Event e = new Event (“Event_C”, REQUEST);
e.addParameter(“param_1", p1);
send (e);
Component B handles the event and sends a response
Connector D
Send (e)
Comp C
Architecture - DEMO
public void handle(Event e)
{
if (e.equals(“Event_C”)) {
...
Event e1= new Event(“RSP_to_C”, REPLY);
e1.addParameter(“response”, resp);
send(e1);
}...
}
An Application
Outline
• Motivation
• Some terminology
• Relating architectures and mobility
– Design
– Modeling
– Implementation
– Deployment
– Dynamic adaptation
• Verdict
Deployment and Mobility
• Deployment is an instance of stateless or weak
mobility [Fuggetta et al. 1998]
– Moving code and data, but not active state
• Deployment is changing
Then
Now
• Complete installation
procedure on CD
ROM
• Entire software
system is installed
• Software producers
and consumers
cooperating and
negotiating
• System update
Deployment Activities
•
•
•
•
Planning
Modeling
Analysis
Implementation
72
Deployment
Planning
• Find and effect a
deployment
architecture that
achieves desired
objectives
Deployment Modeling
• Hardware elements
• Software elements
• Their
parameters
• Their
mappings
• Constraints
• QoS
dimensions
• System
users
• …
Deployment Modeling
as Part of Architecture Modeling
Deployment Analysis
1. Are both deployments valid?
2. Which of the two deployments is “better”?
3. Does the selected deployment have required
properties?
Deployment Analysis in Action
Deployment Analysis in Action
Deployment Implementation
[Carzaniga et al. 1999]
Deployment Implementation
…and Architecture
Outline
• Motivation
• Some terminology
• Relating architectures and mobility
– Design
– Modeling
– Implementation
– Deployment
– Dynamic adaptation
• Verdict
Dynamic Adaptation and Mobility
• Four primitive adaptation operations at the
architectural level
– Addition
– Removal
– Replacement
– Reconnection
• Must be accompanied by modeling, analysis,
implementation support
• May involve mobility
“Figure 8”
Model of
Architectural
Adaptation
Mobility Challenges
• Component quiescence
• Connector adaptation
• Complex state
– Strong mobility [Fuggetta et al. 1998]
•
•
•
•
•
Complex dependencies
System performance
Service replication
Fault tolerance
Service discovery
Connector Adaptation
Connector Adaptation
Complex Dependencies?
Linux, as designed [Bowman et al. 1999]
Complex Dependencies?
Linux, as implemented [Bowman et al. 1999]
What Happens to QoS?
What Happens to QoS?
What Happens to QoS?
What Happens to QoS?
What Happens to QoS?
What Happens to QoS?
Outline
• Motivation
• Some terminology
• Relating architectures and mobility
– Design
– Modeling
– Implementation
– Deployment
– Dynamic adaptation
• Verdict
And the Verdict Is?
• Mobility is essential
• Mobility is hard
• Mobility must be thought of from an
architectural perspective
• Many hints already exist
• Many assumptions may need to be rethought
• No one-size-fits-all solutions
• No silver bullet… yet
And the Verdict Is?
• Mobility/embedding is essential
• Mobility is hard
• Mobility must be thought of from an
architectural perspective
• Many hints already exist
• Many assumptions may need to be rethought
• No one-size-fits-all solutions
• No silver bullet… yet
And the Verdict Is?
• Mobility/embedding is essential
• Mobility/embedding is hard
• Mobility must be thought of from an
architectural perspective
• Many hints already exist
• Many assumptions may need to be rethought
• No one-size-fits-all solutions
• No silver bullet… yet
And the Verdict Is?
• Mobility/embedding is essential
• Mobility/embedding is hard
• Mobility/embedding must be thought of from
an architectural perspective
• Many hints already exist
• Many assumptions may need to be rethought
• No one-size-fits-all solutions
• No silver bullet… yet
And the Verdict Is?
• Mobility/embedding is essential
• Mobility/embedding is hard
• Mobility/embedding must be thought of from
an architectural perspective
• Many hints already exist
• Many assumptions may need to be rethought
• No one-size-fits-all solutions
• No silver bullet… yet
And the Verdict Is?
• Mobility/embedding is essential
• Mobility/embedding is hard
• Mobility/embedding must be thought of from
an architectural perspective
• Many hints already exist
• Many assumptions may need to be rethought
• No one-size-fits-all solutions
• No silver bullet… yet
And the Verdict Is?
• Mobility/embedding is essential
• Mobility/embedding is hard
• Mobility/embedding must be thought of from
an architectural perspective
• Many hints already exist
• Many assumptions may need to be rethought
• No one-size-fits-all solutions
• No silver bullet… yet
And the Verdict Is?
• Mobility/embedding is essential
• Mobility/embedding is hard
• Mobility/embedding must be thought of from
an architectural perspective
• Many hints already exist
• Many assumptions may need to be rethought
• No one-size-fits-all solutions
• No silver bullet…
And the Verdict Is?
• Mobility/embedding is essential
• Mobility/embedding is hard
• Mobility/embedding must be thought of from
an architectural perspective
• Many hints already exist
• Many assumptions may need to be rethought
• No one-size-fits-all solutions
• No silver bullet… yet
Questions?