RoadMap Platform for Infrastructural Services · 1999. 11. 16. · • Provides instant messaging service via Web, 1/2-way pagers, PDAs, etc. – Automatic Java Interface to HTML

The MultiSpace: An evolutionaryPlatform for Infrastructural

ServicesGrobble, Welsh, Brewer

Presented by

Mauricio Plaza

RoadMap

• Introduction

• Basics

• MultiSpace Implementation

• Ninja Architecture

• Applications

Intro

• Strategies Internet Services– Inflexible, highly tuned, hand constructed

– “emergent services” (dist obj)

Basics

• What is a BASE?

• Design– Bases

– Execution Envs

– Dynamic Code Gen

• What is a MultiSpace?

MultiSpace Implementation

• NinjaRMI

• iSpace

• MultiSpace

•

APActive Proxy:Bootstraps thin devicesinto infrastructure, runsmobile code

AP

Workstations & PCs

Ninja Architecture Overview

Base: Scalable, highly-available platform forpersistent-state services

Internet

PDAs(e.g. IBM Workpad)Cellphones, Pagers, etc.

•

Bases• A physical, administrative, and logical boundary

– a collection of machines geographically co-located

– administrative guarantees: no network partitions (!), constant powersupply, trust within the Base

• Base platform simplifies authoring of services

– cluster primitives

• task execution, naming, and monitoring

• load balancing, failure detection, and restart

– persistent data primitives and guarantees

• distributed, available data structures

• Hides service implementation from rest of world

– granularity of services is at cluster level, not node level

Services: Programmatic Access• Service

– Highly available program (or cooperating programs)

• fixed interface at a fixed location (in a Base)

• guarantees about performance, availability, consistency

– Strongly typed interface

• Multiple services of a given type compete

• Compete on location, price, robustness, “quality”, brand name

• Finding services: Service Discovery Service (SDS)

– Find “best” service of given type

• “best” according to multiple criteria (cost, geographic andadministrative location, speed, reputation, etc.)

– “Path” construction tied to service discovery

Base Implementation

• iSpace: the building block of a Base

– receptive execution environment

– intra-Base primitives (stub generation, consistent persistent datarepository access, etc.)

• Multispace: cluster-wide naming and resource mgmt

iSpace

SAN

Multispace cluster

iSpace iSpace iSpace

JVM provides code mobility and service uploadcapability, plus strong typing of service interfaces. Addeddistributed hash table API (think Linda space) to JRE.

Ground up re-implementationof Sun RMI. Includesauthenticated, secure RMI,multicast RMI, and soon, AM-RMI and VIA-RMI.

Name service, RMI stubregistry, and servicecontrol API:

• LoadService (URL)• interf.[ ]=ListServices• stub=GetService(name)• KillService(name)

KillService semanticsunclear… objects vsthreads?

Sandbox that containsuntrusted, uploadedservices. Currently justthe JRE’s standardappletSecurityMgr

Service is an interface, plus objectsthat implement that interface.

Tru

ste

dS

erv

ice

s

Ninja RMI

iSpace Execution Environment

JVM + persistent store APIs

Security Mgr Load

er

UntrustedServices

iSpace

Multispace

iSpace

Multispaceservices

Mul

tispa

ceLo

ader

Cluster-wide nameservice, RMI stubregistry, and servicecontrol API. Servicesnames are at thegranularity of the entirecluster, not individualnodes.

Service instances mustbe restartable, and mustprovide their own inter-instance consistencymechanisms. (Hint: usethe consistentdistributed datastructure primitives.)

Multispace

iSpace

Multispaceservices

Mul

tispa

ceLo

ader

• Multicast soft-state beacons to distributeMultispace state

– beacons contain list of serviceinstances on each node, and an RMIstub for each service instance

• RMI “Redirector Stubs” assembled

– run-time compiled RMI superstub

– contains all of a service’s instance’s stubs

– stub selection policy

• fail-over, broadcast, multicast, fork, etc.

– currently, idempotency and atomicityrequired of service instances

1

2

3

Existing Applications– Ninja "NOW Jukebox"

• Harnesses CD-ROM drives on Berkeley Network of Workstations• Plays real-time MPEG-3 audio served from 40+ CD's worth of music

– Voice-enabled room control (ICEBERG)• Speech-to-text Operators control room services (camera, lights,

microphone)• Eventual integration with GSM cell phones and PDA-based UI

– Parallelisms service• Inversion of Yahoo! directory provides related links support• Uses distributed hash table - service code only ~100 lines worth

– NinjaFAX• Programmable remotely-accessed FAX machine service• Send/receive FAXes; authentication used for access control

– Keiretsu: The Ninja Pager Service• Provides instant messaging service via Web, 1/2-way pagers, PDAs,

etc.

– Automatic Java Interface to HTML forms generation

– Computational economy support (Millennium project)

Example Service: The NinjaJukebox

• Original goal: turn Berkeley’s NOW into a jukebox

– 30-50 unused CD-ROM drives in the workstation cluster

– write software to “rip” music, stream to client in real-time

• Goals quickly expanded as it became successful

– evolved into a communal, collaborative music service

• people add or subtract from jukebox at their own whim

• convert from raw CD audio to MP3 compressed audio

• authentication + access control to address copyrightissues

• collaborative filtering became needed as body of musicgrew

– a perfect service to explore Ninja’s core infrastructure!

Jukebox Design Philosophy

• Desire: rapid evolution and prototyping

– principle : disciplined use of distributed components

• “separation of concerns”: natural decomposition into services

• RPC ingrained into the architecture

• Java was our language of choice

– principle : use of strongly typed interfaces

• embodies the declaration of components’ “service contracts”

• if chosen well, never need to change, and can share data withother interfaces

• Desire: autonomy of Jukebox contributors

– principle : soft-state to achieve eventual consistency

• all information is treated as a hint that will time out

– e.g., existence/location of a song, capability to play a song

The Jukebox, v1.0

• Composed of the following components:

– SoundSmiths

• each indexes a single CD, and beacons the MusicDirectory

• exports typed API to clients for music selection

• audio streamed over untyped HTTP

• autonomy via beacons: their presence and data are soft-state

– MusicDirectory

• centralized soft-state repository gathers beaconed indexes

• API presents an eventually consistent music list to clients

• shields clients from discovering location of all SoundSmiths

– Client GUI

• song tree, songlist editor, and familiar CD controls

– fast-forward, play, pause, etc.

The Jukebox, v1.0

�������������������� �� ��� �

� ������� ������

������ ������� �����

������������ ���� ��

�������� ���������� ��

��������������������

����� ������� ����������������

������ ������� �����

������������ ���� ��

�������� ���������� ��

��������������

��������

���������������� � ��

The Jukebox, v1.0

�������������������� �� ��� �

� ������� ������

�������� ���������� ��

������ ������� �����

������������ ���� ��

������ ������� �����

������������ ���� ��

�������� ���������� ��

��������������������

��������������

��������

���������������� � ��

��� ��� ���� ��� �������������

v2.0: added MP3 playback

• The MP3 revolution happened

– MP3s: great compression, store music in file system

• batch-convert raw audio to MP3, then switch to serving MP3

– to deploy, we simply subclassed existing SoundSmiths

• subclass preserved existing SongListing data structures

• clients already handled MP3 streams over HTTP– could deploy new feature while the service was running!

�������� ���������� ��

������ ������� �����

������������ ���� ��

!"!"��������������������

!"!"����������

������������ ��##�� ��##

v2.0: added security infrastructure

• popularity ⇒ copyright infringement

– need security policy plus authentication infrastructure

– policy: you can access a song if you prove you uploaded it

– mechanism: authenticated RMI

• SecureRMI

– can authenticate RMI endpoints, can encrypt session

– CA tools, CertificateStore cert. repository service

– flexibile authenticators: could easily extend to pay-per-use

• SoundSmith enhancement: ACLs

– when client requests a song, verify access via ACL

– returns a song capability: good for 30 seconds or one use

v3.0: introduced collaborative filtering

• created and deployed a new “DJ” service

– enhanced client to report events to DJ

• fast-forward, stop: infer song likes/dislikes

• explicit rating UI: client overrides DJ’s inferences

• a client’s preferences emerge over time

– all client’s preferences are stored in infrastructure

• decouples human from a particular client machine

• human carries credentials - all other state in infrastructure

• “DJ” can optionally publish client’s preferences

– each client creates a combination of filters

• e.g. (2 x Nikita) and (2 x Steve) and (not Mark)

– client weights song list by this filter

v3.0 User Interface

����$ ������$ �� ���������% ���� ��� �������������% ���� ��� ���� �� �� �������� �� ������ && ������� ��������� ��

�' ����������� ���� ��� ���� �' ���( ��%�' ����������� ���� ��� ���� �' ���( ��%�)�� � � ���� ������� �(�� ������� ��� ����)�� � � ���� ������� �(�� ������� ��� ���

�������� ��� � �������% ����� �(���� �� �'�������� ��� � �������% ����� �(���� �� �'

v3.0 User Interface (continued)

�(� ����� �����%�(� ����� �����%����� ������� �� �� ����� ���

� ���� ������ ��%� ���� ������ ��%�������������� �)����� ���)����� ��

�� ����� ���

Nija JukeBox Summary

• The Ninja Jukebox– one such service: a communal, collaborative

music Jukebox

– three distinct service versions• adding features such as authentication, multiple

music formats, and collaborative filtering

– design principles for rapid evolution• careful use of a distributed object infrastructure

• use of strongly-typed interfaces

Other Example: Keiretsu

Instant Messaging

Q: What does the word Keiretsumean, anyway?

• A: Keiretsu is the Japanese concept whereina group of related companies work togetherfor each other's mutual success. Weactually named the Ninja instant-messagingdemo for Keiretsu under the mistakenimpression that the word translates to a``system of shared information''. Still, it'sironically apropos.

Keiretsu : Instant Messaging

• Soft-state registry

• Redirector Stubs

• Palm Pilots as simple iSpace node

• AP converts simple text to NijaRMI msgs

• AP have Java-based mobile code

Imagine• You walk into a room

You have complete, secure,optimized access to local devicesand your private resources

• Your PDA connects to the localinfrastructure and asks it to build acustom GUI

• Next, your PDA asks theinfrastructure for a path out toyour personal information space,where agents are processing youre-mail, v-mail, faxes, and pages

Dicussion

• Code Mobility

• Bases (The solution?)

• Java as Internet service env

References

• The Ninja Jukebox, by Ian Goldberg, Steven D. Gribble, David Wagner, and Eric A.Brewer. 2nd USENIX Symposium on Internet Technologies and Systems, Boulder, CO,October 1999.

• The MultiSpace: an Evolutionary Platform for Infrastructural Services, by Steven D.Gribble, Matt Welsh, Eric A. Brewer, and David Culler. To appear, Proceedings of the 1999Usenix Annual Technical Conference, Monterey, CA, June 1999.

• Jaguar: Enabling Efficient Communication and I/O from Java, Matt Welsh and DavidCuller. To appear in Concurrency: Practice and Experience, Special Issue on Java for High-Performance Applications, December, 1999.

• An Architecture for a Secure Service Discovery Service, by Steven E. Czerwinski, BenY. Zhao, Todd D. Hodes, Anthony D. Joseph, and Randy H. Katz. Fifth AnnualInternational Conference on Mobile Computing and Networks (MobiCom '99), Seattle,WA, August 1999, pp. 24-35.