• Mailing-list : http://lists.eogeo.org/pipermail/wms-dev/

Ce document est constitué de plusieurs parties. Il s'agit ici de décrire les standards WebServices de l'OGC. Dans une première partie, plus générale, je décrirai ce qu'est un WebService, pourquoi devrait on les utiliser, à quoi sert l'OGC et son fonctionnement. Je donnerai ensuite quelques exemples de liens de WebService francophone et anglophone. Ensuite, je proposerai un certain nombre de logiciels client et serveur qui gère les standards de l'OGC.

Dans une seconde partie, spécifique aux standards, je décrirai les WebServices proposés (principalement par l'OGC) avec quelques exemples de configuration pour un serveur (Mapserver UNN, Geoserveur, deegree, etc.). Cette partie sera séparée en deux sections qui contiendra les standards publiés pour la première section et les standards en discussion pour la deuxième section.

«Un Service Web est un programme informatique permettant la communicaction et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués. Il s'agit donc d'un ensemble de fonctionnalités exposées sur Internet ou sur un Intranet, par et pour des applications ou machines, sans intervention humaine, et en temps réel.¹⁾». En géomatique un WebService propose un Service qui va permettre la prise en charge distante de données, soit pour l'affichage simple de carte (WMS), soit pour du stockage de données (WCS et WFS) soit pour du traitement distant pour éviter d'utiliser du temps d'utilisation du processeur et de la mémoire.

En d'autre terme, une requête est effectuée à un serveur distant qui va réaliser la requête et renvoyer sa réponse sous forme de fichier XML, voire dans certain cas particulier un fichier image. Ces serveurs fonctionnent d'une manière équivalente à tout serveur : HTTP, SMTP, … Plusieurs étapes sont nécessaires pour obtenir ce que l'on veut. Par exemple lors d'un envoi d'un mail, notre client va contacter le serveur d'envoi de mail (SMTP, le contact se fait par envoie d'une requête HELO ²⁾), puis lui envoyer les données (l'adresse de l'expéditeur, puis l'adresse de destination et enfin le mail).

Un autre exemple pris dans la vie réelle est l'exemple du bar. Lorsque vous voulez boire un verre, vous vous déplacez dans un bar, demandez la carte au serveur, vous lui posez des questions sur les boissons puis vous commandez votre commande. Nous retrouvons chacune des ces étapes dans un webservice, comme nous le verrons plus tard.

Du côté des services spatiaux, notre client envoit une requête pour connaitre les possibilités du serveur (GetCapabilities), il peut demander une description supplémentaire pour une couche particulière puis demande les données, le traitement, (GetMap ou GetFeatureInfo dans le cas d'un WMS). Après chaque requête le client reçoit une réponse sous forme de fichier XML ou image dans le cas des WebService de l'OGC.

En géomatique, un WebService est un service qui propose des cartes (WMS, WTS), des données brutes (WFS, WCS, GML, GeoRSS), des données sur les données ou méta-données (CAT), des informations sur la sémiologie (SLD), sur les données d'une carte (WMC), etc.

Lorsque l'on parle de webservice, on parle rapidement de standard, de norme et d'intéropérabilité. Il est important de connaître les différences et la signification de ces termes.

«Standard signifie aussi « norme » en anglais. Les anglophones ne possédant qu'un seul mot pour désigner deux concepts différents, les traductions des textes anglais sont souvent sources de confusion. C'est ainsi que le mot standard est fréquemment utilisé dans le sens de norme en informatique (anglicisme). On parle souvent de standard ouvert lorsque le standard répond à certains critères d'accessibilité et de gouvernance.

En langue française, un standard peut être défini par n'importe quel organisme privé (produit standard), puis faire l'objet d'un processus de normalisation effectué dans le cadre d'un organisme public. Le standard devient alors une norme. Il existe des normes obligatoires aussi bien que des normes optionnelles que personne n'utilise. Un standard est toujours lié à une réalisation. Lorsqu'un standard s'est largement répandu, on parle alors de “standard de fait”.»³⁾

D'après Gordon Bell (Microsoft) et Rob Gingell (Sun Microsystems), un standard :

1. Précise des points d'homogénéité, autorisant toute variété et toute innovation sur les points non spécifiés.
2. Se fonde par principe sur une spécification, pas une implémentation.
3. Importe plus que pour ce qu'il apporte à son utilisateur que par ses qualités propres.
4. Concerne et n'est censé affecter que la communauté qui y adhère.
5. Ne vaut que par l'efficacité de l'organisme qui confère les certifications à ce standard.
6. Ne doit pas, pour être adopté, « du passé faire table rase »
7. Doit laisser une place adéquate aux innovations futures
8. Disparaît quand il devient un obstacle à l'innovation au lieu d'en être une plateforme.

Les standards de l'OGC sont normalisé par l'ISO.

«L'interopérabilité est la capacité que possède un produit ou un système dont les interfaces sont intégralement connues à fonctionner avec d'autres produits ou systèmes existants ou futurs.

Il convient de distinguer 'interopérabilité et 'compatibilité'. Pour être simple, on peut dire qu'il y a compatibilité quand deux produits ou systèmes peuvent fonctionner ensemble et interopérabilité quand on sait pourquoi et comment ils peuvent fonctionner ensemble. Autrement dit, on ne peut parler d'interopérabilité d'un produit ou d'un système que si on en connaît intégralement toutes ses interfaces.[..]

Un exemple de systèmes interopérables est le téléphone. Toutes les interfaces sont des normes gérées par l'UIT-T. On peut ainsi téléphoner sans se soucier de la marque de téléphone de son correspondant ni des matériels utilisés par les différents opérateurs.»⁴⁾

L'intéropérabilité permet ainsi une meilleure communication entre les différentes briques logiciels : client, serveur, à source ouverte ou propriétaire. Elle peut être considéré comme une langue universelle. Ainsi dans le monde réelle, nous trouvons des personnes qui parlent en anglais, d'autres en français, allemand, italien. La communication se fait mal, certaines personnes sont bilingues mais ce n'est jamais parfait. Une langue universelle, connu et surtout parlé de tous, simplifie la communication.

L'apport des webservice peut être classé en trois catégories :

• mutualisation des compétences : travail collaboratif ;
• mutualisation des données : utilisation de données communes à l'ensemble des utilisateurs, plutôt que de copier des répertoires sur chaque poste ;
• mutualisation des ressources : décharger les ressources sur un serveurs commun pour éviter d'acheter x poste très puissant et souvent onéreux pour chaque géomaticien.

Le fait que les webservices soient des standards apporte aussi une interopérabilité client-serveur, et une intéropérabilité historique. Vous pouvez migrer vos serveurs et vos clients d'une manière asynchrone : la transition sera plus fluide et donc moins problématique.

Vous pouvez également coupler vos webservices avec différents clients : client lourd (arcgis, mapinfo, grass), client léger (udig, gvSIG, QGIS), webmapping (openlayers et ses dérivées mapfish, mapbender, mapbuilder, développement personnel, etc.).

Ainsi vous éviter de multiplier les serveurs de données évitant des problèmes de gestion (quelle serveur a quelle version de donnés ?)

Cela permet également des mapshup entre les différents services d'une société (services environnement, service production, service …), entre différentes sociétés (ou collectivités bien sur), etc.

La question pourrait aussi se poser à l'envers, pourquoi ne faut il pas proposer de webservice ? Si vos données évolues très peu, que vous ne voulez pas ou pouvez pas proposer ce genre d'infrastructure (coût, compétence).

Plusieurs architectures réseaux peuvent être mises en place. Chaque architecture répondra à une problématique, mais ce qu'il faut comprendre est que les webservices permettent de s'adapter facile et de faire évoluer l'architecture en souplesse.

Il est possible de connaitre les logiciels en fonction des Web Service qu'ils implémentent à cette page : http://www.opengeospatial.org/resource/products/byspec/?specid=32

Les logiciels proposant un service par Internet :

• Mapserver
• GeoServer
• QGIS
• PyWPS
• deegree (Web Services, iGeo3D et iGeoSecurtiy)
• TinyOWS
• ArcGIS Server
• …

Les logiciels qui gèrent l'utilisation des webservices sont listés ci-dessous :

Créer un fichier wms (ne pas oublier de le rendre éxécutable avec un chmod g+x wms)

#! /bin/sh
MS_MAPFILE=/vers/le/mapfile
export MS_MAPFILE
/vers/le/script/mapserv

Puis appeller l'adresse http://0.0.0.0/vers/wms& pour appeller le webservice WMS.

L'ensemble des webservices présentent des points communs, dans la manière de les structurer, dans les types de requête, les contraintes. Parmi ces dernières, certains caractères sont réservés :

• ? : début de la liste des couples paramètres/valeurs, localhost/cgi/sript?…
• = : séparation du paramètre de ces valeurs, parametre=valeur
• & : séparation des couples paramètres/valeurs, parametre=valeur&parametre=valeur
• ' :
• + : remplace l'espace dans les valeurs.

Du fait de la compatibilité historique, il est nécessaire que le serveur et le client sache quelle version doit être utilisée.

• Questionnement du numéro de version du serveur :
• Format de sortie des réponses :
  • texte : toujours xml
  • image : gif, png, jpeg, tiff, SVG, WebCGM ou tout autre format d'image lu par un navigateur.
• Règles des variables dans les requêtes :
  • pas d'ordre
  • les paramètres ne doivent pas être sensible à la casse
  • les valeurs dans les listes de valeurs des paramètres doivent être séparé par des virgules. Si une valeur contient un espace ou une virgule, ceux-ci doivent être échappé.
  • les valeurs vides doivent être définie avec la chaine vide ''

• Forum/liste sur Géorezo : Geolibre_web
• Forum sur forumsig : http://www.forumsig.org

• Forum de l'OGC : http://feature.opengeospatial.org/forumbb/