1. Highlights of W3C Workshop on Web of Services for Enterprise Computing Ken Laskey, co-chair 3rd SOA for E-Government Conference 1-2 May 2007 Ken Laskey, co-chair 3rd SOA for E-Government Conference 1-2 May 2007

2. Background  WSEC workshop held 27-28 Feb 2007  Hosted by MITRE in Bedford, MA  Eric Newcomer, co-chair  Philippe Le H é garet, W3C contact  WSEC workshop held 27-28 Feb 2007  Hosted by MITRE in Bedford, MA  Eric Newcomer, co-chair  Philippe Le H é garet, W3C contact

3. Goals of Workshop  Provide recommendations to facilitate  Processing business transactions and interaction with pre-Web systems  Connecting intranet and/or extranet services with Web technologies  Generate wide variety of use cases - legacy systems to Web 2.0  Discuss whether current specs and solutions support use cases  Provide recommendations to facilitate  Processing business transactions and interaction with pre-Web systems  Connecting intranet and/or extranet services with Web technologies  Generate wide variety of use cases - legacy systems to Web 2.0  Discuss whether current specs and solutions support use cases

4. Scope of Workshop  What set of use cases should W3C consider or exclude?  What are the advantages and limitations of the current Web architecture in addressing practical use cases for which Web technology would be useful?  What are the advantages and limitations of existing specifications (e.g., Web services, Semantic Web) to address practical use cases for which Web technology would be useful?  What are the advantages and limitations of service oriented architectures?  Should there be more than one architecture? Should there be different architectures for intranet and extranet services?  Are the demands of the intranet and the extranet sufficiently the same to leverage a common architectural solution or are multiple solutions needed?  How should we fix the existing Web stack or Web services stack? What, if anything, needs to be fixed, changed, or added within existing Web and/or Web services technologies?  What should be the impact of tooling on the approach?  What guidelines should W3C give for using services on the Web?  What set of use cases should W3C consider or exclude?  What are the advantages and limitations of the current Web architecture in addressing practical use cases for which Web technology would be useful?  What are the advantages and limitations of existing specifications (e.g., Web services, Semantic Web) to address practical use cases for which Web technology would be useful?  What are the advantages and limitations of service oriented architectures?  Should there be more than one architecture? Should there be different architectures for intranet and extranet services?  Are the demands of the intranet and the extranet sufficiently the same to leverage a common architectural solution or are multiple solutions needed?  How should we fix the existing Web stack or Web services stack? What, if anything, needs to be fixed, changed, or added within existing Web and/or Web services technologies?  What should be the impact of tooling on the approach?  What guidelines should W3C give for using services on the Web?

5. Participating Organizations  American Express  BEA  Boeing  BT  Mark Baker, Coactus Consulting  Torry Harris Business Solutions  FSTC  Fujitsu  Nicholas Gall  Gestalt-LLC  HP  Hitachi Ltd  IBM  IONA  American Express  BEA  Boeing  BT  Mark Baker, Coactus Consulting  Torry Harris Business Solutions  FSTC  Fujitsu  Nicholas Gall  Gestalt-LLC  HP  Hitachi Ltd  IBM  IONA  Peter Lacey  New York Life Insurance Company  Progress Software  Mark Little, Redhat  The Hartford  MITRE  Marc Hadley, Sun Microsystems  W3C Technical Architecture Group  WSO2  Westinghouse Rail Systems Australia  Xerox Corporation  Yahoo

6. Tentative Findings - A Caveat  Parts of workshop report in draft form  Little disagreement, just lack of time  Remarks today are my own without coordination with Eric or Philippe  Parts of workshop report in draft form  Little disagreement, just lack of time  Remarks today are my own without coordination with Eric or Philippe

7. History - Approach in 2001  W3C Web Services workshop  Appeal of a stack of solutions, spinning up lots of groups to build specifications  Foundation of protocols working in context of the Web  Dynamic composability to meet unexpected needs as these arise  W3C Web Services workshop  Appeal of a stack of solutions, spinning up lots of groups to build specifications  Foundation of protocols working in context of the Web  Dynamic composability to meet unexpected needs as these arise

8. The Vision and The Reality  Vision (IBM): “a single scalable stack, offering the best of the Web in simple scenarios, and scaling gracefully to SOAP based Web services with the addition of optional extensions when more robust quality of service features are required”  Reality (after six years):  we are half way through the spec stack  but interoperability has remained elusive  Vision (IBM): “a single scalable stack, offering the best of the Web in simple scenarios, and scaling gracefully to SOAP based Web services with the addition of optional extensions when more robust quality of service features are required”  Reality (after six years):  we are half way through the spec stack  but interoperability has remained elusive

9. The Web and Web Services  Two very different things  Web Services  Ecosystem of specifications enabling ubiquitous messaging on lowest common denominator  Messages not self-describing; need variety of metadata to make usable if not hardwired  Shortcomings: data binding, versioning  Web  Based on REST for messages with precise semantics, URIs as common identifiers  HTTP design features that enable scalability also limit behavior in enterprise environment  Shortcomings: HTTP authentication  Two very different things  Web Services  Ecosystem of specifications enabling ubiquitous messaging on lowest common denominator  Messages not self-describing; need variety of metadata to make usable if not hardwired  Shortcomings: data binding, versioning  Web  Based on REST for messages with precise semantics, URIs as common identifiers  HTTP design features that enable scalability also limit behavior in enterprise environment  Shortcomings: HTTP authentication

10. REST and WS-*  Various strengths and shortcomings of each  Need for workable combination that provides more value and less hostile debate  Neither going away  Various strengths and shortcomings of each  Need for workable combination that provides more value and less hostile debate  Neither going away

11. Challenges for Enterprise  Greatest challenge is not to build more layers but getting the ones we have working  Missing technology that would allow SOAP clients to consume REST and vice versa  Innovator’s dilemma: educating users to possibilities, vendors implementing technology  Center of gravity to deal with spec errata, intended use, new questions; continued interop events  SDOs do not solve problems but are venue where people need to agree on solutions and follow through  Greatest challenge is not to build more layers but getting the ones we have working  Missing technology that would allow SOAP clients to consume REST and vice versa  Innovator’s dilemma: educating users to possibilities, vendors implementing technology  Center of gravity to deal with spec errata, intended use, new questions; continued interop events  SDOs do not solve problems but are venue where people need to agree on solutions and follow through

12. The Way Forward (1)  Undoing REST vs. SOAP  Need to leverage strength in both approaches  Well-defined bridges  Combination, not convergence to single solution  Undoing REST vs. SOAP  Need to leverage strength in both approaches  Well-defined bridges  Combination, not convergence to single solution

13. The Way Forward (2)  Putting the Web in WS (and vice versa)  Unproductive pattern of WS taken off the Web, e.g. WS-Addressing reference parameters  Expose WS resources, e.g. WSDLs, using URIs  Allow all concerned to reference the same resources from either approach without needing specialized tooling  Description beyond WSDL needed for WS and services on Web (see WADL as “REST DL”)  Putting the Web in WS (and vice versa)  Unproductive pattern of WS taken off the Web, e.g. WS-Addressing reference parameters  Expose WS resources, e.g. WSDLs, using URIs  Allow all concerned to reference the same resources from either approach without needing specialized tooling  Description beyond WSDL needed for WS and services on Web (see WADL as “REST DL”)

14. The Way Forward (3)  Need for coordination  Short term goal must be solving interoperability problem  Goals of coordination  Maintenance of errata  Clarification of ambiguity during implementation  Coordination of disconnects between specs  Maintenance/coordination of test suites  Coordination of comments on usefulness for real-world problems  Sponsoring interop events  Capture of interop results as body of best practice  Prepare for “new legacy” of different versions of specs  Need for coordination  Short term goal must be solving interoperability problem  Goals of coordination  Maintenance of errata  Clarification of ambiguity during implementation  Coordination of disconnects between specs  Maintenance/coordination of test suites  Coordination of comments on usefulness for real-world problems  Sponsoring interop events  Capture of interop results as body of best practice  Prepare for “new legacy” of different versions of specs

15. Final Questions  What specific efforts to recommend  Where to recommend the work be done  What specific efforts to recommend  Where to recommend the work be done