Asynchronous+Messaging+Feedback


 * Nationwide Health Information Network Implementer Feedback: Problems with Asynchronous Messaging **


 * **Specification** || **Update Status** ||
 * Patient Discovery || Complete ||
 * Document Submission || Complete ||
 * Messaging Platform || Complete ||

Problem Summary (Dated 3/25/2010)
**Background** The CONNECT development team has provided initial feedback to the Nationwide Health Information Network Specifcations Factory indicating that they are having severe difficulty implementing asynchronous messaging using WS-Addressing, specifically the use of the Reply-To element. Several important business cases require Nationwide Health Information Network services to support both synchronous and asynchronous messaging. Nationwide Health Information Network has adopted a number of IHE specifications which make use of WS-Addressing (a W3C standard) to support asynchronous messaging for several Nationwide Health Information Network services.  CONNECT has just completed an in-depth exercise to analyze the challenges posed by asynchronous messaging. Their detailed analysis is contained in a white paper on the CONNECT web site and includes a description of the problem along with a recommended solution.  []

In the CONNECT web service framework, long running transactions (hours-to-days) that result from a asynchronous request run the risk of tying up computer resources for the duration on the server until they have completed processing the request. This tying up of resources can lead to processing or performance issues with the responding gateway (ex processes pre-maturely timeout, thread starvation, performance degradation).
 *  Problem Summary **

CONNECT has asserted that three of the most popular open source web service frameworks for the Java platform, must be customized in order to utilize WS-Addressing to process a single asynch message (as is currently specified) without tying up recipient web services. Rather than require such customization, CONNECT has proposed that Nationwide Health Information Network modify its asynch specifications to use two separate two-way messages. The first would be the request and ACK and the second would be the response and ACK. Below is a link to a write-up of the CONNECT proposed solution: []
 *  CONNECT’s Proposed Solution **

A small group of Nationwide Health Information Network Spec Factory members reviewed the CONNECT white paper and engaged in discussion with its authors. Initial reaction was general agreement with CONNECT’s assessment of the difficulties in implementing asynch as specified and satisfying the requirement to accommodate very long transaction times. Further, the group also generally supported CONNECT’s proposed two message solution.  There were some concerns about the details of the proposed solution, specifically related to CONNECT’s avoidance of the Reply-To field. Further, there was some discussion of what web service framework customization is considered reasonable and questions as to whether CONNECT had explored all options. Spec Factory asked CONNECT to provide additional details regarding their proposed solution, elaborating the transaction message structure and mechanism so that the full Spec Factory could evaluate it. CONNECT will update the white paper to include these details by Friday, March 26th.
 * Initial Nationwide Health Information Network Spec Factory Review **

1) Is this problem significant enough to require a change to Nationwide Health Information Network specifications which may deviate from the adopted IHE specs? 2) Is this a problem for all Nationwide Health Information Network implementers, or is it specific to the CONNECT implementation? a. Must web service stacks be customized to accommodate Nationwide Health Information Network asynch? <span style="font-family: 'Arial','sans-serif';">b. Is it reasonable to expect implementers to customize? <span style="font-family: 'Arial','sans-serif';">3) Is the use of two separate two-way message the best solution? <span style="font-family: 'Arial','sans-serif';">a. Is the ReplyTo problem specific only to CONNECT? <span style="font-family: 'Arial','sans-serif';">b. Does the non-use of ReplyTo make sense for all implementers?
 * <span style="color: #365f91; font-family: 'Arial','sans-serif';"> Outstanding ****<span style="color: #365f91; font-family: 'Arial','sans-serif';">Questions to be ****<span style="color: #365f91; font-family: 'Arial','sans-serif';">Addressed **