Survey - HP Labs

Download Report

Transcript Survey - HP Labs

Appliance Aggregation Research Group
Terminology, Survey and Scenarios
Ian Taylor, Cardiff University
Dimitris Lioupis, University of Patras
Milan Milenkovic, Intel
Dejan Milojicic, HP Labs
GGF 7, Tokyo, Japan, March 5, 2003
Original Agenda
• Brief intro, Milan Milenkovic & Dejan Milojicic (10m)
• Update on the past activities (5m)
• Review of the documents
– Terminology (Chairs) (10 m)
– Survey (Ian Taylor) (20 m)
– Use cases (Dimitris Lioupis) (20 m)
• Open for discussion (20 m)
• Planning for the next period (5 m)
Overview
•
Setting the Scene
•
Existing Technologies
•
•
•
•
–
–
–
Terminology
Intro to Related Technologies
Appagg Stack
–
BlueTooth, HAVi, UPnP, and Rendezvous
–
P2P, JXTA, Grid Computing, and Jini
Relation to Other Fields
User Scenarios
Next Steps
Summary
Terminology
Definition
Examples
Non Examples
Appliance: a device capable to camera, PDA, laptop,
aggregate with other devices - watch, hotspot
smallest unit of aggregation
no communication,
shared & queued
devices
Ensemble: group of appliances
aggregated to perform a
function greater than their
parts
a camera, PDA, and a
watch used in concert to
capture, annotate, and
communicate pictures
a client-server
relationship such as a
users home PC used to
access Yahoo!
Appliance aggregation: illusion
of multiple appliances that
operate together as a single
entity for a period of time
use the screen of another
device for display; execute a single application
across multiple appliances
execute a distributed
algorithm on a workstation cluster; send a
document to a printer
Terminology, Continued
• Trust: each ensemble should maintain trust boundaries for
its owner
• Data sharing: an ensemble should support sharing of data
and content across the ensemble in a sufficiently
transparent way
• Application sharing: should be possible to share applications
across an ensemble
• Service sharing: it should be possible to share services and
functionality across an ensemble, similarly to applications
Related Technologies
• Grids: Appagg aggregates resources of personal
devices and devices in locale
• P2P: Appagg relies on P2P techniques and the whole
aggregation is essentially P2P-centric
• Middleware: Appagg is middleware – provides the layer
between operating system and applications
Appliance Aggregation: Setting the Scene
Linux
• Connect devices in a simple & coherent fashion into ensembles
• A common model of ownership, shared state, apps, & functionality
• Easier control over appliances, transparent synchronization of data
& continuous access to apps and functionality from any appliance
Appliance Aggregation Stack
Device A
Device B
Applications
Middleware
Services
Transport
Protocols
OS, e.g. OS, e.g.
Mac OS 10
Windows
Network
Jini
JXTA
JXME
APP
AGG
OGSA
Blue
tooth
TCP
UDP
Existing Technologies
•
•
•
•
BlueTooth
HAVi
UPnP
Rendezvous
Bluetooth
• Short-range radio technology aimed at simplifying
• communications between devices and Internet
• data synchronization
• Bluetooth products must pass interoperability test by
Bluetooth Special Interest Group
• Bluetooth 1.0 specification consists of two documents:
• Foundation Core - provides design specifications
• Foundation Profile - provides interoperability guidelines
• Bluetooth contains link and application layer definitions
supporting data, voice, and content-centric apps
• Up to seven simultaneous connections can be established
HAVi
• Sony HAVi - short for Home Audio Video interoperability
• Vendor-neutral audio-video standard
• Aimed specifically at home entertainment environment:
VCR, TV, stereo, security system, video monitors
• Home entertainment & communication devices can be
networked and controlled from a device (eg PC or TV)
• IEEE 1394 (Firewire) for connectivity – up to 800Mbps
UPnP
• Standard based on Internet and Web protocols to
• enable devices to be plugged into a network and
• automatically know about each other
• Target: PC, peripherals, intelligent appliances, & wireless
• When a user plugs a device into the network,
• the device will configure itself
• acquire a TCP/IP address
• announce its presence on network to other devices
• E.g.: send a picture from digital camera directly to printer
• camera issues a "discover" request for any printer
• printer identifies itself and send its location (URL)
• camera & printer negotiate protocol & capabilities (XML)
• camera controls printer & print photograph you selected
Rendezvous
• Networking technology by Apple for
• automatic creation of ad-hoc network of computers and
devices
• discovering the services available on them
• Enable sharing of files, content, printers, and other devices
• E.g: enables discovery, network integration, setup and
administration of router, webcam, printer, and laptop
• Works in the following way
• When a device is added to a network (with no DHCP)
Rendezvous configures it using link-local addressing
• Link-local addressing randomly selects an IP address from
a predefined range and assigns it o the new device
• It verifies if address is used by any other device
• Process is repeated until an unused address is found
Relation to other Technologies
•
•
•
•
P2P File Sharing
JXTA
Grid Computing
Jini
Relation to P2P
• Lessons learned from file sharing
• Stanley Milgram social networking –
make Appagg networks utilize the “small world” effect ?
• KaZaA, Morpheus, Limewire utilize this
• based on a centralized-decentralized structure
JXTA
• Role of JXTA JXME?
• A lightweight JXTA implementation for mobile devices
that could be used to run on appliances
• JXME Goals
1.
2.
3.
4.
5.
6.
Be interoperable with JXTA on desktops and workstations
Provide a p2p infrastructure for small devices
Be simple and easy to use by developers
Be small enough to be used with Cell phones and PDAs
Provide a good user experience
Be CLDC-1.0 and MIDP-1.0 compliant
What is JXTA ?
• A short for juxtapose, as in “side by side”, juxtaposed to
client-server or Web-based computing
• A set of open, generalized P2P protocols allowing any
connected device to communicate and collaborate:
• discovery, resolver, information, pipe binding, endpoint routing & rendezvous
• Designed as a set of building blocks to allow developers
to rapidly develop P2P applications
• Designed to have a peer-to-peer, decentralized model
(also supports traditional client/centralized server)
• As in Gnutella, every JXTA peer can be both a client and
a server
JXTA Design Constraints
Interoperability
• SW vendors tend to create specific code for their services
e.g. file sharing, instant messaging, resulting in
• incompatible systems i.e. not able to interoperate
• vendor-specific P2P user communities
• duplicate effort in software and system primitives
• JXTA attempts to fit in by giving peers a common language
to talk to each other
Platform independence, designed to be independent of:
• programming languages e.g. C or Java
• system platforms e.g. Microsoft Windows and UNIX
• networking platforms (such as TCP/IP or Bluetooth)
Ubiquity
• implementable on every device with a digital heartbeat
• most current are limited certain platforms (Wintel…)
• extendable to new platforms e.g. mobile phones using J2ME
JXTA Architecture
JXTA
Applications
JXTA
Services
JXTA
Core
JXTA Community Applications
JXTA Community
Services
Peer Groups
SUN
JXTA
Services
Peer Pipes
SUN
JXTA
Applications
• Indexing
• Searching
• File Sharing
JXTA
Shell
Peer
Commands
Peer Monitoring
Security (authentication, authorization and on the wire)
Any Peer on the extended Web
Grid Computing
• Grids have infrastructure- v. Appagg’s client-focus
• Grids focus on aggregation of geographically distributed
computation, storage and services
• Appagg focus on personal and environment appliances in
local
• Potential leverage of security/trust & resource aggregation
• OGSA-P2P natural link to Grids
What is Jini?
Historically, operating systems rely on disk drives …
Jini’s goal is to shift this reliance back to the network
Key Features:
• Written in Java
• Builds on Java, object serialization, and RMI to enable
Java objects to move around the network
• Offers network plug and play of services (java objects)
• Allows devices to dynamically establish communication to
share and exchange services across a network
• Provides mechanisms to enable devices to plug together
to form an impromptu community
Jini Players
• Jini defines a runtime infrastructure that enable you to
add, remove, locate, and access services
• There are three main players
a service, e.g printer,
scanner, storage device,
software service etc.
a client which
would like to make
use of this service.
a lookup service (LUS)
- a service locator
… and the network connecting all three - generally be running TCP/IP
Jini In Action: Broad Overview
Jini Service
1. Jini service
discovers LUS
and registers its
service
4. Jini client uses
proxy to contact
Jini service directly
3. Jini client
receives Java
proxy for Jini
Service
LUS –
Lookup Service
the network (TCP/IP)
Jini Client
(Consumer)
2. Jini client
discovers LUS to
locate the desired
Jini service
Scenarios
•
•
•
A Day in the Office
On the way to Work
A Day in Hospital
Scenario 1, A Day in the Office
•
•
•
•
•
Visitors arrival alerts Bill in the office
As they enter room, lights turns on
Bill’s watch identity brings in his virtual desktop
Projectors turns on from the desktop, lights turn off
Voice command to connect other colleagues by phone
Scenario 2, On the way to Work
• Using his PDA Mr. Smith decides whether to go by car or
by train (local inquiry, sensors on roads report on traffic)
• Loads daily news from the nearby kiosks
• Alerts about the stocks, based on his identity
• Download advertisements from the displays in metro
• Act upon stocks while walking to the office
Scenario 3, A Day in Hospital
•
•
•
•
•
•
Doctor access patient’s history using personal appliance
Brings up the pictures from a display device to another
Medicine on stock get checked before prescription is issued
Emergency triggers nearby doctor, using his appliance
His appliance initiates new machinery and …
… results get displayed back on a set of room displays
Summary
• Presented
– Terminology
– Survey
– Scenarios
• Missing
– Introduce security considerations (required in any GGF doc)
– Review by the group and improve the document
– Architectural description of Appagg components & layers
Original Agenda
• Brief intro, Milan Milenkovic & Dejan Milojicic (10m)
• Update on the past activities (5m)
• Review of the documents
– Terminology (Chairs) (10 m)
– Survey (Ian Taylor) (20 m)
– Use cases (Dimitris Lioupis) (20 m)
• Open for discussion (20 m)
• Planning for the next period (5 m)
Next steps
• 1 month reviewing the document
• 3rd week of June Seattle, -2 weeks for document
submitted as a draft
–
–
–
–
–
–
Case studies by Intel (Milan messenger)
Demo something, Chicago (?)
Apple (rendezvous)
Interoperability (long time), power of aggregation
Visionaries of ubiquitous computing
Awareness of general area of pervasive/ubiquitous computing
• Security
• Demos at GGF9? October