Software Architecture

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

2. Overview: Deployment Activities (cont.) Tool Support Mobility Challenges in Migrating Code

3. Deployment Activities (cont.) Analysis Implementation

4. Deployment Activities (cont.) Analysis • 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.) Which is better? Ask these questions: Are both deployments valid? Which deployment is better? Is there a better deployment than this one?

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. Software Engineering Axiom: Better-cheaper-faster – pick any two! • 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.) Implementation • 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.) Implementation Release Install Activate Deactivate Update Adapt De-Install De-Release Activate Install Deactivate Release Update Adapt De-Install De-Release • System is removed from consumer sites. • Process may be simple, may be complex. • Having current architectural models will make this • process easier. • 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. • Now that the system is packaged and transferred, it • can be installed. • Includes extracting, assembling, and configuring the • system. • Involves disabling or shutting down a system. • A system must be maintained. • Updates are initiated by the system’s producers. • Updates must be properly reflected in all • architectural models. • 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. • Encompasses a wide range of activities. • Involves changing the system, may be dynamically. • Redeployment is also possible. • System is retired or no longer supported. • Can be done for many reasons. • Usually advertised.

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

14. Tool Support

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

16. Mobility • 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. Mobility • Mobility Paradigms Remote Evaluation Code-on-Demand Mobile Agent

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

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

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

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

22. Challenges in Migrating Code Quiescence • 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.

23. Challenges in Migrating Code Quiescence • 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

24. Challenges in Migrating Code Quality of Service - QoS

25. Conclusion: Deployment Activities (cont.) Tool Support Mobility Challenges in Migrating Code

26. Thanks!