Software Architecture

Matthew Moccaro

Chapter 10 – Deployment and Mobility

PART II

Mobility

Tool Support

Challenges in Migrating Code

Deployment Activities (cont.)

Overview:

Deployment Activities (cont.)3. Analysis

4. Implementation

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.

Deployment Activities (cont.)

Similar Diagrams tothose located on

page 397

Candidate Deployment Views

Deployment Activities (cont.)

Which is better?

1. Are both deployments valid?

2. Which deployment is better?

3. Is there a better deployment than this one?

Ask these questions:

Deployment Activities (cont.)

1. Are both deployments valid?

If system constraints are specified rigorously, this becomes an easy task.

A simple constraint satisfaction problem.

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.

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

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

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

Deployment Activities (cont.)

Implementation

1.Release2.Install3.Activate4.Deactivate5.Update6.Adapt7.De-Install8.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.

Tool Support

Software developers need tools to:

Support deployment modeling

Support implementation activities

Model – Analyze – Implement – Monitor - Update

Tool Support

Mobility

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

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.

Mobility

Mobility Paradigms

Remote Evaluatio

n

Code-on-Demand

Mobile Agent

Mobility

Remote Evaluatio

n

2+2 4

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.

Mobility

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+2 4

Mobility

Source Has:1. Know-How2. Execution State3. Access to some

resources

The module is transferred to the destination host, where it is executed completely.

2+2+3

7Mobile Agent

4+3

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

It can be unsafe to migrate a componentwhile it is:

• In the middle of processing• Waiting for a result from another

component.• Other components are requesting its

services.

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

Challenges in Migrating Code

Quiescence

Challenges in Migrating Code

Quality of Service - QoS

Mobility

Tool Support

Challenges in Migrating Code

Deployment Activities (cont.)

Conclusion:

Thanks!