Web Services Interoperability Jorgen Thelin Senior Program Manager Connected Systems Division Microsoft Corporation Ensuring interoperability through Web services specifications
Agenda What is Interoperability Ways to Achieve Interoperability WS-* Interop Workshops Plug-fests Profiling / WS-I Microsoft’s Commitment to Interoperability
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
Interoperability means  connecting people, data, and diverse systems 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
Integration via Interop Network App Other Stack App Other MSFT App WSE App WCF Interoperability is the main way to achieve  integration in a heterogeneous environment. Assurances Messaging SOAP WS-Security MTOM WS-Addressing Metadata WS-Policy WSDL WS-Discovery UDDI WS-Metadata Exchange WS-Transfer WS-Enumeration WS-Eventing XML Schema WS-Reliable Messaging WS-Coordination WS-Atomic Transaction WS-Business Activity WS-Trust WS-Secure Conversation Infrastructure and Profiles WS-Management WS-Federation Devices Profile Foundation SOAP / HTTP SOAP / UDP MIME XML Infoset XML 1.0 XML Namespaces WS-* Protocols
Integration via Interoperability Network App Other Vendor Stack App Other MSFT Stack App WCF App WCF Wire level interoperability achieves integration in a heterogeneous environment. App WSE Assurances Messaging SOAP WS-Security MTOM WS-Addressing Metadata WS-Policy WSDL WS-Discovery UDDI WS-Metadata Exchange WS-Transfer WS-Enumeration WS-Eventing XML Schema WS-Reliable Messaging WS-Coordination WS-Atomic Transaction WS-Business Activity WS-Trust WS-Secure Conversation Infrastructure and Profiles WS-Management WS-Federation Devices Profile Foundation SOAP / HTTP SOAP / UDP MIME XML Infoset XML 1.0 XML Namespaces WS-* Protocols
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: Available Proven Compatible Proven scenarios
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
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
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
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
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
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
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
Interop Profiles Define a subset of specifications and options that are: Composable Scoped 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
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
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)
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
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
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/
 
Backup
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
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
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
Delivering WS-* Interop - Microsoft 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 VS2003 + Web Services  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 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 Vista Wave Windows Server 2003 “ R2” Wave
WS-* Protocols - Industry Adoption WS-P Messaging Security Assurances Devices System Mgmt Metadata DPWS WS-SecureConv WS-Security WS-Trust WS-RM WS-AT MEX WS-D SOAP/WSDL 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 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.    Released Product  Public Interop A Co-Author 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) A A A  Canon Inc.  Cape Clear Software Inc.  Computer Associates (Netegrity)  A A  gSOAP  IBM Corp. (DataPower)     IONA Technologies  RedHat  (JBoss / Arjuna)  Layer 7 Technologies Inc.  A  A 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  A A A 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    SAP A   Sun Microsystems, Inc.   Sonic Software  Software AG (WebMethods) A
 

Achieving Interoperability Through Web Services

  • 1.
    Web Services InteroperabilityJorgen Thelin Senior Program Manager Connected Systems Division Microsoft Corporation Ensuring interoperability through Web services specifications
  • 2.
    Agenda What isInteroperability 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.
    Interoperability means connecting people, data, and diverse systems 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
  • 5.
    Integration via InteropNetwork App Other Stack App Other MSFT App WSE App WCF Interoperability is the main way to achieve integration in a heterogeneous environment. Assurances Messaging SOAP WS-Security MTOM WS-Addressing Metadata WS-Policy WSDL WS-Discovery UDDI WS-Metadata Exchange WS-Transfer WS-Enumeration WS-Eventing XML Schema WS-Reliable Messaging WS-Coordination WS-Atomic Transaction WS-Business Activity WS-Trust WS-Secure Conversation Infrastructure and Profiles WS-Management WS-Federation Devices Profile Foundation SOAP / HTTP SOAP / UDP MIME XML Infoset XML 1.0 XML Namespaces WS-* Protocols
  • 6.
    Integration via InteroperabilityNetwork App Other Vendor Stack App Other MSFT Stack App WCF App WCF Wire level interoperability achieves integration in a heterogeneous environment. App WSE Assurances Messaging SOAP WS-Security MTOM WS-Addressing Metadata WS-Policy WSDL WS-Discovery UDDI WS-Metadata Exchange WS-Transfer WS-Enumeration WS-Eventing XML Schema WS-Reliable Messaging WS-Coordination WS-Atomic Transaction WS-Business Activity WS-Trust WS-Secure Conversation Infrastructure and Profiles WS-Management WS-Federation Devices Profile Foundation SOAP / HTTP SOAP / UDP MIME XML Infoset XML 1.0 XML Namespaces WS-* Protocols
  • 7.
    A Standard isnot 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: Available Proven Compatible Proven scenarios
  • 8.
    Components of BusinessInteroperability 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 ProcessStep 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 AchievingInteroperability 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 WorkshopsFocus: 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 TestingFocus: 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 / PilotProjects 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 Definea subset of specifications and options that are: Composable Scoped 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 WeNeed 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 CompatibilityVendors 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 isthe 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-* WorkshopProcess 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/
  • 21.
  • 22.
  • 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 StrategyOpen 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 toInteroperability 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.
    Delivering WS-* Interop- Microsoft 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 VS2003 + Web Services 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 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 Vista Wave Windows Server 2003 “ R2” Wave
  • 27.
    WS-* Protocols -Industry Adoption WS-P Messaging Security Assurances Devices System Mgmt Metadata DPWS WS-SecureConv WS-Security WS-Trust WS-RM WS-AT MEX WS-D SOAP/WSDL 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 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.    Released Product  Public Interop A Co-Author 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) A A A  Canon Inc.  Cape Clear Software Inc.  Computer Associates (Netegrity)  A A  gSOAP  IBM Corp. (DataPower)     IONA Technologies  RedHat (JBoss / Arjuna)  Layer 7 Technologies Inc.  A  A 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  A A A 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    SAP A   Sun Microsystems, Inc.   Sonic Software  Software AG (WebMethods) A
  • 28.

Editor's Notes

  • #2 Situation: Organizations operate in an increasingly heterogeneous IT environment Complication: A single vendor can no longer cover making everything work together Implication: Organizations need to place increasing emphasis on connecting IT systems together themselves Position: At Microsoft we have spent the last 5 years creating Web Services standards and products to achieve multi-vendor interop Opening Action: This talk will help you understand the MS view of interoperability, and share our experiences and best practices for achieving interoperability Benefit: This knowledge will help you effectively bootstrap your processes for achieving multi-vendor interoperability within your organization Main items: What is interoperability 2. Best practice ways to achieve interoperability 3. Microsoft’s commitment to interoperability