| [news.eclipse.technology.ohf] Re: XCA with NIST's public registry |
thanks, Jesse
Jesse Pangburn wrote:
Hi Matt,
My impression is that Bill's xdstest2 tool connects directly to the receiving gateway. For Bill, it was probably a pretty easy thing to add to the existing reg/repo- it looks just like the regular requests that the reg/repo would be receiving. The xdstest2 tool also has an easy job, send one cross gateway action, no real need to correlate and do all that since it's only talking to one receiving gateway.
So he would have no need to make a full fledged initiating gatway. Yes, it would be worth checking with HXTI. I have emailed them before, but having trouble locating it. I'll take another look.
thanks, Jesse
Matthew Davis wrote:
Jesse, good call - you're absolutely right that, across the wire, the transactions look the same but with different WS-A actions.
Ok, so I'm not sure how to proceed or why Bill didn't implement an initiating gateway. That would seem important for testing XCA Receiving Gateways in MESA. It might be worth checking with HXTI. At one point their XCA init gateway was public, but that was back during HIMSS testing.
-Matt
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Important_URLs_.2F__WS_EndpointsJesse Pangburn wrote:Hi Matt,
I've read more on this and done some testing. From the XCA spec:
"The scope of the Cross Gateway Query transaction is based on the Registry Stored Query transaction [ITI-18]."
and
"The scope of the Cross Gateway Retrieve transaction is semantically the same as the Retrieve Document Set transaction [ITI-43]."
So a Cross Gateway Query looks just like a Registry Stored Query and a Cross Gateway Retrieve looks just like Retrieve Document Set, hence the WSDL showing the same elements.
Knowing this, I tried to use the bridge and NIST URLs but got an error:
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>soapenv:Sender</soapenv:Value>
<soapenv:Subcode>
<soapenv:Value>wsa:ActionNotSupported</soapenv:Value>
</soapenv:Subcode>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text xml:lang="en-US">The [action] cannot be processed at the receiver.</soapenv:Text>
</soapenv:Reason>
<soapenv:Detail>
<wsa:ProblemAction>
<wsa:Action>urn:ihe:iti:2007:RegistryStoredQuery</wsa:Action>
</wsa:ProblemAction>
</soapenv:Detail>
</soapenv:Fault>
Clearly it doesn't like the WS:Action parameter contents. On the xds implementers mailing list, an email came 7/9/2008 saying this:
*****************
I have updated the Public Registry and the xdstest2 tool (creating version 01_20) to fix a problem with the XCA implementation. Both the server and the toolkit were issuing and expecting WS:Action values as defined in the XDS specification instead of the values defined in the XCA specification for XCA transactions. The correct values of WS:Action for XCA are: Retrieve: Request is urn:ihe:iti:2007:CrossGatewayRetrieve Response is urn:ihe:iti:2007:CrossGatewayRetrieveResponse
Query: Request is urn:ihe:iti:2007:CrossGatewayQuery Response is urn:ihe:iti:2007:CrossGatewayQueryResponse
*****************
I checked the WSDL though and the action specified there is the XDS.b one, so I'm guessing the WSDL is not showing that properly?
So the NIST implementation appears to be a receiving gateway only and it expects the WS:Action to indicate that the transaction is a cross gateway transaction (going by Bill's email and not the WSDL). An initiating gateway would expect its transactions received to be just like what goes to a registry/repository and would have the normal XDS.b WS:Action values.
So basically it seems to me now that we need an initiating gateway configured to point to NIST's receiving gateway and we then connect the bridge to the initiating gateway. I remember at HIMSS that HXTI was working on XCA, I wonder if they have a public implementation?
thanks, Jesse
Matthew Davis wrote:
Jesse,
Yeah the Bridge is only running an XCA scenario as a Document Consumer. It doesn't participate in any XCA transactions (Cross Gateway Query/Receive). It can only talk to an initiating gateway that's implementing the query/retrieve WS interfaces.
-Matt
added
Actually, Jesse, are you sure NIST doesn't support initiating gateway? when i look at the wsdl (http://129.6.24.109:9080/axis2/services/rg?wsdl) I see RetrieveDocumentSet and AdHocQueryRequest in the list of WS Operations.
Jesse Pangburn wrote:Hi Matt,
So I was thinking to try this out, but my confusion is that I think a piece is missing. My understanding was that XCA looked something like this:
xds consumer -> XCA initiating gateway -> XCA receiving gateway 1
-> XCA receiving gateway 2
-> XCA receiving gateway n
The initiating gateway then gathers up the results from all the receiving gateways and returns it in one cohesive response to the xds consumer actor. So as I understand it the bridge would be acting as the xds consumer that knows how to talk to an XCA initiating gateway, right? However, NIST implements an XCA receiving gateway only- as far as I can see.
So we're missing the initiating gateway in any testing scenario involving NIST right? Or is the bridge sending the Cross Gateway Query and Cross Gateway Receive transactions directly?
thanks, Jesse
Matthew Davis wrote:
Jesse,
The Bridge... not exactly tested on XCA yet. Ha ha. I'd like to spend some time in the next month playing with Bill's implementation, it would be good for the mind (and soul) for us to validate that the paradigms even come close to working. I think our friends at Sage or Wellogic tested XCA at HIMSS and it worked - but I'm sure it wasn't extensive.
I don't believe that a GetDocumentQuery in the Bridge can carry over the homeCommunityId yet. That's something that definitely needs to be added (something I totally forgot about). All other types of XCA should be supported - find documents query, retrieve document set - should work with XCA.
-Matt
Sarah Knoop wrote:Ah that list ----
Correct - no we have not tested with this -- but we can sure try. Second - the bridge does not implement either gateway so it needs to connect to an initiating gateway. We have XCA support (to the extent documented, ie management of the homeCommunityId) on our XDS.b consumer -- and I believe this is made invokable at the bridge level via the rhio config when you set an xca gateway id (and endpoints) for a rhio. Matt would have more insight - but I don't think, yet, we allow for a stored query to be directed at a gateway via the bridge. The retrive document set in the bridge uses the underlying java plugin algorithm that gives precidence to retriving the document set via the gateway, when this bit of information is present.
- Sarah
Jesse Pangburn wrote:Hi Sarah,
If you mean NIST did not implement one at Connecathon, that's true. However, Bill has been working on a receiving gateway integrated with his registry. Are you on the ihe-xds-implementers google group? I've gotten the occasional posting about it on that list.
there's a link to the urls for the endpoints.
So in any case, it seems from your answer that no, you guys have not tested with it :-) Anyone else?
Is the bridge acting as an initiating gateway? Or does it need an initiating gateway to talk to which would then turn around and talk to NIST's receiving gateway?
thanks, Jesse
Sarah Knoop wrote:
Good question ... To my knowledge, NIST did not implement an XCA Gateway, making it difficult for anyone to test an XCA-enabled XDS.b Consumer. The profile also faced a fair number of CPs this year around the expectations/handling of homeCommunityId - so that should shape things for this next round, albeit experimental - perhaps not so 'highly experimental' :-)
- Sarah
Jesse Pangburn wrote:
Hi,
Have you guys tried the bridge XCA code with NIST's public registry? I have not yet but was curious if you guys had, or if there's been any work on it since the "highly experimental" stage it was in at US Connectathon 2008?
thanks, Jesse