110 likes | 242 Views
Async XDS.b. Key Use Cases. Scenario 1 (on demand query): In the integrated Document Source/Repository configuration, the XDS.b document is retrieved from storage and persisted. Allowing for Async responses reduces the time that the Document Source is left hanging waiting for a response.
E N D
Key Use Cases • Scenario 1 (on demand query): In the integrated Document Source/Repository configuration, the XDS.b document is retrieved from storage and persisted. Allowing for Async responses reduces the time that the Document Source is left hanging waiting for a response. • Scenario 2: AsyncXDS.b allows for offline scenarios where actors are not simultaneously connected, making store-and-forward scenarios possible through the use of intermediaries.
Open Issues • How will asynchronous support be integrated into XDS.b, as a named option, required? • Should this be documented in the Web Services Appendix and referenced from transactions which can use it? • Should this apply to PIX, PDQ, QED, RFD, XDR? • Ensure that users of XDS are aware of this change and either explicitly state support of it, or not support of it. (PCC, XDS-I, ...) • Should this add new transactions for the async mode or follow the XDS.a practice of having two modes in one transaction? • Risk Assessment needed. Should WS-I Basic Security be referenced. What other security/privacy concerns need to be considered? • Is there a place for Reliable Messaging, In XDR? Do we need to restrict its use?
Open Issue #1 • How will asynchronous support be integrated into XDS.b, as a named option, or required? • Named option for XDS.b: Volume I will give it a name and will list it and describe it. • Required for XCA Gateway. • If an XDS.b actor supports one Async transaction, then it should support all of them (Async Actor or Sync Actor) • XDS.b Actors shall support Sync and optionally Async • For Repository Actor, a Sync Provide and Register must generate Sync Register • New XDS.b Supplement or update existing one? • Publish Async in a separate supplement
Open Issue #2 • Should this be documented in the Web Services Appendix and referenced from transactions which can use it? • The Web Services Appendix will be referenced from XDS.b transactions that will support this and will include language on the following: • Explain Async and Sync concepts • Explain potential issues when moving from Sync to Async • The fact that Async is not available for a transaction unless documented specifically within that transaction and associated Actors
Open Issue #3 • Should this apply to PIX, PDQ, QED, RFD, XDR? • Yes for: XDR (update XDR supplement), XCA (XCA Gateway shall implement Sync and Async) • No for: RFD (no change needed to documentation) • Should notify owners: QED • Requires further analysis and out of scope for this year: PIX and PDQ
Open Issue #4 • Ensure that users of XDS.b are aware of this change and either explicitly state support of it, or not support of it. (XDS-I, ...) • Co Chair responsibility
Open Issue #5 • Should this add new transactions for the Async mode or follow the XDS.a practice of having two modes in one transaction? • Teddy will pick one option for comments
Open Issue #5Naming and Representation Provide and Register Document Set-b [ITI-41] Document Source Document Repository Current Provide and Register Document Set-b ? Document Source Document Repository Updated Provide and Register Document Set-b ?
Open Issue #6 • Risk Assessment needed. Should WS-I Basic Security be referenced. What other security/privacy concerns need to be considered? • Risk assessment needed • Will be discussed in next f2f in May • Conf call before f2f meeting to prep
Open Issue #7 • Is there a place for Reliable Messaging, In XDR? Do we need to restrict its use? • IHE will not profile reliable messaging this year.