6 Asynchronous Messaging
6.1 Brief Description
Many of the services within NHIN need to function in both a synchronous fashion as well as an
asynchronous fashion. Synchronous would be the model where an initiating gateway sends a request to
the responding gateway and waits for a response to come back on the same HTTP connection. The
responding gateway receives the request and processes it in real-time and sends back the response to
the initiating gateway on that same HTTP connection. Asynchronous messaging is the model where an
initiating gateway sends a request to the responding gateway on one HTTP connection. The responding
gateway receives some sort of HTTP ACK or Application ACK as a response. The initiating gateway is no
longer blocked. The responding gateway processes the request and when completed, it sends a
response message back to the initiating gateway on a separate HTTP socket to a waiting service on the
initiating gateway side or somewhere else.
WS-Addressing is a technology that has been created that enables the ability to provide asynchronous
messaging support within web service stacks in a common way. WS-Addressing defines specific data
elements that facilitate this. Some of the key ones are: MessageID, ReplyTo, and RelatesTo. The
MessageID is a unique identifier attached to the message. ReplyTo identifies the URL of the endpoint
where the response message is to be sent. (Note that if it is not on the same HTTP socket, this implies
that the initiator would have to set up a service that can receive the reply.) The RelatesTo field identifies
the MessageID of the request that is associated with the response.
Several of the NHIN specifications have specified the use of WS-Addressing to provide asynchronous
messaging support on their respective NHIN services. This is based on the underlying IHE specifications
that require the same approach. The approach of using WS-Addressing works well when latency times
between the request and response are relatively small. It does not work well with large or extreme
latencies where the time between the request and response can be in hours, days or weeks. There are a
number of usage scenarios that must be handled within NHIN where the latency duration can be
extreme.
When addressing extreme latencies, the solution must be one where there are no blocked threads and
no long running processes on either the initiating or responding gateways. The current approach of
using WS-Addressing addresses blocked threads on the initiating gateway, but does not solve the
problem of long-running processes on the responding gateway. Using WS-Addressing, the initiating
gateway sends an asynchronous request to the responding gateway it specifies a URL of a web service
that will be used to receive the response in the ReplyTo field. The responding gateway sends a transport
ACK to the initiating gateway and it is no longer blocked. The responding gateway starts to process the
message. Because of the way the current stacks generate the code for the server side of this process, a
long-running process occurs. The process will continue to run until it has processed the message. At the
time it completes its processing, it will send the response back to the initiating gateway to the URL that
was specified. The following diagram shows this process:
To solve the issue of extreme latency, asynchronous messaging will be done with a slight variation on
the combined approach of the previous IHE and current IHE solution. The previous IHE solution specified
the use of two one-way messages, one for the request message and one for the response message. A
gateway that needed to communicate asynchronously would send the request to a web service on the
responding gateway. Since it was a one way message, the sender would not block on the call. The
sender would then provide a web service end point that the responding gateway would use to send the
response message. After the responding gateway had processed the request, it would send the response
as a one-way message to that service on the initiating gateway.
The current IHE proposed approach is to use WS-Addressing and allow the web service stack to manage
the implementation of asynchronous messaging. In this model, the initiating gateway sends a request
message to the responding gateway. In that message it specifies the endpoint URL in the "ReplyTo" field
of the SOAP header. This URL points to a web service that the initiating gateway has provided to receive
the response. The responding gateway web service stack takes the responsibility for making sure that
when the reply is processed that the reply is sent to the location defined by the "ReplyTo" value. Since
the initiating gateway has specified the "ReplyTo" URL which refers to a waiting web service, it only
blocks long enough to wait for an HTTP ACK , which occurs directly from the web service stack. It does
not wait for the message to be processed. However the issue is that the responding gateway (the server
side in this case), while it is not blocked, is in the middle of a long running transaction which does not
complete until the message is processed and response message is sent.
The current NHIN solution is a slight variation on combining both the previous and the current IHE
solution together into a new solution. The approach is to take the two web service approach as the
basis. But rather than using two one-way web services, it would be based on two two-way web services.
The second part (response part) of each web service would simply be an ACK reply. This would be
combined with the use of WS-Addressing to correlate the request and response messages.
There are two main reason for changing this from two one-way messages to two two-way messages.
The first is to address issues around extreme latencies. The key here is that the failed delivery of the
request or response message would be communicated immediately which enables the initiating
gateway to respond to this immediately. If this was not done, then a dropped message would not
become apparent until the entire length of the longest allowable latency time had expired. The second
ensures that the component that needs to be aware of the dropped or missed message receives the
notification. This is most likely the sender of the message and not the web service that is waiting to
process the response. The portion of the code on the initiating gateway that sends the original request is
the one most capable of resending it if there is a problem with the first attempt. By having the
responding gateway send it an ACK message, it knows that the message has been sent and received
successfully by the responding gateway.
One of the biggest items that is being solved by WS-Addressing is the management of message IDs and
the association of the request message to the response message. The value WS-Addressing provides is
that this is handled outside of the message payload for each of the messages. The NHIN solution uses
these fields within WS-Addressing for this purpose. The main three fields that will be used will be the
"ReplyTo" which will always be set to http://www.w3.org/2005/08/addressing/anonymous, the
"MessageID" field that will contain the unique message ID for the message, and the "RelatesTo" field in
the response message that will contain the message ID of the request message.
This implies the following. A responding gateway that supports both synchronous and asynchronous
communication would set up two web services. One for synchronous that handles a request/response
message, and one for asynchronous that is a two-way message where the request contains the same
data type as the synchronous case, but the response is an ACK message. The initiating gateway would
set up a request/response service where the inbound message is the response message from the first
call, and the reply is an ACK that the initiating gateway received it. This further implies that all three of
these web service endpoints need to publish their endpoint URL in the UDDI. It should be noted that the
names and namespaces in the synchronous and the asynchronous versions of the WSDLs would need to
be different so that code generation of the web service code in a gateway supporting both do not have
conflicts.
The following diagram is an illustration of the NHIN solution:
6.2 Message Exchange
The message exchange starts with the initiating gateway. It sends a request to the responding gateway.
The responding gateway receives the message and persists it in whatever mechanism is appropriate.
This may be using queues, files, or some other form. Once it has accepted ownership of the request
message, it replies with an application acknowledgement. After sending the acknowledgment, the
responding gateway proceeds to process the message. When completed, it sends a response to the
initiating gateway on its waiting response web service. The initiating gateway completes the message
by sending an application acknowledgement for that response. The following diagram shows the
sequence of events that occur between the initiating gateway and the responding gateway.
The following WS-Addessing values will be used in this message exchange.
MessageID
This will contain the ID for the message. In the service request, this will contain the message ID for the
request. In the service response, it will contain the message ID for the response.
ReplyTo
This will always be set to the following value: http://www.w3.org/2005/08/addressing/anonymous
RelatesTo
This field will not be passed or will be empty on the service request message. On the service response
message, it will contain the message ID of the request message or request messages that this is in
response to.
6.3 WSDL Design
To support asynchronous messaging there two additional WSDL files will need to be created. One will
contain the definition of the request web service and the second will contain the definition of the
response web service. The mechanism for creating these two WSDL files will be to take the original
synchronous web service WSDL definition and create a WSDL that represents the request part of it and a
second one for the response part of it. In addition, the response part of each of these two web service
methods services will contain an ACK. As this is implemented within each of the NHIN services, an ACK
should be used from the underlying specification. Both HL7 3.0 and EBXML contain ACK data types that
may be used for this purpose.
In addition, in order to make sure that the service is unique when code is generated, the name of the
Port Type is modified. For the request message, the name is changed by appending, "AsyncReq". For
the response message, the name is changed by appending, "AsyncResp". The following is an example of
the PatientDiscovery Synchronous WSDL and its corresponding asynchronous WSDL files.
Patient Discovery Synchronous WSDL File
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:tns="urn:ihe:iti:xcpd:2009"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:hl7="urn:hl7org:v3" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd"
xmlns:wsaws="http://www.w3.org/2005/08/addressing"
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:sc="http://schemas.sun.com/2006/03/wss/server"
xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
name="XCPDRespondingGateway" targetNamespace="urn:ihe:iti:xcpd:2009">
<wsdl:documentation>
Example WSDL for XCPD Responding Gateway
</wsdl:documentation>
<wsdl:types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<!-- Include the message schema -->
<xsd:include
schemaLocation="../schemas/HL7V3/NE2008/multicacheschemas/PRPA_IN201305UV02.x
sd"/>
</xsd:schema>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<!-- Include the message schema -->
<xsd:include
schemaLocation="../schemas/HL7V3/NE2008/multicacheschemas/PRPA_IN201306UV02.x
sd"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="PRPA_IN201305UV02_Message">
<wsdl:part name="Body" element="hl7:PRPA_IN201305UV02"/>
</wsdl:message>
<wsdl:message name="PRPA_IN201306UV02_Message">
<wsdl:part name="Body" element="hl7:PRPA_IN201306UV02"/>
</wsdl:message>
<wsdl:portType name="RespondingGateway_PortType">
<wsdl:operation name="RespondingGateway_PRPA_IN201305UV02">
<wsdl:input message="tns:PRPA_IN201305UV02_Message"
wsaw:Action="urn:hl7-org:v3:PRPA_IN201305UV02:CrossGatewayPatientDiscovery"/>
<wsdl:output message="tns:PRPA_IN201306UV02_Message"
wsaw:Action="urn:hl7-org:v3:PRPA_IN201306UV02:CrossGatewayPatientDiscovery"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="RespondingGateway_Binding_Soap12"
type="tns:RespondingGateway_PortType">
<soap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsp:PolicyReference
URI="#RespondingGateway_Binding_SoapPolicy"/>
<wsdl:operation name="RespondingGateway_PRPA_IN201305UV02">
<soap12:operation soapAction="urn:hl7org:v3:PRPA_IN201305UV02:CrossGatewayPatientDiscovery"/>
<wsdl:input>
<soap12:body use="literal"/>
<wsp:PolicyReference
URI="#RespondingGateway_Binding_Soap_Input_Policy"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
<wsp:PolicyReference
URI="#RespondingGateway_Binding_Soap_Output_Policy"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="RespondingGateway_Service">
<wsdl:port name="RespondingGateway_Port_Soap12"
binding="tns:RespondingGateway_Binding_Soap12">
<soap12:address
location="https://localhost:${HttpsDefaultPort}/NhinConnect/PatientDiscovery"
/>
</wsdl:port>
</wsdl:service>
<wsp:Policy wsu:Id="RespondingGateway_Binding_SoapPolicy">
<wsp:ExactlyOne>
<wsp:All>
<wsaws:UsingAddressing
xmlns:wsaws="http://www.w3.org/2006/05/addressing/wsdl"/>
<sc:KeyStore wspp:visibility="private"
aliasSelector="gov.hhs.fha.nhinc.callback.KeyStoreServerAliasSelector"
callbackHandler="gov.hhs.fha.nhinc.callback.KeyStoreCallbackHandler"/>
<sc:TrustStore wspp:visibility="private"
callbackHandler="gov.hhs.fha.nhinc.callback.TrustStoreCallbackHandler"/>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy>
<sp:RequireClientCertificate/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:TransportBinding>
<sp:EndorsingSupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:EndorsingSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:Policy wsu:Id="RespondingGateway_Binding_Soap_Input_Policy">
<wsp:ExactlyOne>
<wsp:All>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:Policy wsu:Id="RespondingGateway_Binding_Soap_Output_Policy">
<wsp:ExactlyOne>
<wsp:All>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsdl:definitions>
Patient Discovery Asynchronous Request WSDL File
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:tns="urn:ihe:iti:xcpd:2009"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:hl7="urn:hl7org:v3" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd"
xmlns:wsaws="http://www.w3.org/2005/08/addressing"
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:sc="http://schemas.sun.com/2006/03/wss/server"
xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
name="XCPDRespondingGatewayAsyncReq" targetNamespace="urn:ihe:iti:xcpd:2009">
<wsdl:documentation>
WSDL for Asynchronous XCPD Responding Gateway
</wsdl:documentation>
<wsdl:types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<!-- Include the message schema -->
<xsd:include
schemaLocation="../schemas/HL7V3/NE2008/multicacheschemas/PRPA_IN201305UV02.x
sd"/>
</xsd:schema>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<!-- Include the message schema -->
<xsd:include
schemaLocation="../schemas/HL7V3/NE2008/multicacheschemas/MCCI_IN000002UV01.x
sd"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="PRPA_IN201305UV02_Message">
<wsdl:part name="Body" element="hl7:PRPA_IN201305UV02"/>
</wsdl:message>
<wsdl:message name="MCCI_IN000002UV01_Message">
<wsdl:part name="Body" element="hl7:MCCI_IN000002UV01"/>
</wsdl:message>
<wsdl:portType name="RespondingGatewayAsyncReq_PortType">
<wsdl:operation name="RespondingGateway_PRPA_IN201305UV02">
<wsdl:input message="tns:PRPA_IN201305UV02_Message"
wsaw:Action="urn:hl7-org:v3:PRPA_IN201305UV02:CrossGatewayPatientDiscovery"/>
<wsdl:output message="tns:MCCI_IN000002UV01_Message"
wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01:CrossGatewayPatientDiscovery"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="RespondingGatewayAsyncReq_Binding"
type="tns:RespondingGatewayAsyncReq_PortType">
<soap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsp:PolicyReference
URI="#RespondingGateway_Binding_SoapPolicy"/>
<wsdl:operation name="RespondingGateway_PRPA_IN201305UV02">
<soap12:operation soapAction="urn:hl7org:v3:PRPA_IN201305UV02:CrossGatewayPatientDiscovery"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="RespondingGatewayAsyncReq_Service">
<wsdl:port name="RespondingGatewayAsyncReq_Port"
binding="tns:RespondingGatewayAsyncReq_Binding">
<soap12:address
location="https://localhost/NhinConnect/PatientDiscoveryAsyncReq"/>
</wsdl:port>
</wsdl:service>
<wsp:Policy wsu:Id="RespondingGateway_Binding_SoapPolicy">
<wsp:ExactlyOne>
<wsp:All>
<wsaws:UsingAddressing
xmlns:wsaws="http://www.w3.org/2006/05/addressing/wsdl"/>
<sc:KeyStore wspp:visibility="private"
aliasSelector="gov.hhs.fha.nhinc.callback.KeyStoreServerAliasSelector"
callbackHandler="gov.hhs.fha.nhinc.callback.KeyStoreCallbackHandler"/>
<sc:TrustStore wspp:visibility="private"
callbackHandler="gov.hhs.fha.nhinc.callback.TrustStoreCallbackHandler"/>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy>
<sp:RequireClientCertificate/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:TransportBinding>
<sp:EndorsingSupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:EndorsingSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsdl:definitions>
Patient Discovery Asynchronous Response WSDL File
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:tns="urn:ihe:iti:xcpd:2009"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:hl7="urn:hl7org:v3" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd"
xmlns:wsaws="http://www.w3.org/2005/08/addressing"
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:sc="http://schemas.sun.com/2006/03/wss/server"
xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
name="XCPDRespondingGatewayAsyncResp"
targetNamespace="urn:ihe:iti:xcpd:2009">
<wsdl:documentation>
WSDL for Asynchronous XCPD Responding Gateway Responses
</wsdl:documentation>
<wsdl:types>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<!-- Include the message schema -->
<xsd:include
schemaLocation="../schemas/HL7V3/NE2008/multicacheschemas/PRPA_IN201306UV02.x
sd"/>
</xsd:schema>
<xsd:schema elementFormDefault="qualified"
targetNamespace="urn:hl7-org:v3" xmlns:hl7="urn:hl7-org:v3">
<!-- Include the message schema -->
<xsd:include
schemaLocation="../schemas/HL7V3/NE2008/multicacheschemas/MCCI_IN000002UV01.x
sd"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="PRPA_IN201306UV02_Message">
<wsdl:part name="Body" element="hl7:PRPA_IN201306UV02"/>
</wsdl:message>
<wsdl:message name="MCCI_IN000002UV01_Message">
<wsdl:part name="Body" element="hl7:MCCI_IN000002UV01"/>
</wsdl:message>
<wsdl:portType name="RespondingGatewayAsyncResp_PortType">
<wsdl:operation name="RespondingGateway_PRPA_IN201306UV02">
<wsdl:input message="tns:PRPA_IN201306UV02_Message"
wsaw:Action="urn:hl7-org:v3:PRPA_IN201306UV02:CrossGatewayPatientDiscovery"/>
<wsdl:output message="tns:MCCI_IN000002UV01_Message"
wsaw:Action="urn:hl7-org:v3:MCCI_IN000002UV01:CrossGatewayPatientDiscovery"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="RespondingGatewayAsyncResp_Binding"
type="tns:RespondingGatewayAsyncResp_PortType">
<soap12:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsp:PolicyReference
URI="#RespondingGateway_Binding_SoapPolicy"/>
<wsdl:operation name="RespondingGateway_PRPA_IN201306UV02">
<soap12:operation soapAction="urn:hl7org:v3:PRPA_IN201306UV02:CrossGatewayPatientDiscovery"/>
<wsdl:input>
<soap12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="RespondingGatewayAsyncResp_Service">
<wsdl:port name="RespondingGatewayAsyncResp_Port"
binding="tns:RespondingGatewayAsyncResp_Binding">
<soap12:address
location="https://localhost/NhinConnect/PatientDiscoveryAsyncResp"/>
</wsdl:port>
</wsdl:service>
<wsp:Policy wsu:Id="RespondingGateway_Binding_SoapPolicy">
<wsp:ExactlyOne>
<wsp:All>
<wsaws:UsingAddressing
xmlns:wsaws="http://www.w3.org/2006/05/addressing/wsdl"/>
<sc:KeyStore wspp:visibility="private"
aliasSelector="gov.hhs.fha.nhinc.callback.KeyStoreServerAliasSelector"
callbackHandler="gov.hhs.fha.nhinc.callback.KeyStoreCallbackHandler"/>
<sc:TrustStore wspp:visibility="private"
callbackHandler="gov.hhs.fha.nhinc.callback.TrustStoreCallbackHandler"/>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken>
<wsp:Policy>
<sp:RequireClientCertificate/>
</wsp:Policy>
</sp:HttpsToken>
</wsp:Policy>
</sp:TransportToken>
<sp:Layout>
<wsp:Policy>
<sp:Strict/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
</wsp:Policy>
</sp:TransportBinding>
<sp:EndorsingSupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/wssecuritypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:EndorsingSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:MustSupportRefKeyIdentifier/>
<sp:MustSupportRefIssuerSerial/>
<sp:RequireSignatureConfirmation/>
</wsp:Policy>
</sp:Wss11>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</wsdl:definitions>