Anca Ivan, Josh Harman, Michael Allen, Vijay Karamcheti Parallel and Distributed Systems Group

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

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.

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

4. 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

5. fast, secure slow, secure slow,insecure Running example: Web-based mail application

6. fast, secure slow, secure slow,insecure Running example: Web-based mail application

7. fast, secure slow, secure slow,insecure Running example: Web-based mail application

8. fast, secure slow, secure slow,insecure Running example: Web-based mail application Cipher Cipher

9. Partitionable services framework - Modules

10. Mail Server Application registers with Generic Server & Planner

11. Mail Server 2. Client downloads application proxy

12. Mail Server 3. Client requests access to the application

13. Mail Server 4. Planner computes application partitioning

14. Mail Server 5. Planner dynamically deploys the components

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

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

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

18. 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

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>

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

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.

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

23. Mapping component linkage on network path MCI MSI MSI MSI MSI Secure, fast Insecure, slow MCI = MailClientInterface MSI = MailServerInterface

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> MCI MSI MSI MSI MSI ? ? ?

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. MCI MSI MSI MSI MSI

26. 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

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.

28. Case study: Framework benefits and costs • Goal: Framework automatically deploys component-based applications with low costs (dynamic  static).

29. Initial state Seattle New York San Diego

30. Remote mail client, trusted domain Seattle New York San Diego

31. Static vs. dynamic deployment • One time costs – planning & deploying components • Dynamic deployment  Static deployment

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.

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 application www.cs.nyu.edu/~pdsg - Software link

34. Thank you !

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.

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

37. How to flexibly connect the components? Linkages I3 I3 I6 I1 C2 C4 I7 I4 I4 I1 I2 C1 C3 I2 I5

38. Link components that implement interfaces required by other components. I3 I3 I6 I1 C2 C4 I7 I4 I4 I1 I2 C1 C3 I2 I5

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)

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)