1. Web Services Interoperability in Healthcare Mark Oswald Program Manager, eBusiness Healthcare markosw@microsoft.com

2. Agenda Design Principles for Interoperability WS-I Organization Web Services Architecture

3. Design Principles for Web Services Protocols Modular and composable Factored to stand alone or work together General-purpose Agnostic to place it is running or originated Standards-based Multi-vendor interoperation critical Federated No central point of administration, control, failure 3 Microsoft Confidential

4. Modular Use only what you need Everything works together Not reinventing the wheel for every protocol area Defined by composable SOAP headers and SOAP message These ‘infrastructure’ protocols augment domain-specific protocols (e.g., healthcare)

5. Composable Headers Addressing Security Reliability http://business456.com/User12 http://fabrikam123.com/Traffic http://fabrikam123.com/Traffic/Status <wssec:BinarySecurityToken ValueType="wssec:X509v3" EncodingType=“wssec:Base64Binary"> dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD http://fabrikam123.com/seq1234 10 520W 3MPH

6. Standards-Based Commitment to Publishing specifications Working with partners to refine specifications Working with partners, customers, and standards bodies for broad adoption Different standards bodies for different specs, based on the spec

7. Federated Fully distributed Crosses organization and trust domains Does not require centralized servers or administration May sometimes require ‘edge’ software to do protocol translation, security work, routing, etc.

8. www.ws-i.org An open industry effort Industry initiative focused on promoting Web services interoperability Organization formed by industry leaders Open membership and participation Based on partnerships Symbiotic relationship with other standards organizations through integration of their outputs Goal: Enable interoperability across platforms, applications, and programming languages Success will accelerate adoption and deployment of Web services

10. WS-I produces… WS Protocol specifications Core building blocks of WS architecture Created when interoperability is a requirement Typically have co-authors (market leaders) What’s in a Protocol spec Only aspects visible to an observer on the wire Message formats Invariants and obligations Prose describing model and semantics What’s not in a Protocol spec Details that relate to implementation API considerations An abstract implementation Every possible optimization

11. WS-I also produces… WS Profiles A set of rules for using these specs interoperably We treat these like specs Workshops flesh these out Profiles are what makes this stuff real! Examples WS-I Basic Profile 1.0 (standard) WS-Federation Active Client Profile (published) WS Devices Profile (in active development)

12. WS Architecture Evolution Secure, Reliable, Transacted SOAP UDDI WSDL April 2002 WS-Security and Security Roadmap August 2002 WS-Transaction WS-Coordination WS-I 2000 December 2002 WS-Policy WS-Trust WS-SecureConversation July 2003 WS-Federation March 2003 WS-ReliableMessaging WS-Addressing RM Roadmap September 2003 WS-AtomicTransaction WS-Coordination SRT WS Whitepaper

13. Connected Applications Messaging XML Transports SecureReliableTransacted Metadata Management Business Process … Web Services Architecture DevicesMobile P2PEAIB2BGrid

14. Messaging SOAPURIWS-Addressing

15. SOAP Messaging Model SOAP provides an outer wrapper for messages Divides message into two parts Headers and Body Body typically carries 'intent' of the message Headers carry protocol and/or app level context information Headers can be ‘mandatory’ and ‘targeted’

16. <s:Envelope xmlns:s='http://schemas.xmlsoap.org/soap/envelope/' > SOAP 1.1

17. WS-Addressing WS-Addressing provides mechanisms for addressing resources Shipping those addresses in messages Addressing messages to those resources Addressing mechanisms are transport-neutral Internal resource organization is opaque

18. Status SpecStatus SOAP 1.1 Deployed SOAP 1.2 Standard WS-AddressingPublished

19. Metadata WSDL WS-Policy Attachment WS-Policy Assertions WS-Metadata Exchange

20. Metadata Driven Architecture Compatible? Y’s InX’s Out send( ) Y’s InX’s Out To: Y ' receive( ) Y’s In ' To: Y Get Policy Policy used by X when sending a message out (often implicit) Yes Cache Y’s In XY Policy used by Y when receiving a message in

21. Policy WS-Policy: A framework for making statements about resources Used to express receiver requirements for incoming messages (e.g., transports, security) At runtime, can be used to match requirements to capabilities WS-PolicyAssertions: Predefined basics WS-PolicyAttachment: Attaching policy expression to a subject

22. Web Services Description Language (WSDL) Describes the messages that a service sends and receives Provides abstractions for grouping messages and message exchanges (operations) ‘Programming Interface’ for Web Services Provides concrete information for deployment and serialization Transport information Port binding

23. Status SpecStatus WSDL 1.1 Deployed WSDL 1.2 @ standards org WS-Policy In Workshop WS-PolicyAssertions WS-PolicyAttachment WS-MetadataExchange Near 1 st publication

24. Security WS-Security WS-Secure Conversation WS-Trust WS-Security Policy WS-Federation

25. WS-Security Defines a framework for building security protocols IntegrityConfidentiality Propagation of security tokens Framework designed for end-to-end security of SOAP messages From initial sender, through 0-n intermediaries to ultimate receiver

26. WS-Security Leverages existing XML security specs XMLDSIG for integrity XMLENC for confidentiality Provides constructs for transmitting security tokens Supports text and binary tokens

27. WS-Trust Defines how to broker trust relationships Some trust relationship has to exist a priori Defines how to exchange security tokens Defined as an interface specification for a Security Token Service A RequestSecurityToken message is sent to the trust service It responds with a RequestSecurityTokenResponse

28. WS-SecureConversation WS-Security provides for only single message security Nodes will often want to exchange more than one message Specifying new symmetric keys for each message is tedious and verbose WS-SecureConversation defines mechanisms to address this

29. WS-SecureConversation Participants establish a shared context Context contains keys and other information Has an identifier – used in subsequent messages Optionally has creation/expiry timestamps Context can be established in a variety of ways Using WS-Trust Having one party create the context Through negotiation

30. WS-SecurityPolicy A set of policy assertions related to concepts defined by other WS-Sec* specs Allows participants to specify Token types Whether integrity and/or confidentiality are required Algorithms for the above Which message parts need signing/encrypting

31. Status SpecStatus WS-Security @ standards org WS-SecureConversation Workshop: interop WS-Trust WS-SecurityPolicy

32. Distributed State Coordination Reliable Messaging Two-party (source, destination), asynchronous Exactly once, in-order Atomic Transaction Multi-party, all or nothing state change, synchronous Two Phase Commit Phase 1: Prepare to Commit Phase 2: Commit or Abort Business Activity Multi-party, final consistent state, asynchronous Two Phases (almost) Phase 1: Cancel/Complete Phase 2: Close/Compensate Anytime: Exit/Fault

33. Reliable Messaging WS-ReliableMessaging

34. WS-ReliableMessaging RM defines QoS over unidirectional message sequences Exactly once, in-order Simplifies application programming – no need to defend against Lost, duplicated or delayed messages Endpoint failure Acknowledgements sent upon receipt

35. Transactions WS-Security WS-Secure Conversation WS-Trust WS-Security Policy WS-Atomic Transaction WS-Coordination WS-Business Activity

36. WS-AtomicTransaction Classic 2 Phase Commit ACID protocol PrepareCommit/Rollback All resources must be ‘up’ (synchronous) All-or-nothing (complete agreement) Resources are locked – easy programming model Appropriate for scenarios with shared assumptions about latency/trust

37. AT Abstract State Diagram ActiveEnded Aborting Preparing Prepare PreparedCommitting Prepared Committed ReadOnly or Aborted Commit Rollback Participant generatedCoordinator generated Phase 1 Phase 2

38. WS-BusinessActivity Looser isolation model Intermediate states visible Operations cannot be undone Shared state “settles out” at end of interaction Tries to move forward to a known good state May try “Plan B” May use compensation No requirement to lock resources Appropriate for scenarios crossing trust domains

39. WS-Coordination Base Protocol for AT and BA Creates and Registers for Transactions Generates Coordination Context Passes Data to Register for Transactions Based on WS-Addressing Extensible Coordination Types AT and BA are the two predefined ones

40. Summary Consider leveraging ‘broad’ industry efforts (WS-I) for messaging infrastructure needs Commercial platform and tools are available and will continue to evolve WS-I specifications and profiles are work in progress Investigate www.ws-i.org, consider membership www.ws-i.org Support development of the HL7 WS-I Profile

41. © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Thank you