The Future of Clinical Integration

1
The Future of Clinical Integration
2
The Future of Clinical Integration
Mark Oswald Program Manager E-Business Server
Division Microsoft Corporation
3
Agenda

• HL7 Version 3 Overview
• Web Services Interoperability

4
HL7 Version 3
5
HL7 Version 3 Motivations

• Version 2.x has inconsistent methodology for
  defining trigger events, messages, data fields,
  and structural relationships
• Lack of clear re-use guidelines for message
  segments
• Results in inconsistent use of optionality

6
HL7 Version 3 Themes

• New methodology for message development
• Based on a set of Information Models
• Based on storyboards
• Message encoding defined in separate
  specification (ITS)
• XML is currently the only ITS

7
Information Models

• Reference Information Model (RIM)
• Abstract model
• Backbone classes
• Act, Participation, Entity, Role,
  ActRelationship, RoleLink
• D-MIM, R-MIM, and HMDs
• Schema Generator

8
Story Boards

• Represent real world scenarios
• Determine Application Roles
• Determine Trigger Events
• Interaction Sending role Receiving role
  Trigger event Message type

9
Messaging concepts

• Message Wrappers
• Transmission wrapper
• Message identification
• Sending and Receiving systems
• Control Act wrapper
• Event information
• Acknowledgements
• Messaging Profiles
• Web Services
• ebXML (ebms)
• MLLP

10
Web Services and Interoperability
11
SOA Definition

• A service-oriented architecture is one where the
  application is divided into business functions
  invoked as services
• Provision of functionality via standards-based,
  discoverable services.
• SOA utilizes at a minimum
• SOAP
• UDDI
• WSDL
• Other protocols exist that are focused on making
  Web Services secure, reliable, transacted

12
Web Services Interoperability

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

13
Design Principles forWeb 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

14
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)

15
Composable Headers
ltSEnvelope gt ltSHeadergt ltwsaReplyTo
xmlnswsagt ltwsaAddressgthttp//business4
56.com/User12lt/wsaAddressgt lt/wsaReplyTogt
ltwsaTogthttp//fabrikam123.com/Trafficlt/wsaTogt
ltwsaActiongthttp//fabrikam123.com/Traffic/S
tatuslt/wsaActiongt ltwssecSecuritygt
ltwssecBinarySecurityToken
ValueType"wssecX509v3"
EncodingTypewssecBase64Binary"gt     
dWJzY3JpYmVyLVBlc..eFw0wMTEwMTAwMD
lt/wssecBinarySecurityTokengt
lt/wssecSecuritygt ltwsrmSequencegt
ltwsuIdentifiergthttp//fabrikam123.com/seq1234lt/ws
uIdentifiergt ltwsrmMessageNumbergt10lt/wsrm
MessageNumbergt lt/wsrmSequencegt
lt/SHeadergt ltSBodygt ltappTrafficStatus
xmlnsapp"http//highwaymon.org/payloads"gt
ltroadgt520Wlt/roadgtltspeedgt3MPHlt/speedgt
lt/appTrafficStatusgt lt/SBodygt lt/SEnvelopegt
Addressing
Security
Reliability
16
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

17
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.

18
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

19
(No Transcript)
20
WS-I produces

• WS Profiles
• A set of rules for using these specs in an
  interoperable manner
• Profiles are treated 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)

21
WS Architecture EvolutionSecure, Reliable,
Transacted
July 2003 WS-Federation
March 2003 WS-ReliableMessaging WS-Addressing RM
Roadmap
September 2003 WS-AtomicTransaction WS-Coordinatio
n SRT WS Whitepaper
April 2002 WS-Security and Security Roadmap
December 2002 WS-Policy WS-Trust WS-SecureConversa
tion
UDDI
SOAP
WS-I
August 2002WS-TransactionWS-Coordination
WSDL
2000
22
Web Services Architecture
Connected Applications
P2P
EAI
B2B
Grid
Business Process
Devices
Mobile
Management

Secure
Reliable
Transacted
Metadata
Messaging
XML
Transports
23
Messaging
SOAP
URI
WS-Addressing
24
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

25
ltsEnvelope xmlnss'http//schemas.xmlsoap.org
/soap/envelope/' gt ltsHeadergt lt!-- Protocol
related stuff goes here --gt lt!-- App level
context goo goes here too --gt lt/sHeadergt
ltsBodygt lt!-- Intent of message goes here
--gt lt/sBodygt lt/sEnvelopegt
SOAP 1.1
26
WS-Addressing

• WS-Addressing provides mechanisms for addressing
  resources
• Shipping those addresses in messages
• Addressing messages to those resources
• Virtualizes the network
• Addressing mechanisms are transport-neutral
• Internal resource organization is opaque
• Composes with WS-Security and other
  specifications

27
Metadata
WS-MetadataExchange
WS-PolicyAssertions
WS-Policy Attachment
WS-Policy
WSDL
28
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

29
Metadata

• Beyond what WSDL provides, what else is needed to
  describe a Web service?
• Security requirements
• Reliable messaging assurances
• Protocol versioning
• Etc
• These other attributes of a service can be
  described with WS-Policy
• XML-base language
• Complex ltOrgt, ltExactlyOnegt, etc

30
Metadata Driven Architecture
Policy used by X when sending a message out
(often implicit)
Policy used by Y when receiving a message in
31
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

32
Security
WS-Security
WS-Trust
WS-SecureConversation
WS-SecurityPolicy
WS-Federation
33
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

34
WS-Security

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

35
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

36
Security

• Policy
• Only accept Kerberos Tokens
• Only callers who are in the Manager role
• Messages must be encrypted

37
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

38
Trust Well known source
39
Trust Validation
40
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

41
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

42
Secure Conversations
43
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

44
Reliable Messaging
WS-ReliableMessaging
45
WS-ReliableMessaging

• End-to-End Management of Communication Failures
• Simplifies application programming
• Lost, duplicated or delayed messages.
• Endpoint failure
• Deliver Messages Exactly Once, In Order
• Acknowledgements of received messages.
• End-to-end coherent message stream.

46
Transactions
WS-Security
WS-Trust
WS-AtomicTransaction
WS-BusinessActivity
WS-SecureConversation
WS-SecurityPolicy
WS-Coordination
47
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

48
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

49
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

50
WS Considerations

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

51
BizTalk Accelerator for HL7
http//www.microsoft.com/hl7
52
Thank you for attending. Visit www.mshug.org.