Internet Service Models

1. Internet Service Models By Ramakrishna Gummadi Computer Science Division UC Berkeley ramki@cs.berkeley.edu http://www.cs.berkeley.edu/~ramki http://internetware.org ISRG Retreat

2. Motivation • In future, we have: • Thousands of Internet-based services • Millions of heterogeneous end-user devices • How do we develop dynamically composable (mix content and services at runtime), scalable, accessible (same behavior from any device), highly available, customizable (and persistent), extensible (service developers can reuse components), mobile (personal, terminal, and service-level), multi-party, secure, and easy-to-use (have a similar interface) services? ISRG Retreat

3. Examples of Future Internet Services • Talk with a search service and see the results on your WAP-enabled phone, browse the returned web pages using the caching service, both for faster access and for anonymity, ask for the results to be stored under your profile, instant message the top matches to your bookmarks file, and deposit triggers with the search service to notify you of updates. Meanwhile, the search service transparently updates page relevance by using real usage statistics. • Participate in a secure real-time multicast video service that delivers encoded multimedia streams matched to your bandwidth and computing power, and mixed with advertisements and real-time stock quotes. Users are authenticated by a voice-recognition engine using a voice-based active directory. ISRG Retreat

4. Drawbacks of the Current Internet Service Model • Each of the above mentioned services, taken individually, already exists, perhaps on a small scale, but do we understand how to use them together on a global scale? • Currently, users are required to download a separate application for each purpose (instant messaging, VoIP, email, search, multimedia, chat, directory, news, speech, calendar, maps, etc.) with little interoperability, ease of use, security, persistent preference management, or customizability. Browsers attempt to rectify this, but will they be completely successful? • Little advantage is taken presently of the vast underlying network capability, and support for cluster services (a highly successful service doing this is Akamai caching service, but what is the general service model here?). ISRG Retreat

5. Requirements of future Internet Services • Provide an efficient globally scalable event-delivery and handling model • Distinguish between content and service (content-authoring vs. service-creation, content-deployment vs. service-deployment), and ephemeral and persistent data • Support efficient storage, querying, processing, and integration of ephemeral data (stock quotes, weather reports, traffic updates, etc.) • Relocate persistent data as needed, through an unambiguous and customizable naming, name mapping and data fetching scheme • Take advantage of underlying flexible and powerful transport and network facilities, and intelligent signaling capabilities (can exceptions and threads take the support of control and signaling capabilities of the underlying network?) ISRG Retreat

6. Examples of Current Work • Ninja deals with scalable and composable services, through distributed state management, automatic path creation and active proxies • Akamai is concerned with content delivery through aggressive caching • ILU is about providing support for writing distributed applications, components of which are written in any language, and can run on any platform • ActiveX controls allow desktop level composability, extensibility, and customization ISRG Retreat

7. Our Proposed Approach • Cull out a basic set of services, with which general-purpose services can be built; for example, caching, searching, naming and browsing, redirection, general-purpose messaging, service discovery, multimedia coding, WAP, speech and voice recognition, active directory, authentication and security, automatic path creation, billing, transaction (including logging and recovery), instant messaging, service-specific multicasting, calendaring, etc.. • Make these services scalable, available, secure, composable, and customizable. Through dynamic composition, achieve accessibility, mobility, multi-party capability, extensibility, and usability • Try to build an example wide-area service, like the Clearing House, with the above primitives, and achieve the service objectives. ISRG Retreat

8. Our Proposed Approach (contd..) • See how many of the components can be reused in a new setting, like the Oceanstore (a global-scale persistent data utility). • Develop a general-purpose event-specification, multiplexing, delivery, and notification mechanism to support interesting services based on notification, and evaluate push vs. pull approaches. Events can also be used to separate data and control paths • Handle ephemeral data in a uniform way to collect, store, query, and process, through use of mediators, wrappers, and adapters, and integrate its use with that of persistent data (like user data, preferences and billing records) ISRG Retreat

9. Users with diverse Access Devices & Services Ephemeral data (left), Databases, Web, and ERP (right) Adaptive Active Proxy Adaptive Active Proxy Adapter Wrapper Customized Multimedia Service Customized Search Service Messaging (Events, Data & Transactions) Application Server Data Integration, Routing & Transformation Generic Encoding Service Generic Search Service Custom Logic Information Dissemination & Event Notification Class A Class B Class C Class D Control Selectable Transport Stacks Transport Protocol Stack Type 1 Type 2 Type 3 Type 4 C&M Backbone network, including wired, wireless, telephone, and paging ISRG Retreat

10. Implementation Details • Use Java as the development platform, as support for composition built-in (implement needed interfaces) • Provide an easy-to-use and customizable naming service: for example, http://ramki.calendar.internetware.org could refer to my personalized calendar, http://ramki.mail.yahoo.com to my mail, etc. • When invoked, an applet implementing an active proxy is instantiated on the client device with appropriate persistent and ephemeral data customized for the user. The proxy is adaptive and application-aware, and instantiates composable services as needed • A user-specific service is initially created through inheritance from a generic service ISRG Retreat

11. Implementation Details (contd..) • Services are easily relocatable at runtime, being java classes. Thus, an appropriate placement of service with respect to the user is achieved (the service transparently follows the user) • Services are hosted in general-purpose application servers, placed around the world, much like cache-specific Akamai servers, creating an overlay service network over the Internet, if necessary • Services carry authentication certificates, authorization credentials, and billing tickets to allow servers to host them ISRG Retreat

12. Conclusions • Need for a new Internet Service Model is fairly obvious • But we don’t want to build an all-encompassing Internet portal: rather, identify requirements for building services, demonstrate the requirements can be satisfied through approaches discussed above, and clearly prove the ease of creating any general purpose Internet-scale service • We have ideas, are they reasonable? (In particular, the assumptions about core services) ISRG Retreat