-------- Original Message --------
Subject: Re: [astro-runtime-users] Using the AstroRuntime against NVO
registry
Date: Fri, 15 Jun 2007 17:42:11 +0100
From: KevinBenson <kmb@...>
Organization: Mullard Space Science Laboratory, UCL
To: Juan de Dios Santander Vela <jdsant@...>
CC: Astro Runtime Users <astro-runtime-users@...>
References: <AB76D07F-E142-4FA2-9CC5-F34902D7DC2E@...>
<784CCA22-72C4-4B1D-B88F-90B42161137F@...>
<BFE0912F-4DE0-4AC8-ABCA-C3F92EB87EFC@...>



I placed one comment right above the error-stacktrace. (may not be able
to respond to anymore replies till tomorrow).

Also here are a few endpoints you might be interested in:
Canivore-NVO:
I believe this site has recently been updated and if I recall from Ray
might be the main Registry that will be pushed to NVO users. I just
noticed it has Xquery that could be nice to try.
http://nvo.caltech.edu:8080/carnivore/
Service endpoints:
http://nvo.caltech.edu:8080/carnivore/ws

ESA:
http://esavo.esa.int/registry
see: http://esavo.esa.int/registry/services or endpoint for searching:
http://esavo.esa.int/registry/services/RegistrySearch

Astrogrid:
http://galahad.star.le.ac.uk:8080/astrogrid-registry/services/RegistryQuery

Registry that even supports 1.0 (though there is not much 1.0 data if
you look at the jsp pages be sure to change the Contract version to
0.1-0.10 in the menu link to see most of the current 0.10 Resource content)
http://msslxv.mssl.ucl.ac.uk:8080/mssl-registry/
(endpoint for searching)
http://msslxv.mssl.ucl.ac.uk:8080/mssl-registry/services/RegistryQuery
(Since I work at MSSL I tend to more quickly install the latest version
on this registry before galahad gets updated).

And there are a few more Full Astrogrid Registries I know of as well, if
your interested.

cheers,
Kevin

Juan de Dios Santander Vela wrote:
> El 15/06/2007, a las 17:12, Noel Winstanley escribió:
>
>> It may be best to continue much of this discussion on
>> astro-runtime-users@... and off the apps@... list -
>> my understanding is that the apps@... list is more for standards
>> development than user support (however, I'm willing to be corrected
>> on this ;) ). However, some of it does seem relevant to
>> registry@... too.
>
> First, thanks to Tony Linde for bringing this discussion into
> astro-runtime-users, for which I've already registered. I've dropped
> apps@..., but I think that at this stage my questions don't
> belong to registry@....
>
>> On 15 Jun 2007, at 15:19, Juan de Dios Santander Vela wrote:
>>
>>> My problem is that if I try to recover how many SSA services exist,
>>> I obtain just 14 --with some of them not properly working--, but if
>>> I query the NVO, I get as many as 22.
>>>
>>
>> ok. I can confirm this - I did the following in python (xmlrpc
>> interface to AR). [...]
>
> Yes, in fact I'm prototyping functionality in Python, then porting it
> into Java; it helps me better understand things... and test them faster.
>
>> As for some of these services not properly working - this is a pity,
>> and rather out of our control - it is up to the individual service
>> providers to correct.
>
> Yes, I know it's the fault of not proper registry entry curation. I'll
> try to use VoMon in order to assess if a service is really working.
>
>> You see the same behaviour when querying for spectra in AstroScope.
>> Once the new registry schema (1.0) gets deployed, we should be able
>> to use the new 'validationLevel' attribute to filter out the
>> low-quality services.
>
> That's really interesting. Is there an approximate timeframe for that?
>
>> As for the missing services - It's possible that the default
>> astrogrid registry (which AstroRuntime queries against by default)
>> isn't harvesting all that it should.
>>
>> Can you give me details of which NVO registry you're looking at? Then
>> we can make sure that the astrogrid registry is synchronized with it.
>
> Well, I just was able to query the NVO registry through their website:
>
>
<http://nvo.stsci.edu/VORegistry/QueryRegistry.aspx?startres=-1&advanced=true&sq\
l=ResourceType%20like%20'REGISTRY'>
>
>
> (by the way, results have gone down to 21)
>
> Clicking on NVO Developer info
> <http://nvo.stsci.edu/VORegistry/develop.aspx>, "SEARCH services"
> <http://nvo.stsci.edu/VORegistry/registry.asmx>, I get to a page with
> WSDL-described web services. I can use the web to call QueryService,
> for instance, but if I do something like:
>
> >>> endpoint="http://nvo.stsci.edu/VORegistry/registry.asmx" # or
> >>>
> endpoint="http://nvo.stsci.edu/VORegistry/registry.asmx?op=QueryRegistry"
> >>> query = "Select * from Registry where @xsi:type like
> '%SimpleSpectrumAccess%' or @xsi:type like '%SSA%'"
> >>> ar.ivoa.externalRegistry.adqlsQuery(endpoint, query)
I believe you do have the right endpoint for stsci.
If I recall from a very long time ago .Net relies on the SOAPAction and
I suspect we are not sending the SoapAction in the soap request or the
SoapAction is not correct (it could be stsci not having the SoapAction
correct as well). The other registries are usually using Axis or Xfire
and is not relying on the SoapAction. I will flag this up and try to
experiment next week on this endpoint.
>
> I get an exception; using the AR's web interface it gives a 500 error:
>
> HTTP ERROR: 500
>
> Exception thrown when calling method adqlsSearch
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav\
a:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:252)
>
> at
> org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:198)
>
> at
>
org.astrogrid.desktop.modules.system.HtmlServlet.callMethod(HtmlServlet.java:255\
)
>
> at
>
org.astrogrid.desktop.modules.system.AbstractReflectionServlet.navigate(Abstract\
ReflectionServlet.java:93)
>
> at
>
org.astrogrid.desktop.modules.system.AbstractReflectionServlet.doPost(AbstractRe\
flectionServlet.java:173)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
> at
> org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:665)
>
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:569)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
> at org.mortbay.http.HttpContext.handle(HttpContext.java:1434)
> at org.mortbay.http.HttpServer.service(HttpServer.java:896)
> at org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
> at
> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:831)
> at
> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:242)
> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:366)
> at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
> Caused by: org.astrogrid.acr.ServiceException: Registry Service
> Response:Server did not recognize the value of HTTP Header SOAPAction: .
> at
>
org.astrogrid.desktop.modules.ivoa.StreamingExternalRegistryImpl.adqlxSearchStre\
am(StreamingExternalRegistryImpl.java:215)
>
> at
>
org.astrogrid.desktop.modules.ivoa.StreamingExternalRegistryImpl.adqlxSearch(Str\
eamingExternalRegistryImpl.java:182)
>
> at
>
org.astrogrid.desktop.modules.ivoa.StreamingExternalRegistryImpl.adqlsSearch(Str\
eamingExternalRegistryImpl.java:162)
>
> at
>
$ExternalRegistryInternal_1132fb1c957.adqlsSearch($ExternalRegistryInternal_1132\
fb1c957.java)
>
> at
>
$ExternalRegistryInternal_1132fb1c8f5.adqlsSearch($ExternalRegistryInternal_1132\
fb1c8f5.java)
>
> ... 23 more
>
> So, I guess this is not the correct way to specify a SOAP endpoint ;-)
>
>> I should hope the AR would work with any IVOA-standard registry.
>> However, you need to be aware that many registries do not implement
>> the XQuery extensions - and only support keyword or adql-based
>> querying. Again, I hope that the registry upgrade will lead to better
>> descriptions of what functionalites each registry supports.
>>
>> If you could give me the endpoint for the NVO registry you're using,
>> I'll give it a try myself.
>
> Just as above:
>
> NVO Registry SOAP Services:
> <http://nvo.stsci.edu/VORegistry/registry.asmx>
> NVO Registry Web Page:
>
<http://nvo.stsci.edu/VORegistry/QueryRegistry.aspx?startres=-1&advanced=true&sq\
l=ResourceType%20like%20'REGISTRY'>
>
>
>>> b) Not being able to select whether a registry query uses a REST
>>> end-point or
>>> a SOAP one?
>>
>> the IVOA has only standardized a SOAP interface to registries. Rest
>> is a good idea, but not standard. Now, if there's sufficient demand
>> (and stability) of this interface, I've no objection to adding it to
>> AstroRuntime eventually....
>
> My guess was that the AR was making a REST call. If the AR queries
> SOAP registries, maybe the registry endpoint is buried somewhere else...
>
>>> ps. While the Registry of Registries gets developed, is there any
>>> "registry" that can be considered "the canonical registry", at least
>>> for practical reasons?
>>
>> I don't know the answer to this one. I guess within the UK, we
>> consider our registry in Leicester to be the 'uk canonical' registry.
>> Maybe Kevin can give a fuller answer to this.
>>
>> Note that the RofR is only an 'index' of other registires - it does
>> not contain any other kind of resources - so, for example, you can't
>> use it to query for spectra services, only for other registries.
>
> Yes, but it would provide the usable endpoints for those registries,
> right?
>
> Best regards, and thanks for your help!
>
> --Juan de Dios Santander Vela
> Diplomado en CC. Físicas, Ingeniero en Electrónica
> Doctorando en Tecnologías Multimedia
> Becario Predoctoral del Instituto de Astrofísica de Andalucía
>
> Groucho Marx: En las fiestas no te sientes jamás; puede sentarse a tu
> lado alguien que no te guste.
>
_______________________________________________
astro-runtime-users site list
astro-runtime-users@...
http://lists.astrogrid.org/mailman/listinfo/astro-runtime-users



--
=================================================================
Chenzhou Cui
National Astronomical Observatory | Tel: (8610)64872500
Chinese Academy of Sciences | FAX: (8610)64878240
Datun Road 20A, Chaoyang District | Email: ccz@...
Beijing 100012, China | WWW: www.lamost.org/~cb
=================================================================