Home » Archived » OHF » XCA with NIST's public registry
| |
| Re: XCA with NIST's public registry [message #45876 is a reply to message #45847] |
Mon, 18 August 2008 18:25   |
 Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
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.
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
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
>>
|
|
|
| Re: XCA with NIST's public registry [message #45908 is a reply to message #45876] |
Mon, 18 August 2008 23:42 |
No real name
Messages: 292
Registered: July 2009 |
Senior Member |
|
|
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.
> http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
> 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
>>>
>
>
|
|
|
| Re: XCA with NIST's public registry [message #45993 is a reply to message #45908] |
Tue, 19 August 2008 17:11 |
Matthew Davis
Messages: 269
Registered: July 2009 |
Senior Member |
|
|
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.
>> http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>> 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
>>>>
>>
>>
|
|
|
| Re: XCA with NIST's public registry [message #46013 is a reply to message #45993] |
Tue, 19 August 2008 19:02 |
Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
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.
>>>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>> 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
>>>>>
>>>
>>>
|
|
|
| Re: XCA with NIST's public registry [message #46070 is a reply to message #46013] |
Tue, 19 August 2008 23:44 |
Matthew Davis
Messages: 269
Registered: July 2009 |
Senior Member |
|
|
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.
> http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>
>>>> 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
>>>>>>
>>>>
>>>>
>
>
|
|
|
| Re: XCA with NIST's public registry [message #46190 is a reply to message #46070] |
Wed, 20 August 2008 14:21 |
Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
Hi Matt,
I don't know for sure one way or the other if they support initiating
gateway or not. At this url
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
they describe the endpoints as a Receiving Gateway and the several emails
I've seen about it also called it a Receiving Gateway so I had just
assumed. Judging from the WSDL though, looks like I was wrong, which is a
good thing for testing purposes :-)
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.
>>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>
>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>
>>
|
|
|
| Re: XCA with NIST's public registry [message #46220 is a reply to message #46070] |
Wed, 20 August 2008 17:25 |
Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
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.
>>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>
>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>
>>
|
|
|
| Re: XCA with NIST's public registry [message #46281 is a reply to message #46220] |
Wed, 20 August 2008 23:06 |
Matthew Davis
Messages: 269
Registered: July 2009 |
Senior Member |
|
|
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
Jesse 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.
>>>
> http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>
>>>
>>>>>> 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
>>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>
>
|
|
|
| Re: XCA with NIST's public registry [message #46620 is a reply to message #46281] |
Thu, 21 August 2008 22:32 |
Eclipse User |
|
|
|
Originally posted by: jpangburn.healthvision.com
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
> Jesse 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.
>>>>
>>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>
>>>>
>>>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: XCA with NIST's public registry [message #46760 is a reply to message #46620] |
Tue, 26 August 2008 14:04 |
| Eclipse User |
|
|
|
Originally posted by: jpangburn.healthvision.com
Hi,
I contacted HXTI and they do not have their XCA endpoints publicly
available. They said they will be making them available in the fall but
no plans to put them up in the short term.
So at this point with no initiating gateway I think we're out of luck for
testing XCA unless someone else steps up with one.
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
>> Jesse 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.
>>>>>
>>>
>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>>
>>>>>
>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
|
|
| |
| Re: XCA with NIST's public registry [message #586813 is a reply to message #45847] |
Mon, 18 August 2008 18:25 |
Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
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.
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
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
>>
|
|
|
| Re: XCA with NIST's public registry [message #586827 is a reply to message #45876] |
Mon, 18 August 2008 23:42 |
No real name
Messages: 292
Registered: July 2009 |
Senior Member |
|
|
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.
> http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
> 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
>>>
>
>
|
|
|
| Re: XCA with NIST's public registry [message #586863 is a reply to message #45908] |
Tue, 19 August 2008 17:11 |
Matthew Davis
Messages: 269
Registered: July 2009 |
Senior Member |
|
|
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.
>> http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>> 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
>>>>
>>
>>
|
|
|
| Re: XCA with NIST's public registry [message #586873 is a reply to message #45993] |
Tue, 19 August 2008 19:02 |
Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
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.
>>>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>> 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
>>>>>
>>>
>>>
|
|
|
| Re: XCA with NIST's public registry [message #586897 is a reply to message #46013] |
Tue, 19 August 2008 23:44 |
Matthew Davis
Messages: 269
Registered: July 2009 |
Senior Member |
|
|
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.
> http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>
>>>> 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
>>>>>>
>>>>
>>>>
>
>
|
|
|
| Re: XCA with NIST's public registry [message #586944 is a reply to message #46070] |
Wed, 20 August 2008 14:21 |
Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
Hi Matt,
I don't know for sure one way or the other if they support initiating
gateway or not. At this url
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
they describe the endpoints as a Receiving Gateway and the several emails
I've seen about it also called it a Receiving Gateway so I had just
assumed. Judging from the WSDL though, looks like I was wrong, which is a
good thing for testing purposes :-)
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.
>>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>
>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>
>>
|
|
|
| Re: XCA with NIST's public registry [message #586962 is a reply to message #46070] |
Wed, 20 August 2008 17:25 |
Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
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.
>>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>
>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>
>>
|
|
|
| Re: XCA with NIST's public registry [message #586985 is a reply to message #46220] |
Wed, 20 August 2008 23:06 |
Matthew Davis
Messages: 269
Registered: July 2009 |
Senior Member |
|
|
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
Jesse 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.
>>>
> http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>
>>>
>>>>>> 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
>>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>
>
|
|
|
| Re: XCA with NIST's public registry [message #587115 is a reply to message #46281] |
Thu, 21 August 2008 22:32 |
Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
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
> Jesse 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.
>>>>
>>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>
>>>>
>>>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: XCA with NIST's public registry [message #587166 is a reply to message #46620] |
Tue, 26 August 2008 14:04 |
Jesse Pangburn
Messages: 166
Registered: July 2009 |
Senior Member |
|
|
Hi,
I contacted HXTI and they do not have their XCA endpoints publicly
available. They said they will be making them available in the fall but
no plans to put them up in the short term.
So at this point with no initiating gateway I think we're out of luck for
testing XCA unless someone else steps up with one.
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
>> Jesse 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.
>>>>>
>>>
>
http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Import ant_URLs_.2F__WS_Endpoints
>>>
>>>>>
>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>
>>>
|
|
|
Goto Forum:
Current Time: Thu Dec 12 16:43:37 GMT 2024
Powered by FUDForum. Page generated in 0.31775 seconds |