Information Utility GAB Presentation

1
(No Transcript)
2
E-nabling the E-conomy
Alan H. Karp Hewlett-Packard Laboratories
3
E-conomy Components
Market Maker
Match Maker
Legacy Business
Buyer Seller
4
The Essential Difference
Hardware Software Tell the computer how to do
the job
Services Tell the computer what job you want done
5
Technology Need
Do for services what the browser has done for data
Make it as simple, in fact simpler and safer to
create, compose, deploy, manage, personalize, and
access services as it is to publish and access
data on the Web.
6
Outline

• Why

• What

• How

A technology transfer story

• Some geeky stuff

7
Why
8
B2B Procurement
Dynamic lookup, scalability
Current status 1. Static/ preferred supplier 2.
Hard-coded, not easily extensible 3.
Integrated with ERP 4. EDI, cross-device not
automated, security(?) 5. OK with VPN, and
with real-time integration 6. Not
fully automated 7. OK for centralized, else
some user intervention 8. Not automated
Supplier discovery
Transparency, seamless distribution
Policy-based search browse
Integration with ERP systems
Obtain approval/ERP
Virtualization, cross-device, security Data
heterogeneity
Transmit purchase order
Cross-device, security, Data heterogeneity
Sale order confirmation receipt
Granting authorization, delegation cross-enterpris
e
Check status
Scan-device(?), security, cross-enterprise,
delegation
Desktop delivery update
Automated remittance, security
Invoice payment
9
E-services Today(Users Perspective)
Isnt Your Best Value Just a Click Away?
10
E-services Today(Merchants Perspective)
Connections and connections away Maybe
Isnt Creating an E-service Just a Connection
Away?
11
Internet Challenges

• Todays e-business web sites are proprietary,
  massive and costly to develop.
• Companies are forced to build out their entire
  offerings from the ground up.
• Even though they are connected to the Net,
  getting e-businesses and e-commerce sites to talk
  to one another in a meaningful way is difficult,
  special-case work.

The volume of business is limited by the
bandwidth of eyeballs.
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
What
21
P2P, Grid, E-conomy

• P2P
• Get the stuff I need to do my job
• Grid
• Do my job using that stuff
• E-conomy
• Do my job, and I dont care what stuff you use

22
E-Commerce, E-Business, E-Services
23
E-conomy Marketplace
24
Services Framework
25
How
26
Systems Evolution
Monolithic, proprietary systems
Open systems
2-tier client-server systems
E-conomy
Dynamic n-tier systems Brokered service
composition (active personalization)
27
Assumptions and Implications

• Large number of machines
• No centralized anything, forget consistency
• Dynamic
• Deal with failures, new services
• Heterogeneous
• Different hardware, OS, capability
• Hostile environment
• Security is critical
• Different fiefdoms
• Never look inside another machine

28
Architectural Principles

• Design for seamless, flexible, dynamic evolution
• Current and future
• Scalable, manageable, securable, extensible
• Simple abstractions and mechanisms
• No special cases
• No homogeneity requirements
• Uniform abstractions
• Based on widely accepted standards

29
Requirements

• Discovery
• Cant rely on names or interfaces
• Extensible ontologies
• Service discovery within and across enterprises
• Security
• Support for dynamic roles
• Fine grained access control
• Secure firewall traversal
• Manageability
• Generation of management and billing events
• Ability to monitor state and control activities
• Integration with leading management platforms

30
Web Services Stack
Conversations (WSFL/WSCL/XLANG)
Sentences (WSDL)
Words (SOAP)
Alphabet (XML)
Paper (HTTP)
31
A distributed system is one in which a machine I
never heard of can render my machine useless. --
Leslie Lamport
32
A Technology Transfer Story
33
Origins

• Global Computer - 1990
• Two talks to Labs 1992, 1994
• Command performance Joel Birnbaum, 1995
• Future Systems Department Rajiv Gupta
• Client Utility Prototype with Bill Rozas - 1996
• Re-architected by Gang of 4 - Arindam Banerji
• Sales job
• Gave demo 157 times in 18 months
• Distributed 500 copies of video

34
Birth, Infancy, Demise

• E-speak Operation November 1998 with 6 people
• 10M for first year from Unix box division
• Ill sell 500M more stuff in the first 6 months
  after we announce this stuff. He did!
• Alpha release May 1999 E-services Conference
• 30 developers, 30 marketing/training
• Beta 2.2 December 1999 (first usable version)
• Retargeted as B2B platform
• Release 1.0 June 2000
• 150 people, 25M annual budget
• Shut down in May 2001

35
Customers

• Helsinki Telecom (April 1999)
• Used e-speak broker, not full architecture
• Hi-Tel (Korea Telecom) (January 2000)
• Game platform
• HP GSL (June 2000) (decommissioned 1/2003)
• Procurement
• Spin Circuit (August 2000)
• Electronic design documentation
• Slovenia (May 2002)
• mTicka

36
Innovations

• First web services platform
• First open source (GPL) by a major company
• Completely integrated platform
• Security, manageability, discovery, naming
• First complete XML services infrastructure
• E-services Village (UDDI with rich query)
• Dynamic community formation
• Named Computerworld Smithsonian Laureate for
  Visionary Use of Information Technology in
  April 2000

37
Theories on Demise

• Cute puppy, ugly dog
• No industry buy-in
• Too far from HPs mainstream
• OpenView only software success
• Dot bomb
• Lost interest in B2B
• Lack of patience
• No clear path to 1B
• Purchase of Bluestone
• Appserver middleware

38
Keys to Technology Transfer

• Luck
• Timing
• Compelling Vision
• Compelling Demo
• Executive Champion
• Internal and External Validation
• Innovative technology

39
(No Transcript)
40
Opinions
41
Key Issues

• Discovery
• Trust
• Naming

42
Discovery

• AltaVista effect/Googlewacking
• Need context for search
• Global ontologies evolve too slowly
• UDDI Discovery
• Search by name of business
• Search by standard classification
• Search by interface (tModel)
• Problems
• No rich query
• No standard for tModel description
• Needs dynamically extensible ontology

43
Trust

• Trust based on identity not scalable
• Need vouch for mechanism
• Trusted party as risk taker
• Must reflect contractural relationships
• Often forgotten points
• Privileges granted to people
• Access rights enforced on processes
• People need to limit rights of their processes

44
Naming

• Naming interacts with security
• Cant protect what you cant name
• Reusing names a problem
• Location based global name spaces unworkable
• Domain names and IP addresses change
• Firewalls create private name spaces
• Opaque names require locator service
• Hash of contents changing content?
• Random number hijacking of name?
• PKI solutions lifetime of private key?
• Path dependent names reflect trust relationships

45
The Big Problem

• Wheres the architecture?
• A SOAP name is a URL
• A WSDL name is a URL and port
• A UDDI name is a GUID
• So whats a web services name?
• How will we define a transaction?
• What about event driven services?
• An architecture provides the answers

46
Summary
47
The Big Shifts Coming

• Now
• Apps-on-tap
• B2B portals
• Soon
• Outsource computing and storage
• Ubiquitous web services
• Modular building blocks
• Easy access from and to appliances, PCs, servers
• Longer term
• Dynamic brokering
• Web services advertise, discover, and compose
• Web services negotiate, bill, manage, monitor

48
Success Factors
You