Docstoc

Web Services Roadmap for IHE ITI

Document Sample
Web Services Roadmap for IHE ITI Powered By Docstoc
					Web Services Roadmap for IHE ITI
(DRAFT)

Background
Web Services has become a catch-all phrase describing pretty much any HTTP
transaction over a TCP/IP network. A more precise definition of Web Services should
imply richer infrastructure capabilities with all transactions built using SOAP messages.
The following references will provide more detailed background to the various SOAP-
based web services of relevance to IHE.

Web Services SDOs
W3C – The World Wide Web Consortium – the people behind HTML, XML, and all
things “Web”
OASIS – The Organization for the Advancement of Structured Information Standards.
Among the standards developed by OASIS is the ebXML family of specifications.
WS-I – The Web Services-Interoperability Organization. This organization publishes
Profiles, which incorporate various existing standards, and constrain them to improve
interoperability.

Web Services Standards
SOAP 1.1 – The first widely implemented version of SOAP. Many existing web
services are based on SOAP 1.1. This specification was created outside of the W3C and
later was submitted as a W3C note (http://www.w3.org/TR/2000/NOTE-SOAP-
20000508/)
SOAP 1.2 – The latest version of SOAP, and the first version defined by the W3C.
(http://www.w3.org/TR/soap12). Among its features is the ability to bind SOAP
messages to different Internet protocols (e.g. SMTP). All major web services
development platforms already support SOAP 1.2.
WS-* - An aggregate name for web services standards, named using a “WS-“ prefix.
Some these standards are defined by the W3C, others are defined by OASIS, and yet
some newer ones are developed outside of the main SDOs. Many of the now-standard
specifications were developed in a similar way, before being submitted to standards
organizations for approval and further development. There is an overview of how these
fit together at IBM’s DeveloperWorks website.
WSDL 1.1 – The Web Services Description Language was also first developed outside
of the W3C, and later submitted as a note (http://www.w3.org/TR/wsdl). There is a
SOAP 1.2 binding (http://schemas.xmlsoap.org/wsdl/soap12/) for WSDL 1.1.
MTOM – The SOAP Message Transmission Optimization Mechanism “… describes an
abstract feature and a concrete implementation of it for optimizing the transmission
and/or wire format of SOAP messages.” MTOM is built on top of SOAP 1.2 and XOP,
and it is an improvement over both SOAP with Attachments and DIME. It satisfies IHE
and ebXML Registry requirements for handling non-XML objects.
XOP – The XML-binary Optimized Packaging convention, describes “… a means of
more efficiently serializing XML Infosets that have certain types of content.”



C:\Docstoc\Working\pdf\6011fd87-113d-4dca-a452-f17f125849fc.doc   -1-              6/25/2011 3:29:00 PM
WS-I BP 1.1 – The WS-I Basic Profile 1.1 is a collection of Web Services standards
and corresponding constraints for the purposes of interoperability. It is based on SOAP
1.1 and therefore uses WS-I AP to handle attachments.
WS-I SSBP 1.0 – The WS-I Simple SOAP Binding Profile complements WS-I BP 1.1.
It describes SOAP message serialization and is based on SOAP 1.1
WS-I AP 1.0 – The WS-I Attachments Profile slightly predates the MTOM
specification. It is based on SOAP with Attachments, and complements WS-I BP 1.1 and
WS-I SSBP 1.0.
WS-I BSP WD – The WS-I Basic Security Profile is still a workgroup draft. It addresses
both Transport Layer security, and SOAP message security (based on WS-Security).
Additional profiles specify the use of different security tokens within WS-Security.
WS-I SAMLTP WD – The WS-I SAML Token Profile is also a workgroup draft. It
addresses the use of SAML tokens in WS-Security as specified in the WS-Security
SAML Token Profile. This profile is a complement to WS-I BSP.
WS-Security – The OASIS Web Services Security specification defines a mechanism
which “…can be used to accommodate a wide variety of security models and encryption
technologies” in SOAP messaging in order to “…provide message integrity and
confidentiality.” WS-Security is designed to work with both SOAP 1.1 and SOAP 1.2.
The specification provides support for multiple security mechanisms and formats, which
are further specified as profiles. The current version is 1.0, and version 1.1 is a working
draft, headed towards “committee standard” status.
WS-Security SAMLTP – The Web Services SAML Token Profile describes how to use
SAML 1.1 assertions with the WS-Security specification. The current version is 1.0, and
version 1.1 is a working draft, moving through the process together with WS-Security
and other profiles (Kerberos, X.509, etc).
WS-Addressing – The Web Services Addressing specification was developed outside
of the W3C, and was later submitted to the W3C for discussion and as a basis for further
development. The specification “… defines XML elements to identify Web service
endpoints and to secure end-to-end endpoint identification in messages.” Currently there
are two W3C candidate recommendations describing WS-Addressing Core and WS-
Addressing SOAP Binding. Both the original submission and the Candidate
Recommendations rely on SOAP 1.2.
HL7 WS Profile – The 2005 HL7 V3 Normative edition includes a Web Services
Profile DSTU. It is based on WS-I BP 1.0, and therefore on SOAP 1.1 and WSDL 1.1.
The current HL7 V3 ballot contains a Release 2 of the profile, which adds SOAP 1.2,
WS-I BSP, WS-Security, and WS-Addressing. It also includes references to WS-Trust,
WS-Policy, WS-Reliable Messaging, WS-Secure Conversation, and other WS-*
specifications, which have been developed by industry collaboration, but have not been
submitted to a standards body yet..

How do we make sense of all this?
The main goal of IHE is to enable interoperability by profiling existing standards, which
makes implementation more focused and unambiguous. At the same time, we need to pay
attention to the availability and support of these standards in existing development
environments. Some of these specifications are already supported on various platforms,
and others are becoming part of the latest versions. A gradual and consistent approach to


C:\Docstoc\Working\pdf\6011fd87-113d-4dca-a452-f17f125849fc.doc   -2-              6/25/2011 3:29:00 PM
including these standards in IHE profiles will provide participants with a guidance
regarding when certain features will be expected for implementation. The yearly IHE
cycle will also enable corrections to the roadmap based on new developments with these
standards.

The first steps of adopting the various WS specification will build upon the existing
standards and implementations: SOAP 1.2, MTOM, WS-Addressing, WS-Security, as
needed by the different IHE profiles. Other industry events will likely bring these and
other specifications together (e.g. WS-I plans to incorporate SOAP 1.2 and MTOM in its
profiles, the ebXML registry committee plans to create a WS-* binding for the registry
transactions in version 3).

The following IHE profiles will likely be the first ones to incorporate further WS
functionality, so a brief discussion is included.

PDQ/PIX
The HL7 WS Profile can be used as an example for how to combine requirements from
the WS standards. The PDQ/PIX extensions using HL7 V3 should follow the HL7 WS
Profile Release 2, so that SOAP 1.2 can be used as the basis of the extension. Further
development can include the use to WS-Security and WS-Addressing.

XDS
The XDS profile will be getting ready to adopt ebXML registry version 3 transactions.
The initial step will likely be with “canned queries.” Making sure that the SOAP binding
for these transaction is compatible with SOAP 1.2 will make the next steps of adopting
ebXML registry v3 transaction using WS-* bindings a natural evolution of the profile.

XDS Offline mode will be a challenge to express in WS-* terms, but the fact that SOAP
1.2, MTOM, and WS-Addressing are protocol-neutral by design, should make it possible.

The new XDS Peer-to-Peer proposal should also take into account WS-* specifications.
This will, again, allow for a consistent set of transactions, built on a common set of
standards.




C:\Docstoc\Working\pdf\6011fd87-113d-4dca-a452-f17f125849fc.doc   -3-                6/25/2011 3:29:00 PM

				
DOCUMENT INFO