1. 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.

2. A Wireless Sensor Network System Sensor 1 Sensor 5 Sensor 3 Sensor 4 i-phone Sensor 1 Network Backbone There are 4 types of hardware: - i-phone - HUB Server - Gateway PC - Sensors with different platforms and capacity Tied together via network and wireless sensors HUB gateway

3. 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 back- up and recovery Locating the hardware/software/service: after re-deployment, if moved, finding the mobile software and re-executing is difficult

4. 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.Hardware architecture 2.Network architecture 3.Peripheral devices and configuration 4.System software, device drivers and middle-ware 5.Co-requisite & Pre-requisite application software 6.Co-requisite & pre-requisite data and data files (e.g. initialized information) Think about your recently purchased software --- how did it get deployed?

5. Breaking Down Deployment “Major” Activities 1.Planning 2.Modeling 3.Analysis 4.“implementing”

6. 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.

7. 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!

8. Example of Multiple Deployment Choices over 2-QoS attributes Performance transactions/second Availability % 20% 100% 80% 60% 40% 100500400300200600 Deployment choice 1 Deployment choice 2 Deployment choice 3 Deployment choice 4 which deployment should we choose? --- based on ----- The “planning” considers the attributes, “modeling” and “analysis” help make the deployment choice

9. 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)

10. 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 3 rd item above. 2. One may have to consult some algorithms from linear programming or dynamic programming for searching for the optimal solution

11. “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

12. “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.

13. 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

14. 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

15. 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.