400 likes | 520 Views
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. Partitionable services framework. Motivation:
E N D
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
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.
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
Mail Client Weak Mail Client Cache Mail Server Mail Server Cipher 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
fast, secure slow, secure slow,insecure Running example: Web-based mail application
fast, secure slow, secure slow,insecure Running example: Web-based mail application
fast, secure slow, secure slow,insecure Running example: Web-based mail application
fast, secure slow, secure slow,insecure Running example: Web-based mail application Cipher Cipher
Mail Server Application registers with Generic Server & Planner
Mail Server 2. Client downloads application proxy
Mail Server 3. Client requests access to the application
Mail Server 4. Planner computes application partitioning
Mail Server 5. Planner dynamically deploys the components
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
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
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
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 = Node.Trust MailServerInterface Conf = T; Trust > 2 MailServerInterface Conf = T; Trust = 5
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>
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
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.
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
Mapping component linkage on network path MCI MSI MSI MSI MSI Secure, fast Insecure, slow MCI = MailClientInterface MSI = MailServerInterface
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> MCI MSI MSI MSI MSI ? ? ?
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. MCI MSI MSI MSI MSI
Step 2.2: Map virtual connections over physical links MSI Conf = T 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. MCI MSI Conf = T MSI Conf = T MSI Conf = T Conf=T Conf=F Property modification rules
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.
Case study: Framework benefits and costs • Goal: Framework automatically deploys component-based applications with low costs (dynamic static).
Initial state Seattle New York San Diego
Remote mail client, trusted domain Seattle New York San Diego
Static vs. dynamic deployment • One time costs – planning & deploying components • Dynamic deployment Static deployment
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.
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 application www.cs.nyu.edu/~pdsg - Software link
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.
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
How to flexibly connect the components? Linkages I3 I3 I6 I1 C2 C4 I7 I4 I4 I1 I2 C1 C3 I2 I5
Link components that implement interfaces required by other components. I3 I3 I6 I1 C2 C4 I7 I4 I4 I1 I2 C1 C3 I2 I5
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)
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)