1 / 27

Presented by: Onur Celebioglu

The Multispace: an Evolutionary Platform for Infrastructural Services ( S. Gribble, M. Welsh, E. Brewer, D. Culler). Presented by: Onur Celebioglu. Services on Internet. Evolution towards a service oriented infrastructure Banks, restaurants, communities Increasing number of .com businesses

marty
Download Presentation

Presented by: Onur Celebioglu

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. The Multispace: an Evolutionary Platform for Infrastructural Services ( S. Gribble, M. Welsh, E. Brewer, D. Culler) Presented by: Onur Celebioglu

  2. Services on Internet • Evolution towards a service oriented infrastructure • Banks, restaurants, communities • Increasing number of .com businesses • These applications are different from traditional applications

  3. Desired Properties • Available • Scalable • Simple interfaces in front of complex systems • Open to rapidly evolve and customizable by the end-user.

  4. Building Services • Insufficient amount of reusable, general-purpose building blocks • Two different approaches: • Inflexible, highly tuned, custom-built services • Emergent Services using distributed objects

  5. Customized Services • Most wide-spread type • Target a specific application, hardware, etc.. • Advantages: • High performance, robust operation • Disadvantages: • Inflexible, unscalable, may require massive effort to modify.

  6. Using Distributed Objects • Use small components over large area (e.g. CORBA, SUN RMI). • Use different compositions of components to add/modify service. • Unmanageable over wide area. • May cause inconsistency

  7. “Base” Approach • Encapsulate services and state in a controlled environment. • Undistributed to outside, distributed within. • Distribute the objects across the nodes of a cluster of workstations.

  8. Design Principles • Availability, scalability • Base • Service Flexibility • Receptive execution environments • Dynamic code generation

  9. Availability, Scalability • Base -- Cluster of workstations • Clusters provide: • High availability, • scalability, • fast communications, • easier administration.

  10. Receptive Environments • Dynamic configuration of system. • Remotely upload components as necessary. • Use JVM to provide node homogeneity. • Service Components = Java classes

  11. Interface • Should present a single interface while taking care of load-balancing, failover, etc… • Use a front-end machine (single point of failure, performance bottleneck) • Use multiple front end machines • Naming problem (Round robin DNS, static assignment…) • Consistency problem.

  12. Dynamic Code Generation • Clients use redirector stubs to access the service • Stubs are generated dynamically during execution, clients obtain them from a registry • Stubs take care of load-balancing, failover… • Base advertises state to clients • intelligence is injected into the client

  13. Implementation • NinjaRMI: Communications • iSpace: Single node execution environment • MultiSpace: Collection of nodes

  14. RMI Call Stub Code Skeleton NinjaRMI • Success -- method invoked successfully • Failure -- Randomly choose & try different stub Method Call

  15. Additions to Sun RMI • Unicast, UDP-based RMI • Beacons, log, no reliability • Multicast, UDP-based RMI • Services associated with multicast groups • Secure Unicast RMI • Certificate based authentication, Diffie-Helman key exchange, 3DES encryption.

  16. Performance Rtt + JVMs = 0.316msec

  17. Layer 2: iSpace • JVM running component loading service • Manage resources, provides protection, security (using security manager) • Relies on JVM as an OS • iSpace Security manager

  18. Layer 3: MultiSpace • Collection of iSpaces • Provide state info to nodes • Each iSpace sends beacons • Beacons carry RMI stubs (~500 bytes) • Each node has enough information to reconstruct or advertise services • But what about scalability?

  19. Layer 3: MultiSpace • Services can modify beacons • Beacons can be used for decentralized load balancing • Also included; • a distributed hash table • uptime monitoring capabilities

  20. Ninja Jukebox Application • Cluster of 100+ Sun workstations. • CD ripper • push ripper to stations with CDs • scan CD • contact CDDB • make & advertise play list • Master directory • Make global play list available over RMI and HTTP

  21. Ninja Jukebox Performance • Utilizes security extensions to NinjaRMI. • Authentication overhead = 10 sec per certificate exchange. • Streaming mp3 files through the network.

  22. Keiretsu • Provide instant messaging between heterogeneous devices • Clients that can’t run a JVM connect to a proxy • Proxy functionality can be pushed on the nodes as needed

  23. Keiretsu Service API public void identifySelf( String clientName, KeiretsuClientIF clientStub); public void disconnectSelf(String clientName); public void injectMessage(KeiretsuMessage msg); public String[] getClientList(); • All nodes maintain a table of others. • Each node can route messages to every other node.

  24. Keiretsu Performance • Spends CPU to process client stubs • Poor service design

  25. Discussion • Code Mobility • Not only for delivering code to clients, but also useful in the MultiSpace as in Ninja example • Bases simplify the work • Author still needs to ensure consistency , availability. • Java Environment (Modular, safe, slow)

  26. Conclusions • Base: A controlled environment that abstracts load-balancing, failover, etc… • Ninja Jukebox • Rapid evolution, run-time binding of components... • Keiretsu • Simple service building tool, fault-tolerance...

  27. Questions

More Related