Presented by: Onur Celebioglu

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