Alan H. Karp Hewlett-Packard Laboratories

2. E-nabling the E-conomy Alan H. Karp Hewlett-Packard Laboratories

3. W r a p p e r Buyer Standards Seller E-conomy Components Market Maker Match Maker Legacy Business Buyer Seller

4. The EssentialDifference • 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 • “Them’s fightin’ words, pardner!”

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-enterprise Check status Scan-device(?), security, cross-enterprise, delegation Desktop delivery update Automated remittance, security Invoice payment

9. Clicksand clicks away … Maybe Check another site for deal? • Locate merchant sites • Compare • Cross-optimize Itinerary change? E-services Today(User’s Perspective) Isn’t Your Best Value Just a Click Away?

10. Standards • Static, custom solution • Locate and compare Complex, slow, costly E-services Today(Merchant’s Perspective) Isn’t Creating an E-service Just a Connection Away? Connections and connections away … Maybe

11. Internet Challenges • Today’s 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.

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 don’t care what stuff you use

22. Storefront Storefront Storefront Storefront Storefront Customer Care Customer Care Customer Care Customer Care . . . . . . . . . Customer Care Supply Chain Supply Chain Supply Chain Supply Chain Supply Chain IT IT IT IT IT Business E-Commerce E-Business E-Services E-Commerce, E-Business, E-Services

23. New services and service compositions, Cache Locate Bill Monitor New service providers E-conomy Discover Manage Convert Distribute Negotiate Int**net Meter Mirror QoS Verify Isolate New customers E-conomy Marketplace

24. Service Execution Service Specification Workflow E-conomy Requirements Access control (security, billing, ...) Int**net Int**net Service Advertisement Service Discovery E-conomy Int**net E-conomy Int**net buy buy buy Services Framework

25. How

26. Open data (Web) 3-tier, 4-tier, … systems Proprietary, one-of services (Amazon.com, Expedia, eBay, …) 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 • Can’t 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. Discovery (UDDI) Infrastructure and other Services Match Maker Market Maker Web Services Stack WSFL/WSCL/XLANG WSDL SOAP XML HTTP

31. Dynamic Federation Network Web Services Layer . . Host OS Native Hardware A distributed system is one in which a machine I never heard of can render my machine useless. -- Leslie Lamport

32. Opinions

33. Key Issues • Discovery • Trust • Naming

34. 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

35. 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

36. Naming • Naming interacts with security • Can’t protect what you can’t 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

37. The Big Problem Where’s the architecture? A SOAP name is a URL A WSDL name is a URL and port A UDDI name is a GUID So what’s a web services name? How will we define a transaction? What about event driven services? An architecture provides the answers

38. Summary

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

40. Partnerships Business Model Technology Success Factors You