Proactive Infrastructure:
The Ninja Service Platform
David Culler
Eric Brewer, Anthony Joseph & Randy Katz
UC Berkeley
ninja.cs.berkeley.edu
Moving Away from the ‘average’ Device
Server
Client
Infomation
appliances
Scalable, Available
Internet Services
- millions of clients
- always up
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!
Devices
Laptops, Desktops
Imagine
• You walk into a room
• Your PDA connects to the local
infrastructure and asks it to build a
custom GUI
• Next, your PDA asks the
infrastructure for a path out to
your personal information space,
where agents are processing your
e-mail, v-mail, faxes, and pages
You have complete, secure,
optimized access to local devices
and your private resources
How do we enabled distributed innovation
on Scalable, Available Services?
Clients
Clients
Clients
Open
Infrastructure
Services
Clients
Clients
Servers
Clients
Servers
Servers
=> Push services into an Active infrastructure
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
A Structured Architecture Approach
• Bases (1M’s)
–
–
–
–
–
scalable, highly available
persistent state (safe)
databases, agents
“home” base per user
service programming environment
• Active Proxies (100M’s)
– not packet routers
– bootstrap thin devices into
infrastructure
– soft-state and well-connected
• Units (1B’s)
–
–
–
–
sensors / actuators
PDAs / smartphones / PCs
heterogeneous
Minimal functionality: “Smart
Clients”
Wide-Area Path
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
Ex: Personal Information Management
E-Mail store
AP1
AP5
PSTN
IP Core Network
Directory
Server1
Univ-Inbox
Service
AP4
AP2
Directory
Servern
AP3
GSM
Voice Mail store
Laptop (VAT)
• 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
Example: Ninja Jukebox
3
.au/.mp3
player
WWW
Browser
HTTPd
service
Web page
with song
playlists
Music Directory
service
iSpace
Music stream
(.au or .mp3)
4
Pushes an index of
locally available songs to
the master directory.
2
CD “ripper”
service
Fetches track/title &
artist information
from an online DB.
CDDB
service
iSpace
1
Example: Millennium Cluster
Massive Cluster
Clusters
Gigabit Ethernet
Servers
Wireless
PDAs
Cell Phones
Future Devices
• 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
Desktop
PCs
Why Open Infrastructure Services?
Trusted
Client
https
DATEK
(Trust Contract)
Embedded Untrusted Interface?
NINJA Infrastructure Services
Key Store
sRMI
Embeded
Untrusted
Client
Trusted
Client
https
https
Content Filter
(pseudonym)
DATEK
(Trust Contract)
One Time Passwd to pseudo-service
• Cannot increasing the security of the channel so decrease the
value of the content.
Constrained Personal Device & Untrusted
Gateway
NINJA
Key Store
Personal
Appl
Embeded
Untrusted
Client
Trusted
Client
sRMI
GWY
https
https
RMI
PXY
CF
ST
Content Filter
(pseudonym)
DATEK
(Trust Contract)
Example: Minimal Trader
• Shared secret between
user and keystore
• keystore maps to service
identity / authentication
• Content filter transcodes
to very concise info to
pilot
Uniform Access to Diverse Services
NINJA
Key Store
Personal
Appl
Embeded
Untrusted
Client
Trusted
Client
sRMI
GWY
https
https
RMI
PXY
CF
ST
Content Filter
(pseudonym)
Trade-R-us
Trade-R-us
DATEK
(Trust Contract)
Automated “Clients”, ...
NINJA
Key Store
Personal
Appl
sRMI
GWY
RMI
PXY
CF
ST
BOT svc
Embeded
Untrusted
Client
Trusted
Client
https
https
Content Filter
(pseudonym)
Trade-R-us
Trade-R-us
DATEK
(Trust Contract)
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
Ninja Platform Architecture
•
•
•
•
•
Base
Active Proxy
Units
Paths
Service Discovery
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
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
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.
Services names are at the
granularity of the entire cluster, not
individual nodes.
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.
• consistent, persistent, and highly available
– Tree / Trie / Treap
Fast Communication and I/O in Java
• Scalable Ninja services need full
capabilities of Base devices
Scalable Service
JVM
Node
HW/OS
Streaming
data
JNI
Fast
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
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)
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.
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
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
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
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.
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)
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
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
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