Deployment and Mobility of Software
• Software architecture must eventually be
“realized” ---- that is
– a) implemented and
– b) deployed
• Deployment is the placing of software on the
hardware where it is supposed to run.
• These considerations can not wait until the
code is complete, but should be considered
during architecture and high level design
time --- even possibly at requirements time.
A Wireless Sensor Network System
There are 4 types
of hardware:
HUB
- i-phone
- HUB Server
- Gateway PC
- Sensors
i-phone
with different platforms
and capacity
Tied together via
network and
wireless sensors
Sensor 5
gateway
Sensor 1
Network
Backbone
Sensor 3
Sensor 1
gateway
Sensor 4
Deployment Challenges
• Geographically Distributed hardware : how do we get the
software there?
• Heterogeneity of hardware: may have different op systems,
requiring different interfaces/connectors
•
Different configuration: some may require high resolution
screens, others can attach some devices but not others,
differing cpu speed and memory capacity, etc.
•
Differing life span: some hardware may have defects or stops
performing and need re-deployment
•
Differing new technology & growth: some hardware gets
upgraded and requires re-deployment earlier
• Partial mobility: running software may need to be “moved” or
re-deployed in the midst of execution, needing dynamic backup and recovery
• Locating the hardware/software/service: after re-deployment, if
moved, finding the mobile software and re-executing is difficult
Deployment Considerations
•
Initial deployment of the system involves the
transfer of all software components and
connectors from the “source hosts” to the
“destination hosts”; as such one must consider
the following resources on the destination hosts:
1.
2.
3.
4.
5.
6.
Hardware architecture
Network architecture
Peripheral devices and configuration
System software, device drivers and middle-ware
Co-requisite & Pre-requisite application software
Co-requisite & pre-requisite data and data files (e.g.
initialized information)
Think about your recently purchased software --- how did it get deployed?
Breaking Down Deployment “Major” Activities
1.
Planning
2.
Modeling
3.
Analysis
4.
“implementing”
Planning for Deployment
• During planning stage we are concerned about the
actual behavior of the system once it is running
• The requirements for the executing system must be
understood and considered --- these requirements
are usually known as Quality of Service (QoS)
attributes:
–
–
–
–
–
Dependability
Security
Availability
Durability
etc.
Planning for QoS
• Understand each QoS and know how to measure it --(very difficult task --- especially coming up with metric)
• Consider the large number of multiple-properties into
one “set” so that analysis and decision may be made on
some pre-determined criteria (may be difficult
especially with users’ perception)
– Note that some may be conflicting (e.g. speed vs security)
• In deciding on how much of the huge combinations of
potential deployment choices, consider that:
– there may be n software components and connectors
– may have z pieces of hardware
– then one may have to consider on the order of z n number of
combinations of deployment!
Example of Multiple Deployment
Choices over 2-QoS attributes
Deployment choice 1
Deployment choice 2
100%
Deployment choice 3
80%
which deployment
should we choose?
--- based on -----
Availability
% 60%
Deployment choice 4
40%
20%
100
200
300
400
Performance
500
600
transactions/second
The “planning” considers the attributes, “modeling” and “analysis” help make the deployment choice
Modeling the Deployment
• In order to effectively model the deployment, the
following must be included:
– Software system elements (components and connectors)
• Configuration of these elements
• Parameters
– Hardware system elements (host machines, network,
devices, controllers, etc.)
• Configuration
• Parameters
– Set of constraints placed on these elements and/or
parameters & configurations
– List of QoS (or external) attributes of interest
• Formally defined
• Measurement/metric defined
Even for a moderate size system, this set of considerations for modeling
different deployment alternatives can become an “enormous’ effort !
(look at the configurations on page 395 & 397 of your text)
Analysis of the Deployment Alternatives
• Spending the efforts in modeling the deployment
alternatives would be wasted unless these modeled
results are analyzed.
1. Which of the modeled alternatives are “valid” (satisfy the
various constraints placed on the system)?
2. Within the valid alternatives, which one is the best, next
best, etc. ? (develop a ranked list, if possible)
3. From the ranked list, find the “cut-off” point of those
alternatives that satisfy the QoS attributes, thus coming up
with a smaller set or a single deployment choice.
1, Sometimes, it would be sensible to consider the “preferences” of the
system users’ opinion and preference of the QoS attributes, especially
for the 3rd item above.
2. One may have to consult some algorithms from linear programming or dynamic
“Implementing” the Deployment
• The implementation activities are performed on
– Host system where the system was produced (producer site)
– Target system where the system is to run (consumer site)
• The following is a set of main implementation activities:
– Packaging & Release: develop a list of all the elements needed; the
description of all these elements; the description of the configuration of the
elements; the deployment procedure that must be followed once the
system is transferred to the target system; any additional information for
executing the system at the target; (releasing - transferring the package
from producer to consumer sites)
– Install: after the system package is transferred to the target system the
elements are extracted from the package; assembling (following the
deployment procedure) the extracted elements according to the
configuration description; ensuring that all the required resources are
available and initialized
– Activate: start the installed system at consumer site via a set of commands
– Update: once the initial system is activated, fixes and new releases may be
developed and must be i) packaged & released ; ii) installed; and iii)
activated
“De-Implementing” the Deployment
• There are “de-implementation” related activities:
– De-activate: disabling or shutting down the system on the
target consumer system
– De-install: removing the system from the target consumer
system
– De-release (withdraw) : the producer of the system
announces that the system is withdrawn from the market
and that further support of the system will terminate within
some timeframe.
Software Mobility
• There are two main types of mobility.
– Physical mobility of hardware/software and of the user
across physical locations
– Code mobility of software or portion of software from one
hardware host to another hardware host during the course
of execution of that software; this is really re-deployment of
software
• For code mobility there are 3 paradigms:
– Remote evaluation
– Code on demand
– Mobile agent
Code Mobility Paradigms
• Remote Evaluation: The software component on the source host
has the “know-how” or functionality but not all the resources to
complete a service:
-
possibly deactivated and de- the software component is transferred to another
host which has all the necessary resource (transfer and install)
– executed at the other host (activate and execute)
– the result of execution is transferred back to original host
– the transferred component is installed
• Code on Demand: the needed resources exist on the source host,
but the necessary “know-how” or functionality exist somewhere
else:
–
The needed functionality code is i) located, ii) transferred, iii) installed, iv)
activated and v) executed --- the code is normally not returned back.
• Mobile Agent: the needed functionality exist and part of the
resources exist to execute, but some resources are missing
–
The functional component, along with execution state and the partial
resources are i) moved to another host that has the needed resources, ii)
installed, and iii) executed with the transferred execution state
– De-activating the original function, capture the state, and possibly de-install
the code prior to transferring to another host may be quite “tricky” to do
Challenges of Mobile Code
• What are some of the challenges ?
– System Availability (breakage in availability while
resource or code is in transit)
– System Performance (may be erratic when resource
or code is not available and something needs to be
transferred)
– Locating needed resources or code and matching up
with the rest of the configuration (e.g. version
problem)
– Material in transit may be potentially vulnerable to
security attacks
– etc.