The Ninja Service Platform Architecture or, “The Right Way to do Thin Client Computing”

1. The Ninja Service Platform Architectureor,“The Right Way to do Thin Client Computing” Steve Gribble UC Berkeley CS Division gribble@cs.berkeley.edu

2. 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.

3. 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

4. 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

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

6. 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

7. 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

8. Base Implementation • 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 iSpace iSpace iSpace SAN Multispace cluster

9. 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) • KillService semantics unclear… objects vs threads? Sandbox that contains untrusted, uploaded services. Currently just the JRE’s standard appletSecurityMgr Ground up re-implementation of Sun RMI. Includes authenticated, secure RMI, multicast RMI, and soon, AM-RMI 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. iSpace Execution Environment Untrusted Services Loader Trusted Services Security Mgr Ninja RMI JVM + persistent store APIs iSpace

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

11. Multispace services Multispace Loader iSpace Multispace • 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 • 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 atomicity required of service instances 1 2 3

12. 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

13. 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

14. 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.

15. 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