Transcript Universal In-Box

Universal In-Box
Bhaskaran Raman
Iceberg, EECS
ISRG Retreat, Jan 2000
July 21, 2015
Iceberg Retreat, January 2000
1
Outline
•
•
•
•
•
•
Universal In-box: What is it?
Application requirements
How to satisfy the requirements?
Implementation status
Lessons learnt
Summary, open questions
July 21, 2015
Iceberg Retreat, January 2000
2
Universal In-box: What is it?
Integration
Speech-to-Text
Speech-to-Voice Attached-Email
Call-to-Pager/Email Notification
Email-to-Speech
All compositions
of the above!
Universal In-box
Policy-based
Location-based
Activity-based
Personalization
July 21, 2015
Iceberg Retreat, January 2000
3
Universal In-box: What is it?
•
•
•
•
One of the first Iceberg applications
Wide range of requirements
Canonical hybrid service
Related efforts:
– commercial products
– PCS efforts: UMTS, IMT2000, UPT
– MPA (Stanford), TOPS (AT&T)
July 21, 2015
Iceberg Retreat, January 2000
4
Application Requirements (Goals)
• Extend to new networks
– Different generations of PCS networks
– Micro-cellular networks
– Pico-cellular (BlueTooth Scatternets)
• Extend to new devices
– CDMA phones, 2-way pagers, Palm VII, Visor
– Device of the future
July 21, 2015
Iceberg Retreat, January 2000
5
Application Requirements (Goals)
• Accommodate new data formats
– new codecs
– better speech recognition/generation
• Personalization
– very important
July 21, 2015
Iceberg Retreat, January 2000
6
Application Requirements (Goals)
Personalization
is crucial
July 21, 2015
Iceberg Retreat, January 2000
7
Application Requirements (Goals)
• Further requirements
–
–
–
–
Scaling to a large user-base
Working in the wide-area
Resilient to failures
Security and privacy
July 21, 2015
Iceberg Retreat, January 2000
8
Outline
•
•
*
•
•
•
Universal In-box: What is it?
Application requirements
How to satisfy the requirements?
Implementation status
Lessons learnt
Summary, open questions
July 21, 2015
Iceberg Retreat, January 2000
9
Meeting the Requirements
• Design principles
– Network independence
– Device independence
– Pushing control to the callee
• Leverage Ninja Service platform
– for service availability and fault-tolerance
July 21, 2015
Iceberg Retreat, January 2000
10
Iceberg Components
July 21, 2015
Iceberg Retreat, January 2000
11
Meeting the Requirements
• Network Independence
– Provided by IAP
– Addition of a new n/w
• Develop a new IAP
• And deploy multiple IAPs
• Device Independence
– Device name independence
– Device type independence
July 21, 2015
Iceberg Retreat, January 2000
12
Meeting the Requirements
• Name independence
– use any end-point id
– hierarchical, distributed naming service
– level of indirection, for wide-area operation
• Data-Type independence
– APC Service
– Ninja paths (operators + connectors)
– Adding data formats is as simple as writing the
relevant operators
July 21, 2015
Iceberg Retreat, January 2000
13
Meeting the Requirements
• Personalization
– Preference profiles
• scripts
• GUI for generating profiles
– Preference-Registry
• storing and processing profiles
• PAC for dynamic inputs
• Preference-Registry: a service in a Ninja-Base
July 21, 2015
Iceberg Retreat, January 2000
14
Meeting the Requirements
Preference
Manager
July 21, 2015
Iceberg Retreat, January 2000
15
What has been implemented?
• IAPs
– for GSM testbed, VAT, Voice-Mail service,
Instant-Messaging (Sanctio)
•
•
•
•
•
APC Service (Emre/Barbara, Morley)
Naming Service: LDAP
Preference Registry: iSpace service
Preference Manager GUI (Rahul)
Personal Activity Coordinator (PAC) - Xia
July 21, 2015
Iceberg Retreat, January 2000
16
Lessons learnt: What was easy?
• Extension to include a new communication
service (Sanctio)
• Built IAP (proxy) to interface Sanctio endpoints to Iceberg
• Making the service available at all endpoints after the extension
– Cell-Phone, VAT, Potentially POTS-Phone
Effort involved in building a service is
independent of the number of networks it is
made available on
July 21, 2015
Iceberg Retreat, January 2000
17
Lessons learnt: Why it was easy?
• What gave the flexibility?
– Separation of concerns: network, device-name
and device-type independence
– Deployment flexibility - anyone can deploy an
IAP
– IAP can interface to a network or a generic
service end-point
– Modeling components as services
July 21, 2015
Iceberg Retreat, January 2000
18
Lessons learnt: What was hard?
• Getting the interfaces right
– still may not be generic enough
– can the pref-reg interface support other
services?
• Scaling measurements
– Client problems:
• socket problems, client saturation, RMI too slow
– Server problems:
• RMI too slow, JVM bugs, (thread) scheduling problems
July 21, 2015
Iceberg Retreat, January 2000
19
Summary
• Key idea: Infrastructure components for
network/device independence,
personalization
• Important to get interfaces right
• Good experience in building and extending a
hybrid service
July 21, 2015
Iceberg Retreat, January 2000
20
What next?
•
•
•
•
Interface to new APC service
Interface to PAC
Implement security mechanisms
Usability of Preference-Manager
July 21, 2015
Iceberg Retreat, January 2000
21
Further Open Questions
• Interfaces and Components:
– What is a flexible interface between the PrefReg and the PAC?
– Other middleware components for other
services?
• Testing platform for testing scalability,
fault-tolerance, etc.
• Handling feature interactions
• Your question goes here…
July 21, 2015
Iceberg Retreat, January 2000
22