Open WPS Platform

ZCFG : le fichier de configuration de service ZOO

Authors:Nicolas Bozon, Gérald Fenoy, Jeff McKenna
Last Updated:$Date: 2011-12-07 14:44:57 +0100 (Wed, 07 Dec 2011) $

Le fichier de configuration de service ZOO (.zcfg) deécrit le service et sera parsé par le Kernel ZOO. Nous décrirons ici ce qu’un tel fichier contient. Vous pouvez aussi jeter un oeil aux exemples existants de fichiers ZCFG dans le répertoire cgi-env de chaque service disponible dans l’arborescence des sources SVN du projet ZOO.

Un fichier de configuration ZOO est divisé en trois sections distinctes :

  1. Information de métadonnée principale

  2. Liste des Information de métadonnée en entrées

  3. Liste des Information de métadonnée en sorties

Note

Le fichier de configuration de service ZOO est sensible à la casse.

Information de métadonnée principale

La première partie d’un fichier de configuration ZOO contient l’information de métadonnée relative au service. Notez que le “name of your service” entre crochets sur la première ligne doit avoir un nom exactement le même que celui de la fonction que vous avez défini dans votre code de fournisseur de services. Dans la plupart des cas, ce nom est aussi le nom du fichier ZCFG sans l’extension “.zcfg”.

Vous pouvez voir ci-dessous une description de l’information de métadonnée principale:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
[Name of your service]
Title = Title of your service
Abstract = Description of your service
processVersion = Version number of your service
storeSupported = true/false
statusSupported = true/false
serviceType = the programming language used to implement the service (C/Fortran/Python/Java/PHP/Javascript)
serviceProvider = name of your services provider (shared library/Python Module/Java Class/PHP Script/JavaScript script)
<MetaData>
  title = Metadata title of your service
</MetaData>

Liste des entrées

La liste des entrées contient l’informations de métadonnée de chaque entrée supportée, et elles sont groupées en utilisant un noeud <DataInputs>.

Chaque entrée est définie comme :

  • un nom (entre crochets comme pour le nom du service avant)

  • diverse propriétés de métadonnée (Title, Abstract, minOccurs et maxOccurs)

  • un type de noeud de donnée (description)

Une liste d’entrées typique (<DataInputs>) ressemble à ce qui suit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<DataInputs>
  [Name of the first input]
    Title = Title of the first input
    Abstract = Abstract describing the first input
    minOccurs = Minimum occurence of the first input
    maxOccurs = Maximum occurence of the first input
    <Type Of Data Node />
  [Name of the second input]
    Title = Title of the second input
    Abstract = Abstract describing the second input
    minOccurs = Minimum occurence of the second input
    maxOccurs = Maximum occurence of the second input
    <Type Of Data Node />
</DataInputs>

Note

vous pouvez ajouter un noeud <MetaData> comme dans l’information de métadonnée principale.

Liste des sorties

TLa liste des sorties est très similaire à un liste d’entrées exceptée qu’elle est spécifiée comme un noeud <DataOutputs>.

Un noeud ``<DataOutputs>``typique ressemble à ce qui suit:

1
2
3
4
5
6
<DataOutputs>
  [Name of the output]
    Title = Title of the output
    Abstract = Description of the output
    <Type Of Data Node />
</DataOutputs>

Type de noeud de données

Au début de cette introduction sur les ZCFG, nous avons parlé du “Type de noeud de données” pour décrire le type de données des entrées et des sorties.

Vous pouvez définir votre donnée comme:

Excepté pour LiteralData, chaque noeud du type de donnée doit avoir au moins un noeud <Default> et un noeud <Supported>. Même si l’un d’eux est vide, il doit être présent avec un tag ouvrant et fermant sur deux différentes lignes. Donc, quelque chose comme ce qui suit:

1
2
<Default>
</Default>

Autrement, le ZOO-Kernel ne sera pas capable de parser votre ZCFG et échouera à traiter les requêtes.

Noeud LiteralData

Un noeud <LiteralData> contient:

  • une noeud <Default>,

  • zéro noeud <Supported> ou plus en fonction de l’existence ou du nombre d’unités de mesures (UOM), et

  • de la propriété dataType. La propriété dataType définit le type de la donnée litérale, comme une chaîne, un entier et ainsi de suite (consultez la liste complète des types de données supportées).

Les noeuds <Default> et <Supported> peuvent contenir la propriété ``uom``pour définir quel UOM (Unité de mesure) doit être utilisée pour cette valeur en entrée.

Pour des noeuds <LiteralData> en entrée, vous pouvez ajouter la propriété value au noeud <Default> pour définir une valeur par défaut pour cette entrée. Cela signifie que, quand votre service sera lancé, même si l’entrée n’a pas été définie, cette valeur par défaut sera définie comme la valeur courante pour cette entrée.

Un noeud <LiteralData> typique, définissant un type de donnée ``float``en utilisant des mètres ou des degrés pour ses UOM, ressemble à ce qui suit:

1
2
3
4
5
6
7
8
9
<LiteralData>
  dataType = float
  <Default>
    uom = meters
  </Default>
  <Supported>
    uom = feet
  </Supported>
</LiteralData>

Noeud BoundingBoxData

Un noeud <BoundingBoxData> contient:

  • un noeud <Default> avec une propriété CRS définissant le système de référence de coordonnées par défaut (CRS), et

  • un noeud <Supported> ou plus en fonction du nombre de CRS que votre service supporte (notez que vous pouvez alternativement utiliser un seul noeud <Supported> avec une liste séparée par des virgules des CRS supportés).

Un noeud <BoundingBoxData> typique, pour deux CRS supportés (EPSG:4326 et EPSG:3785), ressemble à ce qui suit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
<BoundingBoxData>
  <Default>
    CRS = urn:ogc:def:crs:EPSG:6.6:4326
  </Default>
  <Supported>
    CRS = urn:ogc:def:crs:EPSG:6.6:4326
  </Supported>
  <Supported>
    CRS = urn:ogc:def:crs:EPSG:6.6:3785
  </Supported>
</BoundingBoxData>

Noeud ComplexData

Un noeud ComplexData contient:

  • un noeud <Default> et

  • un ou plusieurs noeuds <Supported> en fonction du nombre de formats supportés. Un format est Un format est constitué de ce jeu de propriétés: mimeType, encoding et optionnellement schema.

Pour des noeuds ComplexData en sortie, vous pouvez ajouter la propriété extension pour définir quelle extension à utiliser pour nommer le fichier quand le stockage du résultat est requis. Evidemment, vous devrez ajouter la propriété extension à chacun des formats supportés (pour les noeuds <Default> et <Supported>).

Vous pouvez aussi ajouter la propriété asReference au noeud <Default> pour définir si la sortie doit être stockée sur la partie serveur par défaut.

Note

la client peut toujours modifier le comportement en configurant l’attribut asReference à true ou false pour cette sortie dans le paramètre ResponseDocument de la requête.

Vous pouvez voir ci-dessous un exemple de noeud ComplexData pour le support des mimeTypes par défaut application/json et text/xml (encodé en UTF-8 ou base64):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
<ComplexData>
  <Default>
    mimeType = application/json
    encoding = UTF-8
  </Default>
  <Supported>
    mimeType = text/xml
    encoding = base64
    schema = http://fooa/gml/3.1.0/polygon.xsd
  </Supported>
  <Supported>
    mimeType = text/xml
    encoding = UTF-8
    schema = http://fooa/gml/3.1.0/polygon.xsd
  </Supported>
</ComplexData>