1 / 29

Using Views for Customizing Reusable Components in Component-Based Frameworks

Using Views for Customizing Reusable Components in Component-Based Frameworks. Anca-Andreea Ivan Vijay Karamcheti New York University. Application Adaptation. Motivation: Applications run in heterogeneous environments. Network state changes over time. Problem:

kimo
Download Presentation

Using Views for Customizing Reusable Components in Component-Based Frameworks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using Views for Customizing Reusable Components in Component-Based Frameworks Anca-Andreea Ivan Vijay Karamcheti New York University

  2. Application Adaptation Motivation: • Applications run in heterogeneous environments. • Network state changes over time. Problem: • Changes in environment state often impact application performance in a negative way. Solution: • Flexibly adapt the application to environment changes.

  3. Choices for Application Adaptation Two classes of application adaptation: • Applications adapt by themselves • Requires code modification • Systems adapt applications: • Applications expose knobs: Tunability Framework • Systems adapt applications by deploying components: • Static linkages: CCM, .NET • Dynamic linkages: Partitionable Services Framework-PSF, CANS

  4. Mail Client Weak Mail Client Cache Mail Server Mail Server Cipher Running Example: Web-Based Mail Application • Components: • Clients can require certain quality of service levels: • Minimum operation time (send/receive). • Confidentiality : privacy required (or not).

  5. Partitionable Services Framework A B PSF secure, fast insecure, slow

  6. Partitionable Services Framework - Protocol User makes request PSF authorizes user PSF customizes comp PSF extracts properties PSF creates plan PSF authorizes nodes PSF deploys comp Nodes authorize comp Nodes link/run comp

  7. Challenges • Descriptive application specification that comprises general application properties. [HPDC 2002] • Efficient planning process that considers application and environment properties. [IPDPS 2003] • Efficient and flexible component customization. • Distributed, single sign-on, cross-domain authorization. • Efficient and secure deployment process.

  8. Challenges • Descriptive application specification that comprises general application properties. [HPDC 2002] • Efficient planning process that considers application and environment properties. [IPDPS 2003] • Efficient and flexible component customization. • Distributed, single sign-on, cross-domain authorization. • Efficient and secure deployment process.

  9. Component Customization - Summary • Definition of component customization • Advantages of component customization • View definition • Example • View run-time support • View generator • View deployment system

  10. Component Customization • “Component customization” denotes the automatic creation of new components based on old components and a few simple rules. • Base component is and implements • MessageInterface • AddressInterface • NotesInterface • One possible component is and implements • MessageInterface • AddressInterface

  11. Advantages of Component Customization • Increased chances to find a valid deployment plan: • New components can have different properties. • Customized, single sign-on access control: • Customizing / removing / adding methods. • Distributing only the minimum necessary code to users . • No need to access sources (Java bytecode modification). • Ease the programming effort: • Defining simple rules instead of duplicating code.

  12. View Definition • A view () represents a component, if • Its functionality is derived from the component functionality. is a for • Its data is a subset of the data used by the component. is a for

  13. MessageInterface m1 x = 3 view WeakMailClient class MailClient MessageInterface m1 AddressInterface AddressInterface m2 m2 y = 4 NotesInterface NotesInterface m3 m3 z ++ z ++ m4 a = 10 Using Views x = 3 y = 6 y = 4 z ++

  14. XML View Description <View name = WeakMailClient /> <Represents name = MailClient /> <Restricts> <Interface name = MessageInterface /> <Interface name = AddressInterface /> <Adds_Methods> <MSign> m4 <MBody> a = 10 <Customizes_Methods> <MSign> m2 <MBody> y = 6

  15. View Generation Tool - VIG • VIG is an automatic view generator. • Input: original component + view definition rules • Output: new component (e.g. view) • Based on bytecode modifier (Javassist) • Operations allowed when defining a view: • Add new fields; copy fields from the original component; • Add new methods; copy or customize methods from the original component; • Restrict interfaces; add new interfaces.

  16. Views – Run-Time System • User makes request. • PSF authorizes user. • PSF customizes components. • PSF extracts link & node & component properties. • PSF creates a valid plan. • PSF authorizes nodes. • PSF deploys components on nodes. • Nodes authorize components. • Nodes run & link components. PSF A

  17. Challenges in deploying views • Expressing views properties (environment properties): • General properties (e.g. privacy, OS - version) • Different administrators. • Authorizing users, node, views: • Different domains. • No centralized certification authority. • No total knowledge about the credential space. • Linking views: • Secure communication channels. • Continuous monitoring of the trust relationships.

  18. View – Run-Time System • Distributed trust managements system • Each domain has its own certification root and defines its own meaningful credentials. • dRBAC [ICDCS 2002] • Communication abstraction to establish secure, authenticated, and continuously monitored links between components. • Switchboard [RESH 2002]

  19. A.user A.partner [→ Dell.linux ]Dell [→ A.comp ]A [→ A.comp ]A [ →A.partner]A Using Views, dRBAC, and Switchboard [Dell.linux→Mail.Node]Mail PSF A

  20. Current status • JDK 1.4 • Bouncycastle 1.16 • Linux, Windows 2000 (XP) • Partitionable Services Framework • http://www.cs.nyu.edu/pdsg/pdsg.htm - Software/PSF • PSF, VIG, Sekitei • Disco: • http://www.cs.nyu.edu/pdsg/pdsg.htm - Software • dRBAC, Switchboard

  21. Related Work • Cross-domain authorization: • DCE, DCOM, Corba • Multiple certification roots • No requirement for total knowledge • Expressing environment properties: • CANS, Ninja, previous version of PSF • Translating between environment and application props. • Granularity of access control: • DCE, Corba, DCOM • Flexible, single sign-on access control

  22. Contributions • Automatic creation of new components (e.g. views) by customizing old components • Increased chances of successful planning • Customized, single sign-on access control • Distributed trust management and role-based access control system (dRBAC) • Expressing component and environment properties • Secure communication channels with continuous monitoring of trust relationships (Switchboard)

  23. Thank you ivan@cs.nyu.edu http://www.cs.nyu.edu/~ivan

  24. Partitionable Services Framework - Protocol • User makes request to access service. • PSF authorizes user before granting access to service. • PSF customizes the set of available components. • PSF extracts link & node properties. • PSF creates a valid plan. • PSF authorizes nodes before deploying components. • PSF deploys components on the nodes. • Nodes authorize components before running them. • Nodes link & run components on nodes.

  25. dRBAC – Distributed RBAC • Self-certifying delegations: [  NY.user ]NY • Third-party delegations: [  NY.user] SE • Assignment delegations: [ SE NY.user ‘] NY • Attributes for delegations [  NY.user w/ BW=100kb ] NY

  26. [  NY.user ] NY User Authorization New York [ SE NY.user ‘] NY Seattle [  NY.user] SE

  27. [  NY.user ] NY [  NY.user] SE [  NY.user] SE ?  NY.user Distributed Authorization [ SE NY.user ‘] NY [ SE NY.user ‘] NY

  28. Node Authorization & Translation Environment Properties New York [  Dell.linux] Dell Seattle [  IBM.xp] IBM [ Dell.linuxMail.node w/ Secure= T ] Mail Mail [ IBM.xp Mail.node w/ Secure= F ] Mail

  29. Component Authorization [  NY.exec w/ CPU = 100 ] NY New York [  NY.exec w/ CPU = 100 ] NY [  NY.exec w/ CPU = 100 ] NY [  NY.exec w/ CPU = 100 ] NY Seattle [NY.exec  SE.exec w/ CPU = 80 ] NY

More Related