PDSG NYU 1 Partitionable Services: A Framework for Seamlessly Adapting Distributed Applications to Heterogeneous Environments Anca Ivan, Josh Harman, Michael

PDSGNYU

1

Partitionable Services: A Framework for Seamlessly Adapting Distributed

Applications to Heterogeneous Environments

Anca Ivan, Josh Harman, Michael Allen, Vijay Karamcheti

Parallel and Distributed Systems Group

New York University

PDSGNYU

2

Partitionable services framework

Motivation:

Applications run in heterogeneous environments Devices with different resource capabilities & security settings

Network state changes in time and space

Problem

Changes in environment state often impact application performance in a negative way.

PDSGNYU

3

Partitionable services framework

Motivation :

Applications run in heterogeneous environments

Network state changes in time and space

Problem :

Changes in environment state often impacts application performance in a negative way.

Solution :

Flexibly adapting the application by placing/moving functionality into the network Descriptive specification of component-based applications

PDSGNYU

4

Running example: Web-based mail application

Components

Properties Confidentiality : privacy required (or not) Trust Level: equivalent to security clearance

Performance Minimum operation time (send/receive) security guarantees

CipherWeak Mail

ClientMail ClientCache

Mail Server

Mail Server

PDSGNYU

5


Mail ServerAccounts: A, B, C

Client A

Client C

Client B

fast, secure slow, secure slow,insecure

PDSGNYU

6




Client A

Client C

Client B

PDSGNYU

7




Client A

Client C

Client B

Cache Mail ServerAccounts: B

PDSGNYU

8




Client A

Client C

Client B

CacheMail ServerAccounts: C

Cipher Cipher

PDSGNYU

9

Partitionable services framework - Modules

Lookup Service

PlanningPolicies

Generic Server

SmockRun-time

wrappercoherence

wrappercoherence

wrappercoherence

PDSGNYU

10

1. Application registers with Generic Server & Planner

Lookup Service

PlanningPolicies

Generic Server

ServiceInformation

1. registerproxy

registerapplicationdescription

SmockRun-time

wrappercoherence

wrappercoherence

wrappercoherence

Mail Server

PDSGNYU

11

2. Client downloads application proxy

Lookup Service

PlanningPolicies

Generic Server

ServiceInformation

1. registerproxy

lookup

2. downloadproxy

Client


SmockRun-time

wrappercoherence

wrappercoherence

wrappercoherence

Mail Server

PDSGNYU

12

3. Client requests access to the application

Lookup Service

3. make request

PlanningPolicies

Generic Server

ServiceInformation

1. registerproxy

lookup

2. downloadproxy

Client


SmockRun-time

wrappercoherence

wrappercoherence

wrappercoherence

Mail Server

PDSGNYU

13

4. Planner computes application partitioning

Lookup Service

3. make request

PlanningPolicies

Generic Server

ServiceInformation

NetworkInformation

1. registerproxy

lookup

2. downloadproxy

4. computepartitioning

Client


SmockRun-time

wrappercoherence

wrappercoherence

wrappercoherence

Mail Server

PDSGNYU

14

5. Planner dynamically deploys the components

Lookup Service

3. make request

PlanningPolicies

Generic Server

ServiceInformation

NetworkInformation

1. registerproxy

lookup

2. downloadproxy

4. computepartitioning

5. deploycomponents

Client


SmockRun-time

wrappercoherence

wrappercoherence

wrappercoherence

Mail Server

PDSGNYU

15

A. Declarative application specification

Applications are fully defined by components and views. Both the components and the views are described at the level of

interfaces.

A view ( ) represents a component, if Its functionality is a subset of the component functionality.

Its data is a subset of the data used by the component.

is a that represents

is a that represents

PDSGNYU

16

Component description

Goal: Flexible, demand-driven component deployments

Solution: Declarative component specification Component functionality (What is the provided service ?) Component linkages (How to connect the components ?) Component properties (When and where to deploy them?)

Declarative component description XML-based implementation

PDSGNYU

17

What services do the components provide ? Functionality.

Components and views are described at the level of interfaces.

Each interface has a set of desired properties.

<View> Name: CacheMailServer Represents: MailServer

<Implements> Name: MailServerInterface

Properties: Confidentiality = T; TrustLevel = Node.TrustLevel

</Implements>

</View>

MailServerInterface

Conf = T; Trust = Node.Trust

PDSGNYU

18

MailServerInterface

Conf = T; Trust = Node.Trust

How to combine components? Valid linkages.

<View> Name: CacheMailServer Represents: MailServer

<Implements> Name: MailServerInterface

Properties: Confidentiality = T; TrustLevel = Node.TrustLevel

</Implements>

<Requires> Name: MailServerInterface

Properties: Confidentiality = T; TrustLevel > 2

</Requires>

</View>

MailServerInterface

Conf = T; Trust > 2

MailServerInterface

Conf = T; Trust = 5

PDSGNYU

19

When and where to deploy components?Conditions and behaviors

Conditions dictate when and where to deploy components. E.g. The node needs to be trusted enough.

Behaviors indicate the component demeanor. E.g. CPU consumption, bandwidth consumption.

<View> Name: CacheMailServer Represents: MailServer <Conditions> Properties: Node.TrustLevel {1…3} </Conditions> <Behaviors> RRF: 0.2 </Behaviors></View>

PDSGNYU

20

B. Planner

Goal: Satisfy client requests by dynamically deploying and instantiating components in the network

Input: application description + network description

Output: component mappings

2 step process Find all valid linkages Map linkages onto the network

PDSGNYU

21

Step 1: Find all valid linkages

Problem: Given a set of components, finds all valid virtual paths.

Valid linkage requires match between required and implemented interfaces.

PDSGNYU

22

Step 2: Map virtual paths onto the network

Problem: Given a set of virtual paths and the current state of the network, find the best mapping of a path. 2.1. Deploy a component on a node only if the properties of the

node respect the component requirements. 2.2. Two components are deployed only if the required interfaces

properties are compatible with the implemented interfaces properties, given the properties of the network.

2.3. Components are deployed only if the expected resource usage does not exceed the link/node capacities

PDSGNYU

23

Mapping component linkage on network path

MSI MSIMSIMCI MSI

MCI = MailClientInterface

MSI = MailServerInterface

Secure, fast

Insecure, slow

PDSGNYU

24

Step 2.1: Deploy components on nodes.

A component is deployed on a certain node only if the properties of the node respect the conditions of the component.

<View> Name: CacheMailServer

<Conditions> Properties: Node.TrustLevel {1…3} </Conditions>

</View>

? ??

MSI MSIMSIMCI MSI

PDSGNYU

25

Step 2.2: Map virtual connections over physical links

Interfaces match if names & properties match

Interface properties are modified by the properties of the network. Linkages can become invalid because of the environment.

MSI MSIMSIMCI MSI

PDSGNYU

26

Step 2.2: Map virtual connections over physical links

2.2. Two components are deployed only if the required interfaces properties are compatible with the implemented interfaces properties, given the properties of the network.

In Env Out

T T T

F * F

* F F

Property modification rules

Conf=FConf=T

MSI

Conf = T

MSI

Conf = T

MSI

Conf = T

MCI MSI

Conf = T

PDSGNYU

27

C. Run-time system

Wrapper: environment common for all nodes Implemented in Java Dynamic class loading and installation

Cache coherence protocol Consistency at the level of views Conflicts triggered based on a dynamic conflict map

• Each view is defined by a set of properties. Two views conflict if the intersection of their sets is not empty.

PDSGNYU

28

Case study: Framework benefits and costs

Goal: Framework automatically deploys component-based applications with low costs (dynamic static).

Framework Application Test bed

Code - JDK 1.3

Lookup service based on Jini 1.2

Descriptions use XML Winter Pack 01

Code – JDK 1.3

Cryptography - Cryptix JCE implementation

Pentium III (1 GHz) machines

Click modular router simulates network delays

Brite tool to generate network topology

PDSGNYU

29

Initial state

New York

San Diego

Seattle

Secure link (0 ms / 100 Mb/s)

Insecure link

200ms20 Mb/s

400ms8 Mb/s

100ms50 Mb/s

Network node

PDSGNYU

30

Remote mail client, trusted domain

New York

San Diego

Seattle

Secure link (0 ms / 100 Mb/s)

Insecure link

200ms20 Mb/s

400ms8 Mb/s

100ms50 Mb/s

Network node

PDSGNYU

31

Static vs. dynamic deployment

One time costs – planning & deploying components

Dynamic deployment Static deployment

0

0.5

1

1.5

2

2.5

3

1 2 3 4 5

Number of clients

Tim

e se

nd

mes

sag

e [m

s]

Dynamic, no cache

Static, no cache

Dynamic, cache

Static, cache

PDSGNYU

32

Related work – Adaptation infrastructures

Adapting the network to the application: GARA, Darwin

Adapting the application to the network CANS, EPIQ, ErDOS Active Harmony, Tunability Framework, Active Streams,

Eager Handlers

Partitionable Services Framework Flexible composition of general components, based on

descriptive specification. Maps application properties to network properties.

PDSGNYU

33

Conclusions

Flexible framework that allows seamless access to component-based applications Declarative component description Flexible, automatic deployment of components

Case study – mail application Dynamic deployment Static deployment

Early version of the infrastructure and the mail applicationwww.cs.nyu.edu/~pdsg - Software link

PDSGNYU

34

Thank you !

PDSGNYU

35

Future work

Improve the run-time deployment of components (decrease one-time costs).

Improve the planning algorithms: Integrate framework with network monitoring tools Develop & deploy AI-based planner

Automatically trigger re-deployment when network properties change and no longer satisfy component requirements

Improve the descriptive specification for better expression of application properties/requirements.

PDSGNYU

36

Partitionable services architecture - Modules

Generic server Handles application registration and user requests

Planner Links components into virtual paths Dynamically maps virtual paths onto network

Lookup service

Wrappers Run as special environment on all nodes Provides cache coherence service, if needed

PDSGNYU

37

How to flexibly connect the components? Linkages

C2 C4

C3C1

I1

I6

I7

I3

I4

I5

I4I2

I3

I1

I2

PDSGNYU

38

Link components that implement interfaces required by other components.

C2 C4

C3C1

I1

I6

I7

I3

I4

I5

I4I2

I3

I1

I2

PDSGNYU

39

Application vs. Environment

View environment and application properties as credentials

[ Node-<xyz> JDK1.4-machine ] NYU-SysAdmin

Delegation credentials define mappings between the two

[ JDK1.4-machine AppTrustLevel = 5 ] AppDeployer

Determine if an env. resource satisfies application property Need to find a chain of valid credentials (trust management

problem)

PDSGNYU

40

Case study - scenarios

Local client SF - Static deployment (comp are installed manually) DF - Dynamic deployment (comp are installed dynamically)

Remote client + cache close to remote client SS0, DS0 – cache coherence protocol is disabled SS500 (1000), DS500 (1000) – the cache coherence is triggered

every 500 (1000) messages

Remote client SS - Static deployment (client connects over slow connection)

Documents

PDSG NYU 1 Partitionable Services: A Framework for Seamlessly Adapting Distributed Applications to Heterogeneous Environments Anca Ivan, Josh Harman, Michael