Document Sample
IHE-XDS-MTOM-Detailed_cordonnier_-0.10 Powered By Docstoc
					                      IHE Profile Proposal (Detailed)
1. Proposed Profile: IHE XDS Web Services
   Proposal Editor: Roberto Ruggeri, Emmanuel Cordonnier
   Date: 11/27/2006
   Version: 0.10
   Domain: ITI XDS

2. Summary
Web Services are becoming the de-facto standard for intra- and cross-enterprise integration and
being supported by an increasing number of platform and vendors, both in commercial and open-
source implementations. Although some more advanced specifications are still evolving and
subject to change and therefore not suitable for inclusion in an IHE profile, most of the
foundation specifications are solid and adopted by open standard bodies:
      SOAP 1.2 [SOAP12]
      WSDL 1.1 [WSDL11]
      XOP [XOP10]
      MTOM [MTOM]
The proposal would allow for a Web Services binding to the Repository using solid and stable
specification, but in a way that would preserve customers’ and vendors’ investment by naturally
including more sophisticated and advanced specifications once these become standard, stable and
solid implementations emerge in the marketplace.
IHE XDS today employs different versions of the same standard (ebXML Registry 2.0 and 3.0)
and obsolete specifications (SOAP with Attachments or SwA). The proposal outlines the
      Update the XDS Web Services implementation to use SOAP 1.2
      Update the XDS transactions to use ebXML Registry 3.0
      Update the Provider and Register Document Set “on-line” mode transaction to use
       MTOM in alternative to SwA
      Provide an additional SOAP binding for the XDS Retrieve Document transaction that also
       uses MTOM
SOAP12, WSDL11form today the basis for all the Web Services specification and are widely
implemented in the industry. MTOM/XOP adds an efficient way to transport attachments
reducing the requirements in terms of bandwidth and resources required to encode/decode the
Using MTOM over SwA will become much more important as security profiles are layered upon
the existing ones. SwA forces you to transmit documents outside of the SOAP Envelope as a
multipart MIME package, in cases where security is important and the SOAP messages needs to
be signed or encrypted, there is no way using SwA to preserve the association between the SOAP
message and the attachment that are submitted as part of the same message. MTOM on the other
      hand respects the XML Infoset and all the attachments that are included in the SOAP message are
      also transmitted within the message itself, respecting the security measures applied to the
      document. For more information check the following references:
             Web Services, Opaque Data, and the Attachments Problem (June 2004):
             Attachments in SOAP Messages (Dec 2005):
             XML SOAP and Binary Data (February 2003):

      3. Use Cases
      The use case has no change vs. the initial one for Provide and Register Document Set. It is only a
      technical evolution. To be more precise:
             MTOM based Provide and Register Document Set “on-line” mode fits exactly the use
              case of the one which is SwA based, which will be deprecated in the future
             Provide and Register Document Set “off-line” mode will be maintained as it (for the time
              being), because its correspond to another use case (in particular in the context of XDR
              where the Document Recipient can be unable to be reached by an HTTP based
             MTOM based Retrieve Document will fit well the situation where the Document
              Consumer wants to import the document, while the existing HTTP Get mapped Retrieve
              Document, to be maintained as it (for the time being), can be easier to implement when
              the Document Consumer wants only to display the document to the user

      4. Standards & Systems
      The actors impacted are XDS Document Source, XDS Document Repository, XDR Document
      Source, XDR Document Recipient.
      These are the relevant standards that would be referenced from the amended XDS profile:
             SOAP 1.2 [SOAP12] – “SOAP Version 1.2 is a lightweight protocol intended for
              exchanging structured information in a decentralized, distributed environment. “Part 1:
              Messaging Framework” defines, using XML technologies, an extensible messaging
              framework containing a message construct that can be exchanged over a variety of
              underlying protocols”5. SOAP is maintained by the World Wide Web Consortium.
             WSDL 1.1 [WSDL11] – “WSDL is an XML format for describing network services as a
              set of endpoints operating on messages containing either document-oriented or procedure-
              oriented information. The operations and messages are described abstractly, and then
              bound to a concrete network protocol and message format to define an endpoint. Related
              concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to
              allow description of endpoints and their messages regardless of what message formats or
              network protocols are used to communicate”6. WSDL is maintained by the World Wide
              Web Consortium.

             XOP [XOP10] – The XML-binary Optimized Packaging convention, describes “… a
              means of more efficiently serializing XML Infosets that have certain types of content.”7
              XOP is maintained by the World Wide Web Consortium.
             MTOM [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.”8 MTOM is built on top of SOAP 1.2
              and XOP, and is maintained by the World Wide Web Consortium.

      5. Technical Approach
      In order to prevent compatibility issues with the existing XDS implementations and to preserve
      current investment, an appropriate approach has to be defined.
      One way could be to introduce two new actors that implement the new transactions based on the
      above mentioned standards: the “Document Repository Bridge” and “Document Registry Bridge”
      (temporary names).
      The new “Document Repository Bridge” actor would implement the following transactions:
             Provide and Register Document Set “on-line” mode: using [SOAP12], [WSDL11],
             Register Document Set: using [SOAP12], [WSDL11]
             Retrieve Document: using [SOAP12], [WSDL11], [MTOM]
      The new “Document Registry Bridge” actor would implement the following transactions:
             Register Document Set: using [SOAP12], [WSDL11]
             Patient Identity Feed
             Registry Stored Query: using [SOAP12], [WSDL11]
      This way, Document Consumers and Document Sources have the option of choosing whatever
      interface they prefer. Existing clients can keep working with the previous XDS interfaces, while
      new clients can start using the new Web Services interfaces. The new actors, initially optional,
      could be eventually become required once additional profiles start building upon them.
      Another approach could be to introduce new optional modes for the existing transactions:
             Provide and Register Document Set “MTOM on-line” mode: using [SOAP12],
              [WSDL11], [MTOM]
             Register Document Set “3.0 mode”: using [SOAP12], [WSDL11]
             Retrieve Document “MTOM mode”: using [SOAP12], [WSDL11], [MTOM]

      New actors
      If the first approach is retained, “Document Repository Bridge” and “Document Registry Bridge”
      (temporary names)
      Existing actors
      Existing actors would not be affected, but the option of transactions if the second approach is

New transactions (standards used)
The new transactions (or the new modes on existing tracsactions) are semantically equivalent to
the existing ones, making it easier for the two new actors to interface with legacy consumers,
sources, registry and repositories. The new transactions differ from the existing ones because of
different standards used for encapsulating messages:
       Provide and Register Document Set: using [SOAP12], [WSDL11], [MTOM]
       Register Document Set: using [SOAP12], [WSDL11]
       Retrieve Document: using [SOAP12], [WSDL11], [MTOM]
       Registry Stored Query: using [SOAP12], [WSDL11]
Additionally for each one of the transactions an appropriate WSDL and policy file will be
provided in order to simplify the development of clients and proxies for the different actors.
Impact on existing integration profiles
No impact on the existing profiles and implementations as the new actors or new modes for
transactions will be optional in year 1 of the profile.
New integration profiles needed
No new integration profiles needed.
Breakdown of tasks that need to be accomplished
Here is a basic breakdown of the tasks:
       Design a SOAP binding for the Document Retrieve transaction
       Design WSDL files for the new actors that are semantically equivalent to the new
       Perform some basic validation and platform testing to assure technical correctness

6. Risks
Here are some of the possible risks identified:
       Lack of a process to allow for phased introduction of new standards into existing profiles
        could slow down the process. Ideally we could use this proposal to set a precedent and
        establish such process.
       Willingness from vendors to support the new actors and migrate existing implementations

7. Open Issues
   1. Should “Patient Identity Feed” be updated to Web Services too?
   2. Should “Secure Node” be updated to Web Services too?
   3. Should “Audit” be updated to Web Services too?
   4. How to define the MTOM binding for Retrieve Document which can be applied in the
      future to existing transactions (RID, XDS-I/WADO) and to new transactions (Retrieve
      Document Set)?
   5. How to manage the optionality of the different transport modes?

8. Effort Estimates
<The technical committee will use this area to record details of the effort estimation.>
9. References
[SOAP12] SOAP 1.2 Recommendation
[WSDL11] WSDL 1.1 Note
[XOP10] XML-binary Optimized Packaging
[MTOM] SOAP Message Transmission Optimization Mechanism

Shared By: