Transcript Slide 1
Web Services Interoperability in Healthcare Mark Oswald Program Manager, eBusiness Healthcare [email protected] 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 Microsoft Confidential 3 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 <S:Envelope … > <S:Header> Addressing Security Reliability <wsa:ReplyTo xmlns:wsa=“> <wsa:Address>http://business456.com/User12</wsa:Address> </wsa:ReplyTo> <wsa:To>http://fabrikam123.com/Traffic</wsa:To> <wsa:Action>http://fabrikam123.com/Traffic/Status</wsa:Action> <wssec:Security> <wssec:BinarySecurityToken ValueType="wssec:X509v3" EncodingType=“wssec:Base64Binary"> dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD </wssec:BinarySecurityToken> </wssec:Security> <wsrm:Sequence> <wsu:Identifier>http://fabrikam123.com/seq1234</wsu:Identifier> <wsrm:MessageNumber>10</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> <S:Body> <app:TrafficStatus xmlns:app="http://highwaymon.org/payloads"> <road>520W</road><speed>3MPH</speed> </app:TrafficStatus> </S:Body> </S:Envelope> 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. 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 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 July 2003 WS-Federation March 2003 WS-ReliableMessaging WS-Addressing RM Roadmap April 2002 WS-Security and Security Roadmap UDDI SOAP 2000 WSDL WS-I September 2003 WS-AtomicTransaction WS-Coordination SRT WS Whitepaper December 2002 WS-Policy WS-Trust WS-SecureConversation August 2002 WS-Transaction WS-Coordination Web Services Architecture Connected Applications Mobile Secure Management Reliable Messaging XML Transports EAI B2B Grid Business Process … Transacted Metadata Devices P2P Messaging SOAP URI WS-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='http://schemas.xmlsoap.org/soap/envelope/' > <s:Header> <!-- Protocol related stuff goes here --> <!-- App level context goo goes here too --> </s:Header> <s:Body> <!-- Intent of message goes here --> </s:Body> </s:Envelope> 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 Spec SOAP 1.1 SOAP 1.2 WS-Addressing Status Deployed Standard Published Metadata WS-Metadata Exchange WS-Policy Assertions WS-Policy Attachment WS-Policy WSDL Metadata Driven Architecture Policy used by X when sending a message out (often implicit) X Y Get Policy Compatible? Policy used by Y when receiving a message in Cache Y’s In X’s Out Y’s In Yes ' send( To: Y receive( To: Y To: Y X’s Out Y’s In ) Y’s 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 Spec WSDL 1.1 WSDL 1.2 WS-Policy WS-PolicyAssertions WS-PolicyAttachment WS-MetadataExchange Status Deployed @ standards org In Workshop In Workshop In Workshop Near 1st publication Security WS-Security WS-Secure Conversation WS-Trust WS-Security WS-Federation Policy WS-Security Defines a framework for building security protocols Integrity Confidentiality 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 Spec WS-Security WS-SecureConversation WS-Trust WS-SecurityPolicy Status @ standards org Workshop: interop Workshop: interop Workshop: interop 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-Atomic WS-Business WS-Security WS-Trust Transaction Activity WS-Secure WS-Security Conversation Policy WS-Coordination WS-AtomicTransaction Classic 2 Phase Commit ACID protocol Prepare Commit/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 Phase 2 Phase 1 Rollback Aborting Aborted Prepare Active Committed Prepared Commit Preparing Prepared Committing Ended ReadOnly or Aborted Coordinator generated Participant generated 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 www.ws-i.org, consider membership Support development of the HL7 WS-I Profile Thank you © 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.