Post on 25-Sep-2020
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.