VizieRResources < Projets

Problématique

Ressources VizieR

Il y a deux types de ressources sur VizieR : les tables de données astronomiques et les interfaces d'accès à ces tables. Actuellement ces deux types de ressources sont confondus en un seul type TabularSkyService. Un tel type contient à la fois les métadonnées décrivant la table elle-même (colonnes, UCD...) et les métadonnées décrivant les interfaces d'accès à cette table :

<interface xsi:type="vr:WebBrowser">
   <accessURL use="full">http://vizier.u-strasbg.fr/cgi-bin/VizieR-2?-source=VIII/16/mrcj2000</accessURL>
</interface>
<interface qtype="GET" xsi:type="vs:ParamHTTP">
   <accessURL use="base">http://vizier.u-strasbg.fr/viz-bin/votable/-dtd/-A?-source=VIII/16/mrcj2000</accessURL>
   <vs:resultType xmlns:vs="http://www.ivoa.net/xml/VODataService/v0.5">text/xml+votable</vs:resultType>
</interface>

Dans cet extrait nous pouvons voir que deux types d'interfaces sont décrites : la première nous renvoie sur la page Web permettant de choisir une requète sur la table et de préciser plusieurs paramètres (format de sortie...), et la deuxième nous retourne directement le contenu de la table dans un format arbirtaire qui est ici VoTable.

Cette approche n'est pas acceptable dans le sens où les métadonnées sur un certain type de service (une interface d'accès ici) sont intégrées à CHAQUE ressource VizieR de type table (il y en a plus de 11000...). De plus aucun paramètre que l'on pourrait passer à ce service n'est précisé : une URL arbitraire est données et c'est à l'application utilisant le registry de savoir comment utiliser le service.

Un problème plus général

En clair, nous pouvons dire qu'un service (e.g. une interface d'accès aux données VizieR) devrait être une ressoure à part entière dans laquelle nous pourrions décrire une URL de base, les paramètres possibles...etc. Cela enrichirait les possiblités d'utilisation d'un tel service par une application utilisant le registry. Par ailleurs au niveau d'une ressource de type "table de données" seule une reférence vers une ressource VO de type service serait nécessaire et il n'y aurait plus de redondance d'information. En effet les informations propres au service seraient décrites dans la ressource de ce type.

Actuellement le schéma d'une ressource VO ne propose pas de définition générique d'une application. Il ne propose que l'élément <interface> permettant de préciser une URL (d'un WSDL dans le cas d'un service Web). Ce problème général a été soulevé par Astrogrid, qui a décidé d'y remédier en créant l'environnement CEA.

L'exemple CEA d'Astrogrid

CEA (Common Execution Architecture) est un ensemble d'interfaces et schémas servant à modéliser la façon dont on peut exécuter des applications astronomiques au sein du VO. Il répond à un besoin précis au niveau du VO :

il faut un moyen de décrire une application générale, de façon générique (le schéma actuel d'une ressource VO ne le permet pas).
Ce moyen doit être d'un niveau d'abstraction supérieur au WSDL décrivant un service Web.

Voici les différents composants que l'on retrouve dans l'architecture CEA :

Application - implémente une action possible (extraction de données...)
CEC (Common Execution Controller) - composant servant d'interface entre l'application cliente et l'application
Application cliente (processus invoquant)
Monitoring service - le CEC peut envoyer des informations sur son statut à ce composant
Storage sercice
Results service

Un WSDL décrit l'interface du composant CEC : CEC WSDL. L'intérêt d'un WSDL unique et constant pour accéder à un composant CEC est que l'application cliente sait à l'avance comment requéter le CEC sans se soucier de l'application qu'il y a derrière.

Intégration au registry

Pour intégrer CEA au registry trois nouveaux types de ressources ont été définies :

cea:CeaApplicationType - décrit une application (paramètres...)
cea:CeaHttpApplicationType - décrit une application basée sur HTTP.
cea:CeaServiceType - décrit un service (son rôle est de lancer certaines applications).

La ressource de type cea:CeaApplicationType

Une ressource de type cea:CeaApplicationType contient, en plus des éléments standards d'une ressource VO, l'élément <cea:ApplicationDefinition>. Voici un exemple de contenu extrait de la ressource ivo://org.astrogrid/CDS.XMatch :

<vr:Resource xsi:type="cea:CeaApplicationType">
   ...
   <cea:ApplicationDefinition xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <cea:ApplicationKind>http</cea:ApplicationKind>
      <cea:Parameters>
         <cea:ParameterDefinition name="seuils" type="text">
            <ceapd:UI_Name>Thresholds</ceapd:UI_Name>
            <ceapd:UI_Description>thresholds[2] contains the 2 extreme search radii in arcsec (separated by a comma)</ceapd:UI_Description>
            <ceapd:Units>arcsec</ceapd:Units>
         </cea:ParameterDefinition>
         <cea:ParameterDefinition name="coordTab1" type="text">
            <ceapd:UI_Name>Table1 Position Columns</ceapd:UI_Name>
            <ceapd:UI_Description>arrays contaning indices of columns with position (e.g.{3,4} if RA and DEC are in columns 3 and 4 for Table1)</ceapd:UI_Description>
         </cea:ParameterDefinition>
         <cea:ParameterDefinition name="coordTab2" type="text">
            <ceapd:UI_Name>Table2 Position Columns</ceapd:UI_Name>
            <ceapd:UI_Description>arrays contaning indices of columns with position (e.g.{3,4} if RA and DEC are in columns 3 and 4 for Table1)</ceapd:UI_Description>
         </cea:ParameterDefinition>
         <cea:ParameterDefinition name="method" type="integer">
            <ceapd:DefaultValue>1</ceapd:DefaultValue>
            <ceapd:UI_Name>matching method</ceapd:UI_Name>
            <ceapd:UI_Description>is one of {bestMatch=1, allMatch=2, noMatch=4}, or a combination (or'ed) of these (e.g. bestMatch and noMatch =&gt; 5)</ceapd:UI_Description>
         </cea:ParameterDefinition>
         <cea:ParameterDefinition name="tab" type="VOTable">
            <ceapd:UI_Name>Input VOTable</ceapd:UI_Name>
            <ceapd:UI_Description>This VOTable file should contain two tables with the data to be cross matched</ceapd:UI_Description>
         </cea:ParameterDefinition>
            <cea:ParameterDefinition name="output" type="VOTable">
            <ceapd:UI_Name>Output VOTable</ceapd:UI_Name>
            <ceapd:UI_Description>The result of the cross match</ceapd:UI_Description>
         </cea:ParameterDefinition>
      </cea:Parameters>
      <Interfaces>
         <ceab:Interface name="simple">
            <ceab:input>---++++ La ressource _cea:CeaApplicationType_
               <ceab:pref ref="coordTab1"/>ceab:Interface
               <ceab:pref ref="coordTab2"/>
               <ceab:pref ref="methoUne d"/>
               <ceab:pref ref="tab"/>
            </ceab:input>
            <ceab:output>
               <ceab:pref ref="output"/>
            </ceab:output>
         </ceab:Interface>
      </Interfaces>
   </cea:ApplicationDefinition>
   ...
</vr:Resource>

On y retrouve la définition précise des paramètres acceptés par l'application (élément <cea:ParameterDefinition>), avec pour chacun d'eux des informations comme le nom, la description, le type, la valeur par défaut et l'UCD s'il y en a un qui est associé. La valeur de retour est également décrite dans cet élément.

L'élément <ceab:Interface> permet de décrire quels sont les paramètres à passer et dans quel ordre, et quel est le paramètre décrivant la valeur de retour. Par contre aucune URL d'accès n'est précisé, car dans l'architecture CEA c'est le "service" qui est accessible via une URL et qui peut invoquer une application.

Ainsi nous pouvons dire qu'avec ce nouveau type de ressource cea:CeaApplicationType nous disposons d'une description générique d'une application VO.

La ressource de type cea:CeaHttpApplicationType

Une ressource de type cea:CeaHttpApplicationType est une extension d'une ressource de type cea:CeaApplicationType servant à décrire les applications requétables par HTTP. Voici un exemple de contenu extrait de la ressource ivo://org.astrogrid/INTWideFieldSurveySIAP :

<vr:Resource xsi:type="cea:CeaHttpApplicationType">
   ...
   <cea:ApplicationDefinition xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <cea:ApplicationKind>http</cea:ApplicationKind>
      <cea:Parameters>
         <cea:ParameterDefinition name="POS" type="text">
            <ceapd:UI_Name>Position</ceapd:UI_Name>
            <ceapd:UI_Description>Comma separated position of centre of field RA,DEC in decimal degrees</ceapd:UI_Description>
            <ceapd:Units>String</ceapd:Units>
         </cea:ParameterDefinition>
         <cea:ParameterDefinition name="SIZE" type="text">
            <ceapd:UI_Name>Size</ceapd:UI_Name>
            <ceapd:UI_Description>Comma separated size of field RA,DEC in decimal degrees</ceapd:UI_Description>
            <ceapd:Units>String</ceapd:Units>
         </cea:ParameterDefinition>
         <cea:ParameterDefinition name="FORMAT" type="text">
            <ceapd:UI_Name>Format</ceapd:UI_Name>
            <ceapd:UI_Description>e.g. image/fits - see SIAP definition</ceapd:UI_Description>
            <ceapd:Units>String</ceapd:Units>
         </cea:ParameterDefinition>
         <cea:ParameterDefinition name="IMAGES" type="text">
            <ceapd:UI_Name>ImagesTable</ceapd:UI_Name>
            <ceapd:UI_Description>A VOTable of images</ceapd:UI_Description>
            <ceapd:Units>String</ceapd:Units>
         </cea:ParameterDefinition>
      </cea:Parameters>
      <cea:Interfaces>
         <ceab:Interface name="Standard">
            <ceab:input>
               <ceab:pref ref="POS"/>
               <ceab:pref ref="SIZE"/>
               <ceab:pref ref="FORMAT"/>
            </ceab:input>
            <ceab:output>
               <ceab:pref ref="IMAGES"/>
            </ceab:output>
         </ceab:Interface>
      </cea:Interfaces>
   </cea:ApplicationDefinition>
   <cea:CeaHttpAdapterSetup xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <ceab:URL>http://archive.ast.cam.ac.uk/cgi-bin/wfs-siap/queryImage</ceab:URL>
   </cea:CeaHttpAdapterSetup>
   ...
</vr:Resource>

Par rapport à une ressource de type cea:CeaApplicationType un élément en plus est présent : <cea:CeaHttpAdapterSetup>. Il permet de préciser l'URL servant à requéter l'application par HTTP directement, sans passer par un "service".

La ressource de type cea:CeaServiceType

Une ressource de type cea:CeaServiceType possède l'élément <interface> standard d'une ressource VO. Il précise comment accéder à ce service. En plus des éléments standards d'une ressource VO un élément <cea:ManagedApplications> est présent, permettant de lister par référence les applications que ce service peut invoquer. Voici un exemple de contenu extrait de la ressource ivo://org.astrogrid/RealHttpCEC :

<vr:Resource xsi:type="cea:CeaServiceType">
   ...
   <interface xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="vs:WebService">
      <accessURL use="full">http://zhumulangma.star.le.ac.uk:8080/astrogrid-cea-http-SNAPSHOT/services/CommonExecutionConnectorService</accessURL>
   </interface>
   <cea:ManagedApplications xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <cea:ApplicationReference>ivo://org.astrogrid/INTWideFieldSurveySIAP</cea:ApplicationReference>
      <cea:ApplicationReference>ivo://org.astrogrid/CDS.XMatch</cea:ApplicationReference>
   </cea:ManagedApplications>
   ...
</vr:Resource>

Ce service permet donc d'invoquer les applications ivo://org.astrogrid/INTWideFieldSurveySIAP et ivo://org.astrogrid/CDS.XMatch.

Finalement une application cliente désirant utiliser une application aura deux requètes à faire au niveau du registry :

rechercher la ressource VO de type cea:CeaApplicationType correspondant à l'application voulue.
rechercher la ressource VO de type cea:CeaServiceType capable d'invoquer l'application dont la première requète a permis d'obtenir l'identifiant VO.

-- BriceGassmann - 27 Jun 2005

Topic revision: r5 - 2005-06-29 - BriceGassmann

Account
- Log In
- Register User

Centre de Données astronomiques de Strasbourg

Edit
Attach