Achieving Interoperability Through Web Services
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Achieving Interoperability Through Web Services

on

  • 1,113 views

 

Statistics

Views

Total Views
1,113
Views on SlideShare
1,111
Embed Views
2

Actions

Likes
0
Downloads
14
Comments
0

2 Embeds 2

http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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

Achieving Interoperability Through Web Services Presentation Transcript

  • 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.
    • 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 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
  • 6. 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
  • 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:
          • Available
          • Proven
          • Compatible
        • 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:
      • 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 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/
  • 21.  
  • 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. 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.