The ZOO Service configuration file (.zcfg) describes the service and will be parsed by
the ZOO Kernel. We will describe here what such a file contains.
You can also take a look at the existing examples of ZCFG files in the cgi-env directory
of each services available in the ZOO-Project SVN source tree.
The fist part in a ZOO Configuration file contains the metadata information relative to the service.
Note that the “name of your service” between brackets on the first line has to be the exact same name
as the function you defined in your services provider code. In most cases, this name is also the name
of the ZCFG file without the “.zcfg” extension.
You can see below a description of the main metadata information:
| [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>
|
The list of outputs is very similar to a list of inputs except it is specified as a <DataOutputs> node.
A typical <DataOutputs> node looks like the following:
| <DataOutputs>
[Name of the output]
Title = Title of the output
Abstract = Description of the output
<Type Of Data Node />
</DataOutputs>
|
In the beginning of this ZCFG introduction, we spoke about “Type Of Data Nodes” to describe the data type of inputs and outputs.
You can define your data as:
Except for LiteralData, each Type Of Data node must have at least one <Default> and one <Supported> node. Even
if one of those are empty, it has to be present with an opening and closing tag on two different lines. So, something
like the following:
Otherwise, ZOO-Kernel won’t be able to parse your ZCFG and will fail to process requests.
A <LiteralData> node contains:
- one <Default> node,
- zero or more <Supported> nodes depending on the existence or the number of supported Units Of Measure (UOM), and
- a dataType property. The dataType property defines the type of literal data, such as a string, an interger and so on
(consult the complete list of supported data types).
<Default> and <Supported> nodes can contain the uom property to define which UOM has to be used for
this input value.
For input <LiteralData> nodes, you can add the value property to the <Default> node to define a default
value for this input. This means that, when your Service will be run, even if the input wasn’t defined, this default
value will be set as the current value for this input.
A typical <LiteralData> node, defining a float data type using meters or degrees for its UOM, looks like the
following:
| <LiteralData>
dataType = float
<Default>
uom = meters
</Default>
<Supported>
uom = feet
</Supported>
</LiteralData>
|
A <BoundingBoxData> node contains:
- one <Default> node with a CRS property defining the default Coordinate Reference Systems (CRS), and
- one or more <Supported> nodes depending on the number of CRS your service supports (note that you can
alternatively use a single <Supported> node with a comma-separated list of supported CRS).
A typical <BoundingBoxData> node, for two supported CRS (EPSG:4326
and EPSG:3785),
looks like the following:
| <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>
|
A ComplexData node contains:
- a <Default> node and
- one or more <Supported> nodes depending on the number of supported formats. A format is made up of this
set of properties : mimeType, encoding and optionaly schema.
For output ComplexData nodes, you can add the extension property to define what extension to use to name
the file when storing the result is required. Obviously, you’ll have to add the extension property to each
supported format (for the <Default> and <Supported> nodes).
You can also add the asReference property to the <Default> node to define if the output should be
stored on server side per default.
Note
the client can always modify this behavior by setting asReference attribute to true or false
for this output in the request ResponseDocument parameter.
You can see below a sample ComplexData node for default application/json and text/xml (encoded in UTF-8
or base64) mimeTypes support:
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>
|