
\title{\'Evaluation du Web Processing Service de l'OGC ...}
\subtitle{... pour une utilisation dans un SIG c\^ot\'e client}
\author{par Christopher Michael et Daniel P. Ames, traduit par Yves Jacolin}
%\author{Christopher
%Michaelis\textstyleFootnotexxSymbol{\footnotemark{}}\footnotetext{\ Research
%Assistant, Idaho State University Geospatial Software Lab}
% and Daniel P. Ames, PhD,
%PE\textstyleFootnotexxSymbol{\footnotemark{}}\footnotetext{\ Assistant
%Professor, Dept. of Geosciences, Idaho State University}}

\maketitle

\section{R\'esum\'e}
\label{sec:abstract}
La sp\'ecification de Web Processing Service de l'Open Geospatial Consortium a \'et\'e propos\'ee pour r\'epondre aux besoins de d\'eveloppements de modules de g\'eotraitement par Internet, et de facilit\'e de partage des algorithmes et des fonctionnalit\'es de g\'eotraitement. Cet article cherche \`a \'evaluer la proposition de WPS en respect de la faisabilit\'e et de l'utilit\'e potentielle, et d'identifier les zones \`a am\'eliorer.

Les questions que posent la proposition du WPS sont discut\'es ensemble avec des solutions posibles. Plusieurs am\'eliorations potentielles \`a cette proposition sont pr\'esent\'ees et consid\'er\'ees, incluant un m\'ecanisme pour guider les applications clientes dans la demande correctes des donn\'ees et dans le moyen de lister les donn\'ees disponibles sur un serveur.

\section{Introduction}
\label{sec:introduction}
L'Open Geospatial Consortium (OGC, ou OpenGIS) est une organisation de normalisation par consensus d'abord concern\'e par la diffusion de sp\'ecifications libres (c.a.d. non propri\'etaire) pour unifier les logiciels d'information g\'eographique, en apportant \`a la fois une vari\'et\'e de formats disjoints et des m\'ecanismes de communication pour permettre une interoperabilit\'e (Open Geospatial Consortium, 2006). Plut\^ot que d'\'eviter cette normalisation et la laisser enti\`erement propri\'etaire, plusieurs d\'eveloppeurs de syst\`eme SIG {\textquotedblleft}ont montr\'es une extraordinaire coop\'eration en \'equipe pour soumettre des Sp\'ecifications de l'OpenGIS{\textquotedblright} (Information Today, 1997) et ont activement fait leur ces normes, certains en participant eux-m\^eme \`a leur d\'eveloppement. Comme l'OGC est compos\'e de professionnels dans de nombreux champs d'application, plut\^ot qu'un simple comit\'e dans un seule environnement corporate, les normes sont typiquement de grande qualit\'e et sont disponible pour n'importe quel nombre de t\^ache scientifiques diff\'erentes.

Le 17 novembre 2005, l'OGC a publi\'e la quatri\`eme r\'evision de la proposition pour la sp\'ecification appel\'e Web Processing Service (WPS) (Open Geospatial Consortium, 2005). Cette sp\'ecification propos\'ee d\'ecrit un m\'ecanisme par lequel un g\'eotraitement peut \^etre r\'ealis\'e sur des serveurs distant, en utilisant principalement du XML (Extensible Markup Language) pour la communication par Internet. La sp\'ecification est faite de telle sorte qu'elle doit \^etre compl\'etement ind\'ependant du langage et de la plateforme. L'OGC a demand\'e au lecteur de commenter pendant une certaine dur\'ee, avec une date butoir au 4 f\'evrier 2006. Bien que le forum pour les commentaires des lecteurs soit d\'ej\`a ferm\'e, il y en a eut, jusqu'ici, peu si toutes les \'etudes r\'eelles sur la faisabilit\'e et l'utilit\'e de la proposition du point de vue du SIG c\^ot\'e client.
%Although the forum for public comments has already closed, there have been, to date, few if any real-world studies on the feasibility and utility of the proposal from the client-side GIS point of view.

Avant le WPS, des syst\`emes de g\'eotraitement bas\'e sur le web et des approches similaires au WPS ont \'et\'e d\'evelopp\'es par diverses entit\'es. Le plus remarquable, le produit ArcInfo 8.3 (ESRI 2003) de l'Institut de Recherche de Syst\`eme Environnementale (ESRI) contient une fonctionnalit\'e appel\'e le Serveur de G\'eotraitement [NdT : Geoprocessing Server], lequel fonctionne sur des serveurs UNIX pour r\'ealiser des g\'eotraitement derri\`ere des logiciels client ESRI qui envoit un travail \`a r\'ealiser. Le protocole du Seveur de G\'eotraitement d'ESRI est propri\'etaire et ferm\'e ce qui implique que seul les logiciels d'ESRI sont capable d'utiliser les possibilit\'es de traitement distant. D'une mani\`ere int\'eressante, cette fonctionnalit\'e a \'et\'e retir\'ee de la vesion suivante (ArcGIS 9.0). Une fonctionalit\'e similaire mais subtilement diff\'erente a \'et\'e introduite dans ArcGIS Server 9.2, o\`u un outil appel\'e {\textquotedblleft}Model Builder{\textquotedblright} construit \`a partir de composants d'ESRI plus simple peut servir des clients ArcGIS Desktop et ArcExplorer (Environmental Systems Research Institute, 2006). Contrairement au WPS, le d\'eveloppement d'ESRI n'est pas compatible avec les produits qui ne proviennent pas d'ESRI et est un protocole de communication ferm\'e, propri\'etaire l'emp\'echant d'\^etre adopt\'e largement ou \'etudi\'e dans un environnement non-ESRI.

\section{Qu'est ce qu'est le Web Processing Service (WPS)?}
\label{sec:whatis}
Le Web Processing Service d\'efinie un m\'ecanisme par lequel ubn client peut soumettre un traitement \`a un serveur. Le service d\'efinie une {\textquotedblleft}instance serveur{\textquotedblright}, ou un serveur, en tant qu'entit\'e qui peut fournir un ou plusieurs traitements, ou des t\^aches de traitement individuel (par exemple, ajouter deux jeu de rasters ensemble peut \^etre un traitement). De cette mani\`ere, n'importe quel serveur peut \^etre capable de r\'ealiser des traitements multiples et diff\'erent, et pas n\'ecessairement li\'e.

La sp\'ecification indique que le XML (eXtensible Markup Language) doit \^etre utilis\'e pour toutes les communications. Les documents XMLS sont fait d'\'el\'ements individuels, qui sont des conteneurs logiques pour des donn\'ees li\'es. Un \'el\'ement peut contenir d'autres \'el\'ements, et n'importe quel \'el\'ement peut contenir des attributs qui d\'ecrivent cette \'el\'ement. Un exemple simple d'un document XML pourrait \^etre :

\begin{footnotesize}
\begin{verbatim}
<landscape name="Smithsonian Park">
	<tree type="Elm" height="8" />
</landscape>
\end{verbatim}
\end{footnotesize}
Ce document XMS d\'ecrit un paysage, lequel est indiqu\'e par l'\'el\'ement nomm\'e {\textquotedblleft}landscape{\textquotedblright}. Un attribut nomm\'e {\textquotedblleft}name{\textquotedblright} indique qu'il s'agit du Parc Smithsonian. Un sous-\'el\'ement nomm\'e {\textquotedblleft}Tree{\textquotedblright} implique que le paysage contient ou poss\`ede cet arbre, et l'arbre a deux attributs suppl\'ementaire qui d\'ecrivent le type de l'arbre et sa hauteur. L'\'el\'ement est ferm\'e, ou termin\'e, en r\'ep\'etant le nom de l'\'el\'ement avec un slash devant.

XML a \'et\'e con\c{c}ue pour \^etre {\textquotedblleft}directement utilisable sur Internet{\textquotedblright}, {\textquotedblleft}lisible par un \^etre humain et raisonnablement clair{\textquotedblright}, {\textquotedblleft}formel et concis{\textquotedblright}, et {\textquotedblleft}facile \`a \'ecrire{\textquotedblright} (W3C, 2000). Utiliser du XML est b\'en\'efique principalement par sa lisibilit\'e par un \^etre humain ce qui aide grandement dans la conception et le d\'ebogage d'application l'utilisant. Les documents XML peuvent \^etre valid\'e pour s'assurer qu'ils contiennent tous les \'el\'ements et attributs n\'ecessaires. La validation est fa\^ites par un sch\'ema XML, qui est une forme sp\'eciale de document XML qui d\'ecrivent la structure qu'un document XML doit suivre.

Le but principal du Web Processing Service est de d\'efinir comment communiquer pour r\'ealiser un traitement distant. \`A cette fin, il y a trois requ\^etes cl\'es qui peut \^etre faites \`a un serveur WPS : GetCapabilities, DescribeProcess, et Execute. La premi\`ere de ces requ\^etes demande au serveur de lister les traitements individuels qui sont disponible sur le serveur, accompagn\'e d'un court r\'esum\'e et de mots-cl\'e.La requ\^ete ne n\'ecessite pas de param\`etres. Une fois qu'un traitement a \'et\'e identifi\'e \`a partir de la r\'eponse, une requ\^ete {\textquotedblleft}DescribeProcess{\textquotedblright} peut \^etre envoy\'ee, en pr\'ecisant le traitement en question comme param\`etre. La r\'eponse \`a cette requ\^ete inclus les m\^emes informations que la r\'eponse GetCapabilities, avec des informations plus d\'etaill\'ees sur les param\`etres en entr\'ee n\'ecessaire pour le traitement et si l'entr\'ee est simple (par exemple un nombre simple comme 23) ou complexe (par exemple un fichier de donn\'ees). Les sorties complexes sont typiquement encod\'e en XML, par exemple en utilisant GML (Geographic Markup
Language, un parent du XML) pour les donn\'ees vecteurs.

Si la r\'eponse DescribeProcess indique que c'est le traitement que l'utilisateur ou le client souhaite \'ex\'ecuter, la troisi\`eme requ\^ete (Execute) peut \^etre invoqu\'ee. C'est avec cette requ\^ete que le serveur r\'ealisera en r\'ealit\'e le traitement. Les param\`etres obligatoires incluent le nom du traitement ainsi que tout entr\'ee n\'ecessaire pour ce traitement particulier. La r\'eponse \`a la requ\^ete Execute est un document ExecuteResponse, un autre document XML qui indique un status du traitement, qui retourne les entr\'ees qui ont \'et\'e utilis\'ees, et fournit soit une sortie litt\'erale simple ou des liens vers une sortie complexe. Le status du traitement peut \^etre {\textquotedblleft}ProcessAccepted{\textquotedblright}, informant que le traitement a \'et\'e re\c{c}u et est mis dans la pile des traitements ; {\textquotedblleft}ProcessStarted{\textquotedblright}, informant que le traitement est en cours ; {\textquotedblleft}ProcessSucceeded{\textquotedblright}, signifiant que le traitement est termin\'e ; ou {\textquotedblleft}ProcessFailed{\textquotedblright}, indiquant que un probl\`eme est apparut. Si le status est ProcessAccepted ou ProcessStarted, le status est accompagn\'e par un attribut qui indique o\`u le document ExecuteResponse peut \^etre trouv\'e. De cette mani\`ere le client peut v\'erifier le status du traitement par une requ\^ete sur le prochain document ExecuteResponse. Dans le cas d'un retour ProcessStarted, un message du status et un pourcentage de progression peut \^etre fournit.

Si le status du traitement est ProcessFailed, le document ExecuteResponse contient aussi un code d'erreur dans l'\'el\'ement XML ExceptionReport, qui peut \^etre un des 5 codes d'erreurs (MissingParameterValue,
InvalidParameterValue, NoApplicableCode, ServerBusy ou FileSizeExceeded). Si le traitement r\'eussit, le document en r\'eponse incluera soit les sorties (dans le cs d'une simple valeur litt\'erale) ou des liens URL vers les sorties compelxes (tels qu'un fichier avec des donn\'ees raster). Si une seule sortie complexe est produit, cette sortie peut \^etre retourn\'ee directement \`a la place du document ExecuteResponse. Ensemble, ces trois requ\^etes d'op\'eration et leurs r\'eponses constituent la majorit\'e de la proposition du Web Processing Service.

\section{Pourquoi et quand un Web Processing Service doit \^etre utilis\'e ?}
\label{sec:whentouse}
%la premi\`ere phrase est \`a v\'erifier !!
Parce que les fonctionnalit\'es de g\'eotraitement propos\'ees sont illimit\'ees de capacit\'es ou de nature (Open Geospatial Consortium, 2005), la proposition contient de grandes promesses dans l'utilisation d'outils de calcul sans inqui\'etude tradionnelle telle que la distribution de corection de bug ou la v\'erification de la version la plus \`a jour. Bien que l'\'etendue de ce qui peut \^etre accomplit est illimit\'e, plusieurs op\'erations peuvent \^etre compl\'et\'es plus rapidement localement (c'est \`a dire, sur un PC de bureau d'utilisateur) qu'\`a distance (c'est \`a dire sur un serveur central), sp\'ecialement apr\`es avoir pris en compte le temps de t\'el\'echargement des donn\'ees en entr\'ee et renvoy\'e les donn\'ees resultantes en sorties par la suite. Lors du choix entre le traitement des donn\'ees en local ou distante, un certain nombre de facteur doit \^etre consid\'er\'e en plus de la taille brute des jeux de donn\'ees impliqu\'ees. La complexit\'e du calcul a une grande importance. Si le calcul prend plusieurs heures pour se terminer m\^eme pour un petit jeu de donn\'ees, il peut \^etre pr\'ef\'erable de r\'ealiser les calculs \`a distance. Si la t\^ache n'est pas complexe et la plus grosse partie du travaille repose sur l'urgence de gros volumes de donn\'ees stock\'ees localement, il peut \^etre plus efficasse de r\'ealiser le calcul localement. D'o\`u, avant de choisir d'utiliser seulement le calcul de donn\'ees distant, un choix intelligent doit \^etre fait entre mettre en place un traitement local ou distant. Comme illustr\'e dans le graphique de la Figure 1, le traitement distant a une place utileans le traitement moderne. De plus grandes capacit\'es de puissance de calcul dans une ferme de serveurs peut facilement r\'eduire le co\^ut des t\^aches qui demandent du temps et qui sont hautement complexe, sp\'ecialement lorsque elles sont combin\'ees \`a un r\'eseau \`a haut-d\'ebit tel que les fibres optiques ou l'\'ethernet Gigabit. Par cons\'equent, les donn\'ees doivent \^etre envoy\'ees aux serveurs ayant typiquement de grande capacit\'e de calcul, au lieu d'utiliser l'ordinateur local plus lent, lorsque le temp de calcul des donn\'ees localement serait plus important que le temps combin\'e de trasmission des donn\'ees, r\'ealiser le calcul \`a distance, et les r\'ecup\'erer.

Le calcul distant est \'egalement un choix id\'eal si l'algorithme est relativement nouveau, et est encore en d\'eveloppement actif. Dans ce sc\'enario, les nouvelles publications des versions ne n\'ecessite pas des mis \`a jour logiciels par l'utilisateur final. Plut\^ot, seul le serveur n\'ecessite une mise \`a jour pour refleter le nouveau code ou algorithme. Par cons\'equence tous les utilisateurs automatiquement gagne un acc\`es \`a la version la plus r\'ecente et la plus pr\'ecise du calcul simplement en utilisant le service de calcul bas\'e sur le serveur. Ce seul point de contr\^ole sur le calcul cr\'ee \'egalement la possiblit\'e de charger le serveur par son utilisation du calcul, si cela est voulut.

% Revoir le terme de appel de fonction dans ce paragraphe.
La vue traditionnelle des mandats de traitement distant dont la donn\'ee est t\'el\'echarg\'ee, tel que dans un Appel de Prroc\'edure Distant [NdT : Remote Procedure Calls] (RPC) o\`u la donn\'ee en entr\'ee et les param\`etres sont envoy\'e ensemble avec un appel de fonction (Bloomer, 1992). La donn\'ee en entr\'ee peut \^etre \'egalement stock\'ee sur le serveur, n\'ecessitant que le client d\'efinisse seulement l'entr\'ee particuli\`ere qui est n\'ecessaire. Cela cr\'ee l'opportunit\'e pour un serveur de traitement de fournir \'egalement la donn\'ee : la donn\'ee brute ne sera pas n\'ecessairement fournie, mais la donn\'ee du r\'esultat calcul\'e peut \^etre renvoy\'e sans n\'ecessairement t\'el\'echarger la donn\'ee en entr\'ee. Cela prend tout son sens particuli\`erement lors de traitement n\'ecessitant des donn\'ees en temps r\'eel tel que les observations des stations m\'et\'eorologiques, les observations du trafic en temps r\'eel, etc. Ces calculs peuvent \^etre fourni par la m\^eme agence qui collecte la donn\'ee, autorisant le traitement a avoir acc\`es aux derni\`eres donn\'ees disponibles. Les motivations pour utiliser un serveur de traitement distant sont multiples, mais la d\'ecision ultime doit reposer sur l'utilisateur si le traitement distant est appropri\'e pour la t\^ache ou non.
% La derni\`ere phrase pose probl\`eme : "The motivations for using a remote processing server are many, but ultimately the decision must lie with the user whether remote processing is appropriate for the task."

\begin{figure}[tbp]
   \centering
\includegraphics[scale=0.7]{topical/ames/WPS_for_OSGeo-short-img1.png}
   %caption of the figure
   \caption{Traitement local et traitement distant ont chacun leur temps appropri\'e.}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:figure1}
\end{figure}

\section{Consid\'erations sur le d\'eveloppement d'un WPS}
\label{sec:considerations}
La proposition du WPS d\'ecrit un m\'ecanisme par lequel un ordinateur client peut soumettre un travail \`a r\'ealiser sur un ordinateur distant. C'est une architecture client/serveur classique, signifiant qu'\`a la fois un composant client et un composant serveur sont n\'ecessaires. Dans un but de d\'eveveloppement et de test il est utile de compiler le composant c\^ot\'e client sur un syst\`eme d'information g\'eographique pr\'e-existant pour profiter des fonctionnalit\'es de visualisation existantes des donn\'ees g\'eospatiales \`a traiter et retourner, cependant, cela n'est pas toujours n\'ecessaire et les tests initiaux peuvent \^etre facilement r\'ealis\'e en ligne de commande ou avec des outils de test ignorant l'aspect g\'eographique. Ce composant c\^ot\'e client est la portion qui prend en charge la communication XML \`a travers Internet avec le serveur, id\'ealement sans que l'utilisateur n'est besoin de voir directement ou d'\'ecrire le WML dans le but de voir les traitements disponibles ou pour lancer leurs requ\^etes et r\'ecup\'erer les r\'esultats. Il est pr\'ef\'erable de compiler ce composant c\^ot\'e client de telle mani\`ere qu'il ne repose pas sur un logiciel particulier, propri\'etaire ou autre.

Le composant c\^ot\'e server lequel fournit \`a l'impl\'ementation cliente (et \`a d'autres impl\'ementations clientes) de v\'eritables services doit \^etre \'egalement ind\'ependant (c'est \`a dire non reli\'e \`a un algorithme de g\'eotraitement ou un calcul qui doit \^etre fourni). Une approche \`a ce probl\`eme est de placer une couche d'interface autour de routines de g\'eotraitement existantes ou non \'ecrites comme des utilitaires en ligne de commande bas\'e sous linux, des services Windows ou des applications windows. Aussi longtemps que le d\'eveloppement de l'application ou de l'algorithme en question peut \^etre \'ex\'ecut\'e sans interacion avec l'utilisateur (par exemple, \`a travers des arguments en ligne de commande, communication TCP/IP, ou par un transfer de donn\'ees OLE), cette fine couche de communications est une bonne option. Il peut \^etre plac\'e autour de fonctionnalit\'e de g\'eotraitement existant et d'outils existant (ou de nouveaux outils d\'evelopp\'es) pour leur permetre d'\^etre servi par du WPS, en fournissant un XML qui r\'epond aux n\'ecessit\'es minimales du sch\'ema de communication WPS de l'interface. Plut\^ot que de n\'ecessiter une re-\'ecriture compl\`ete d'un logiciel existant, celui-ci n\'ecessitera certainement de faibles modifications pour le faire fonctionner d'une mani\`ere innattendue, id\'ealement via des arguments en ligne de commande et des fichiers de log g\'en\'er\'es. Les commandes de GRASS (Neteler, 2006) sont un bon exemple d'outils en ligne de commande existants lesquels peuvent \^etre utilis\'e (wrapper) d'une mani\`ere telle que celle-la.

Ce wrapper peut alors initialiser l'outils en fonction de son besoin, et contr\^oler un fichier de log ou renvoyer un message sur le status pour indiquer si le traitement a r\'eussit, est encore en train de tourner, est en \'echec ou est dans la liste des traitements \`a faire. Les pourcentages du status et des messages d'erreur pertinent peuvent \'egalement \^etre r\'ecup\'er\'e des fichiers de log, pour \^etre retourn\'e \`a l'utilisateur final \`a travers des communications appropri\'ees d'une mani\`ere automatique, avec cette technique de wrapping. En plan\c{c}ant ce petit wrapper autour de cet outils ind\'ependant leur permet d'\^etre utilis\'e dans plusieurs endroits et pour de nombreux objectifs avec peu d'effort. Au fond ce wrapper devient le {\textquotedblleft}Serveur WPS{\textquotedblright}, parce qu'il prend en charge toutes les communications n\'ecessaire par le WPS. Ce wrapper, constituant le serveur WPS, peut \^etre d\'evelopp\'e comme une page PHP, comme une page en ASP .NET, comme une application ind\'ependante ou en utilisant une autre technologie de serveur.

La plupart des op\'erations n\'ecessaire \`a un serveur WPS sont simplement des op\'erations de m\'eta-donn\'ees : fournir des informations sur les traitements individuels (c'est \`a dire, les entr\'ees requises) et lister les traitements disponibles sur un serveur. Le serveur WPS chargera id\'ealement les informations sur les traitements disponibles \`a partir d'un fichier de configuration (peut-\^etre un par traitement) ou d'une base de donn\'ees, permettant alors au cod\'e \'ecrit pour le serveur WPS d'\^etre r\'eutilis\'e simplement en ajoutant des traitements additionnels aux fichiers de configuration ou \`a la base de donn\'ees. Ces fichiers de configuration ou cette base de don\'ees peut \'egalement indiquer au serveur WPS comment lancer le traitement et comment lui envoy\'e les fichiers en sorties.

Un aper\c{c}u du flux de communication sugg\'er\'ee entre une application cliente et une application serveur est montr\'e Figure 2. Au d\'ebut, l'application cliente envoie une requ\^ete au serveur, fournissant une requ\^ete GetCapabilities. Le serveur WPS renvoit alors un document XML correspondant au sch\'ema WPS (fl\`eche 1 dans la Fig. 2). Le client pr\'esente alors \`a l'utilisatuer une liste des traitements disponible sur le serveur (fl\`eche 2 dans la Fig. 2). L'utilisateur s\'electionne un des ces traitements, entrainant l'envoie par le client d'une requ\^ete sur les informations additionnelles sur ce traitement (fl\`eche 3) en envoyant une requ\^ete DescribeProcess. L'application cliente aide l'utilisateur \`a collecter et \`a entrer les param\`etres en entr\'es n\'ecessaire pour que le traitement soit \'ex\'ecut\'e ; il initialise alors le traitement sur le serveur (fl\`eche 3) en envoyant une requ\^ete Execute. Le serveur \`a son tour d\'eclenchera la commande de lancement du traitement sp\'ecialis\'e (fl\`eche 4).

Remarquez que le serveur WPS ne doit pas \'ex\'ecuter le traitement demand\'e directement, parce que cela pourrait impliquer un d\'elais : le serveur aurait besoin de terminer le traitement avant qu'une r\'eponse soit envoy\'e au client. \`A la place, il ets pr\'ef\'erable d'avoir le serveur WPS initialisez un traitement dans diff\'erent thread, ou dans diff\'erents processus, ainsi une ExecuteResponse initial peut \^etre imm\'ediatement retourn\'e vers le client. De cette mani\`ere, les op\'erations de g\'eotraitement qui n\'ecessitent beaucoup de temps permettra \`a l'utilisateur de travailler sur son ordinateur. Pour une meilleur propret\'e et s\'ecurit\'e, il est plus init\'eressant de d\'emarrer un processus compl\`etement nouveau, ainsi si un processus se termine anormalement il n'arr\^etera pas le serveur WPS enti\`erement \'egalement : uen commande de lancement de proc\'essus sp\'ecialis\'e est alors une bonne solution.

\begin{figure}[tbp]
   \centering
   \includegraphics[scale=0.5]{topical/ames/WPS_for_OSGeo-short-img2.png}
   %caption of the figure
   \caption{Suggested communications flow between the client and
the server.}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:figure2}
\end{figure}
Comme expliqu\'e \`a la section 2, ce document ExecuteResponse initial informe o\`u l'application cliente peut trouver les futures mises \`a jours du status (c'est \`a dire, la prochaine ExecuteResponse) \`a propos de l'op\'eration demand\'ee, ainsi que la notification du succ\`es, de l'\'echec, des travaux accept\'es ou refus\'es, et fournit des mises \`a jours du status. L'application cliente doit questionner le document ExecuteResponse suivant autant de fois que l'utilisateur le d\'esire (fl\`eche 6 \`a la Fig. 2). Id\'ealement le serveur WPS doit \^etre con\c{c}u de telle mani\`ere qu'un document ExecuteResponse peut \^etre trouv\'e \`a un endroit logique, peut \^etre en utilisant toujours la m\^eme URL pour les r\'eponses les plus r\'ecentes. Une bonne approche pour adresser des g\'en\'erations de documents de r\'eponse serait la cr\'eation de page web sp\'ecialis\'e ou de composant serveur qui lirait simplement un fichier de log qui serait \'ecrit par un processus \'ex\'ecut\'e pour d\'etermin\'e le status en cours ou les erreurs.

Avoir la possibilit\'e de fournir la mise \`a jour des status n\'ecessite que le composant du serveur soit capable d'obtenir de tel mise \`a jour du processus qui est \'ex\'ecut\'e. Cela implique qu'un fichier de log est une excellent solution : le processus doit \^etre capable d'\'ecrire un fichier de log ou de rediriger sa sortie standard vers un fichier texte. De cette mani\`ere, le fichier peut \^etre automatiquement lu par le serveur WPS, permettant une bonne connectivit\'e entre les composants du syst\`eme.

Une fois que le document ExecuteResponse indique que le traitement s'est termin\'e, le serveur doit retourner un message d'erreur applicable ou retourner l'endroit o\`u la donn\'ee g\'en\'er\'ee peut \^etre t\'el\'echarg\'ee ou r\'ecup\'er\'ee. Le logiciel client doit alors autoriser l'utilisateur pour sauver ou voir la donn\'ees, puis compl\'eter le r\^ole du WPS.

\section{Am\'eliorations propos\'ees, probl\`emes et solutions potentiels}
\label{sec:suggested}

Bien que la proposition du WPS soit capable d'accomplir ses buts initiaux sosu sa forme courante, la proposition peut \^etre am\'elior\'ee par 6 changements cl\'es. Ces changements incluent deux \'el\'ements additionnels dans la r\'eponse DescribeProcess fournit par le serveur, lequel d\'ecrit l'entr\'ee et la sortie d'un traitement donn\'ees, ainsi qu'un m\'ecanisme par lequel un client peut annuler une requ\^ete qui est en attente ou en cours. Les changements potentiels incluent \'egalement des corrections dans des comportements inconsistant, la fourniture de types d'erreur additionnels pour la prise en charge d'erreur, et la possibilit\'e d'avoir un seul point d'entr\'e pour chaque traitement et peut \^etre un seul point d'entr\'e pour chaque serveur.

Le premier changement sugg\'er\'e est d'ajouter un \'el\'ement au document XML (eXtensible Markup
Language) lequel est retourn\'e apr\`es une requ\^ete DescribeProcess. \`A ce jour, les entr\'ees n\'ecessaire sont list\'ees par ce document, mais aucune description de la mani\`ere dont le client doit questionner l'utilisateur pour cet entr\'ee n'est fournis. La donn\'ees n\'ecessaire peut arriver sous la forme d'une s\'election d'une forme sur une carte, d'une valeur litt\'erale tel que {\textquotedblleft}23{\textquotedblright}, rechercher un fichier d'un type donn\'ees, ou une douzaine d'autres m\'ethodes pour r\'ecup\'erer des donn\'ees. Dans nos tests de d\'eveloppement, nous avobns introduit un nouvel \'el\'ement XML appel\'e {\textquotedblleft}PromptMethod{\textquotedblright} pour r\'esoudre ce probl\`eme. Cet \'el\'ement peut contenir les valeurs {\textquotedblleft}browseforvector{\textquotedblright}, {\textquotedblleft}browseforraster{\textquotedblright}, {\textquotedblleft}getboundingbox{\textquotedblright}, ou {\textquotedblleft}getmatchingregex{\textquotedblright}. Cela impliquera que l'application cliente devra demander respectivement un fichier vecteur, un fichier raster, r\'ecup\'erer une boite englobante (par exemple, en demandant \`a l'utilisateur de la dessiner) ou r\'ecup\'erer un certain nombre d'information correspondant \`a un motif particulier. Les trois premiers ne n\'ecessite aucune explication ; la derni\`ere getmatchingregex, acceptera seulement une valeur entr\'e par l'utilisateur laquelle correspondra \`a l'expression r\'eguili\`ere fournit.

Une expression r\'eguli\`ere est une r\`egle d\'efinie par des caract\`eres sp\'eciaux, tels que {\textquotedblleft}\^{}[a-zA-Z][a-zA-Z]\${\textquotedblright}. Cette expression r\'eguli\`ere cherchera au d\'ebut de l'entr\'ee (symbolis\'e par \^{}), suivit de deux caract\`eres, de A \`a Z, ind\'ependemment de la casse, suivie par la fin de l'entr\'ee (symbolis\'e par le symbol dollar). Cela fournit un filtre en entr\'ee flexible et rapidement configurable afin de s'assurer que l'utilisateur entre bien l'entr\'e qui est n\'ecessaire. Il existe certaines variations de la syntaxe dans les expressions r\'eguli\`ere \`a cause de la diversit\'e des moteurs de traitement des expressions r\'eguili\`eres (Goyvaerts, 2006), singifiant qu'un soin particulier doit \^etre pris afin que les expressions sont con\c{c}u de telle mani\`ere qu'elles seront interpr\'et\'ees correctement par tous les clients et le serveur. Un exemple de l'addition sugg\'er\'ee au WPS peut \^etre vue \`a la Figure 3, o\`u l'expression r\'eguli\`ere a \'et\'e d\'efinie par {\textquotedblleft}\^{}{\textbackslash}d\{8\}\${\textquotedblright}. Cette expression indique que le d\'ebut de la cha\^ine (\^{}) doit \^etre suivit par 8 chiffres (d\{8\}) puis par la fin de la cha\^ine (\$). Cette expression assume que le traitement des expressions r\'eguli\`ere de Microsoft sera utilis\'e.

Le second changement sugg\'er\'e est une autre addition \`a la r\'eponse DescribeProcess. \`A ce jour il n'existe pas de m\'ecanisme par lequel un serveur peut lister les donn\'ees disponibles sur le serveur pour une utilisation pour un traitement donn\'ees. Un tr\`es bon exemple o\`u cela peut \^etre utile est dans le calcul des limites des bassins versant - d\'efinissant un r\'eseau de flux et de bassin bas\'e sur un jeu de donn\'ees de mod\`ele num\'erique de terrain (Savant et al., 2002). Les raster d'\'el\'evation peuvent typiquement \^etre tr\`es important, il est donc ind\'esirable et souvent impossible de t\'el\'echarger compl\'etement le fichier en entr\'ee sur le serveur. Les jeux de donn\'ees tels que les donn\'ees d'\'el\'evation ne change pas souvent, et peuvent \^etre stock\'ees sur le serveur pour sauvegarder du temps. Dans nos tests de d\'eveloppement, nous r\'esolvons cela en introduisant un \'el\'ement XML nomm\'e {\textquotedblleft}AvailableData{\textquotedblright},avec un \'el\'ement enfant pour chaque donn\'ees contenant un nom et une br\`eve descriptions comme montr\'e Figure 4. Non seulement cela augmente la vitesse du traitement en enlevant le besoin de t\'el\'echarger les donn\'ees en entr\'ee, mais cela cr\'ee \'egalement un moyen pour lequel un serveur WPS peut agir comme d\'ep\^ot de donn\'ees ou les traiter et renvoyer les donn\'ees calcul\'ees.

\begin{figure}[tbp]
   \centering
\includegraphics[scale=0.3]{topical/ames/WPS_for_OSGeo-short-img3.png}
   %caption of the figure
   \caption{ \'El\'ement PromptMethod sugg\'er\'e dans la r\'eponse DescribeProcess.}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:figure3}
\end{figure}

\begin{figure}[tbp]
   \centering
\includegraphics[scale=0.3]{topical/ames/WPS_for_OSGeo-short-img4.png}
   %caption of the figure
   \caption{\'El\'ement AvailableData sugg\'er\'e dans la r\'eponse DescribeProcess.}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:figure4}
\end{figure}
Dans la proposition actuel du WPS il i y a une incoh\'erence apr\`es avoir soumit un travail au serveur en regards de ce qu'il devrait arriver par la suite. Si le traitement r\'esultera en une seule valeur retourn\'e et que la requ\^ete Execute a \'et\'e r\'ealis\'e avec le param\`etre {\textquotedblleft}store{\textquotedblright} \`a false, le WPS autorisera le traitement \`a retourner imm\'ediatement la sortie, plut\^ot qu'un document ExecuteResponse XML. S'il y a plus d'un r\'esultat, ou si on a demand\'e au traitement de stocker les r\'esultats, alors une document ExecuteResponse est g\'en\'er\'e. Ce comportement est incoh\'erent , puisque n'importe quel traitement pourrait retourner soit de multiples r\'esultat en sortie ou un seul, en fonction des param\`etres fournis au triatement. Au lieu de cela, il est plus simple de toujours retourner un document ExecuteResponse, en stockant n'importe quelle donn\'ee en sortie (par exemple des fichiers vecteurs ou rasters) sur le serveur jusqu'au t\'el\'echargement par le client. De simple valeur en sortie (par exemple un nombre unique) peut \^etre retourn\'e directement inclus dans le document ExecuteResponse, avec des liens pointant vers les sorties complexes. Notre troisi\`eme suggestion est de toujours demander de retourner un document ExecuteResponse pour fournir une meilleur coh\'erence et une simplification du d\'eveloppement du client.

Apr\`es avoir soumis un travail au serveur WPS, il peut \^etre utile d'annuler l'op\'eration demand\'ee ; cette \'eventualit\'e n'est pas pr\'evue dans la proposition actuelle. Au cours de nos d\'eveloppement tests (et comme pour nos quatres changements propos\'es) nous avons introduit l'utilisation d'une {\textquotedblleft}URL d'annulation de requ\^ete{\textquotedblright} dans le document ExecuteResponse, en compagnie de l'URL existante indiquant o\`u trouver le prochain document ExecuteResponse. De cette mani\`ere un client souhaitant annuler un traitement a seulement besoin d'acc\`eder \`a l'URL pour lancer l'annulation du traitement demand\'e, emp\'echant de gacher du temps de traitement du serveur pour des traitements ind\'esirables.

Notre cinqi\`eme changement sugg\'er\'e \`a la proposition du WPS est d'avoir un unique point d'entr\'e pour chaque requ\^ete possible  (GetCapabilities, DescribeProcess, et Execute) pour un traitement donn\'e. Id\'ealement, un unique point d'entr\'ee (par exemple une unique page PHP) pourrait \^etre utilis\'e non seulement pour chaque requ\^ete sur un traitement, mais aussi pour chaque traitement disponible sur ce serveur. Pour l'instant, chacune des requ\^etes qu'un traitment g\`ere peut avoir une URL diff\'erente pour r\'ealiser cete requ\^ete, comme illustr\'e \`a la figure 5. Dans cette figure, l'URL GetCapabilities est entour\'e en bleu, l'url DescribeProcess en vert et l'URL Execute en rouge. Ici chaque URL est la m\^eme, rendant la maintenance et le d\'eveloppement plus facile, bien qu'il soit acceptable d'avoir diff\'erent URL d'acc\`es pourchaque op\'eration. Des confusions ou des erreurs peuvent facilement arriver avec les diff\'erentes URL pour ces op\'erations. Cel apeut \^etre corriger facilement en le rendant n\'ecessaire pour utiliser une seul URL pour les trois requ\^etes qu'un traitement doit g\'er\'e.

Enfin, notre sixi\`eme suggestion est de d\'evelopper un syst\`eme de gestion d'erreur plus structur\'e. Pour l'instant, il ya tr\`es peu de types d'erreur (Pour l'instant il y a tr\'e peu d'erreur MissingParameterValue, InvalidParameterValue, NoApplicableCode, ServerBusy et FileSizeExceeded), qui sont limit\'e - particuli\`erement lors de la tentative de lecture automatique d'une erreur. Avec un faible nombre de types d'erreur (codes d'erreur), il n'y a pas de mani\`ere g\'en\'erique pour prendre en charge les erreurs de la part de l'utilisateur. Une hi\'erarchie plus complexe et structur\'ee permettrait aux applications clientes de comprendre la nature de l'erreur qui est apparue, peut \^etre en r\'ecup\'erant ou r\'eessayant automatiquement si n\'ecessaire. La possibilit\'e de insonoriser l'utilisateur des erreurs et de r\'ecup\'erer \'el\'egament est une partie importante de n'importe quelle structure de standard, et cette capacit\'e pourrait \^etre rendu possible avec une hi\'erarchie des erreurs plus d\'etaill\'ee.

\begin{figure}[tbp]
   \centering
   \includegraphics[scale=0.3]{topical/ames/WPS_for_OSGeo-short-img5.png}
   %caption of the figure
   \caption{Possiblit\'e d'avoir diff\'erente URL pour chaque requ\^ete pour le m\^eme traitement peut entrainer une confusion et une complexit\'e \`a \'eviter.}
   %label of the figure, which has to correspond to \ref{}:
   \label{fig:figure5}
\end{figure}

\section{Conclusions}
\label{sec:conclusions}
Dans l'ensemble, la proposition du WPS est un moyen performant de normalisation d'un m\'ecanisme de communications pour le g\'eotraitement client/serveur. La proposition fonctionne comme elle est actuellement structur\'e et est en effet appropri\'e pour plusieurs t\^aches SIG. Le d\'eveloppement de composant client et les traitements WPS du serveur a montr\'e que la proposition du WPS est solide et efficasse. N\'eanmoins, il y a plusieurs opportunit\'es d'am\'elioration \`a la proposition du WPS en incluabnt les six recommendations sp\'ecifiques fournit ici. Nous esp\'erons que ces observations seront b\'en\'efique \`a chacun pour d\'evelopper les sp\'ecifications du WPS propos\'e sur diverses plateformes SIG.

N'importe quelle activit\'e de g\'eotraitement peut \^etre pr\'esent\'e au format WPS. Cela permet aux d\'eveloppeurs d'algorithme pour continuellement am\'eliorer l'algorithme tout en permettant aux utilisateurs n'importe o\`u d'utiliser le code, sans devoir mettre \`a jour vers la derni\`ere version. Cela assure \'egalement que le code et les algorithmes utilis\'es soient de grande qualit\'e : si un bug est d\'etect\'e dans une version publi\'ee d'un algorithme qui est distribu\'e sur un CD, aucun moyen n'existe pour s'assurer que tous les utilisateurs mettent \`a jours avec succ\`es \`a la version corrig\'ee. Avec une architecture de traitement bas\'e sur Internet, ce probl\`eme est simplifi\'e simplement en publiant le nouvel algorithme sur le serveur de traitement. Les g\'eotraitement consommant du temps et intes\'ement le processeur peut \^etre r\'ealis\'e sur un serveurdistant, lib\'erant le bureau de l'utilisateur pour travailler sur d'autres t\^aches. Les gros jeux de donn\'ees peuvent \^etre stock\'es sur le serveur et traiter en fonction des param\`etres particulier de l'utilisateur, en combinant les aspects de d\'ep\^ot de donn\'ees et de traitement de donn\'ees dans un seul syst\`eme.

La proposition du WPS introduit un standard qui permettra \`a diff\'erents d\'eveloppeurs dans des endroits diff\'erents de produire des offres de g\'eotraitement et de les leur fournir facilement \`a diff\'erentes plateformes clientes. Dans ces tests, il a \'et\'e d\'emontr\'e que la proposition du WPS est pratique et utiliasble dans sa d\'efinition actuel. Les am\'eliorations additionnels propos\'e peuvent am\'eliorer le WPS significativement, le rendant meilleur pour la t\^ache pour laquelle il a \'et\'e cr\'ee.

%\section{References}
%\label{sec:references}

\begin{footnotesize}
\begin{thebibliography}{99}
\bibliographystyle{amsplain}



\bibitem{Bloomer-1992}
Bloomer, John. 1992. 
{\bf Power Programming with RPC. Cambridge, MA:}
O{\textquoteright}Reilly Media.

\bibitem{ESRI-2003}
Environmental Systems Research Institute (ESRI). 2003. 
{\bf ArcGIS Desktop Products Data Sheet.}
WWW document, \url{http://www.esrichina-bj.cn/produce/esri/arcgisdesktopsheet.pdf}

\bibitem{ESRI-2006}
Environmental Systems Research Institute (ESRI). (2006). 
{\bf ArcGIS 9.2 Webinar -- ArcGIS Server: Publishing a Geoprocessing Model.}
WWW document, \url{http://events.esri.com/info/index.cfm?fuseaction=seminarRegForm\&shownumber=9919}

\bibitem{Information_Today-1997}
{\bf GIS Competitors Cooperate on OpenGIS Specs. 1997. }
Information Today, 14(2), 15-15.

\bibitem{Goyerts-2006}
Goyvaerts, Jan. 2006. 
{\bf Regular Expression Tutorial.}
WWW document, \url{http://www.regular-expressions.info/tutorial.html}

\bibitem{OGC-2006}
Open Geospatial Consortium, Inc. 2006. 
{\bf Vision and Mission.}
WWW document, \url{http://www.opengeospatial.org/about/?page=vision}

\bibitem{OGC-2005}
Open Geospatial Consortium, Inc. 2005. 
{\bf OpenGIS{\textregistered} Web Processing Service (WPS) Discussion Paper.}
WWW document, \url{http://www.opengeospatial.org/}

\end{thebibliography}
\end{footnotesize}


\address{Christopher Michael\\
	Research Assistant\\
	Idaho State University Geospatial Software Lab}

\address{Daniel P. Ames, PhD\\
	Assistant Professor\\
	Department of Geosciences, Idaho State University}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: main_document.tex
%%% End:

