XDS.b Implementation

From IHE Wiki
Jump to navigation Jump to search

This page is a placeholder for future XDS.b Implementation Notes
Rruggeri 15:49, 26 July 2007 (CDT)
If the Profile Implementation Template is useful feel free to use it. If not, feel free to improve it. :-))
kevino 12:26, 27 July 2007 (PDT)

Generating Proxies using SOAP Tools

There are some general guidelines to follow when generating proxies, especially for complex WSDL/schemas such as the ones included in XDS.b, that will make your life much, much easier.

The first one is use generic, non-strongly typed WSDL for development purposes, that is for the purpose of generating the proxy.
Strongly typed WSDL will force the infrastructure to go through all the xml type definitions and generate classes for them. The mapping between XSD and object oriented constructs is not always straightforward and you might run into some problems even with valid instances.
This approach works well for your average weather web service, but not for more complex scenarios like the ones we have to deal with.

Furthermore, generating classes through proxies will force turning the XML in the SOAP message to objects where most likely you will have to deal with the XML anyways. This step can also be somewhat resource intensive as it forces a validation of the whole message which is usually avoided in production environments with high transaction volume.

Generic WSDL for development replace the types of the input/output SOAP messages with generic xs:any types. By generating the proxy from that modified WSDL you get a method signature that basically only deals with raw XML documents for input and output. Yes, you lose "automatic" XSD validation, but you can always put that step back in if you want and make it optional when you go to production.

Axis2 Proxy Generation on Windows

The Axis2 tool for WSDL to Java classes (WSDL2Java) exhibits the following problem when running on Windows, and using WSDLs referencing the HL7 V3 schema: 

Caused by: org.apache.axis2.schema.SchemaCompilationException: can not find the parent schema for the complex type {urn:hl7-org:v3}CS from the parent schema urn:hl7-org:v3

The reason for this seems to be the handling of file paths in Java on Windows: while URLs require forward slashes as path separators, system file paths use the Windows convention of back slashes. When one schema file references another schema file in a different directory, it uses relative paths with URL syntax, and this confuses Axis2.

One possible workaround on Windows is to use Cygwin, which provides a UNIX-like environment on Windows, including a BASH shell. This still requires a small change to the Axis2 distribution: replace the $AXIS2_HOME/bin/axis2.sh with the following: 

#!/bin/sh

#  Copyright 2001,2004-2006 The Apache Software Foundation
#
#  Licensed under the Apache License, Version 2.0 (the "License");
#  you may not use this file except in compliance with the License.
#  You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
#  Unless required by applicable law or agreed to in writing, software
#  distributed under the License is distributed on an "AS IS" BASIS,
#  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#  See the License for the specific language governing permissions and
#  limitations under the License.

# ----------------------------------------------------------------------------
#    Axis2 Script
#
# Pre-requisites
#   - setenv.sh must have been called.
#
#   AXIS2_HOME   Home of Axis2 installation. If not set I will  try
#                   to figure it out.
#
#   JAVA_HOME       Must point at your Java Development Kit installation.
#
# -----------------------------------------------------------------------------

# Get the context and from that find the location of setenv.sh
. `dirname $0`/setenv.sh

#add any user given classpath's
USER_COMMANDS=""
prearg=""
for arg in "$@"
do
   if [ "$arg" != -classpath ] && [ "$arg" != -cp ] && [ "$prearg" != -classpath ] && [ "$prearg" != -cp  ]
   then
      USER_COMMANDS="$USER_COMMANDS ""$arg"
   fi

   if [ "$prearg"=-classpath ] || [ "$prearg"=-cp  ]
   then
      AXIS2_CLASSPATH="$arg":"$AXIS2_CLASSPATH"
   fi
   prearg="$arg"
done 


"$JAVA_HOME/bin/java" -Xmx80m -classpath "$AXIS2_CLASSPATH" \
-Daxis2.xml="$AXIS2_HOME/conf/axis2.xml" -Daxis2.repo="$AXIS2_HOME/repository"  $USER_COMMANDS

Then you can run the proxy generator like this: 

/usr/local/axis2-1.3/bin/wsdl2java.sh --noMessageReceiver --noWSDL -uri <path-to-WSDL> -o <path-to-generated-code>

Interpreting Web Services Specifications for XDS.b and XCA

We have had great difficulty in interpreting Web Services specifications and determining what makes sense for use in XDS.b and XCA. To understand this topic it is important to understand the state of the art when we started XDS and where it is today.

When we started XDS (now known as XDS.a) we referenced OASIS ebXML Registry version 2.1. When this standard was written, Web Services were in their relative infancy and the rules were not yet well established. This standard referenced two forms of SOAP messages. The terminology used was roughly SOAP message and SOAP with Attachments message. The intent was that a SOAP message could not carry documents (attachments) but a SOAP with Attachments message could. Both of these formats are defined by W3C specifications and the registry standard used them in a consistent manner. IHE, through its XDS profile, did not interpret or change them. We did put a large effort into trying to explain and test them.

The ebXML Registry 2.1 specification described a non-symmetrical use of these messages. On what XDS calls Provide and Register, the registry standard called for the request message to be formatted as SOAP with Attachments and the response was a basic SOAP message. As we started XDS this seemed logical and we did not question it. The IHE/XDS community got familiar with this approach and it has become our gold standard. Unfortunately the Web Services community went in a different direction.

Things evolved withing the web services community. SOAP 1.1 was replaced by SOAP 1.2. Web Services Addressing became an accepted specification. SOAP with Attachments evolved into MTOM/XOP. Within the OASIS Registry committee, the 2.1 specification was replaced with the 3.0 specification. In IHE, we published XDS.b as a technology update to XDS and renamed XDS to XDS.a.

All this is well and good but we in IHE seriously underestimated the complexity of Web Services. It turns out that the Web Services community found that the W3C specifications were not adequate to gain interoperability. WS-I was born out of this need. The WS-I specifications profile and constrain the W3C specifications in much the way that many IHE specifications profile and constrain HL7 specifications. WS-I has its own interoperability testing event, similar to an IHE Connectathon.

Furthermore there are a few unwritten rules that the Web Services community seems to know but we cannot find written in any of their standards. The big unwritten rule is: the response message shall be in the same format as the request message. I would love to find this in a written standard but cannot. None the less, every toolkit I have heard of expects this. Axis2 and .NET both automatically respond in the same format as the request. It is difficult to get them to do otherwise. There are new specifications being developed that focus on Web Services Policy which include ways to specify in WSDL finer granularity expectations for the formatting of individual messages. ITI has reviewed these specifications and determined that they are not yet ready for our use.

What does this unwritten rule mean for XDS.b and XCA? Any transaction that sends documents uses MTOM/XOP. Its response message will be in MTOM/XOP as well. Any transaction that expects to receive documents back in a response must send the request in MTOM/XOP format so the response can be in MTOM/XOP. This is why we have written this unwritten rule into the updated XDS.b supplement. Interoperability seems to require it.

This seems like an awkward approach to a community of developers who have gotten used to writing their own WS stacks. Why did so many of use write our own WS stack? Because the original SOAP with Attachments specification was never fully accepted in the WS industry and was never fully supported with good implementations on many platforms. So we built our own WS stack and tuned it to include just the features that the XDS.a profile required.

So, what are the key formats? As we understand it today there are 4 formats of which 3 need to be supported for use in XDS.b and XCA. They are:

  • SIMPLE SOAP
  • SIMPLE SOAP with embedded content
  • MTOM/XOP with optimized content
  • MTOM/XOP with un-optimized content

The format we have chosen not to support is SIMPLE SOAP with embedded content. MTOM/XOP with embedded content is what most of use think of as MTOM/XOP because the expectation of that standard is that all content is optimized. It does, however, allow for non-optimized content to be used. .NET generates MTOM/XOP with non-optimized content when sending very small chunks of content (documents) and this is allowed by the MTOM standard. The next section explains these formats in detail.

In conclusion, if XDS.b and XCA are to achieve the interoperability what we need, the community will have to adapt to the more modern rules of Web Services. Many of us will not want to write code to handle all this variability. Honestly, healthcare as a community should not be specifying low level communications interfaces like Web Services. They have been defined by the larger computer industry and we should accept what they have standardized. For some implementers this means using an existing, well tested Web Services tool kit. Others will continue to build their own. Those that build their own accept the responsibility of conforming to the standards and norms of the Web Services industry. The tools developed within the IHE community will never be able to fully test the full range of options available to us from the Web Services industry. We do not have the resources. We will focus on testing the areas where most developers make mistakes. This provides the most leverage for our effort.

Example SOAP, MTOM, and MTOM/XOP Messages

There are two basic types of SOAP messages defined by W3C and profiled by [WS-I]: Simple SOAP messages and MTOM/XOP encoded messages. Given options within the MTOM specification this results in the following coding options:

  • SIMPLE SOAP
  • SIMPLE SOAP with embedded content
  • MTOM/XOP with optimized content
  • MTOM/XOP with un-optimized content

The XDS.b and XCA supplements accept 3 of the above 4 options. SIMPLE SOAP with embedded content is not acceptable.

This section offers examples of these formats. These examples are taken from the Public Registry implementation where possible. Note that the Content-Length header has been removed.

A SIMPLE SOAP message looks like this response to a Provide and Register-b transaction. The SOAP Envelope makes up the entire body of the message. There is no embedded document. 

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml; action="urn:ihe:iti:2007:RegisterDocumentSet-bResponse";charset=UTF-8
Transfer-Encoding: chunked
Date: Mon, 08 Sep 2008 11:09:15 GMT

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <soapenv:Header>
        <wsa:Action>urn:ihe:iti:2007:RegisterDocumentSet-bResponse</wsa:Action>
        <wsa:RelatesTo>urn:uuid:D9D54C50296A3C11D11220872153270</wsa:RelatesTo>
    </soapenv:Header>
    <soapenv:Body>
        <rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
            status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
    </soapenv:Body>
</soapenv:Envelope>

This is also a Simple SOAP message, also transmitted as the body of an HTTP message. It contains base64 encoded data in the photo element. This format is not used in XDS. 

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo>
    </m:data>
  </soap:Body>
</soap:Envelope>

MTOM/XOP (MTOM is an abstract format and XOP is the only existing encoding for that format) messages are always structured as MIME Multipart messages. Within this overall format there are two options for including documents in, for example, a Provide and Register-b transaction. When the sender composes the XOP package, a decision can be made whether to optimize some, all, or none of the documents.

The first step in optimization is to build the XOP optimized package (multipart). But, the optimization of each chunk of content (documents to us) is a separate decision. So the basic optimized package (without optimized content) looks like: 

Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<mymessage.xml@example.org>";
    startinfo="application/soap+xml; action=\"ProcessData\""
Content-Description: A SOAP message with no optimized content

--MIME_boundary
Content-Type: application/xop+xml;
    charset=UTF-8;
    type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary--

Structurally this is just the Simple SOAP message with an embedded document (unoptimized) wrapped in a multipart. Technically this is a valid MTOM/XOP package and therefore valid for use with Provide and Register-b transaction (and others).

What most think of first when we hear MTOM/XOP is the use of that format with optimized content. This means moving the content (document) out from being base64 encoded and stored as the value of an XML element and putting into a Part un-encoded (no base64). An example of an XOP package with optimized content is shown below. Notice that content of the <photo/> element has been removed and put into another Part of the Multipart. In its place is an <xop:Include/> element that 'points' to the content in the other Part. 

Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<mymessage.xml@example.org>";
    startinfo="application/soap+xml; action=\"ProcessData\""
Content-Description: A SOAP message with my pic and sig in it

--MIME_boundary
Content-Type: application/xop+xml;
    charset=UTF-8;
    type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo xmlmime:contentType='image/png'>
        <xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/me.png'/>
      </m:photo>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary--

Transition from MTOM to MTOM/XOP

[This section, written in the Fall of 2007, is not a correct interpretation of the MTOM/XOP standard. This section has been replaced by xxx]

The XDS.b supplement, as published, documents the use of the MTOM [standard]. Now that the testing season has started, we have found that this choice of standards is not appropriate. This section documents the reason for the change and the necessary updates to the XDS.b supplement. This material will be formatted as a formal Change Proposal to the XDS.b profile later this season. These change will be in effect for January 2008 North American Connectathon.

Choice of Standards

In many ways XDS.b is a technology update to the original XDS (now called XDS.a). The move from SOAP with Attachments to MTOM is part of this update. In selecting MTOM as the replacement we thought we were tracking the industry correctly. The real situation is slightly more complicated. There are two relevant standards here, [MTOM] and [XOP] ([XOP FAQ]). As originally published, XDS.b references MTOM without XOP. This update changes that to be MTOM with XOP. This change is being made for the following reasons:

  • In common/casual usage, from my own informal survey, the term MTOM is used to mean MTOM with XOP
  • It is pretty hard to find discussion of MTOM without XOP.
  • The following packages are known to support MTOM/XOP: Apache Axis2, .NET. My informal survey of web-available material indicates the same for JBOSS and Oracle.
  • Several sites document performance issues when using MTOM without XOP when used with large attachments. From and XDS point of view this means large documents. I believe this comes from using XML parsers that are not optimized for dealing with such large text nodes within the XML. More on this below where I discuss technology issues.
  • .NET ([documentation]) uses a strategy of using MTOM for small documents and MTOM/XOP for large documents.

Change Proposal

The following changes are proposed for the Provide and Register Document Set-b transaction:

  1. The Document Source actor may send either MTOM or MTOM/XOP formats.
  2. The Document Repository actor shall accept both MTOM and MTOM/XOP formats.

The following changes are proposed for the Retrieve Document Set transaction:

  1. The Document Repository actor may send either MTOM or MTOM/XOP formats.
  2. The Document Consumer actor shall accept both MTOM and MTOM/XOP formats.

Discussion of Standards

To understand this change one needs to understand parts of MTOM, XOP, and SOAP with Attachments standards.

Soap with Attachments (SwA) uses mime/multipart structure. The top level wrapper for this standard looks like: 

MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml
Content-Description: XDS.a example using SOAP with Attachments

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit

<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>

<!-- Metadata Goes Here -->
...
<ExtrinsicObject id="mydocument" />
...

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: text/xml
Content-ID: <mydocument>

document contents
--MIME_boundary--

This is how XDS.a works. The id attribute of each ExtrinsicObject element is available as a multipart Part. The id attribute corresponds with the Content-ID value (angle brackets required). If the document is base64 encoded then additional headers in the mydocument part header assert that.

MTOM takes a radically different approach. This is what is documented in the XDS.b profile as it stands now. The same example looks like: 

MIME-Version: 1.0
Content-Type: type=text/xml
Content-Description: XDS.b example using MTOM

<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>

<!-- Metadata Goes Here -->
...
<ExtrinsicObject id="mydocument" />
...
<Document id="mydocument">base64 encoded document contents</Document>
...

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

This encoding does not use a multipart. The base64 encoded bits of the document are transmitted as a text node which is a child of the <Document/> element.

MTOM/XOP looks a little like both of the above. 

MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml
Content-Description: MTOM/XOP example

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <claim061400a.xml@claiming-it.com>

<?xml version='1.0' ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>

<!-- Metadata Goes Here -->
...
<ExtrinsicObject id="mydocument" />
...
<Document id="mydocument">
    <Include href="cid:1.urn:uuid:BC47538ED684E0A2D41194546709563@apache.org" 
        xmlns="http://www.w3.org/2004/08/xop/include" />
</Document>
...

</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary
Content-Type: text/xml
Content-Transfer-Encoding: binary
Content-ID: <cid:1.urn:uuid:BC47538ED684E0A2D41194546709563@apache.org>

binary encoding of document contents
--MIME_boundary--

The id attribute of the ExtrinsicObject metadata element matches the id attribute of a Document element also in metadata. That Document element has a child element <Include> whose href attribute names the mime Part that contains the document contents. To the best of my understanding, here is were XOP offers a benefit. Instead of requiring base64 encoding, these attachment can be binary encoded. Much better for large documents.

Example Retrieve Document Set transaction

Below is an example request and response from a Retrieve Document Set transaction taken from a trace of the Public Registry. The original was chunk encoded (included header Transfer-Encoding: chunked). This encoding has been removed for readability. To make this a valid transaction either the chunked encoding would have to be redone or a Content-Length header would have to be added.

There are two examples here, the first returns MTOM, the second returns MTOM/XOP. The second example is included because several implementations of MTOM/XOP do not use the Content-Type header for passing an accurate mime type, instead passing the generic value application/octet-stream. This is allowed by the XOP standard. Because of this, one must rely on the XDS metadata mimeType attribute for the Provide and Register Document Set.b transaction and on the MimeType element in the Retrieve Document Set transaction. The second example only shows the response since the request could be the same.

Request 

POST /axis2/services/xdsrepositoryb HTTP/1.1
Content-Type: application/soap+xml; charset=UTF-8; action="urn:ihe:iti:2007:RetrieveDocumentSet"
User-Agent: Axis2
Host: localhost:9087

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <soapenv:Header>
        <wsa:To>http://localhost:9087/axis2/services/xdsrepositoryb</wsa:To>
        <wsa:MessageID>urn:uuid:D565D5833AE3D90AFD1198851327915</wsa:MessageID>
        <wsa:Action>urn:ihe:iti:2007:RetrieveDocumentSet</wsa:Action>
    </soapenv:Header>
    <soapenv:Body>
        <RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:ihe:iti:xds-b:2007 file:/Users/bill/ihe/Frameworks/ITI-4/XDS.b/schema/IHE/XDS.b_DocumentRepository.xsd">
            <DocumentRequest>
                <RepositoryUniqueId>1.19.6.24.109.42.1</RepositoryUniqueId>
                <DocumentUniqueId>129.6.58.91.13297</DocumentUniqueId>
            </DocumentRequest>
            <DocumentRequest>
                <RepositoryUniqueId>1.19.6.24.109.42.1</RepositoryUniqueId>
                <DocumentUniqueId>129.6.58.91.13298</DocumentUniqueId>
            </DocumentRequest>
        </RetrieveDocumentSetRequest>
    </soapenv:Body>
</soapenv:Envelope>

Response

The documents included in the response are MTOM encoded (see <xdsb:Document/> element). 

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml; action="urn:ihe:iti:2007:RetrieveDocumentSetResponse";charset=UTF-8
Date: Fri, 28 Dec 2007 14:15:28 GMT

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <soapenv:Header>
        <wsa:Action>urn:ihe:iti:2007:RetrieveDocumentSetResponse</wsa:Action>
        <wsa:RelatesTo>urn:uuid:D565D5833AE3D90AFD1198851327915</wsa:RelatesTo>
    </soapenv:Header>
    <soapenv:Body>
        <xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007">
            <rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
            <xdsb:DocumentResponse>
                <xdsb:Document>VGhpcyBpcyBteSBkb2N1bWVudC4KCkl0IGlzIGdyZWF0IQoK</xdsb:Document>
                <xdsb:RepositoryUniqueId>1.19.6.24.109.42.1</xdsb:RepositoryUniqueId>
                <xdsb:DocumentUniqueId>129.6.58.91.13297</xdsb:DocumentUniqueId>
                <xdsb:mimeType>text/plain</xdsb:mimeType>
            </xdsb:DocumentResponse>
            <xdsb:DocumentResponse>
                <xdsb:Document>VGhpcyBpcyBteSBzZWNvbmQgZG9jdW1lbnQuCgpJdCBpcyBncmVhdCEKCg==</xdsb:Document>
                <xdsb:RepositoryUniqueId>1.19.6.24.109.42.1</xdsb:RepositoryUniqueId>
                <xdsb:DocumentUniqueId>129.6.58.91.13298</xdsb:DocumentUniqueId>
                <xdsb:mimeType>text/plain</xdsb:mimeType>
            </xdsb:DocumentResponse>
        </xdsb:RetrieveDocumentSetResponse>
    </soapenv:Body>
</soapenv:Envelope>

Response in MTOM/XOP format showing the slack encoding of mimeType. Note the header in the second Part:

Content-Type: application/octet-stream
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_3BE45FAC62CF0568A81199380869988; type="application/xop+xml"; start="0.urn:uuid:3BE45FAC62CF0568A81199380869989@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:RetrieveDocumentSetResponse"
Date: Thu, 03 Jan 2008 17:21:04 GMT

--MIMEBoundaryurn_uuid_3BE45FAC62CF0568A81199380869988
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:3BE45FAC62CF0568A81199380869989@apache.org>

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <soapenv:Header>
        <wsa:Action>urn:ihe:iti:2007:RetrieveDocumentSetResponse</wsa:Action>
        <wsa:RelatesTo>urn:uuid:A920DC9E26409B53231199380832547</wsa:RelatesTo>
    </soapenv:Header>
    <soapenv:Body>
        <xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007">
            <rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
            <xdsb:DocumentResponse>
                <xdsb:Document>
                    <xop:Include href="cid:1.urn:uuid:3BE45FAC62CF0568A81199380869990@apache.org"
                        xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
                </xdsb:Document>
                <xdsb:RepositoryUniqueId>1.19.6.24.109.42.1</xdsb:RepositoryUniqueId>
                <xdsb:DocumentUniqueId>1.2.3.4.100000022002209036.1196211173506.1</xdsb:DocumentUniqueId>
                <xdsb:mimeType>text/xml</xdsb:mimeType>
            </xdsb:DocumentResponse>
        </xdsb:RetrieveDocumentSetResponse>
    </soapenv:Body>
</soapenv:Envelope>


--MIMEBoundaryurn_uuid_3BE45FAC62CF0568A81199380869988
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:3BE45FAC62CF0568A81199380869990@apache.org>

Detailed document removed for clarity 

--MIMEBoundaryurn_uuid_3BE45FAC62CF0568A81199380869988

Example Provide and Register Document Set-b transaction

Below is an example request and response from a Provide and Register Document Set-b transaction taken from a trace of the Public Registry. The original was chunk encoded (included header Transfer-Encoding: chunked). This encoding has been removed for readability. To make this a valid transaction either the chunked encoding would have to be redone or a Content-Length header would have to be added.

Request 

POST /axis2/services/repositoryBonedoc HTTP/1.1
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_806D8FD2D542EDCC2C1199332890718; type="application/xop+xml"; start="0.urn:uuid:806D8FD2D542EDCC2C1199332890719@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"
User-Agent: Axis2
Host: localhost:9085

--MIMEBoundaryurn_uuid_806D8FD2D542EDCC2C1199332890718
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:806D8FD2D542EDCC2C1199332890719@apache.org>

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <soapenv:Header>
        <wsa:To>http://localhost:9085/axis2/services/repositoryBonedoc</wsa:To>
        <wsa:MessageID>urn:uuid:806D8FD2D542EDCC2C1199332890651</wsa:MessageID>
        <wsa:Action>urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b</wsa:Action>
    </soapenv:Header>
    <soapenv:Body>
        <xdsb:ProvideAndRegisterDocumentSetRequest xmlns:xdsb="urn:ihe:iti:xds-b:2007">
            <lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
                <rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
                    <rim:ExtrinsicObject id="Document01" mimeType="text/plain"
                        objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">
                    </rim:ExtrinsicObject>
                    <rim:RegistryPackage id="SubmissionSet01"
                        objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:RegistryPackage">
                    </rim:RegistryPackage>
                    <rim:Association
                        associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember"
                        sourceObject="SubmissionSet01" targetObject="Document01" id="ID_12928619_2"
                        objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Association">
                        <rim:Slot name="SubmissionSetStatus">
                            <rim:ValueList>
                                <rim:Value>Original</rim:Value>
                            </rim:ValueList>
                        </rim:Slot>
                    </rim:Association>
                </rim:RegistryObjectList>
            </lcm:SubmitObjectsRequest>
            <xdsb:Document id="Document01">
                <xop:Include href="cid:1.urn:uuid:806D8FD2D542EDCC2C1199332890776@apache.org"
                    xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
            </xdsb:Document>
        </xdsb:ProvideAndRegisterDocumentSetRequest>
    </soapenv:Body>
</soapenv:Envelope>

--MIMEBoundaryurn_uuid_806D8FD2D542EDCC2C1199332890718
Content-Type: text/plain
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:806D8FD2D542EDCC2C1199332890776@apache.org>

This is my document.

It is great!


--MIMEBoundaryurn_uuid_806D8FD2D542EDCC2C1199332890718--


Response 

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse";charset=UTF-8
Date: Thu, 03 Jan 2008 04:01:37 GMT

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <soapenv:Header>
        <wsa:Action>urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse</wsa:Action>
        <wsa:RelatesTo>urn:uuid:806D8FD2D542EDCC2C1199332890651</wsa:RelatesTo>
    </soapenv:Header>
    <soapenv:Body>
        <rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
            status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
    </soapenv:Body>
</soapenv:Envelope>

Example Register Document Set-b transaction

Below is an example request and response from a Register Document Set-b transaction taken from a trace of the Public Registry. The original was chunk encoded (included header Transfer-Encoding: chunked). This encoding has been removed for readability. To make this a valid transaction either the chunked encoding would have to be redone or a Content-Length header would have to be added.

Request 

POST /axis2/services/registryBonedoc HTTP/1.1
Content-Type: application/soap+xml; charset=UTF-8; action="urn:ihe:iti:2007:RegisterDocumentSet-b"
User-Agent: Axis2
Host: localhost:9085


<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <soapenv:Header>
    <wsa:To>http://localhost:9085/axis2/services/registryBonedoc</wsa:To><wsa:MessageID>urn:uuid:1CF198BACD3697AB7D1203091097442</wsa:MessageID>
    <wsa:Action>urn:ihe:iti:2007:RegisterDocumentSet-b</wsa:Action>
  </soapenv:Header>
  <soapenv:Body>
    <lcm:SubmitObjectsRequest xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
      <rim:RegistryObjectList xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
        <rim:ExtrinsicObject id="Document01" mimeType="text/plain" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"/>
      </rim:RegistryObjectList>
    </lcm:SubmitObjectsRequest>
  </soapenv:Body>
</soapenv:Envelope>

Response 

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/soap+xml; action="urn:ihe:iti:2007:RegisterDocumentSet-bResponse";charset=UTF-8
Date: Fri, 15 Feb 2008 15:58:21 GMT

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <soapenv:Header>
    <wsa:Action>urn:ihe:iti:2007:RegisterDocumentSet-bResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:1CF198BACD3697AB7D1203091097442</wsa:RelatesTo>
  </soapenv:Header>
  <soapenv:Body>
    <rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success" />
  </soapenv:Body>
</soapenv:Envelope>

See Also

Cross Enterprise Document Sharing

Cross-Enterprise Document Sharing Implementation

XDS Stored Query Implementation

Metadata Issues

RegistryObjectList within RegistryPackage

The ebRIM 3.0 Schema allows the nesting of a RegistryObjectList within a RegistryPackage but XDS.b does not and the XDS tools do not recognize this nesting. For now XDS.b accepts XDS.a metadata content but with the ebRIM 3.0 coding requirements (different namespace, extra attributes, sub-element ordering etc.)

Retrieved from "http://wiki.ihe.net/index.php?title=XDS.b_Implementation&oldid=23364"