150 likes | 269 Views
PRISM Programming in the Small and Many. Nenad Medvidovic Marija Mikic-Rakic (neno,marija)@usc.edu. Past and Present. The past: programming in the small small, simple systems single developer programs are hacked developer = customer = user The present: programming in the large
E N D
PRISMProgramming in the Small and Many Nenad Medvidovic Marija Mikic-Rakic (neno,marija)@usc.edu
Past and Present • The past: programming in the small • small, simple systems • single developer • programs are hacked • developer = customer = user • The present: programming in the large • large, complex systems • powerful hardware • teams of developers • systems are engineered • many people, many roles
Present and FutureProgramming in the Small and Many • Highly distributed systems • Dynamic • Mobile • Heterogeneous • Resource-constrained • Ad-hoc network connections Software development in such a setting - Prism
This has been your computer • This will become your computer Prism Challenges • Resource constraints • Demand highly efficient computation, communication, and memory footprint • Demand unorthodox solutions • e.g., off-loading components • Hardware and software heterogeneity • Proprietary operating systems • Dialects of programming languages • Device-specific data formats • Lack of support for inter-device interaction • Lack of support for code mobility
Prism Objectives • Asynchronous communication • Peer-to-peer interactions • Dynamic reconfiguration • Deployment • Mobility • Disconnected operation • Execution context awareness • Scalability • Efficiency
Palm-3 Palm-2 PC Palm-1 iPAQ Prism Style • Extensively leverages C2 • Peer-to-peer interactions • Side component ports, peer connectors, peer messages • Preserves substrate independence • Architectural self-awareness • Application level • Meta level • Admin component • Continuous analysis component • Message types • Application data • Component content • Architectural model A Requests Notifications B C D Peer
Prism Connectors • All Prism connectors are able to exchange data, code, and architectural models • Two interaction techniques • Client-server, Peer-to-peer • Four connector categories • Spanning contexts • Address spaces, Processes, Machines • Marshalling and unmarshalling of information • XML encoding • Wireless interaction (IR) • Network link monitoring • Mechanisms • CORBA, RMI, Sockets, ILU, Q, Polylith • Synchronous and asynchronous interaction • Message routing policies • Unicast • Multicast • Broadcast • Delivery guarantees • Support for real-time constraints pending • Useful in connector-to-connector interaction • Reusable security module • E.g., used in IR border connector • Multiple such modules would allow altering security policy on the fly • Open issue • Mismatched security policies by interacting connectors • Ensure reliable component upgrades • Monitor multiple versions of a component • Correctness, Performance, Reliability • Functional behavior of system unaffected • Performance possibly affected • Possible impact on real-time systems • Basic • Border • Secure • Multiversioning
Request 5 000 000 Request 100 000 Implementing Prism Architectures Size1.35KB at system start-up max 56KB Performance500MHz PentiumIII RAM 256 +Java KVM framework +50 components above +one connector + one component below +50 threads +100 000 sent messages ______________________________________________________________________________________________________~ 4.7 seconds Adjustable threading Adjustable scheduling
Available Troops Repository Map Repository Admin Component Admin Component Map Display Map Display Admin Component Strategy Analyzer Troops Deployer Map Display M M Strategy Analyzer Strategy Analyzer` Admin Component Admin Component M M Map Display Map Display M M M M M M A Prism Application M
Leverages ComponentContent message • Leverages Prism’s support for code mobility • Assumes preloading a skeleton configuration on each device • Implemented as an extension to Visio (COTS) Deployment Support add(DataRepository: source PC): PC weld(TopBorderConnector,C_IPAQAvailableTroops): iPAQ peerWeld(G_AvailableTroops,SideBorderConnector):Palm-1
Support for Disconnected Operation • Minimize the risks associated with disconnection • Maximize availability / minimize degradation • Reroute communication • Fetch components before disconnection occurs • Relevant factors for prefetching • Statefulness • Event frequencies across network links • Dependencies of candidate components • Type of disconnection • Time to disconnection • Required and available memory • Network bandwidth
Defining the Problem • Minimum K-cut problem • Memory as an additional constraint • Knapsack - simplification • Benefit of migration does not change if the component is migrated along with some other components • For each component we need • Required memory • Benefit of migration Benefit = 0 Benefit = Benefit + fi* (1 - di) • Available memory TAM = min(M, t * nb)
Time to Disconnection Message Connection Speed Processing Component Strategy Analyzer Available Memory fi War Manager di Resulting Set Deployment Advisor Analyze strategy Strategy Analyzer 0.06 1 Required Memory (KB) 1s 13KB/s 13 50KB 9 Strategy Analyzer 5 Simulate War Manager 0.16 0 Benefit 0.5s 40KB/s 0.31 15KB 0.16 War Manager Deployment Advisor 0.18 Advise Deployment Advisor 0.18 0 1s 30KB/s 40KB War Manager Deployment Advisor Strategy Analyzer Deploy Strategy Analyzer 0.37 0 Results
Future Work • Real-time guarantees • Decentralized ownership • Trust • Resource analysis • Automated optimized application deployment
Web Site • http://sunset.usc.edu/~softarch/Prism/