1. Web Services Interoperability Jorgen Thelin Senior Program Manager Connected Systems Division Microsoft Corporation Ensuring interoperability through Web services specifications

2. Agenda What is Interoperability Ways to Achieve Interoperability WS-* Interop Workshops Plug-fests Profiling / WS-I Microsoft’s Commitment to Interoperability

3. What is Interoperability? Integration Combining software or hardware components or both into an overall system. Interoperability The ability to exchange and use information (usually in a large heterogeneous network made up of several local area networks) The ability of software and hardware on multiple machines from multiple vendors to communicate Source: Dictionary.com http://dictionary.reference.com/search?q=interoperability http://dictionary.reference.com/search?q=integration

4. It gives customers control over the data they create and want to share Vendors create innovative solutions that bridge technologies to address real customer needs in an innovative manner The nature of software allows for translatability in lieu of uniformity Interoperability means connecting people, data, and diverse systems

5. Integration via Interop Network App Other Stack App Other MSFT App WSE App WCF Assurances Messaging SOAP WS-Security MTOMWS-Addressing Metadata WS-Policy WSDL WS-Discovery UDDI WS-Metadata Exchange WS-TransferWS-EnumerationWS-Eventing XML Schema WS-Reliable Messaging WS-Coordination WS-Atomic Transaction WS-Business Activity WS-Trust WS-Secure Conversation Infrastructure and Profiles WS-ManagementWS-Federation Devices Profile Foundation SOAP / HTTP SOAP / UDP MIME XML Infoset XML 1.0 XML Namespaces WS-* Protocols Interoperability is the main way to achieve integration in a heterogeneous environment.

6. Integration via Interoperability Network App Other Vendor Stack App Other MSFT Stack App WCF App WCF Assurances Messaging SOAP WS-Security MTOMWS-Addressing Metadata WS-Policy WSDL WS-Discovery UDDI WS-Metadata Exchange WS-TransferWS-EnumerationWS-Eventing XML Schema WS-Reliable Messaging WS-Coordination WS-Atomic Transaction WS-Business Activity WS-Trust WS-Secure Conversation Infrastructure and Profiles WS-ManagementWS-Federation Devices Profile Foundation SOAP / HTTP SOAP / UDP MIME XML Infoset XML 1.0 XML Namespaces WS-* Protocols Wire level interoperability achieves integration in a heterogeneous environment. App WSE

7. A Standard is not Enough A specification does not guarantee integration or interoperability Problems that can arise: It’s paper not product Differing spec interpretations Optionality underlap / disconnect Fit to business scenario Also need to have: Implementations that are: AvailableProvenCompatible Proven scenarios

8. Components of Business Interoperability Agreed syntax representations E.g. XML Agreed protocols E.g. SOAP + WS-* specs (such as WS- ReliableMessaging) Agreed payload formats E.g. HL7 schemas for healthcare data Profiled composition E.g. Pre-defined options to ensure functionality Agreed business scenarios E.g. Well defined interaction scenarios / use cases

9. WS-* Specification Process Step 2 Broader Participation Step 1 Develop Process reconciles conflicting goals Quality of engineering Time to market Breadth of industry support Step 3 Standardization Step 4 Profiling Increasing Industry Participation Specification Published Feedback and Interop Workshops Revise spec Standards Org Such as: WS-I, HL7, ACORD, Devices Profile Idea

10. Techniques for Achieving Interoperability Protocol Implementation and Testing Scenario-based approaches Examples: WS-* Interop Workshops Product Plug-fests E2E (end-to-end) Scenario Testing Proof-of-Concept / Pilot projects Specification Profiling … and repeat

11. WS-* Interoperability Workshops Focus: Testing the specification(s) Goal: Produce well-engineered, quality WS-* specifications Based in specified interop scenarios Ground the spec development efforts in implementation and usage experience Demonstrate / prove spec interoperability Gain implementation experience earlier Discover inconsistencies with other WS-* specifications Apply software testing disciplines to specs Refine the important spec usage scenarios Determine readiness for standardization Involvement: Vendors with implementations Initiated by key vendors or standards orgs Often prototype or early development code

12. Product Plug-fests Focus: Unit Testing the product(s) Goal: Get products working together Based in specified interop scenarios May or may not be using business data Ground the product implementation efforts in usage experience Demonstrate / prove product interoperability Gain interoperability experience earlier Discover inconsistencies with other WS-* products Refine the important product usage scenarios Determine readiness for product release Involvement: Vendors with implementations Initiated by key vendors or key interest groups Usually close-to-release products

13. End-to-End Scenario Testing Focus: System Testing the product(s) with a realistic E2E business scenario Goal: Demonstrate products working together Based on specified end-to-end business scenarios Uses realistic business data Ground the product implementation efforts in usage experience Demonstrate / prove product interoperability Discover inconsistencies with other WS-* products Refine the important product usage scenarios Involvement: Vendors with implementations Initiated by key vendors or key interest groups Usually released or close-to-release products

14. Proof-of-Concept / Pilot Projects Focus: Testing the application and product deployment(s) Goal: Demonstrate internal systems working together Based on specified end-to-end business scenarios Uses realistic business data Ground the in-house implementation and product deployment efforts in realistic usage experience Demonstrate / prove product applicability Gain deployment experience earlier Discover inconsistencies with other systems Refine the important product deployment scenarios Determine readiness for product and system deployment Involvement: Customers + Vendors products Initiated by customers or vendor partnership Usually released products

15. Interop Profiles Define a subset of specifications and options that are: ComposableScoped Work together Examples: Secure RM – WS-ReliableMessaging + WS-Trust / WS- SecureConversation / WS-Security ACORD Messaging Profile – WS-* + ACORD payload schemas Who defines the profile? Vertical domain org – eg. ACORD Horizontal org – eg. WS-I Customer – singly or in groups

16. Why Do We Need Interop Profiles? Need to constrain (soften) runtime options to achieve out-of-box interoperability WS-* Architecture is designed for general applicability across a wide range of industries / scenarios Often too much optionality in the base specifications Tailor to specific domain / environment E.g. Devices Profile only requires SOAP 1.2 not SOAP 1.1 to lower implementation footprint Guide implementation and deployment choices Achieve a proven composition of protocols and payloads Allows simplification of application deployment e.g. WCF allows selection of interop profile to use

17. Profiling: WS-I Focus: Cross-industry profiling for baseline Web Service interoperability Deliverables – Current work: Basic Profile v1.2 SOAP 1.1 + WSDL 1.1 + UDDI 2.0 + Attachments (MTOM) Basic Security Profile v1.1 BP v1.x + WS-Security 1.1 + HTTPS Basic Profile v2.0 SOAP 1.2 + WSDL 1.1 + UDDI 2.0 + WS-Addressing + Attachments (MTOM) Reliable Secure Profile (RSP) BP 1.x + BSP 1.x + WS-ReliableMessaging 1.1 + WS- SecureConversation 1.3 Sample Applications (Supply Chain Management) Profile testing tools (vendor / user self-testing)

18. Proving Interop Compatibility Vendors Vendor self-test Community Multi-vendor community testing (eg. WS-* Interop Workshops and plug-fests) Industry wide demo (eg. WS-Security Interop Demo @ Gartner WS Summit) Customers In-house testing Competitor bake-off

19. Summary Interoperability is the best way to achieve integration in a heterogeneous IT environment Wire-level interoperability is the real goal Web Services WS-* Architecture designed to support multi-vendor environments There are several ways to help achieve interoperability: Usage scenarios based techniques (WS-* Interop Workshops, Plug-fests, Proof-of-Concept / Pilot projects) Specification Profiling Testing Microsoft is deeply committed to delivering products with proven interoperability that work well in heterogeneous environments

20. Links WS-* Workshop Process Overview http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wkshopprocess.asp WS-* Workshops home page http://msdn.microsoft.com/webservices/community/workshops/ Microsoft Interoperabilty home page http://www.microsoft.com/interop WS-* Specifications index page http://msdn.microsoft.com/webservices/understanding/specs/ MSDN Web Services Developer Center http://msdn.microsoft.com/webservices/

22. Backup

23. WS-* Specs & Workshops Typical Steps:  Spec is developed among a small number of companies  1 st Publication – publicly available  Feedback Workshop  2 nd Publication – publicly available  Interop Workshop  3 rd Publication – publicly available  Submission to standards org

24. Microsoft’s WS Strategy Open Interoperable Protocol Architecture – WS-* Invest in WS-* as an open, interoperable protocol framework for Service Orientation Ensure all the pieces work together Enable WS-* interoperability with industry partners Easy-to-use distributed application platform – Indigo Adopt WS-* as the underlying wire format Easy-to-use development environment – Visual Studio Facilitate design and deployment of distributed Web services applications Distributed IT Infrastructure Adopting WS-* as the glue technology Systems Management Connected Devices Identity Management User Experience Office/InfoPath, InfoCard

25. Microsoft’s Commitment to Interoperability Bill Gates’ Executive E-mail - Building Software That Is Interoperable By Design – 03-Feb-2005 http://www.microsoft.com/mscorp/execmail/2005/02-03interoperability.asp “However, the definition of well-designed [WS-*] protocol architecture is just part of the challenge. As part of this collaborative effort, Microsoft and other companies have invested significant resources to ensure that Web services implementations from different companies really are interoperable. This has involved industry workshops, extensive testing, revision of specifications in the face of experience, and even setting up an industry body known as WS-I to help ensure interoperability.” Plus deep commitment at the execution level WS-* Spec authorship WS-* Workshop Process Participation in Standards bodies Participation in WS-I Early WS-* implementations (WSE) Strategic WS-* platform (Indigo) Plug-fests - Product testing of multi-vendor interop

26. VS 2005 + WSE 3.0  SOAP 1.1, 1.2  WSDL 1.1  MTOM  WS-Addressing 2004/08 (or REC)  WS-Security 1.0 (U/P, X509, Kerberos)  WS-Secure Conversation  WS-Trust  WS-Policy based  Limited wire Interop with WSE 2.0 AD Federation Services in R2  Cross-organizational Identity Federation  Web SSO SQL Server 2005  SOAP 1.1,1.2  WSDL1.1  WS-Security 1.0 Management  WS-Management Delivering WS-* Interop - Microsoft VS2003 + Web Services Enhancements (WSE) 2.0 Enhancements (WSE) 2.0  SOAP 1.1  WSDL 1.1  WS-Addressing 2004/03  WS-Security 1.0 (U/P, X509, Kerberos)  WS-Secure Conversation 2004/04  WS-Trust 2004/04  WS-Policy based WCF (Indigo) -.NET 3.0 Wire-level interop with WSE3.0 In addition:  MTOM  SAML Token Profile 1.0  Security Policy  WS-Federation Active Client - Enables easy to build STS - Enables easy to build STS  WS-RM 2005/02, Policy  WS-AT/WS-C 2005/02, Policy  WS-Policy/PolicyAttachment  WS-MEX Easy to use Digital Identity / InfoCard Active Directory: Federation WSD API: Device Profile VistaWave Windows Server 2003“R2”Wave

27. AMD Inc. A Computer Associates A Dell Inc.  gSOAP Intel Corp.  HP / Mercury / Systinet A Microsoft Oracle SAP Sonic Software A Sun Microsystems, Inc.  WEBM Solutions, Inc.  WS-P WS-* Protocols - Industry Adoption Messaging Security Assurances Devices System Mgmt Metadata DPWS WS-SecureConv WS-Security WS-Trust WS-RM WS-AT MEX WS-D Released Product  Public Interop ACo-Author SOAP/WSDL Apache (WSO2) BEA Systems Inc. A Choreology Ltd IBM Corp. IONA Technologies RedHat (JBoss / Arjuna) HP / Mercury / Systinet Microsoft Oracle SAP Progress / Sonic Software Sun Microsystems Inc.  Tibco Software, Inc.  Apache (WSO2) BEA Systems Inc. A BMC (OpenNetwork) AAA Canon Inc. Cape Clear Software Inc. Computer Associates (Netegrity) AA gSOAP IBM Corp. (DataPower)  IONA Technologies RedHat (JBoss / Arjuna) Layer 7 Technologies Inc. AA HP / Mercury / Systinet  Microsoft Nokia Novell Oracle EMC (RSA Security)  Ping Identity Corp. A SAP Sonic Software Sun Microsystems, Inc. Tibco Software, Inc. Verisign Inc AAA Software AG (WebMethods) Apache (WSO2) Amazon BEA Systems Inc. Cape Clear Software Inc. Canon Inc.  eBay Inc. Epson Corp.  Fuji-Xerox Google gSOAP HP IBM Corp.  Intel Corp.  Iona RedHat (JBoss / Arjuna) Microsoft Novell Oracle Ricoh Co.  SAP Sun Microsystems, Inc. Xerox Corp.  BEA Systems Inc. A Brother Industries  Canon Inc.  Epson Corp.  Exceptional Innovation  Fuji-Xerox Co.  gSOAP HP Intel Corp.  Lexmark International, Inc. A Microsoft Peerless Systems Corp.  Schneider Electric SA  Toshiba Software AG (WebMethods) A Xerox Corp.  Apache (WSO2)  BEA Systems Inc.  Computer Associates A gSOAP IBM Corp.  RedHat (JBoss / Arjuna)  Layer 7 Technologies  HP / Mercury / Systinet Microsoft Novell Oracle SAPA Sun Microsystems, Inc. Sonic Software Software AG (WebMethods) A MTOM © 2003-2007 Microsoft Corporation. All rights reserved. The information contained in this document represents the current view at the time of publication and is subject to change. WS-Man WS-XFer / Enum WS-Fed UDDI