300 likes | 307 Views
This article discusses the concept of Appliance Aggregation, which aims to connect devices in a seamless manner, enabling easy control, data synchronization, and continuous access to applications and functionality. It explores related technologies such as Bluetooth, HAVi, UPnP, and Rendezvous, and their relation to other fields like P2P, JXTA, Grid Computing, and Jini. The article also presents user scenarios and outlines the next steps in this field.
E N D
Appliance Aggregation Research GroupTerminology, 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 • Terminology • Intro to Related Technologies • Appagg Stack • Existing Technologies • BlueTooth, HAVi, UPnP, and Rendezvous • Relation to Other Fields • P2P, JXTA, Grid Computing, and Jini • User Scenarios • Next Steps • Summary
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
ApplianceAggregation: 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 APPAGG Applications Jini Middleware Services OGSA JXTA JXME Bluetooth Transport Protocols TCP UDP OS, e.g. Windows OS, e.g. Mac OS 10 Network
Existing Technologies • BlueTooth • HAVi • UPnP • Rendezvous
Bluetooth • Short-range radio technology aimed at simplifying • communications between devices and Internet • data synchronization • Bluetooth productsmust 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 benetworked 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 • 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 Shell Peer Commands JXTA Architecture JXTA Applications JXTA Community Applications SUN JXTA Applications JXTA Services JXTA Community Services SUN JXTA Services • Indexing • Searching • File Sharing Peer Groups Peer Pipes Peer Monitoring JXTA Core 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? Jini’s goal is to shift this reliance back to the network Historically, operating systems rely on disk drives … 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 clientwhich would like to make use of this service. a service, e.g printer, scanner, storage device, software service etc. 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 4. Jini client uses proxy to contact Jini service directly Jini Client (Consumer) 3. Jini client receives Java proxy for Jini Service 2. Jini client discovers LUS to locate the desired Jini service 1. Jini service discovers LUS and registers its service LUS – Lookup Service the network (TCP/IP)
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