Difference between revisions of "XDS.b Implementation"
(81 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
− | + | If the [[Profile Implementation Template]] is useful feel free to use it. If not, feel free to improve it. :-))<br /> | |
− | [[User: | + | [[User:kevino|kevino]] 12:26, 27 July 2007 (PDT)<br /> |
+ | |||
+ | == Annotated Transaction Examples == | ||
+ | |||
+ | The following are fully annotated example transactions. | ||
+ | |||
+ | [[Annotated ProvideAndRegister.b Transaction|Provide and Register.b]] | ||
+ | <br /> | ||
+ | [[Annotated StoredQuery Transaction|Stored Query]] | ||
+ | <br /> | ||
+ | [[Annotated Retrieve Document Set Transaction|Retrieve Document Set]] | ||
+ | <br /> | ||
+ | [[Document Replacement in a Provide and Register|XDS Replace]] | ||
+ | <br /> | ||
+ | [[#NwHIN_SAML_Headers|NwHIN SAML Headers]] | ||
+ | |||
+ | == More on MTOM vs MTOM/XOP == | ||
+ | |||
+ | One note on MTOM vs MTOM/XOP. After describing them as separate things last year (our mistake), they are really only one concept. MTOM is a general structure for attachment encoding. As a general structure, it requires a concrete encoding scheme to be used with it. XOP is currently the only concrete encoding scheme defined for use with MTOM. So, for now, MTOM and MTOM/XOP mean the same thing. Later there could be an MTOM/XYZ which would be different. | ||
+ | |||
+ | The real distinctions being made this year are: | ||
+ | |||
+ | 1) MTOM/XOP vs SIMPLE SOAP | ||
+ | |||
+ | The key and most observable difference in these formats is that MTOM/XOP is based on MIME Multipart encoding and SIMPLE SOAP has the XML content as the message body. | ||
+ | |||
+ | It is common industry practice, although not distinguished well in standards, that the request and response should be the same format. The thinking behind this is "if the sender can generate xyz format then he can accept it too". This concept is not well documented in standards and we had to discuss it with folks on the W3C committees to understand it fully. Is it truly illegal to respond to an MTOM message with SIMPLE SOAP? No, but, to do so you need to know that the client can accept this format in this instance. How would you know this? Because of a private agreement. So for purposes of interoperability, we established in the profile the hard rule that request format shall be same as response format. This plays out in two transactions, Provide and Register.b and Retrieve Document Set forcing the Provide and Register Response.b to be MTOM/XOP and the Retrieve Document Set Response to also be MTOM/XOP. | ||
+ | |||
+ | |||
+ | 2) Optimized vs Un-optimized MTOM/XOP | ||
+ | |||
+ | The most basic document coding in SOAP is to insert the document contents as the value of an element coded in Base64. The Base64 encoding in necessary to ensure the document contents does not interfere with the XML parsing. This can be the simplest thing to do if the document is really small but with a large document, the document contents must be processed through the XML parser which is time consuming and may expose size related implementation issues in the XML parser. Also the encode/decode time of document in base64 is time/space consuming. Therefore, it is generally a good idea to push the document contents out of the XML document and place it in its own part of a MIME Multipart. Then it is not part of the XML stream so the XML parsing is easier/faster and as its own part, binary encoding can be done. Binary coding means that it is not base64 coded. This pushing of the document contents into a multipart part, is called optimization. | ||
+ | |||
+ | This plays out in the MTOM/XOP transactions as: | ||
+ | * Start with a MTOM/XOP wrapper | ||
+ | * Metadata goes in the root part which is identified by the start parameter of the content-type header | ||
+ | * Documents are included by the Document element (as defined by profile) | ||
+ | * If the un-optimized format is used then the document contents are included as base64 encoded value of the Document element. | ||
+ | * If optimized format is used then the document contents are placed into a separate part. The content-id of the part is then referenced by the Document element. The encoding of this part is not constrained by profile. Binary encoding can be used. | ||
== Generating Proxies using SOAP Tools == | == 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.<br /> | + | 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.<br /><br /> |
The first one is use generic, non-strongly typed WSDL for development purposes, that is for the purpose of generating the proxy.<br /> | The first one is use generic, non-strongly typed WSDL for development purposes, that is for the purpose of generating the proxy.<br /> | ||
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.<br /> | 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.<br /> | ||
Line 11: | Line 49: | ||
<br /> | <br /> | ||
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.<br /> | 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.<br /> | ||
+ | === Axis2 Proxy Generation on Windows === | ||
+ | The [http://ws.apache.org/axis2/ Axis2] tool for WSDL to Java classes (WSDL2Java) exhibits the following problem when running on Windows, and using WSDLs referencing the HL7 V3 schema: | ||
+ | <pre> | ||
+ | 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 | ||
+ | </pre> | ||
+ | |||
+ | 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 [http://cygwin.com/ 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: | ||
+ | <pre> | ||
+ | #!/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 | ||
+ | </pre> | ||
+ | |||
+ | Then you can run the proxy generator like this: | ||
+ | <pre> | ||
+ | /usr/local/axis2-1.3/bin/wsdl2java.sh --noMessageReceiver --noWSDL -uri <path-to-WSDL> -o <path-to-generated-code> | ||
+ | </pre> | ||
+ | |||
+ | == Interpreting Web Services Specifications for XDS.b and XCA == | ||
+ | |||
+ | '''[This section, written in the Fall of 2007, outlines the work necessary for writing the XDS.b and XCA profiles. These profiles now fully profile the usage of Web Services.]''' | ||
+ | |||
+ | 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 within 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 == | ||
+ | |||
+ | Updated 30 July 2013 - updated examples to show mustUnderstand attribute - bill | ||
+ | |||
+ | There are two basic types of SOAP messages defined by W3C and profiled by [[http://www.ws-i.org/Profiles/BasicProfile-2_0(WGD).html 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 profiles accept 3 of the above 4 options. SIMPLE SOAP with embedded content is not acceptable. | ||
+ | |||
+ | This section offers examples of these forms. These examples are taken from the Public Registry implementation where possible. Note that the Content-Length header has been removed. Also, the metadata is truncated since it is not the focus of this discussion. | ||
+ | |||
+ | A SIMPLE SOAP message looks like this response to a Register-b transaction. The SOAP Envelope makes up the entire body of the message. There is no embedded document. | ||
+ | |||
+ | <pre> | ||
+ | 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 soapenv:mustUnderstand="true">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> | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | The following is also technically a SIMPLE SOAP message since it is a simple (not multi-part) HTTP format. It contains base64 encoded data in the Document element. This form is not used in XDS. Embedding large base64 coded documents into the XML is a large and unreasonable load on XML parsers. | ||
+ | <pre> | ||
+ | POST /axis2/services/xdsrepositoryb HTTP/1.1 | ||
+ | Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348; type="application/xop+xml"; start="0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" | ||
+ | User-Agent: Axis2 | ||
+ | Host: localhost:5000 | ||
+ | Transfer-Encoding: chunked | ||
+ | |||
+ | <?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:5000/axis2/services/xdsrepositoryb</wsa:To> | ||
+ | <wsa:MessageID>urn:uuid:AFBE87CB65FD88AC4B1220879854302</wsa:MessageID> | ||
+ | <wsa:Action soapenv:mustUnderstand="true">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"/> | ||
+ | </rim:RegistryObjectList> | ||
+ | </lcm:SubmitObjectsRequest> | ||
+ | <xdsb:Document id="Document01">base64 content goes here</xdsb:Document> | ||
+ | </xdsb:ProvideAndRegisterDocumentSetRequest> | ||
+ | </soapenv:Body> | ||
+ | </soapenv:Envelope> | ||
+ | </pre> | ||
+ | |||
+ | MTOM/XOP (MTOM is an abstract format and XOP is the only existing encoding for that abstract format) messages are always structured as MIME Multipart messages. Within this overall form there are two options for including documents, for example, in 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: | ||
+ | |||
+ | <pre> | ||
+ | POST /axis2/services/xdsrepositoryb HTTP/1.1 | ||
+ | Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348; type="application/xop+xml"; start="0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" | ||
+ | User-Agent: Axis2 | ||
+ | Host: localhost:5000 | ||
+ | Transfer-Encoding: chunked | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348 | ||
+ | Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" | ||
+ | Content-Transfer-Encoding: binary | ||
+ | Content-ID: <0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@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:5000/axis2/services/xdsrepositoryb</wsa:To> | ||
+ | <wsa:MessageID soapenv:mustUnderstand="true">urn:uuid:AFBE87CB65FD88AC4B1220879854302</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"/> | ||
+ | </rim:RegistryObjectList> | ||
+ | </lcm:SubmitObjectsRequest> | ||
+ | <xdsb:Document id="Document01">base64 content goes here</xdsb:Document> | ||
+ | </xdsb:ProvideAndRegisterDocumentSetRequest> | ||
+ | </soapenv:Body> | ||
+ | </soapenv:Envelope> | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348-- | ||
+ | </pre> | ||
+ | |||
+ | Note the base64 encoded document contents inside the <Document/> element. 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). We understand that .NET generates this form for the inclusion of very small documents. | ||
+ | |||
+ | What most think of first when we hear MTOM/XOP is the use of that form 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 <Document/> element has been removed and put into its own Part of the Multipart. In its place is an <xop:Include/> element that 'points' to the content in the other Part. | ||
+ | |||
+ | <pre> | ||
+ | POST /axis2/services/xdsrepositoryb HTTP/1.1 | ||
+ | Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348; type="application/xop+xml"; start="0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" | ||
+ | User-Agent: Axis2 | ||
+ | Host: localhost:5000 | ||
+ | Transfer-Encoding: chunked | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348 | ||
+ | Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" | ||
+ | Content-Transfer-Encoding: binary | ||
+ | Content-ID: <0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@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:5000/axis2/services/xdsrepositoryb</wsa:To> | ||
+ | <wsa:MessageID>urn:uuid:AFBE87CB65FD88AC4B1220879854302</wsa:MessageID> | ||
+ | <wsa:Action soapenv:mustUnderstand="true">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"/> | ||
+ | </rim:RegistryObjectList> | ||
+ | </lcm:SubmitObjectsRequest> | ||
+ | <xdsb:Document id="Document01"> | ||
+ | <xop:Include href="cid:1.urn:uuid:AFBE87CB65FD88AC4B1220879854390@apache.org" | ||
+ | xmlns:xop="http://www.w3.org/2004/08/xop/include"/> | ||
+ | </xdsb:Document> | ||
+ | </xdsb:ProvideAndRegisterDocumentSetRequest> | ||
+ | </soapenv:Body> | ||
+ | </soapenv:Envelope> | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348 | ||
+ | Content-Type: text/plain | ||
+ | Content-Transfer-Encoding: binary | ||
+ | Content-ID: <1.urn:uuid:AFBE87CB65FD88AC4B1220879854390@apache.org> | ||
+ | |||
+ | This is my document. | ||
+ | |||
+ | It is great! | ||
+ | |||
+ | |||
+ | --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348-- | ||
+ | </pre> | ||
+ | |||
+ | == Example Retrieve Document Set transaction == | ||
+ | |||
+ | Updated 30 July 2013 - added mustUnderstand attribute - bill | ||
+ | |||
+ | Below is an example request and response from a Retrieve Document Set transaction taken from a trace of the [http://ihexds.nist.gov 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. | ||
+ | |||
+ | Note that the request is carried MTOM/XOP package even though it does not need it. We have come to understand that the expected behavior of Web Service interactions is to have the request and response in the same format. Since the response must carry documents it must use MTOM/XOP. Without this rule the request could use SIMPLE SOAP but since the requirement of consistency between request and response, the request must also be in MTOM/XOP format. | ||
+ | |||
+ | |||
+ | '''Request''' | ||
+ | |||
+ | <pre> | ||
+ | POST /tf6/services/xdsrepositoryb HTTP/1.1 | ||
+ | Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_DCD262C64C22DB97351256303951323; type="application/xop+xml"; start="<0.urn:uuid:DCD262C64C22DB97351256303951324@apache.org>"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:RetrieveDocumentSet" | ||
+ | User-Agent: Axis2 | ||
+ | Host: localhost:5000 | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_DCD262C64C22DB97351256303951323 | ||
+ | Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" | ||
+ | Content-Transfer-Encoding: binary | ||
+ | Content-ID: <0.urn:uuid:DCD262C64C22DB97351256303951324@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 soapenv:mustUnderstand="true">http://localhost:5000/tf6/services/xdsrepositoryb</wsa:To> | ||
+ | <wsa:MessageID>urn:uuid:DCD262C64C22DB97351256303951276</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"> | ||
+ | <DocumentRequest> | ||
+ | <RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId> | ||
+ | <DocumentUniqueId>2009.9.1.1573</DocumentUniqueId> | ||
+ | </DocumentRequest> | ||
+ | </RetrieveDocumentSetRequest> | ||
+ | </soapenv:Body> | ||
+ | </soapenv:Envelope> | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_DCD262C64C22DB97351256303951323-- | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | '''Response''' | ||
+ | |||
+ | The documents included in the response are MTOM encoded (see <xdsb:Document/> element). | ||
+ | |||
+ | <pre> | ||
+ | HTTP/1.1 200 OK | ||
+ | Server: Apache-Coyote/1.1 | ||
+ | Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_F862C3E04D9E35266C1256303956115; type="application/xop+xml"; start="0.urn:uuid:F862C3E04D9E35266C1256303956116@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:RetrieveDocumentSetResponse" | ||
+ | Date: Fri, 23 Oct 2009 13:19:11 GMT | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_F862C3E04D9E35266C1256303956115 | ||
+ | Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" | ||
+ | Content-Transfer-Encoding: binary | ||
+ | Content-ID: <0.urn:uuid:F862C3E04D9E35266C1256303956116@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 soapenv:mustUnderstand="true">urn:uuid:DCD262C64C22DB97351256303951276</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:RepositoryUniqueId>1.19.6.24.109.42.1.5</xdsb:RepositoryUniqueId> | ||
+ | <xdsb:DocumentUniqueId>2009.9.1.1573</xdsb:DocumentUniqueId> | ||
+ | <xdsb:mimeType>application/pdf</xdsb:mimeType> | ||
+ | <xdsb:Document> | ||
+ | <xop:Include href="cid:1.urn:uuid:F862C3E04D9E35266C1256303956117@apache.org" | ||
+ | xmlns:xop="http://www.w3.org/2004/08/xop/include"/> | ||
+ | </xdsb:Document> | ||
+ | </xdsb:DocumentResponse> | ||
+ | </xdsb:RetrieveDocumentSetResponse> | ||
+ | </soapenv:Body> | ||
+ | </soapenv:Envelope> | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_F862C3E04D9E35266C1256303956115 | ||
+ | Content-Type: application/octet-stream | ||
+ | Content-Transfer-Encoding: binary | ||
+ | Content-ID: <1.urn:uuid:F862C3E04D9E35266C1256303956117@apache.org> | ||
+ | |||
+ | This is the content of the document. | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_F862C3E04D9E35266C1256303956115-- | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | == Example Provide and Register Document Set-b transaction == | ||
+ | |||
+ | Updated 30 July 2013 - added attribute mustUnderstand - bill | ||
+ | |||
+ | Below is an example request and response from a Provide and Register Document Set-b transaction taken from a trace of the [http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page 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. | ||
+ | |||
+ | Note: this is not a complete submission, the metadata attributes of the Submission Set (RegistryPackage) and Document Entry (ExtrinsicObject) have been removed for clarity. An example with full metadata is found | ||
+ | [[#http://wiki.ihe.net/index.php?title=XDS.b_Implementation#Example_Provide_and_Register_Document_Set-b_transaction_.28with_full_metadata.29|here]] | ||
+ | |||
+ | Request | ||
+ | |||
+ | <pre> | ||
+ | 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 soapenv:mustUnderstand="true">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-- | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | |||
+ | Response | ||
+ | |||
+ | Note that this message does not NEED MTOM/XOP encoding (no attachments present). But, since the request and response must be in the same format (SIMPLE SOAP or MTOM) this response must be in MTOM encoding. | ||
+ | |||
+ | <pre> | ||
+ | HTTP/1.1 200 OK | ||
+ | Server: Apache-Coyote/1.1 | ||
+ | Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_7BFFF2BD24C642EA531247750913327; type="application/xop+xml"; | ||
+ | start="<0.urn:uuid:7BFFF2BD24C642EA531247750913328@apache.org>"; | ||
+ | start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse" | ||
+ | Date: Thu, 16 Jul 2009 13:28:32 GMT | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_7BFFF2BD24C642EA531247750913327 | ||
+ | Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" | ||
+ | Content-Transfer-Encoding: binary | ||
+ | Content-ID: <0.urn:uuid:7BFFF2BD24C642EA531247750913328@apache.org> | ||
+ | |||
+ | <?xml version='1.0' encoding='UTF-8'?> | ||
+ | <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> | ||
+ | <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"> | ||
+ | <wsa:Action soapenv:mustUnderstand="true">urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse</wsa:Action> | ||
+ | <wsa:RelatesTo>urn:uuid:AD33D8190CB655E8751247750894152</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> | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_7BFFF2BD24C642EA531247750913327-- | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | == Example Register Document Set-b transaction == | ||
+ | |||
+ | Updated 30 July 2013 - added mustUnderstand attribute - bill | ||
+ | |||
+ | Below is an example request and response from a Register Document Set-b transaction taken from a trace of the [http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page 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 | ||
+ | |||
+ | <pre> | ||
+ | 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 soapenv:mustUnderstand="true">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> | ||
+ | </pre> | ||
+ | |||
+ | Response | ||
+ | |||
+ | <pre> | ||
+ | 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 soapenv:mustUnderstand="true">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> | ||
+ | </pre> | ||
+ | |||
+ | == Example Provide and Register Document Set-b transaction (with full metadata) == | ||
+ | |||
+ | Updated 30 July 2013 - added mustUnderstand attribute - bill | ||
+ | |||
+ | Below is an example request and response from a Provide and Register Document Set-b transaction taken from a trace of the [http://ihexds.nist.gov 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. | ||
+ | |||
+ | This example includes full metadata for the submission of a single Document. | ||
+ | |||
+ | Request | ||
+ | |||
+ | <pre> | ||
+ | POST /tf6/services/xdsrepositoryb HTTP/1.1 | ||
+ | Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_566EAD10FEBB55C5A61257193478449; type="application/xop+xml"; start="<0.urn:uuid:566EAD10FEBB55C5A61257193478450@apache.org>"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" | ||
+ | User-Agent: Axis2 | ||
+ | Host: localhost:5000 | ||
+ | |||
+ | --MIMEBoundaryurn_uuid_566EAD10FEBB55C5A61257193478449 | ||
+ | Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" | ||
+ | Content-Transfer-Encoding: binary | ||
+ | Content-ID: <0.urn:uuid:566EAD10FEBB55C5A61257193478450@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:5000/tf6/services/xdsrepositoryb</wsa:To> | ||
+ | <wsa:MessageID soapenv:mustUnderstand="true">urn:uuid:566EAD10FEBB55C5A61257193478400</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:Slot name="creationTime"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>20051224</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="languageCode"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>en-us</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="serviceStartTime"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>200412230800</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="serviceStopTime"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>200412230801</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="sourcePatientId"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>89765a87b^^^&3.4.5&ISO</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="sourcePatientInfo"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>PID-3|pid1^^^&1.2.3&ISO</rim:Value> | ||
+ | <rim:Value>PID-5|Doe^John^^^</rim:Value> | ||
+ | <rim:Value>PID-7|19560527</rim:Value> | ||
+ | <rim:Value>PID-8|M</rim:Value> | ||
+ | <rim:Value>PID-11|100 Main St^^Metropolis^Il^44130^USA</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="Physical"/> | ||
+ | </rim:Name> | ||
+ | <rim:Description/> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" | ||
+ | classifiedObject="Document01" nodeRepresentation="" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_1"> | ||
+ | <rim:Slot name="authorPerson"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>^Smitty^Gerald^^^</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="authorInstitution"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Cleveland Clinic</rim:Value> | ||
+ | <rim:Value>Parma Community</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="authorRole"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Attending</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="authorSpecialty"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Orthopedic</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | </rim:Classification> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" | ||
+ | classifiedObject="Document01" nodeRepresentation="" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_2"> | ||
+ | <rim:Slot name="authorPerson"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>^Dopplemeyer^Sherry^^^</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="authorInstitution"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Cleveland Clinic</rim:Value> | ||
+ | <rim:Value>Berea Community</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="authorRole"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Primary Surgon</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="authorSpecialty"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Orthopedic</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | </rim:Classification> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" | ||
+ | classifiedObject="Document01" nodeRepresentation="History and Physical" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_3"> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Connect-a-thon classCodes</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="History and Physical"/> | ||
+ | </rim:Name> | ||
+ | </rim:Classification> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" | ||
+ | classifiedObject="Document01" | ||
+ | nodeRepresentation="1.3.6.1.4.1.21367.2006.7.101" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_4"> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Connect-a-thon confidentialityCodes</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="Clinical-Staff"/> | ||
+ | </rim:Name> | ||
+ | </rim:Classification> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" | ||
+ | classifiedObject="Document01" nodeRepresentation="CDAR2/IHE 1.0" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_5"> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Connect-a-thon formatCodes</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="CDAR2/IHE 1.0"/> | ||
+ | </rim:Name> | ||
+ | </rim:Classification> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" | ||
+ | classifiedObject="Document01" nodeRepresentation="Outpatient" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_6"> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Connect-a-thon | ||
+ | healthcareFacilityTypeCodes</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="Outpatient"/> | ||
+ | </rim:Name> | ||
+ | </rim:Classification> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" | ||
+ | classifiedObject="Document01" nodeRepresentation="General Medicine" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_7"> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Connect-a-thon practiceSettingCodes</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="General Medicine"/> | ||
+ | </rim:Name> | ||
+ | </rim:Classification> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" | ||
+ | classifiedObject="Document01" nodeRepresentation="34108-1" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_8"> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>LOINC</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="Outpatient Evaluation And Management"/> | ||
+ | </rim:Name> | ||
+ | </rim:Classification> | ||
+ | <rim:ExternalIdentifier | ||
+ | identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" | ||
+ | value="76cc765a442f410^^^&1.3.6.1.4.1.21367.2005.3.7&ISO" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" | ||
+ | id="id_9" registryObject="Document01"> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="XDSDocumentEntry.patientId"/> | ||
+ | </rim:Name> | ||
+ | </rim:ExternalIdentifier> | ||
+ | <rim:ExternalIdentifier | ||
+ | identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" | ||
+ | value="1.2009.9.1.2455" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" | ||
+ | id="id_10" registryObject="Document01"> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="XDSDocumentEntry.uniqueId"/> | ||
+ | </rim:Name> | ||
+ | </rim:ExternalIdentifier> | ||
+ | </rim:ExtrinsicObject> | ||
+ | <rim:RegistryPackage id="SubmissionSet01" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:RegistryPackage"> | ||
+ | <rim:Slot name="submissionTime"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>20041225235050</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="Physical"/> | ||
+ | </rim:Name> | ||
+ | <rim:Description> | ||
+ | <rim:LocalizedString value="Annual physical"/> | ||
+ | </rim:Description> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d" | ||
+ | classifiedObject="SubmissionSet01" nodeRepresentation="" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_11"> | ||
+ | <rim:Slot name="authorPerson"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>^Dopplemeyer^Sherry^^^</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="authorInstitution"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Cleveland Clinic</rim:Value> | ||
+ | <rim:Value>Berea Community</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="authorRole"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Primary Surgon</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Slot name="authorSpecialty"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Orthopedic</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | </rim:Classification> | ||
+ | <rim:Classification | ||
+ | classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" | ||
+ | classifiedObject="SubmissionSet01" | ||
+ | nodeRepresentation="History and Physical" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" | ||
+ | id="id_12"> | ||
+ | <rim:Slot name="codingScheme"> | ||
+ | <rim:ValueList> | ||
+ | <rim:Value>Connect-a-thon contentTypeCodes</rim:Value> | ||
+ | </rim:ValueList> | ||
+ | </rim:Slot> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="History and Physical"/> | ||
+ | </rim:Name> | ||
+ | </rim:Classification> | ||
+ | <rim:ExternalIdentifier | ||
+ | identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8" | ||
+ | value="1.2009.9.1.2456" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" | ||
+ | id="id_13" registryObject="SubmissionSet01"> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="XDSSubmissionSet.uniqueId"/> | ||
+ | </rim:Name> | ||
+ | </rim:ExternalIdentifier> | ||
+ | <rim:ExternalIdentifier | ||
+ | identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832" | ||
+ | value="1.3.6.1.4.1.21367.2009.1.2.1" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" | ||
+ | id="id_14" registryObject="SubmissionSet01"> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="XDSSubmissionSet.sourceId"/> | ||
+ | </rim:Name> | ||
+ | </rim:ExternalIdentifier> | ||
+ | <rim:ExternalIdentifier | ||
+ | identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446" | ||
+ | value="76cc765a442f410^^^&1.3.6.1.4.1.21367.2005.3.7&ISO" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" | ||
+ | id="id_15" registryObject="SubmissionSet01"> | ||
+ | <rim:Name> | ||
+ | <rim:LocalizedString value="XDSSubmissionSet.patientId"/> | ||
+ | </rim:Name> | ||
+ | </rim:ExternalIdentifier> | ||
+ | </rim:RegistryPackage> | ||
+ | <rim:Classification classifiedObject="SubmissionSet01" | ||
+ | classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" | ||
+ | id="ID_1216346_1" | ||
+ | objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"/> | ||
+ | <rim:Association | ||
+ | associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" | ||
+ | sourceObject="SubmissionSet01" targetObject="Document01" id="ID_1216346_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:566EAD10FEBB55C5A61257193478499@apache.org" | ||
+ | xmlns:xop="http://www.w3.org/2004/08/xop/include"/> | ||
+ | </xdsb:Document> | ||
+ | </xdsb:ProvideAndRegisterDocumentSetRequest> | ||
+ | </soapenv:Body> | ||
+ | </soapenv:Envelope> | ||
+ | |||
+ | |||
+ | --MIMEBoundaryurn_uuid_566EAD10FEBB55C5A61257193478449 | ||
+ | Content-Type: text/plain | ||
+ | Content-Transfer-Encoding: binary | ||
+ | Content-ID: <1.urn:uuid:566EAD10FEBB55C5A61257193478499@apache.org> | ||
+ | |||
+ | This is my document. | ||
+ | |||
+ | It is great! | ||
+ | |||
+ | |||
+ | --MIMEBoundaryurn_uuid_566EAD10FEBB55C5A61257193478449-- | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | == 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.) | ||
+ | |||
+ | Start of some ebRIM [[ebRIM|documentation]]. | ||
+ | |||
+ | ==See Also== | ||
+ | The [[IT Infrastructure]] Domain manages this profile. | ||
+ | |||
+ | The [http://www.ihe.net/Technical_Framework/index.cfm#IT ITI Technical Framework] is the official master document for this Profile. | ||
+ | |||
+ | The [[Cross-Enterprise Document Sharing-b (XDS.b)]] page is an overview of the Profile. | ||
+ | |||
+ | [[Cross Enterprise Document Sharing]] is an alternative to this profile | ||
+ | |||
+ | [[Cross-Enterprise Document Sharing Implementation]] | ||
+ | |||
+ | [[XDS Stored Query Implementation]] | ||
+ | |||
+ | [[Category:Profile Implementations]] |
Latest revision as of 11:25, 3 May 2016
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)
Annotated Transaction Examples
The following are fully annotated example transactions.
Provide and Register.b
Stored Query
Retrieve Document Set
XDS Replace
NwHIN SAML Headers
More on MTOM vs MTOM/XOP
One note on MTOM vs MTOM/XOP. After describing them as separate things last year (our mistake), they are really only one concept. MTOM is a general structure for attachment encoding. As a general structure, it requires a concrete encoding scheme to be used with it. XOP is currently the only concrete encoding scheme defined for use with MTOM. So, for now, MTOM and MTOM/XOP mean the same thing. Later there could be an MTOM/XYZ which would be different.
The real distinctions being made this year are:
1) MTOM/XOP vs SIMPLE SOAP
The key and most observable difference in these formats is that MTOM/XOP is based on MIME Multipart encoding and SIMPLE SOAP has the XML content as the message body.
It is common industry practice, although not distinguished well in standards, that the request and response should be the same format. The thinking behind this is "if the sender can generate xyz format then he can accept it too". This concept is not well documented in standards and we had to discuss it with folks on the W3C committees to understand it fully. Is it truly illegal to respond to an MTOM message with SIMPLE SOAP? No, but, to do so you need to know that the client can accept this format in this instance. How would you know this? Because of a private agreement. So for purposes of interoperability, we established in the profile the hard rule that request format shall be same as response format. This plays out in two transactions, Provide and Register.b and Retrieve Document Set forcing the Provide and Register Response.b to be MTOM/XOP and the Retrieve Document Set Response to also be MTOM/XOP.
2) Optimized vs Un-optimized MTOM/XOP
The most basic document coding in SOAP is to insert the document contents as the value of an element coded in Base64. The Base64 encoding in necessary to ensure the document contents does not interfere with the XML parsing. This can be the simplest thing to do if the document is really small but with a large document, the document contents must be processed through the XML parser which is time consuming and may expose size related implementation issues in the XML parser. Also the encode/decode time of document in base64 is time/space consuming. Therefore, it is generally a good idea to push the document contents out of the XML document and place it in its own part of a MIME Multipart. Then it is not part of the XML stream so the XML parsing is easier/faster and as its own part, binary encoding can be done. Binary coding means that it is not base64 coded. This pushing of the document contents into a multipart part, is called optimization.
This plays out in the MTOM/XOP transactions as:
- Start with a MTOM/XOP wrapper
- Metadata goes in the root part which is identified by the start parameter of the content-type header
- Documents are included by the Document element (as defined by profile)
- If the un-optimized format is used then the document contents are included as base64 encoded value of the Document element.
- If optimized format is used then the document contents are placed into a separate part. The content-id of the part is then referenced by the Document element. The encoding of this part is not constrained by profile. Binary encoding can be used.
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
[This section, written in the Fall of 2007, outlines the work necessary for writing the XDS.b and XCA profiles. These profiles now fully profile the usage of Web Services.]
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 within 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
Updated 30 July 2013 - updated examples to show mustUnderstand attribute - bill
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 profiles accept 3 of the above 4 options. SIMPLE SOAP with embedded content is not acceptable.
This section offers examples of these forms. These examples are taken from the Public Registry implementation where possible. Note that the Content-Length header has been removed. Also, the metadata is truncated since it is not the focus of this discussion.
A SIMPLE SOAP message looks like this response to a 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 soapenv:mustUnderstand="true">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>
The following is also technically a SIMPLE SOAP message since it is a simple (not multi-part) HTTP format. It contains base64 encoded data in the Document element. This form is not used in XDS. Embedding large base64 coded documents into the XML is a large and unreasonable load on XML parsers.
POST /axis2/services/xdsrepositoryb HTTP/1.1 Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348; type="application/xop+xml"; start="0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" User-Agent: Axis2 Host: localhost:5000 Transfer-Encoding: chunked <?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:5000/axis2/services/xdsrepositoryb</wsa:To> <wsa:MessageID>urn:uuid:AFBE87CB65FD88AC4B1220879854302</wsa:MessageID> <wsa:Action soapenv:mustUnderstand="true">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"/> </rim:RegistryObjectList> </lcm:SubmitObjectsRequest> <xdsb:Document id="Document01">base64 content goes here</xdsb:Document> </xdsb:ProvideAndRegisterDocumentSetRequest> </soapenv:Body> </soapenv:Envelope>
MTOM/XOP (MTOM is an abstract format and XOP is the only existing encoding for that abstract format) messages are always structured as MIME Multipart messages. Within this overall form there are two options for including documents, for example, in 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:
POST /axis2/services/xdsrepositoryb HTTP/1.1 Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348; type="application/xop+xml"; start="0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" User-Agent: Axis2 Host: localhost:5000 Transfer-Encoding: chunked --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348 Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" Content-Transfer-Encoding: binary Content-ID: <0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@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:5000/axis2/services/xdsrepositoryb</wsa:To> <wsa:MessageID soapenv:mustUnderstand="true">urn:uuid:AFBE87CB65FD88AC4B1220879854302</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"/> </rim:RegistryObjectList> </lcm:SubmitObjectsRequest> <xdsb:Document id="Document01">base64 content goes here</xdsb:Document> </xdsb:ProvideAndRegisterDocumentSetRequest> </soapenv:Body> </soapenv:Envelope> --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348--
Note the base64 encoded document contents inside the <Document/> element. 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). We understand that .NET generates this form for the inclusion of very small documents.
What most think of first when we hear MTOM/XOP is the use of that form 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 <Document/> element has been removed and put into its own Part of the Multipart. In its place is an <xop:Include/> element that 'points' to the content in the other Part.
POST /axis2/services/xdsrepositoryb HTTP/1.1 Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348; type="application/xop+xml"; start="0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" User-Agent: Axis2 Host: localhost:5000 Transfer-Encoding: chunked --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348 Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" Content-Transfer-Encoding: binary Content-ID: <0.urn:uuid:AFBE87CB65FD88AC4B1220879854349@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:5000/axis2/services/xdsrepositoryb</wsa:To> <wsa:MessageID>urn:uuid:AFBE87CB65FD88AC4B1220879854302</wsa:MessageID> <wsa:Action soapenv:mustUnderstand="true">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"/> </rim:RegistryObjectList> </lcm:SubmitObjectsRequest> <xdsb:Document id="Document01"> <xop:Include href="cid:1.urn:uuid:AFBE87CB65FD88AC4B1220879854390@apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include"/> </xdsb:Document> </xdsb:ProvideAndRegisterDocumentSetRequest> </soapenv:Body> </soapenv:Envelope> --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348 Content-Type: text/plain Content-Transfer-Encoding: binary Content-ID: <1.urn:uuid:AFBE87CB65FD88AC4B1220879854390@apache.org> This is my document. It is great! --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348--
Example Retrieve Document Set transaction
Updated 30 July 2013 - added mustUnderstand attribute - bill
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.
Note that the request is carried MTOM/XOP package even though it does not need it. We have come to understand that the expected behavior of Web Service interactions is to have the request and response in the same format. Since the response must carry documents it must use MTOM/XOP. Without this rule the request could use SIMPLE SOAP but since the requirement of consistency between request and response, the request must also be in MTOM/XOP format.
Request
POST /tf6/services/xdsrepositoryb HTTP/1.1 Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_DCD262C64C22DB97351256303951323; type="application/xop+xml"; start="<0.urn:uuid:DCD262C64C22DB97351256303951324@apache.org>"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:RetrieveDocumentSet" User-Agent: Axis2 Host: localhost:5000 --MIMEBoundaryurn_uuid_DCD262C64C22DB97351256303951323 Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" Content-Transfer-Encoding: binary Content-ID: <0.urn:uuid:DCD262C64C22DB97351256303951324@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 soapenv:mustUnderstand="true">http://localhost:5000/tf6/services/xdsrepositoryb</wsa:To> <wsa:MessageID>urn:uuid:DCD262C64C22DB97351256303951276</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"> <DocumentRequest> <RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId> <DocumentUniqueId>2009.9.1.1573</DocumentUniqueId> </DocumentRequest> </RetrieveDocumentSetRequest> </soapenv:Body> </soapenv:Envelope> --MIMEBoundaryurn_uuid_DCD262C64C22DB97351256303951323--
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: multipart/related; boundary=MIMEBoundaryurn_uuid_F862C3E04D9E35266C1256303956115; type="application/xop+xml"; start="0.urn:uuid:F862C3E04D9E35266C1256303956116@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:RetrieveDocumentSetResponse" Date: Fri, 23 Oct 2009 13:19:11 GMT --MIMEBoundaryurn_uuid_F862C3E04D9E35266C1256303956115 Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" Content-Transfer-Encoding: binary Content-ID: <0.urn:uuid:F862C3E04D9E35266C1256303956116@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 soapenv:mustUnderstand="true">urn:uuid:DCD262C64C22DB97351256303951276</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:RepositoryUniqueId>1.19.6.24.109.42.1.5</xdsb:RepositoryUniqueId> <xdsb:DocumentUniqueId>2009.9.1.1573</xdsb:DocumentUniqueId> <xdsb:mimeType>application/pdf</xdsb:mimeType> <xdsb:Document> <xop:Include href="cid:1.urn:uuid:F862C3E04D9E35266C1256303956117@apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include"/> </xdsb:Document> </xdsb:DocumentResponse> </xdsb:RetrieveDocumentSetResponse> </soapenv:Body> </soapenv:Envelope> --MIMEBoundaryurn_uuid_F862C3E04D9E35266C1256303956115 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-ID: <1.urn:uuid:F862C3E04D9E35266C1256303956117@apache.org> This is the content of the document. --MIMEBoundaryurn_uuid_F862C3E04D9E35266C1256303956115--
Example Provide and Register Document Set-b transaction
Updated 30 July 2013 - added attribute mustUnderstand - bill
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.
Note: this is not a complete submission, the metadata attributes of the Submission Set (RegistryPackage) and Document Entry (ExtrinsicObject) have been removed for clarity. An example with full metadata is found here
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 soapenv:mustUnderstand="true">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
Note that this message does not NEED MTOM/XOP encoding (no attachments present). But, since the request and response must be in the same format (SIMPLE SOAP or MTOM) this response must be in MTOM encoding.
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_7BFFF2BD24C642EA531247750913327; type="application/xop+xml"; start="<0.urn:uuid:7BFFF2BD24C642EA531247750913328@apache.org>"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse" Date: Thu, 16 Jul 2009 13:28:32 GMT --MIMEBoundaryurn_uuid_7BFFF2BD24C642EA531247750913327 Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" Content-Transfer-Encoding: binary Content-ID: <0.urn:uuid:7BFFF2BD24C642EA531247750913328@apache.org> <?xml version='1.0' encoding='UTF-8'?> <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"> <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"> <wsa:Action soapenv:mustUnderstand="true">urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse</wsa:Action> <wsa:RelatesTo>urn:uuid:AD33D8190CB655E8751247750894152</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> --MIMEBoundaryurn_uuid_7BFFF2BD24C642EA531247750913327--
Example Register Document Set-b transaction
Updated 30 July 2013 - added mustUnderstand attribute - bill
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 soapenv:mustUnderstand="true">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 soapenv:mustUnderstand="true">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>
Example Provide and Register Document Set-b transaction (with full metadata)
Updated 30 July 2013 - added mustUnderstand attribute - bill
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.
This example includes full metadata for the submission of a single Document.
Request
POST /tf6/services/xdsrepositoryb HTTP/1.1 Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_566EAD10FEBB55C5A61257193478449; type="application/xop+xml"; start="<0.urn:uuid:566EAD10FEBB55C5A61257193478450@apache.org>"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" User-Agent: Axis2 Host: localhost:5000 --MIMEBoundaryurn_uuid_566EAD10FEBB55C5A61257193478449 Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" Content-Transfer-Encoding: binary Content-ID: <0.urn:uuid:566EAD10FEBB55C5A61257193478450@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:5000/tf6/services/xdsrepositoryb</wsa:To> <wsa:MessageID soapenv:mustUnderstand="true">urn:uuid:566EAD10FEBB55C5A61257193478400</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:Slot name="creationTime"> <rim:ValueList> <rim:Value>20051224</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="languageCode"> <rim:ValueList> <rim:Value>en-us</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="serviceStartTime"> <rim:ValueList> <rim:Value>200412230800</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="serviceStopTime"> <rim:ValueList> <rim:Value>200412230801</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="sourcePatientId"> <rim:ValueList> <rim:Value>89765a87b^^^&3.4.5&ISO</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="sourcePatientInfo"> <rim:ValueList> <rim:Value>PID-3|pid1^^^&1.2.3&ISO</rim:Value> <rim:Value>PID-5|Doe^John^^^</rim:Value> <rim:Value>PID-7|19560527</rim:Value> <rim:Value>PID-8|M</rim:Value> <rim:Value>PID-11|100 Main St^^Metropolis^Il^44130^USA</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Physical"/> </rim:Name> <rim:Description/> <rim:Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="Document01" nodeRepresentation="" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_1"> <rim:Slot name="authorPerson"> <rim:ValueList> <rim:Value>^Smitty^Gerald^^^</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorInstitution"> <rim:ValueList> <rim:Value>Cleveland Clinic</rim:Value> <rim:Value>Parma Community</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorRole"> <rim:ValueList> <rim:Value>Attending</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorSpecialty"> <rim:ValueList> <rim:Value>Orthopedic</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification> <rim:Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="Document01" nodeRepresentation="" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_2"> <rim:Slot name="authorPerson"> <rim:ValueList> <rim:Value>^Dopplemeyer^Sherry^^^</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorInstitution"> <rim:ValueList> <rim:Value>Cleveland Clinic</rim:Value> <rim:Value>Berea Community</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorRole"> <rim:ValueList> <rim:Value>Primary Surgon</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorSpecialty"> <rim:ValueList> <rim:Value>Orthopedic</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification> <rim:Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="Document01" nodeRepresentation="History and Physical" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_3"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>Connect-a-thon classCodes</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="History and Physical"/> </rim:Name> </rim:Classification> <rim:Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="Document01" nodeRepresentation="1.3.6.1.4.1.21367.2006.7.101" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_4"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>Connect-a-thon confidentialityCodes</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Clinical-Staff"/> </rim:Name> </rim:Classification> <rim:Classification classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="Document01" nodeRepresentation="CDAR2/IHE 1.0" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_5"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>Connect-a-thon formatCodes</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="CDAR2/IHE 1.0"/> </rim:Name> </rim:Classification> <rim:Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="Document01" nodeRepresentation="Outpatient" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_6"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>Connect-a-thon healthcareFacilityTypeCodes</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Outpatient"/> </rim:Name> </rim:Classification> <rim:Classification classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="Document01" nodeRepresentation="General Medicine" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_7"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>Connect-a-thon practiceSettingCodes</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="General Medicine"/> </rim:Name> </rim:Classification> <rim:Classification classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="Document01" nodeRepresentation="34108-1" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_8"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>LOINC</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Outpatient Evaluation And Management"/> </rim:Name> </rim:Classification> <rim:ExternalIdentifier identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="76cc765a442f410^^^&1.3.6.1.4.1.21367.2005.3.7&ISO" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_9" registryObject="Document01"> <rim:Name> <rim:LocalizedString value="XDSDocumentEntry.patientId"/> </rim:Name> </rim:ExternalIdentifier> <rim:ExternalIdentifier identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="1.2009.9.1.2455" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_10" registryObject="Document01"> <rim:Name> <rim:LocalizedString value="XDSDocumentEntry.uniqueId"/> </rim:Name> </rim:ExternalIdentifier> </rim:ExtrinsicObject> <rim:RegistryPackage id="SubmissionSet01" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:RegistryPackage"> <rim:Slot name="submissionTime"> <rim:ValueList> <rim:Value>20041225235050</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Physical"/> </rim:Name> <rim:Description> <rim:LocalizedString value="Annual physical"/> </rim:Description> <rim:Classification classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d" classifiedObject="SubmissionSet01" nodeRepresentation="" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_11"> <rim:Slot name="authorPerson"> <rim:ValueList> <rim:Value>^Dopplemeyer^Sherry^^^</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorInstitution"> <rim:ValueList> <rim:Value>Cleveland Clinic</rim:Value> <rim:Value>Berea Community</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorRole"> <rim:ValueList> <rim:Value>Primary Surgon</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorSpecialty"> <rim:ValueList> <rim:Value>Orthopedic</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification> <rim:Classification classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" classifiedObject="SubmissionSet01" nodeRepresentation="History and Physical" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" id="id_12"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>Connect-a-thon contentTypeCodes</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="History and Physical"/> </rim:Name> </rim:Classification> <rim:ExternalIdentifier identificationScheme="urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8" value="1.2009.9.1.2456" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_13" registryObject="SubmissionSet01"> <rim:Name> <rim:LocalizedString value="XDSSubmissionSet.uniqueId"/> </rim:Name> </rim:ExternalIdentifier> <rim:ExternalIdentifier identificationScheme="urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832" value="1.3.6.1.4.1.21367.2009.1.2.1" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_14" registryObject="SubmissionSet01"> <rim:Name> <rim:LocalizedString value="XDSSubmissionSet.sourceId"/> </rim:Name> </rim:ExternalIdentifier> <rim:ExternalIdentifier identificationScheme="urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446" value="76cc765a442f410^^^&1.3.6.1.4.1.21367.2005.3.7&ISO" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier" id="id_15" registryObject="SubmissionSet01"> <rim:Name> <rim:LocalizedString value="XDSSubmissionSet.patientId"/> </rim:Name> </rim:ExternalIdentifier> </rim:RegistryPackage> <rim:Classification classifiedObject="SubmissionSet01" classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd" id="ID_1216346_1" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"/> <rim:Association associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:HasMember" sourceObject="SubmissionSet01" targetObject="Document01" id="ID_1216346_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:566EAD10FEBB55C5A61257193478499@apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include"/> </xdsb:Document> </xdsb:ProvideAndRegisterDocumentSetRequest> </soapenv:Body> </soapenv:Envelope> --MIMEBoundaryurn_uuid_566EAD10FEBB55C5A61257193478449 Content-Type: text/plain Content-Transfer-Encoding: binary Content-ID: <1.urn:uuid:566EAD10FEBB55C5A61257193478499@apache.org> This is my document. It is great! --MIMEBoundaryurn_uuid_566EAD10FEBB55C5A61257193478449--
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.)
Start of some ebRIM documentation.
See Also
The IT Infrastructure Domain manages this profile.
The ITI Technical Framework is the official master document for this Profile.
The Cross-Enterprise Document Sharing-b (XDS.b) page is an overview of the Profile.
Cross Enterprise Document Sharing is an alternative to this profile