Transcript The Ninja Service Platform Architecture or, “The Right Way to do Thin Client Computing” Steve Gribble UC Berkeley CS Division [email protected].

The Ninja Service Platform
Architecture
or,
“The Right Way to do Thin Client Computing”
Steve Gribble
UC Berkeley CS Division
[email protected]
Approaches to Date
Sony MagicLink: No connectivity to speak of, limited
application capability, but a very flashy OS. This PDA was a
(small) island unto itself. Pessimal form-factor.
Palm Pilot / IBM WorkPad: Thin, zippy, out-of-the-way OS,
huge bazaar following. Originally intended for occasional
synchronization and long periods of disconnected use. (We’re
changing that usage model.)
Windows CE devices: Big OS attempting to fool apps into
thinking PDA is a full-fledged desktop machine. Rich
hardware. Applications are scaled down versions of
Windows 95 apps (e.g. pocket IE), and perform very poorly.
Our Approach
• Carefully choose where you fight your battles
– slim OS on the PDA
– split applications between PDA and infrastructure
• solve hard problems in infrastructure, not PDA
• PDA is mostly a UI, plus a soft-state cache
• It’s a connected world
– “access is the killer app”
– use intelligent infrastructure to bridge between complex
online services and simple devices
• Ninja
– software infrastructure to support next generation services
and heterogeneous devices
Ninja Project Goals
• Infrastructure for Internet-based Services which are ...
–
–
–
–
Scalable: support large and growing user population
Highly-available: continually up and running
Fault-tolerant: mask hardware & software faults
Customizable: Enable users to inject personal preferences (and code!)
• Universal architecture for constructing and deploying services
– programming model and execution environments for scalable services
– mobile code for rapid service deployment
• Authenticated and pay-per-use services
– HINDE: architecture for digitally secure e-cash
• Span the spectrum of end-user devices
– PCs, workstations, web browsers, PDAs, cell-phones, (2-way) pagers, …
– infrastructure automatically deploys components needed to assist
impoverished devices in accessing services
Architecture Overview
Base: Scalable, highlyavailable platform for
persistent-state services
Workstations & PCs
AP
Internet
AP
Cellphones, Pagers, etc.
Active Proxy:
Bootstraps thin devices
into infrastructure, runs
mobile code
PDAs
(e.g. IBM Workpad)
Bases
• A physical, administrative, and logical boundary
– a collection of machines geographically co-located
– administrative guarantees: no network partitions (!),
constant power supply, 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 and
administrative location, speed, reputation, etc.)
– “Path” construction tied to service discovery
Base Implementation
iSpace
iSpace
iSpace
iSpace
SAN
Multispace cluster
• iSpace: the building block of a Base
– receptive execution environment
– intra-Base primitives (stub generation, consistent persistent
data repository access, etc.)
• Multispace: cluster-wide naming and resource mgmt
iSpace Execution Environment
Untrusted
Services
Security Mgr
Loader
Sandbox that contains
untrusted, uploaded
services. Currently just
the JRE’s standard
appletSecurityMgr
Trusted
Services
Service is an interface, plus objects
that implement that interface.
Name service, RMI stub
registry, and service
control API:
• LoadService (URL)
• interf.[ ]=ListServices
• stub=GetService(name)
• KillService(name)
Ninja RMI
KillService semantics
unclear… objects vs
threads?
Ground up re-implementation
JVM + persistent store APIs
of Sun RMI. Includes
authenticated, secure RMI,
iSpace
multicast RMI, and soon, AMRMI and VIA-RMI.
JVM provides code mobility and service upload
capability, plus strong typing of service interfaces. Added
distributed hash table API (think Linda space) to JRE.
Service instances must
be restartable, and must
provide their own interinstance consistency
mechanisms. (Hint: use
the consistent
distributed data
structure primitives.)
Multispace
services
iSpace
Multispace
Loader
Multispace
Cluster-wide name
service, RMI stub
registry, and service
control API. Services
names are at the
granularity of the entire
cluster, not individual
nodes.
• Multicast soft-state beacons to
distribute Multispace state
– beacons contain list of service
instances on each node, and an RMI
stub for each service instance
Multispace
services
Multispace
Loader
Multispace
iSpace
• RMI “Redirector Stubs” assembled
1
2
– run-time compiled RMI superstub
– contains all of a service’s instance’s stubs
– stub selection policy
• fail-over, broadcast, multicast, fork, etc.
3
– currently, idempotency and atomicity
required of service instances
Distributed Data Structures
• Solve the state management problem once and
provide high-level abstractions to service authors
– Hypothesis: given a set of highly-available, scalable,
persistent data structures, persistent BASE services will
be much easier to construct
• Example data structures:
– append/truncate-only Log
• system logging, generational mailstore, undo/redo logs, etc.
– Hash table
• web cache, search index/data, mint accounts, etc.
• pop quiz: why and how is this different than a filesystem?
– Tree / Trie / Treap
• to get interval search capabilities
Example Application: Parallelisms
• Provides “relevant site”
information given a URL
– an inversion of Yahoo! directory
• Yahoo!: returns URLs from a
hierarchy of topics
• Parallelisms: builds an index of all
URLs, and returns other URLs in
same topic groups
– read-mostly traffic, nearly no
consistency requirements
– large database of URLs
• ~ gigabyte of space for 1.5 million
URLs and 80000 topics
• Service FE itself is very simple
– 400 semicolons of C
• 130 for app-specific logic
• 270 for threads, HTTP munging, etc.
http://ninja.cs.berkeley.edu/~demos/
paralllelisms/parallelisms.html
Existing Applications
– Ninja "NOW Jukebox"
• Harnesses Berkeley Network of Workstations
• Plays real-time MPEG-3 audio served from 110+ CD's worth of music
– Voice-enabled room control
• Speech-to-text Operators control room services (camera, lights, microphone)
• Eventual integration with GSM cell phones and PDA-based UI
– Stock Trading Service
• Accesses real-time stock data from Internet
• Programmatic interface to buy/sell/trade stocks through online brokerage
– 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, WorkPads, etc.
Future Applications
• Universal Inbox
– e-mail, FAX, pager, voicemail accessible anywhere
• Universal Remote
– multiple-UI control of household/room devices
– automatic UI generation
• Ecash Mint
– Authenticated service to act as digital secure cash mint