The Ninja Service Platform Architecture or, “The Right Way to do Thin Client Computing” Steve Gribble UC Berkeley CS Division

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 battlesCarefully 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 worldIt’s a connected world –“access is the killer app” –use intelligent infrastructure to bridge between complex online services and simple devices NinjaNinja –software infrastructure to support next generation services and heterogeneous devices

Ninja Project Goals Infrastructure for Internet-based Services which are...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 servicesUniversal 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 servicesAuthenticated and pay-per-use services –HINDE: architecture for digitally secure e-cash Span the spectrum of end-user devicesSpan 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

AP Active Proxy: Bootstraps thin devices into infrastructure, runs mobile code AP Workstations & PCs Architecture Overview Base: Scalable, highly- available platform for persistent-state services Internet PDAs (e.g. IBM Workpad) Cellphones, Pagers, etc.

Bases A physical, administrative, and logical boundaryA 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 servicesBase 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 worldHides service implementation from rest of world –granularity of services is at cluster level, not node level

Services: Programmatic Access ServiceService –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)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: the building block of a BaseiSpace: 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 mgmtMultispace: cluster-wide naming and resource mgmt iSpace SAN Multispace cluster iSpace

JVM provides code mobility and service upload capability, plus strong typing of service interfaces. Added distributed hash table API (think Linda space) to JRE. Ground up re-implementation of Sun RMI. Includes authenticated, secure RMI, multicast RMI, and soon, AM- RMI and VIA-RMI. Name service, RMI stub registry, and service control API: LoadService (URL) interf.[ ]=ListServices stub=GetService(name) KillService(name) KillService semantics unclear… objects vs threads? Sandbox that contains untrusted, uploaded services. Currently just the JRE’s standard appletSecurityMgr Service is an interface, plus objects that implement that interface. Trusted Services Ninja RMI iSpace Execution Environment JVM + persistent store APIs Security Mgr Loader Untrusted Services iSpace

Multispace iSpace Multispace services Multispace Loader Cluster-wide name service, RMI stub registry, and service control API. Services names are at the granularity of the entire cluster, not individual nodes. Service instances must be restartable, and must provide their own inter- instance consistency mechanisms. (Hint: use the consistent distributed data structure primitives.)

Multispace iSpace Multispace services Multispace Loader Multicast soft-state beacons to distribute Multispace stateMulticast soft-state beacons to distribute Multispace state –beacons contain list of service instances on each node, and an RMI stub for each service instance RMI “Redirector Stubs” assembledRMI “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 atomicity required of service instances 1 2 3

Distributed Data Structures Solve the state management problem once and provide high-level abstractions to service authorsSolve 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:Example data structures: Log –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 URLProvides “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 topics Service FE itself is very simpleService FE itself is very simple –400 semicolons of C 130 for app-specific logic 270 for threads, HTTP munging, etc. 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 InboxUniversal Inbox – , FAX, pager, voic accessible anywhere Universal RemoteUniversal Remote –multiple-UI control of household/room devices –automatic UI generation Ecash MintEcash Mint –Authenticated service to act as digital secure cash mint