1. Matthew Moccaro Chapter 10 – Deployment and Mobility PART II

2. MobilityMobility Tool Support Challenges in Migrating Code Deployment Activities (cont.)

3. 3.Analysis 4. Implementation

4. Deployment Activities (cont.)  Developing a deployment model can be a huge undertaking.  Doing this is only worthwhile if you use the model to make decisions.  To use the model, you need to analyze the model.

5. Deployment Activities (cont.) Similar Diagrams to those located on page 397 Candidate Deployment Views

6. Deployment Activities (cont.) 1.Are both deployments valid? 2.Which deployment is better? 3.Is there a better deployment than this one? Ask these questions:

7. Deployment Activities (cont.) 1. Are both deployments valid?  If system constraints are specified rigorously, this becomes an easy task.  A simple constraint satisfaction problem.

8. Deployment Activities (cont.) 2. Which deployment is better?  More difficult to decide.  Quality of Service dimensions can help.  Durability over Latency  Introduce system users and capture their preferences.

9. Deployment Activities (cont.) 3. Is there a better deployment than this one?  Even more difficult to decide.  What is the best possible deployment?  Algorithms to help us:  MIN and MINLP  Greedy, Genetic, Decentralized

10.  Only two of these can be achieved at one time.  Some or all of the users are likely to be unhappy with the system.  Functionality-Scalability-Performance

11. Deployment Activities (cont.)  Our software is now ready to be effected.  Activities involved in this process:  Release / De-Release  Install / De-Install  Activate / Deactivate  Update  Adapt

12. Deployment Activities (cont.) 1.Release 2.Install 3.Activate 4.Deactivate 5.Update 6.Adapt 7.De-Install 8.De-Release Release Packaged so that it can be transferred to consumer sites. System may also need to be advertised to the customer. Includes description, software modules, deployment model, deployment procedures, and any additional information. Install Now that the system is packaged and transferred, it can be installed. Includes extracting, assembling, and configuring the system. Activate The system must now be activated on the target hosts. Involved providing a command to start up the system. Many times involves an activation key. Deactivate Involves disabling or shutting down a system. Update A system must be maintained. Updates are initiated by the system’s producers. Updates must be properly reflected in all architectural models. Adapt Encompasses a wide range of activities. Involves changing the system, may be dynamically. Redeployment is also possible. De-Install System is removed from consumer sites. Process may be simple, may be complex. Having current architectural models will make this process easier. De-Release System is retired or no longer supported. Can be done for many reasons. Usually advertised.

13. Tool Support  Software developers need tools to:  Support deployment modeling  Support implementation activities  Model – Analyze – Implement – Monitor - Update

14. Tool Support

15. MobilityMobility  Once a system is in operation, parts of it may need to be redeployed or migrated.  Code mobility / logical mobility – a piece of software moves across hardware hosts during system execution.  For all this to be possible, certain facilities such as dynamically linked libraries or dynamic class loading must be available.

16. MobilityMobility  Stateful / Strong Mobility – A module contains a run time state.  Stateless / Weak Mobility – Only the code itself needs to be migrated.  Stateful mobility is much more difficult, as migration can only be done at certain times, and its effect on the rest of the system considered.

17. MobilityMobility Mobility Paradigms Remote Evaluation Code-on- Demand Mobile Agent

18. MobilityMobility Remote Evaluation 2+22+244 Source host has the know-how, but not the resources to perform a service. The module is transferred to the destination host, where it is executed and the result is sent back to the source host.

19. MobilityMobility Code-on- Demand Destination host requests the know- how, and has the resources to perform a service. The module is transferred to the destination host, where it is executed. 2+22+244

20. MobilityMobility Source Has: 1.Know-How 2.Execution State 3.Access to some resources The module is transferred to the destination host, where it is executed completely. 2+2+32+2+377 Mobile Agent 4+34+3

21. Challenges in Migrating Code  Run time mobility depends on several factors, including the support of dynamic linking and loading of modules  Quiescence  Provided Quality of Service - QoS

22.  It can be unsafe to migrate a component while it is: In the middle of processing Waiting for a result from another component. Other components are requesting its services. Challenges in Migrating Code

23.  The system must provide facilities to suspend all interactions while the process takes place.  Two capabilities are required for this:  Embodied Suspend  Insulation of external components Challenges in Migrating Code

25. MobilityMobility Tool Support Challenges in Migrating Code Deployment Activities (cont.)