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
How do we get arbitrarily powerful, personalized
services on arbitrarily small devices anywhere?

• Harness the intelligence in the infrastructure
• adapt (distill) content to specific device and
  context
• increasingly diverse population
• Connectivity!

4
Imagine

• You walk into a room

5
How do we enabled distributed innovation on
Scalable, Available Services?
Infrastructure Services
gt Push services into an Active infrastructure
6
Ninja Project Goals

• Enable a service-centric world
• 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
• 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

7
A Structured Architecture Approach
8
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

9
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

10
Example Ninja Jukebox
11
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

12
Why Open Infrastructure Services?
DATEK (Trust Contract)
Trusted Client
The Internet
https
13
Embedded Untrusted Interface?
14
One Time Passwd to pseudo-service

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

15
Constrained Personal Device Untrusted Gateway
NINJA
Key Store
Personal Appl
sRMI
Content Filter (pseudonym)
Embeded Untrusted Client
https
DATEK (Trust Contract)
Trusted Client
The Internet
https
16
Example Minimal Trader

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

17
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
18
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
19
Requirements

• 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
• Provide support in the Ninja platform
• Compose services upon it

20
Ninja Platform Architecture

• Base
• Active Proxy
• Units
• Paths
• Service Discovery

21
Base

• 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

22
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

23
iSpace Execution Environment
Untrusted Services
Loader
Trusted Services
Security Mgr
Ninja RMI
JVM persistent store APIs
iSpace
24
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
25
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

26
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 Service
JVM
JNI
Fast Devices
Node HW/OS
Streaming data
27
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)

28
Wide-Area Paths

• Path is a first-class entity
• Explicit or automatic creation
• Can change dynamically
• change path or its operators
• Unit of authentication -- delegate along the path
• Unit of local resource allocation
• bandwidth, cycles, etc.

29
Operators/Connectors

• Operators
• transformation
• aggregation
• agents
• wrappers for legacy servers
• application and transport level
• Connectors
• abstract wires
• ADUs
• varying semantics
• uni/multicast
• includes AN components

• Interfaces
• Set of methods
• Currently in Java w/ XML spec
• Goal inherit COM objects
• Strong types enable automated connection

30
Automatic Path Creation

• After resource discovery
• we know the source sink
• next we must create a path between them
• 1) Find logical path of operators
• path must type check
• 2) Place operators on bases/APs
• some operators have affinity place them first
• some operators may be Active Networks components
• 3) Add connectors as needed

31
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, PDA
  svcs
• service discovery path creation
• Java I/O and fast communication
• cluster-wide data structures

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

33
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)

34
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

35
Thoughts

• Strong typing, mobile code, type safety are
  fundamental in designing, developing, and using
  the next generation infrastructure
• Service Composition is the next level of
  Programming

36
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