Internet Service Models

1
Internet Service Models

• By
• Ramakrishna Gummadi
• Computer Science Division
• UC Berkeley
• ramki_at_cs.berkeley.edu
• http//www.cs.berkeley.edu/ramki
• http//internetware.org

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?

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.

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?).

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?)

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

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.

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)

9
Ephemeral data (left), Databases, Web, and ERP
(right)
Users with diverse Access Devices Services
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
CM
Backbone network, including wired, wireless,
telephone, and paging
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.intern
  etware.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

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

12
Conclusions

• Need for a new Internet Service Model is fairly
  obvious
• But we dont 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)