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.
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:
| [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>
|
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:
| <DataOutputs>
[Name of the output]
Title = Title of the output
Abstract = Description of the output
<Type Of Data Node />
</DataOutputs>
|
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:
Autrement, le ZOO-Kernel ne sera pas capable de parser votre ZCFG et échouera à traiter les requêtes.
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:
| <LiteralData>
dataType = float
<Default>
uom = meters
</Default>
<Supported>
uom = feet
</Supported>
</LiteralData>
|
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:
| <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>
|
Un noeud ComplexData contient:
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>
|