Web Services Interoperability in Healthcare Mark Oswald Program Manager, eBusiness Healthcare

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

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

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)

Composable Headers Addressing Security Reliability <wssec:BinarySecurityToken ValueType="wssec:X509v3" EncodingType=“wssec:Base64Binary"> dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD W 3MPH

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

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.

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

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

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)

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

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

Messaging SOAPURIWS-Addressing

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’

<s:Envelope xmlns:s=' > SOAP 1.1

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

Status SpecStatus SOAP 1.1 Deployed SOAP 1.2 Standard WS-AddressingPublished

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

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

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

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

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

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

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

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

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

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

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

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

Status SpecStatus standards org WS-SecureConversation Workshop: interop WS-Trust WS-SecurityPolicy

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

Reliable Messaging WS-ReliableMessaging

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

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

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

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

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

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

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 consider membership Support development of the HL7 WS-I Profile

© 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