1. Deferred Messaging Brown Bag 1

2. Agenda 2 Background Solution Implementation Details Additional Information

3. Background 3 NHIN Participants identified the need for asynchronous messaging Asynchronous messaging was defined as:  “A request message is sent and at some point in time in the future a response message is received”  This response could come back hours, days, or up to a month later First approach to solve this was with Asynchronous Web Services and WS-Addressing  Under took a large scale research effort to investigate current stack implementations of Asynchronous Web Services and WS-Addressing support  Determined that the NHIN definition of asynchronous messaging was not the same as the stack implementers definition  Determined there was no stack support for what the NHIN was trying to achieve  Determined a custom solution was needed to support NHIN Use Cases

4. Solution 4 The custom solution proposed by the CONNECT Team was to break up the synchronous version of a service into a two deferred services  Request Service and Response Service  These services would take a request or response as an input and return an application acknowledgement as an output  Uses WS-Addressing MessageID and RelatesTo fields in the SOAP Header to correlate responses with requests Benefits of this approach:  Allows for long running transactions of any length  Easy to implement  Gives the sender assurance that the request message was delivered  Uses the WS-Addressing standard for a future, potential upgrade if and when stacks catch up

5. Implementation - WSDLs 5 WSDLs must include WS-Addressing  Entity  Proxy (pass-through)  Nhin  Adapter  Secure and Unsecure  Secure versions of existing WSDLs already include WS-Addressing WS-Addressing is used to correlate responses with requests  Same MessageID value must be specified in the MessageID WS- Addressing field for all request messages associated with a particular transaction  Corresponding RelatesTo value must be specified in the RelatesTo WS- Addressing field for all response messages associated with a particular transaction Orchestration WSDLs do not need to be modified (i.e. Audit Repository, MPI, etc)

6. Implementation – WSDLs (con’t) 6 This can be specified directly or via a WS-Policy reference in the binding definition within the WSDL or WS-Policy Statement

7. Implementation – Receiving Interface 7 When an application receives a message on an Entity, Proxy, Nhin, or Adapter Deferred Messaging Interface it must extract the WS- Addressing values from the SOAP Header so they can be used later on  For request messages this would be the MessageID field  For response messages this would be the RelatesTo field  These values need to be extracted from the SOAP Header and stored in the Assertion class AsyncMessageIdExtractor Class available to support this extraction  Used to extract values from the WS-Addressing Header  The GetAsyncMessageId method extracts the MessageID field  The GetAsyncRelatesTo method extracts the MessageID field  These values should be put in the asyncMessageId field of the Assertion class AsyncMessageIdExtractor msgIdExtractor = new AsyncMessageIdExtractor(); assertion.setAsyncMessageId(msgIdExtractor.GetAsyncMessageId(context)); or AsyncMessageIdExtractor msgIdExtractor = new AsyncMessageIdExtractor(); assertion.setAsyncMessageId(msgIdExtractor.GetAsyncRelatesTo(context));

8. Implementation – Sending Interface 8 When an application sends a message on an Entity, Proxy, Nhin, or Adapter Deferred Messaging Interface it must insert the WS-Addressing values into the SOAP Header prior to sending the message  For request messages this would be the MessageID field  For response messages this would be the RelatesTo field  These values need to have the value from the asyncMessageId field in the Assertion class be inserted into the SOAP Header  New code to accommodate this should be added to the Component Spring Proxy for each interface. Message Handler class is needed to override WS-Addressing values set by the stack The AsyncMessageHandler class is a generic message handler class that can be used by any service All that needs to be done is to assign this class to the outgoing web-service port ArrayList handlerSetUp = new ArrayList (); AsyncMessageHandler msgHandler = new AsyncMessageHandler(); handlerSetUp.add(msgHandler); ((javax.xml.ws.BindingProvider) port).getBinding().setHandlerChain(handlerSetUp);

9. Implementation – Sending Interface 9 AsyncMessageIdCreator Class available to support the creation of the MessageID  Used to put the MessageID value in the request context  Also adds additional information to the request context to associate this value with a request or response  The CreateRequestContextForMessageId method sets the request context values to indicate a deferred request is being sent  The CreateRequestContextForRelatesTo method sets the request context values to indicate a deferred response is being sent  The request context will be used by the Message Handler class to insert the id into the appropriate location AsyncMessageIdCreator msgIdCreator = new AsyncMessageIdCreator(); requestContext.putAll(msgIdCreator.CreateRequestContextForMessageId(assertion)); or AsyncMessageIdCreator msgIdCreator = new AsyncMessageIdCreator(); requestContext.putAll(msgIdCreator.CreateRequestContextForRelatesTo(assertion));

10. Implementation – Misc 10 Message correlation  For the most part message correlation is an adapter activity  In the special cases where the Gateway actually processes the messages there may be a need to correlate deferred responses with requests Patient Discovery HIEM  As part of the Generic Asynchronous Messaging Design there is a database available to assign with their correlation Error Conditions If an error occurs on the Responding Gateway side then an indication of the error needs to be passed to the Adapter The Adapter should be the component that decides when to return the response to the Initiating Gateway To accomplish this an Adapter Error WSDL Interface needs to be in place and any error conditions passed to this interface

11. Implementation – Misc 11 Gateway Message Processing  In order to support the “man in the loop” use case, but still have the Gateway process a message a Queue WSDL Interface is needed  Upon receipt of a Deferred Request Message that will be processed by the Gateway it will be sent to the Adapter Queue WSDL Interface  The Adapter will send the Deferred Request Message back to the Gateway when it determines it is time to process the message

12. Additional Information 12 Background: http://developer.connectopensource.org/display/CONNECTWIKI/Asynchronous+W eb+Service+Calls+Using+WS-Addressing http://developer.connectopensource.org/display/CONNECTWIKI/Asynchronous+W eb+Service+Calls+Using+WS-Addressing Engineering Analysis: http://developer.connectopensource.org/display/CONNECTWIKI/Asynchronous+M essaging+Engineering+Analysis http://developer.connectopensource.org/display/CONNECTWIKI/Asynchronous+M essaging+Engineering+Analysis Proposal: http://developer.connectopensource.org/display/CONNECTWIKI/Asynchronous+M essaging+Proposal http://developer.connectopensource.org/display/CONNECTWIKI/Asynchronous+M essaging+Proposal CONNECT Generic Deferred Messaging Design: http://developer.connectopensource.org/display/CONNECTWIKI/Generic+Asynchr onous+Communication http://developer.connectopensource.org/display/CONNECTWIKI/Generic+Asynchr onous+Communication CONNECT Patient Discovery Design: http://developer.connectopensource.org/display/CONNECTWIKI/Patient+Discover y+Service http://developer.connectopensource.org/display/CONNECTWIKI/Patient+Discover y+Service

13. Wrap up 13 QUESTIONS???