1. technology and computing
2. data centers

The Horizontal Internet
CS241, Internet Services
© 1999-2001 Armando Fox
[email protected]
Outline

The horizontal Internet

Internet service composition (intro)

Implications for software structure (intro)

A few words about the Project
Early Internet Services: “Vertical”

TWA reservations, CIRRUS banking network


Proprietary, closed systems (Tandem NonStop hardware)
America Online (pre-Web)

PC and Mac proprietary client S/W

Proprietary mainframe-based back end

Modem banks connect directly to terminal concentrators
Early WWW Portals: “Diagonal”


Commodity protocols & software...

HTTP, TCP/IP, SSL, off-the-shelf client (Navigator, MSIE)

Farms of off-the-shelf servers
…augmented with proprietary “secret sauce”

Web-based email (Hotmail, Yahoo, …)

Industrial-scale homebuilt email servers (EarthLink)

Search engine portals (AltaVista, Infoseek, Lycos...)

Customizable news (My Yahoo, Netcenter…)

AOL is now a Web portal + world’s largest ISP
Portal Evolution (1)

All operations at server site

Infrastructure vendor (e.g. Cisco) sells directly to destination
sites (e.g. Yahoo.com)

Client requests go to destination site operations center
PortalCo
InfraCo
Content
Advertisements
Search
User profiles
Mobile-friendly pages
Portal Evolution (2)

Operations migrate to “server farms” (e.g. Exodus)

Infrastructure vendors sell primarily to IDC’s

All client traffic and peering handled via IDC

Peering relationships between IDC’s (not operators)
Data
Center
PortalCo
InfraCo
Data
Center
InfraCo
Content
Advertisements
Search
User profiles
Mobile-friendly pages
Data
Center
Administration,
site updates
InfraCo
Portal Evolution (3)

Services migrate to hosted application providers

Typically paid per use or similar metering

Client doesn’t visit arms merchants directly (still sees portal’s
brand)
Some portal Data
services outsourced
Center
to “arms merchants”
PortalCo
InfraCo
AdTarget
Co
Data
Center
Data
Center
InfraCo
InfraCo
Content
User profiles
Mobile-friendly pages
SearchCo
Portal Evolution (4)

“Arms merchants” provide individual services to
destination sites/brands

Inktomi Traffic Server, Cisco Hosted Apps Initiative, others
DevelopmentData
platform for various
Center
services
PortalCo
InfraCo
Data
Center
AdTarget
Co
Data
Center
AppDevCo
InfraCo
InfraCo
Content
User profiles
Mobile-friendly pages
SearchCo
AppDevCo
The Arms Merchants Model
What
Hosted Service
Search
Email
Calendar
Cache/mirror
Shop
Ads
Thin access
“Sensitive” info
Notify on
update
Email CRM
Inktomi
CriticalPath
When.com (AOL acq)
Sandpiper/Inktomi
Inktomi
DoubleClick
ProxiNet (Puma acq)
VerticalOne
NetMind (Puma acq)
General Interactive
Sell Iron (or S/W)
Excite, Infoseek
Software.com, NetApp
Netscape Server
Network Appliance, Cisco
NetGravity
Unwired Planet
??
??
??
The Food Chain

Who’s at each level?
Aggregators/Brands
Value-Added Svcs
Arms
Arms Infrastructure
Physical Plant
Infrastructure Vendor
Advantages of Large Hosted Services


Amortization of infrastructure costs (at IDC’s)

Physical plant, physical security & human monitoring

Network connectivity

Scale of 100’s of nodes requires serious infrastructure
Large scale can increase service sophistication

Inktomi search DB over 2x competitors’

Doubleclick ad selection uses large DB, cross-site history,
compute-intensive selection algorithm

Tracking usage/buying/etc. patterns of specific user
populations (mobile users, leisure travelers, etc.)

Direct-to-consumer wholesale-style e-commerce (Paul Allen,
Mercata) aggregates buying power of many individuals
Disadvantages...

“In a society where knowledge is power, centralized
knowledge is centralized power”
--Richard Sobel, HLS Fellow, Berkman Center for Internet & Society


Do you want your user profile, portfolio balances, etc. stored
at one place or many? (VerticalOne)
Business model highly dependent on partners

Billing models being adopted slowly (pay per use,
subscription, …)

Shift of responsibility: HSP may have operations
responsibility (wearing a pager vs. not)
Other Arms To Be Marketed?


Geographic/location services: maps, directions, POI’s

Today: MapQuest, MapBlast, Yahoo Maps...

Tomorrow: “Powered by”
Extension to other platforms

Today: Yahoo to your pager, Fidelity Instant Broker, …

Tomorrow: “Powered by”

User profiles

Others

Directories (yellow/white pages, mail/news, encyclopediae)

Highly customized news feeds
Toward Service Composition


Services from building blocks

Can think of a particular destination Web site as providing
one or more autonomous “building block”

MapQuest: given a pair of addresses, return directions and
map

Amazon: given keywords, return listing and price info for
matching books

IMDB: given movie title or other keywords, return movie
reviews and production info
Can we create new Internet services simply by
composing these, without writing (much) new code?
Programming Via Service Composition

Remote invocation of several services in real time


Example: “Find the most highly reviewed James Bond movie
and locate the best price for it”
Observations

Typically services aren’t designed to be composed, and may
have do quite different tasks

“Compositor” only does remote invocation--not mobile code

Potential for good fault isolation

Potential for high availability through redundancy

Can compose “meta-services” into higher-level ones

management/heterogeneity issues in dealing with a
collection of autonomous services
Why Compose Web Services?

Highly available building blocks



We’ve learned to make heavily-used destination sites H/A
Autonomous services

Fault isolation through loose coupling

“Self-sufficient”

We don’t own or control them--so no control over their
interfaces--but...
Universally deployed open protocols

Self-describing services

No compile or link step needed for client (no issue of stale
interface stubs)

No mobile code: just “submit-and-scrape” invocation
Related Work

XML-RPC

SOAP

Idea: provide structural, programmatic-like interfaces
to Web services

Today: “fake” RPC using HTTP and HTML

What aspects of it are “fake”?
Composition Using Strong Types


How do you know when it’s “safe” to compose A and
B?

Output semantics of A match input semantics of B

Example: A maps keywords to movie titles and reviews; B
maps movie titles to prices at online vendors
The main problem is semantic mapping of arguments

In most systems to date, this requires human level
knowledge

If system is purpose-built for composition, semantic
mapping can be explicitly coded into service interfaces

Otherwise, we can “wrap” each service with a shell that
codes semantic mapping of that service
Example: IMDB and Netflix

A non-earth-shaking example...

Consider services M and N


M is IMDB: movie title --> critics’ reviews ranked by rating

N is Netflix: movie title --> vendors ranked by price

Example composition: (M,N) is “Identify highest-reviewed
James Bond film, and find the best price”
Common mundane problem…

M’s movie title includes a year: Tomorrow Never Dies (1998)

N’s doesn’t…must munge M’s movie title to feed to N

Problem: where to capture this transformation?
Composition and Appliance Computing
How can you exploit service composition for…

A TiVo box?

Digital photography?

Portable MP3 players?

Home-control applications?

etc.
It will be a feature for your project to leverage this
Composition Challenges


Economics

How is billing done? (Subscription? Per-use? Transactionbased? Subsidy?)

Is there incentive to provide user choice?
Technical challenges

Type system and semantics

Runtime system and error handling

You’ll hear more about these in future classes
Internet Evolution

Clients and servers (today)
S
S
S
C
S
C
S
C
C
S
Internet Evolution

Clients, servers, and caches (to reduce client latency and
backhaul congestion)
S
S
S
C
$
C
$
S
$
S
C
C
S
Internet Evolution

Add proxies and service compositors to provide various
kinds of intelligent information delivery
S
S
S
P
C
CS
P $
C
P $
S
$
S
C
C
S
A few words about the project

Appliance computing (1/24) & composition (2/12)



We will provide software infrastructure for both of these
You can build either an application or more
infrastructure (with a “toy” app to demonstrate it)

It is a feature to leverage existing Web services via
composition

We have a (limited) hardware and software budget
General project process

Pre-proposal (~1 page) posted on Web: 1/31

Revised proposal forms basis for project & discussions with
Advisors starting 2/5

No other explicit checkpoint/design review till end of qtr
Today’s Travel Photo: Where Am I?