Proactive Infrastructure: The Ninja Service Platform

1
Proactive InfrastructureThe Ninja Service
Platform

• David Culler, Eric Brewer, Anthony Joseph Randy
  Katz
• UC Berkeley
• ninja.cs.berkeley.edu

2
Moving Away from the average Device
3
Core Questions

• Scalable, Highly Available Services gt
  well-engineered, well- maintained and relatively
  centralized platforms
• How do we preserve the distributed innovation of
  the personal computer era in a service-centric
  world
• Emerging devices are diverse and highly
  constrained
• How do we deliver powerful services on small
  devices?
• gt Push services into an Active infrastructure

4
Ninja Project Goals

• Enable a service-centric world (rather than
  applications)
• Move applications into the core of the network
• Robust infrastructure for services
• Scalable, highly available, and persistent
• Customizable enable personal preferences (and
  code!)
• Support a wide-range of devices pagers to PCs
• Easy to author despite these challenges
• Universal framework for constructing and
  deploying services
• Programming model and execution environment for
  scalable services
• Authentication and pay-per-use services
• Automatic discovery, composition and use of
  sub-services

5
Ex Personal Information Management

• Users (will) have lots of (new) end devices
• Each device has its own address, capabilities,
  etc.
• Universal Inbox gives users control over how
  info reaches them
• Transcoders adapt content to end device

6
Example Ninja Jukebox
7
Example Millennium Cluster
Cell Phones

• Large-Scale Campus-wide Testbed
• Management by Services
• push monitoring service into nodes
• clusterview service logs, aggregates, manages
• Resource allocation by market services
• banks, brokers, merchants

8
Traditional Internet Service
DATEK (Trust Contract)
Trusted Client
The Internet
https
9
Infrastructure Services Embedded Untrusted
Interface
10
Example One Time Passwd to pseudo-service

• Cannot increasing the security level of the
  communications channel so decrease the value of
  the content.

11
Constrained Personal Info Appliance - Untrusted
Gateway
NINJA
Key Store
Personal Appl
sRMI
Content Filter (pseudonym)
Embeded Untrusted Client
https
DATEK (Trust Contract)
Trusted Client
The Internet
https
12
Example Minimal Trader

• Shared secret between user and keystore
• keystore maps to service identity /
  authentication
• Content filter transcodes to very concise info to
  pilot

13
Uniform Access to Diverse Services
NINJA
Key Store
Personal Appl
sRMI
GWY
RMI PXY
ST
CF
Trade-R-us
Trade-R-us
Content Filter (pseudonym)
Embeded Untrusted Client
https
DATEK (Trust Contract)
Trusted Client
The Internet
https
14
Automated Clients, ...
NINJA
Key Store
Personal Appl
sRMI
GWY
RMI PXY
ST
CF
BOT svc
Trade-R-us
Trade-R-us
Content Filter (pseudonym)
Embeded Untrusted Client
https
DATEK (Trust Contract)
Trusted Client
The Internet
https
15
Requirements Summary

• Utility scalable, highly available, reliable
• Support for persistent data
• Support for streams, not just RPC
• Support for automatic data transformation
• Support for fine-grain authentication and payment
• The Ninja architecture addresses these

16
What is a Service?

• Service
• Highly available program (or cooperating
  programs)
• fixed interface at a fixed location (lives in the
  infrastructure)
• guarantees about performance, availability,
  consistency
• Strongly typed interface
• Multiple services of a given type compete
• Compete on location, price, robustness,
  quality, brand name
• Service Discovery Service (SDS)
• Find best service of given type
• current approach based on weighted statistical
  matching
• Construct a path from client to service

17
Impose Structure to Simplify
18
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

19
Base Implementation
iSpace
iSpace
iSpace
iSpace
SAN
Multispace cluster

• iSpace the building block of a Base
• receptive execution environment
• intra-Base primitives (stub generation,
  persistent data repository, etc.)
• Multispace cluster-wide naming and resource mgmt

20
iSpace Execution Environment
Untrusted Services
Loader
Trusted Services
Security Mgr
Ninja RMI
JVM persistent store APIs
iSpace
21
Multispace
Services names are at the granularity of the
entire cluster, not individual nodes.

• RMI Redirector Stubs assembled
• run-time compiled RMI superstub
• contains all of a services instances stubs
• stub selection policy
• fail-over, broadcast, multicast, fork, etc.
• currently, idempotency and atomicity required of
  service instances

1
2
3
22
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.
• consistent, persistent, and highly available
• Tree / Trie / Treap

23
Active Proxy

• Local execution environment (interchangeable)
• No support for persistent data (soft state)
• Runs an iSpace but not a MultiSpace
• Bootstraps small devices into the infrastructure
• could run Jini or other local discovery
  mechanisms
• could be in a home or basestation
• performs resource discovery and path creation for
  the device
• typically well connected (while device is not)

24
Fast Communication and I/O in Java

• Scalable Ninja services need full capabilities of
  Base devices
• fast SAN, IO rivers
• JNI overhead too large
• can violate type safety
• chokes JVM
• JDI by JIT interpositioning
• intelligent devices reflected as Java objects
• JIT interprets operations on devices
• data buffers bypass JVM
• ex Java AM over VIA on Myrinet

Scalable SVC
JVM
JDI?
Streaming data
25
Status

• Several services running all the time
• Release 1.0 now available
• contact info ninja.cs.berkeley.edu
• Includes
• NinjaRMI, including authentication
• iSpace/MultiSpace infrastructure
• SDS (soon)
• Several example services, including Ninja Jukebox
• Active current focus
• driving applications e-mail, group calendar
• service discovery path creation
• Java I/O and fast communication
• cluster-wide data structures

26
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)
• Integration with GSM cell phones and PDA-based UI
  (soon)
• 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.

27
Coming Applications

• Universal Inbox
• e-mail, FAX, pager, voicemail accessible anywhere
• persistent data (yes we will use it!)
• Infrastructure-based group calendar
• handles both web and PDA access
• supports disconnected operation
• Universal Remote
• multiple-UI control of household/room devices
• automatic UI generation
• Ecash Mint
• Authenticated service to act as digital secure
  cash mint
• Enable real pay-per-use services (e.g. Coke
  machine)

28
Ninja Requirements Summary

• Utility scalable, highly available, reliable
• Base, MultiSpace, Smart Client, NinjaRMI, and
  mobile code
• Architecture for easy development/deployment of
  services
• Support for persistent data
• Base and persistent hash tables
• Support for streams, not just RPC
• Operators and wide-area paths
• Support for automatic data transformation
• Wide-area paths Strong typing Automatic Path
  Creation
• Span spectrum of end-user devices dynamically
• Support for fine-grain authentication and payment
• Authenticated and pay-per-use services

29
To Read More

• http//ninja.cs.berkeley.edu
• The MultiSpace an Evolutionary Platform for
  Infrastructural Services, S. Gribble, Welsh,
  Brewer, and Culler. 1999 Usenix Annual Technical
  Conference.
• An Architecture for a Secure Service Discovery
  Service, Czerwinski, Zhao, Hodes, Joseph, and
  Katz., MobiCom '99