1. Recombinant Computing
Evan Welbourne, 590UC

2. Problem: Interoperability
Future UbiComp environments:
“Combinatorial explosion” of devices and services
Each addition should add value to the entire network
Challenges for a solution:
no foreknowledge
must discover, accommodate
must be flexible and generic

3. Solution: Recombinant Computing
Three Foundation Technologies: Component arch + Resource Discovery + Mobile Code
Basic Premises:
Fixed, domain-independent interfaces
Mobile code
User-in-the-loop
Allows users to “recombine” devices for previously unplanned tasks

4. Why Not Jini? Why is recombinant computing better than related work?
Sun’s Jini also uses mobile code to support extensibility but doesn’t separate semantics from syntax in interfaces e.g. getName(), getPrinterType(), …
HP’s Cooltown uses HTTP for a fixed, universal interface but is limited by constraints on data types and protocols
Stanford’s iRoom allows tuple sharing with an event heap but isn’t scalable and requires prior agreement on tuples

5. Embodied Solution: Speakeasy
A component-based embodiment
Connection-oriented: components connect and exchange objects - objects are “leased” and expire after a timeout - calling component’s context is provided to callee
Component functionality expressed through interfaces:
Original set of Interfaces: Connection, Context, Control
Evolved into: Data transfer, Collection, Metadata, Control
Interfaces implement generic communication “patterns”

6. Data Transfer Interface
Challenge: A wide variety of transfer protocols and data types in use, how do they interoperate?
Approach: 1 Setup connection with a public communication “pattern” 2 Sender sends ‘source-provided endpoint’ to receiver 3 Data over private interface with appropriate protocol 4 Receiver accepts byte-stream from endpoint
A 3rd party can initiate this transfer
receiver
sender
SPE

7. Discovery Protocol Bridge
Collection Interface
Challenge: Need extensible discovery protocols, and a way for users to cluster components together
Approach: 1 Return an object representing the aggregate 2 Object allows search on its components 3 Object allows queries on membership changes
Example Collection Interfaces: - Filesystem aggregates directories - Bridge to another network with different protocols
Discovery Protocol Bridge

8. Contextual Metadata Interface
Challenge: Allow sensemaking of components without hardcoding semantics
Approach: 1 Caller sends a metadata object to callee 2 Object contains an extensible list of key-value pairs 3 User or inference engine interprets or ignores metadata 4 Metadata object can dynamically update metadata
Examples Keys: - Name, Location, Administrative Domain, …

9. Control Interface
Challenge: Allow component-specific control without prior agreement or foreknowledge
Approach: 1 Multiple UIs for each component (e.g. GUI, HTML) 2 Caller can indicate the type of UI it wants 3 Callee sends component-specific UI object to the caller 4 Caller interacts with callee using the UI object
Example UIs: - UNIX pipes, web browser, form wizard
Drawbacks: - Must explicitly write UIs for each component or use UIML - UI should be amenable to non-human control

10. Applications
A number of possible paradigms: UNIX pipes, scripting languages, dataflow diagrams, browser-style drag-and-drop, form-wizard
Assuming user interaction via a “resource poor” device (PDA, cell phone)
Implemented the HTML-based Speakeasy browser: - Supports discovery, connection, and interaction - Direct-connect mode allows access to raw functionality - Task-oriented templates offer intelligent task prototypes - New templates can be created by example and shared

11. CSCW – Adhoc P2P Collaboration
Casca: an application for adhoc P2P collaboration Creates “converspace” across machines and networks Allows sharing of files, services, devices,… Uses Speakeasy to allow “spontaneous” collaboration
Casca avoids the limitations of similar P2P systems: share only a fixed set of resources (Napster, mp3s) limited resource discovery assumes interest in all peers restricted network transport

12. User Evaluation Evaluating the Speakeasy browser: 2 evaluations
First evaluation (5 users, 2-week period) - Users given PDA with mockup browser - Asked to setup and give a presentation, with hints - All but one were able to form and use a mental model
Second evaluation (6 users, ?-week period) - Users given PDA with real browser - Same task, but using templates and no hints given - One of six couldn’t complete task without intervention
Users were confused by large number of components
Users found a lack of feedback on the state of the world

13. Questions – User oriented
Is this the right user-model for UbiComp?
Explicit connections demand user’s attention
What is the limit to user-in-the-loop computing?
Tangible and non-display interfaces? Whiteboard?
Is a collection interface the right abstraction?
User has to think about system: network bridge, etc
Heterogeneous collections?
Can a collection be automatically created?
Has there been enough ongoing evaluation?
Is it the right kind of evaluation?

14. Questions – System oriented
Multi-standard service interoperation problem
Speakeasy uses single-standard services
Says service standards should be domain independent

15. References Slide 1-2 images: Siemens Webzine (http://w4.siemens.de)
Other images from Google image search or the following papers:
W. K. Edwards et. al.: “The Case for Recombinant Computing” “Using Speakeasy for Ad Hoc Peer to Peer Collaboration” “Challenge: Recombinant Computing and the Speakeasy Approach”
M. W. Newman et. al.: “User Interfaces When and Where They are Needed: An Infrastructure for Recombinant Computing” “Designing for Serendipity: Supporting End-User Configuration of Ubiquitous Computing Environment”