DESS CAMSI2004-2005
Rapport de stage
ETUDE D'ARCHITECTURE DES FUTURSSEGMENTS SOL D'OBSERVATION
Tuteur de stage : François THIEBOLT
Olivier JEAN-THEODORE
mars 2005 – juillet 2005
Maître de stage : Fabrice LEVY
Table des matièresI.Présentations............................................................................................ 4
I.1.Présentation du DESS................................................................................................ 4I.2.Présentation d'Astrium.............................................................................................. 4
I.2.1.L'entreprise.................................................................................................................. 5I.2.2.Le département Systèmes Sol, Applications & Services...........................................5
I.3.Présentation du stage..................................................................................................7I.3.1.Sujet...............................................................................................................................7I.3.2.Objet du stage...............................................................................................................7I.3.3.Déroulement du stage.................................................................................................. 7I.3.4.Environnement logiciel................................................................................................8I.3.5.Planning........................................................................................................................ 9
I.3.5.1.Calendrier des tâches......................................................................................... 9I.3.5.2.Diagramme de Gantt..........................................................................................9
I.4.Présentation du projet GMES................................................................................. 10I.4.1.Le besoin d'une infrastructure................................................................................. 10I.4.2.Une solution existante, MASS/SSE.......................................................................... 11
I.4.2.1.Contexte et rôle du portail SSE....................................................................... 11I.4.2.2.Éléments constituants d'une chaîne de services...............................................13I.4.2.3.Chaîne de services utilisant SSE......................................................................14I.4.2.4.Architecture du portail SSE............................................................................. 15I.4.2.5.Flux des données et des contrôles dans la chaîne de services..........................16
I.4.3.Cahier des charges de la solution attendue............................................................. 17
II.Étude des workflows............................................................................ 19II.1.Présentation générale sur les workflows...............................................................19
II.1.1.Définition...................................................................................................................19II.1.2.Modèle de référence WfMC.................................................................................... 20II.1.3.Quelques acteurs du marché................................................................................... 21
II.2.Workflows centralisés classiques...........................................................................22II.3.Workflows distribués..............................................................................................23II.4.Mise en évidence des apports d'une solution distribué........................................25II.5.Application du modèle distribué à l'architecture GMES.................................... 26
II.5.1.Solution distribuée pour l’infrastructure GMES..................................................26II.5.2.Architecture d'un noeud..........................................................................................28II.5.3.Transit des données et du contrôle d'une chaîne de services avec unearchitecture distribuée....................................................................................................... 29
III.Organisations et standards dans le domaine géospatial..................31III.1.Les organismes normalisateurs dans le géospatial............................................. 32
III.2.Open Geospatial Consortium (OGC).................................................................. 32III.2.1.Structure de l'OGC.................................................................................................32III.2.2.Les programmes de l'OGC.................................................................................... 33
Programme de spécification........................................................................................33Programme d'interopérabilité......................................................................................33Assistance (Outreach & Community Adoption)......................................................... 33
III.2.3.Les principales normes OGC.................................................................................34III.2.3.1.WMS – Web Map Service............................................................................ 34III.2.3.2.WMC - Web Map Context............................................................................35III.2.3.3.GML – Geography Markup Language.......................................................... 35III.2.3.4.WFS - Web Feature Service..........................................................................37III.2.3.5.WTS - Web Terrain Service..........................................................................37III.2.3.6.WCS - Web Coverage Service...................................................................... 38III.2.3.7.WPS - Web Processing Service.................................................................... 39III.2.3.8.CAT - Catalogue Services.............................................................................40
III.3.International Organization for standardization (ISO)...................................... 42III.3.1.Présentation et rôle de l'ISO..................................................................................42III.3.2.ISO/TC 211..............................................................................................................43III.3.3.Les projets ISO/TC 11............................................................................................43
III.4.World Wide Web Consortium (W3C)................................................................. 45III.4.1.Présentation et rôle................................................................................................. 45III.4.2.Technologies W3C.................................................................................................. 46
III.4.2.1.Extensible Markup Language (XML)........................................................... 47III.4.2.2.Simple Objet Access Protocol (SOAP).........................................................48III.4.2.3.Web Services.................................................................................................50III.4.2.4.Web Services Description Language (WSDL)..............................................52III.4.2.5.Semantic Web............................................................................................... 53III.4.2.6.Web Ontology Language (OWL).................................................................. 54
IV.Conclusion........................................................................................... 58V.Annexes..................................................................................................59
V.1.Acronymes................................................................................................................59V.2.Bibliographie............................................................................................................61
I. Présentations
I.1. Présentation du DESS
DESS Concepteur en Architecture de Machines et Systèmes Informatiques.
Composante de rattachement : UFR MIG
Formation conjointe avec : Ecole Nationale Supérieure d’Electrotechnique, d’Electronique,
d’Informatique et d’Hydraulique de Toulouse (ENSEEIHT), Institut National des Sciences
Appliquées de Toulouse (INSA).
Objectif de la formation
Cette formation vise à former des spécialistes en architecture matérielle de systèmes informatiques
en dispensant aux étudiants d’une part un éventail de connaissances suffisant pour aborder ce
domaine (architecture de base, circuits, applications) et d’autre part un approfondissement de
certains aspects plus spécialisés (VLSI, architectures dédiées).
I.2. Présentation d'Astrium
- 4 -
I.2.1. L'entreprise
EADS Astrium est l’un des leaders mondiaux de la conception et de la fabrication de systèmes de
satellites. Ses activités couvrent les systèmes de télécommunications et d’observation civils et
militaires, les programmes scientifiques et la navigation, les moyens sol associés et les équipements
spatiaux.
EADS Astrium présente un palmarès remarquable :
• L’un des leaders mondiaux pour les satellites d’observation de la Terre
• Le maître d’oeuvre de plus de 60 satellites de télécommunications
• Un acteur clé du nouveau système européen de navigation par satellites
• L’un des principaux fournisseurs de systèmes spatiaux militaires
• Le leader européen pour les programmes scientifiques
• Un fournisseur de premier plan en matière d’équipements et de sous-systèmes
Implanté en France, en Allemagne, au Royaume-Uni et en Espagne, EADS Astrium dispose d’une
organisation industrielle équilibrée et intégrée qui en fait un partenaire de choix pour tous ses
clients, qu’ils soient nationaux, internationaux, institutionnels ou commerciaux.
La société possède des moyens de conception, de production et d’essais parmi les mieux adaptés et
les plus avancés de l’industrie spatiale. Elle emploie près de 6 000 personnes hautement qualifiées.
EADS Astrium est détenue à 100 % par EADS SPACE, qui réunit l’ensemble des activités spatiales
du groupe EADS, European Aeronautic Defence and Space Company, l’un des leaders mondiaux
de l’aéronautique, de la défense et des services associés.
I.2.2. Le département Systèmes Sol, Applications & Services
Ce département a pour mission:
• De concevoir, développer et maintenir des systèmes sol (prototype et récurrents) : Centres de
contrôle, centre de mission, bancs de tests, simulateurs satellites et lanceurs, systèmes de
transmission d'informations par satellites et réseaux terrestres, systèmes de traitement
d’informations satellitaires.
• D’offrir des services de maintenance & logistique (formation, support utilisateur, etc.).
- 5 -
Ces produits et services sont réalisés pour le compte de clients:
• Internes à Astrium, en particulier les équipes d'intégration satellites/lanceurs et de validation du
logiciel embarqué.
• Externes, dans un contexte international : agences spatiales, organismes publics ou privés,
industriels.
En règle générale, la fourniture des produits et services comprend les grandes étapes suivantes : • l’élaboration de propositions techniques et financières en réponse à des appels d’offres.
• Le gain du contrat déclenche les activités d’ingénierie et de développement du système (logiciel
et matériel) qui peuvent s’étaler sur plusieurs mois, voire plusieurs années (1-3 ans) et qui se
concluent par une recette usine.
• L’acceptation par le client lors d’une recette site constitue le début de la phase de garantie
(généralement 1 an) suivie de la phase de maintenance qui peut aller jusqu’à la fin de vie du
système.
Pour l'ensemble de ces activités, le département se positionne généralement en maîtrise d’oeuvre,
mais peut intervenir également comme sous-contractant d’un maître d’oeuvre interne (BU) ou
externe.
Des études libres et des actions de R&D, de maquettage, d’évaluation et de veille technologiques,
sont également menées au sein de l’unité afin de maintenir la technicité du personnel, d’améliorer
les processus & la compétitivité, d’assurer en permanence la satisfaction du client.
Par ailleurs, le département élabore pour ses besoins propres certains outils d'aide au développement
et à l'intégration/validation des systèmes.
Les principaux domaines de compétences nécessaires à la réalisation de ces activités incluent : • L'ingénierie des systèmes : étude, architecture, développement et maintenance de systèmes.• L'ingénierie du logiciel : étude, développement et maintenance de logiciel.• L’ingénierie hardware : étude, développement et maintenance d'équipements.
- 6 -
I.3. Présentation du stage
I.3.1. Sujet
Analyse de l'utilisation des concepts et des technologies GRID, SOA, OGSA, Web Service pour les
besoins d'architecture des segments sol d'observation et de la chaîne des services à valeur ajoutée,
en particulier dans le contexte GMES. Le stagiaire fera un état de l'art de ces technologies,
analysera les architectures envisagées pour les futurs segments sol d'observation, et définira leur
applicabilité et limitations dans ce contexte.
I.3.2. Objet du stage
De part ses compétences dans les technologies des segments sol, EADS Astrium est impliquée dans
l'étude de l'architecture de la future infrastructure GMES (Global Monitoring for Environment and
Security).
Cette étude porte sur les technologies à mettre en oeuvre, l'intégration de celles ci entre elles ainsi
que sur l'architecture globale de la structure. Mon rôle en tant que stagiaire a consisté en l'étude de
différentes technologies et concepts pressentis pour GMES et de les appliquer au cahier des charges
du projet pour vérifier leur pertinence dans ce contexte.
I.3.3. Déroulement du stage
Après une rapide phase de familiarisation avec l'entreprise, l'intranet et les ressources dont je
disposerais durant le stage, la première étape a été de prendre connaissance avec le projet GMES.
Ensuite une étude des workflows classiques ainsi que sur le concept récent des workflows distribués
qui rejoignent les systèmes multi-agents a été mené. Parallèlement à cela l'étude de la solution SSE
de l'ESA a été faite afin d'en mesurer les limitations et de voir dans quelle mesure les technologies
étudiées permettaient d'apporter une solution plus en phase avec GMES. En dernier lieu une étude
approfondie des différentes normes existantes dans le domaine de géospatial ainsi que sur les
- 7 -
organismes les développant a été effectuée en vue d'apporter une synthèse des protocoles permettant
des communications entre les systèmes géospatiaux.
Ces travaux se sont concrétisés par la production de trois présentations destinées à alimenter
l'équipe de R&D chargée du projet en documents synthétiques :
• Une présentation sur les workflows et les workflows distribués,
• Une présentation modélisant l'apport des workflows distribués à l'architecture GMES,
• Une présentation synthétisant l'ensemble des normes et technologies candidates à une intégration
dans GMES.
Enfin l'étape finale a été la rédaction de ce présent document qui récapitule et synthétise les
recherches effectuées au cours de mon séjour à EADS Astrium.
Le support des recherches a été constitué en grande partie par des articles trouvés sur Internet
notamment dans le domaine des workflows distribués ainsi que des documentations techniques et
des présentations sur les technologies étudiées. Une bibliographie de ces documents a été fournie
ainsi que leur résumé afin de constituer une vivier pouvant servir à une exploitation future des
technologies étudiées.
Les documents internes à l'entreprise m'ont également été d'un grand support pour l'appréciation
globale et le cadrage du sujet ainsi que sur certains points spécifiques me constituant de la sorte une
base de départ pour la suite des investigations.
I.3.4. Environnement logiciel
• Windows NT, XP
• Internet
• Mozilla Firefox
• OpenOffice.org
• Microsoft Office XP
• Microsoft Visio XP
• IrfanView
• Acrobat reader
- 8 -
I.4. Présentation du projet GMES
I.4.1. Le besoin d'une infrastructure
L'engagement de l'Europe à promouvoir le développement
durable et à globaliser la prise de décisions dans les
territoires de la communauté nécessite des données et des
informations pertinentes acquises dans des délais
acceptables. L'établissement en 2008 d'une capacité
Européenne de surveillance globale de l'environnement et
des risques contribuera à assurer l'approvisionnement de ces
informations.
Actuellement, les politiques Européennes d'environnement et de risques souffrent d'avoir à se
reposer sur des données fragmentées de qualité et de valeur inégales. Et cela, en dépit du fait que sur
les 20 ou 30 dernières années, un bon nombre d'organisations ont été crées spécifiquement pour
collecter et produire des données à l'échelle Européenne et dans les états membres. Dans la même
période des progrès considérables ont été fait dans les systèmes d'observation et dans les
technologies de l'information.
Les premières conclusions des chaînes 1 et 2 de la période initiale du projet GMES; « Deliver to
Learn » et « Assess to Structure » ont révélé trois causes interdépendantes derrière le problème de la
non pertinence des informations :
- 10 -
• Les nombreuses organisations impliquées dans la récolte de données et la production
d'informations en Europe ne coordonnent pas suffisamment leurs activités.
• Les nombreuses infrastructures techniques produisent des données qui sont fréquemment
incomplètes, non comparables d'un site à un autre et sont le plus souvent difficile d'accès.
• Un dialogue plus actif entre les utilisateurs de l'information et les fournisseurs est nécessaire pour
obtenir un flux de données et d'information plus pertinent et efficace.
En conséquence, les investissements fait en Europe ces dernières décennies dans la production
d'informations pour l'environnement et la gestion des risques se sont soldés par une faible efficacité
générale et des bénéfices décevants pour les décideurs du service public, les industrie privées, les
scientifiques et les citoyens.
Les compétences GMES se présentent en trois composantes qui
répondent aux problèmes précédents :
• Un partenariat entre les acteurs clés Européens
• Un système d'informations partagé Européen
• Un mécanisme de dialogue permanent
I.4.2. Une solution existante, MASS/SSE
I.4.2.1. Contexte et rôle du portail SSE
Les efforts actuels pour élargir le marché Européen de l'Observation de la Terre (EO) ont mis en
évidence le besoin de services et de produits sur l'information plus proches des attentes du client
(facilement maîtrisables et utilisables sont manipulations).
Aujourd'hui la transformation de produits basiques (comme des images) en informations est réalisée
par un petit nombre de sociétés spécialisées qui opèrent de façon indépendante dans leur domaine
d'application spécifique. Cette séparation augmente les coûts ainsi que les durées de traitement, ce
qui nuit à une optimisation des ressources allouées. Ce problème nuit au déploiement de services
EO rentables, en particulier lorsque le processus ne constitue pas un bloc, mais une répétition de
processus basiques, qui sont réalisée efficacement par des sociétés spécialisées. La mise en place de
- 11 -
partenariats stratégiques pour fournir des services coopératifs peut réduire le coût global, accroître
les performances, permet d'offrir le même service à plus d'utilisateur et élargie l'offre avec de
nouveaux services.
A cette fin, l'identification de l'ensemble des sociétés liées aux standards EO et l'aide d'une entité
neutre et libre pour l'habilitation des services deviennent indispensable.
Le Service Support Environment (SSE) développé par de département segment sol ESA-ESRIN a
comme but d'identifier une voie pour la résolution des problèmes évoqués en implémentant un
environnement orienté service ouvert entre les utilisateurs et les fournisseurs de services. Cet
environnement facilite l'approvisionnement et la gestion des services permettant à chaque
organisation de bien exploiter l'expertise du service, en outre cela permet la création d'un nouveau
service à partir d'un ensemble de services de bases fournis par d'autres fournisseurs.
Les principaux objectifs de SSE sont:
– fournir une infrastructure permettant des interactions de type business to business (B2B) entre
fournisseurs et avec les utilisateurs (B2C),
– permettre aux services basiques mais aussi ceux orchestrés de bout en bout de rester dans
l'infrastructure du fournisseur,
– permettre le rajout et le retrait de services à SSE facilement,
– permettre le chaînage de services pour en produire de plus compliqués,
– permettre les services de type « abonnement » (par exemple, la surveillance et l'alerte sur les
incendies),
– permettre l'évolution et la maintenance des services,
– permettre l'identification et l'accès aisé aux services, avec une visualisation de la progression
jusqu'à la finalisation.
L'infrastructure SSE a été initialement développée dans le projet MASS GSTP durant la période
2001-2003. L'intérêt que le projet GSTP a généré a poussé ESRIN à améliorer le système initial et
cela a abouti à SSE disponible sur http://services.eoportal.org.
- 12 -
I.4.2.2. Éléments constituants d'une chaîne de services
SSE fournit un accès à de nombreux services associés à des activités de nature environnementale,
scientifique, décisionnelle, publique ou commerciale.
Le projet MASS-GSTP a démontré que le système SSE peut être utilisé pour fournir un accès à
différents genres de services:
• Production,
• archives,
• catalogues,
• planification de missions,
• utilitaires.
De plus, ces services peuvent être combinés entre eux de façon à créer des chaînes de services ou
être superposés avec d'autres couches venant d'autres sources comme le montre la figure ci dessous.
Il n'y a pas de restrictions sur la taille des services qui peuvent être simples et réduits (généralement
des composants à combiner avec d'autres pour créer un chaîne complexe) ou plus évolués comme
une application.
- 13 -
Ci dessus un exemple type de workflow modélisé avec le workflow SSE.
I.4.2.3. Chaîne de services utilisant SSE
Sur la figure ci dessous un exemple de chaîne de services. On constate que le résultat final est
obtenu à partir de l'assemblage de services élémentaires.
- 14 -
I.4.2.4. Architecture du portail SSE
Les accès à SSE se font par l'intermédiaire d'un navigateur Web en utilisant HTTP ou HTTPS. Il y a
4 types d'utilisateurs ayant chacun des droits d'accès spécifiques:
• Les utilisateurs anonymes ou les services qui accèdent à des services SSE gratuits.
• Les utilisateurs ou services enregistrés. Ils peuvent faire des devis et commander des services
payants.
• Les fournisseurs de services qui sont autorisés à mettre en ligne leurs services sur le portail SSE.
Ils peuvent également utiliser les services existants pour en utilisant le workflow SSE pour offrir
un service à valeur ajoutée.
• L'administrateur et le service d'assistance de SSE qui gèrent le portail et publient des articles sur
celui ci.
Ci dessous un schéma représentant l'infrastructure SSE.
- 15 -
I.4.2.5. Flux des données et des contrôles dans la chaîne de services
La figure ci dessous représente l'utilisation de SSE dans l'accès et la distribution de données par FTP
dans un exemple ou un service A est demandé par l'utilisateur et consiste en la chaîne de deux
autres services, S1 et S2.
1. L'utilisateur accède à SSE pour rechercher le service ou la donnée qui l'intéresse. Il peut pour
cela utiliser l'annuaire des services qui les organise en catégories et sous-gatégories. Une page de
lui indique les paramètres à donner pour commander le service.
2. Le moteur workflow intégré à SSE sait que le service demande l'invocation d'un premier
fournisseur et transmet la commande à celui ci.
3. Le fournisseur reçoit la commande et effectue le traitement adéquat. Quand celui ci est terminé, il
renvoie le résultat. Le message peut être une adresse FTP ou récupérer les données ou la donnée
elle même si elle est assez petit pour être contenue le message XML.
4. Le moteur workflow sait que la prochaine étape est l'appel à un deuxième service S2 qui reçoit
en entrée le résultat de S1 et quelques informations contenue dans la commande initiale A.
5. Transfère effectif des données d'un fournisseur à l'autre.
- 16 -
6. Lorsque le traitement de S2 est accompli, le fournisseur renvoie ses résultats au moteur workflow
SSE.
7. Le moteur workflow sait maintenant que la commande A est terminée et il l'indique à
l'utilisateur.
8. L'utilisateur peut voir si les résultats sont disponibles sur le portail SSE ou être notifié par email
quand ils le seront. Dans le cas de données de taille importante le message de résultat contient
l'adresse du serveur FTP du dernier fournisseur dans la chaîne.
I.4.3. Cahier des charges de la solution attendue
La singularité du projet GMES se manifeste sur
plusieurs points:
• La criticité des services implique un haut niveau
de sécurité et de disponibilité. Il faut prévoir des
mécanismes minimisant au maximum les
défaillances dans le système ainsi que l'impact
qu'elles produisent. Il faut également prendre en
compte les différents niveaux d'importance que
peuvent avoir des services; un service lié à l'urbanisation (qui change peu sur de courtes
périodes) ne requiert pas le même niveau de disponibilité qu'un service lié aux risques
humanitaires ou aux catastrophes naturelles.
• Le volume des données traitées conditionne la façon dont on gère les données et le transport de
celles ci. Il faut également prendre garde à ce que les ressources informatiques ne soient pas
saturées par un volume trop important. L'engorgement en un point pourrait alors congestionner
les accès à des services dont l'importance peut se révéler cruciale.
• La recherche des informations et des services doit être adaptée, aisée et automatique pour un
agent informatique.
• L'hétérogénéité des ressources doit être gommée de façon à permettre l'exploitation optimale
des informations et des services que chaque élément du réseau peut offrir. Il faut prévoir une
couche d'interface qui permettra d'abstraire les disparités architecturales, et cela sans avoir à
changer le matériel déjà en place.
- 17 -
• La souveraineté de chaque site et la transparence doivent être préservées en vue d'éviter que les
opérateurs actuels ne perdent le contrôle des services qu'ils offrent.
Ci dessus une représentation schématique des différents domaines intervenant dans le contexte
GMES.
- 18 -
Atmosph.LC&V
Ocean
Risks
Water
HumAid
II. Étude des workflows
II.1. Présentation générale sur les workflows
II.1.1. Définition
Un workflow est un flux d'informations au sein d'une organisation, comme, par exemple, la
transmission automatique de documents entre des personnes.
On appelle "WorkFlow" (littéralement "flux de travail") la modélisation et la gestion informatique
de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un
processus métier (aussi appelé processus opérationnel). Le terme de Workflow pourrait donc être
traduit en français par Gestion électronique des processus métier. De façon plus pratique le
WorkFlow décrit le circuit de validation, les tâches à accomplir entre les différents acteurs d'un
processus, les délais, les modes de validation et fournit à chacun des acteurs les informations
nécessaires pour la réalisation de sa tâche. Pour un processus de publication en ligne par exemple, il
s'agit de la modélisation des tâches de l'ensemble de la chaîne éditoriale.
Il permet généralement un suivi et identifie les acteurs en précisant leur rôle et la manière de le
remplir au mieux.
- 19 -
Ci dessous un schéma montrant le rôle d'un workflow dans une organisation.
II.1.2. Modèle de référence WfMC
La WfMC (Workflow Management Coalition) a plus de 300
membres fournisseurs de système de Workflow à travers le
monde. Ils représentent toutes les facettes du domaine :
fournisseurs de logiciels, universités et consultants.
Le but de la WfMC est de développer des standards dans le
domaine de Workflow en collaboration avec les acteurs principaux.
- 20 -
Ci dessous le modèle de référence préconisé par la WfMC
II.1.3. Quelques acteurs du marché• W4 propose l'un des plus grands moteurs de workflow. Une interface au-dessus du moteur est
également proposée par W4, mais une autre peut être créée par toute personne en ressentant le
besoin.
• OpenSymphony, un moteur de workflow Open Source.
• VivTek propose un tool-kit libre de workflow nommé wftk sous licence GNU/GPL.
• OpenWFE est un moteur de workflow open source. Il est écrit en Java, mais possède des
librairies d'accès pour Python et .NET.
• Enhydra Shark, moteur de workflow open-source Java basé sur les standards de la WfMC qui
fonctionne notamment avec l'éditeur XPDL JaWE.
• YAWL est un moteur de workflow Open Source basé sur un langage de modélisation qui dérive
des patrons de conception catalogués dans workflowpatterns.
- 21 -
II.2. Workflows centralisés classiquesComme on le voit sur la figure ci dessous l'intégralité du flux de control est géré par une entité
centrale, le moteur de workflow.
La plupart des solutions actuelles suivent le modèle de référence de la WfMC en établissant un
moteur de workflow central qui coordonne les taches entre elles.
Les acteurs du processus sont isolés entre eux et n'interagissent qu'avec le moteur, ils sont ignorants
du déroulement de l'ensemble et ne voient que la partie qui leur est attribuée.
- 22 -
Comme le montre la figure suivante, chaque étape doit être initiée et validée par le moteur
workflow qui assure la maîtrise d'oeuvre globale.
Il est manifeste que ce système souffre d'une grande vulnérabilité liée à son centralisme:
• la disponibilité de l'ensemble est conditionnée par un seul élément,
• la communication avec plusieurs systèmes hétéroclites est complexe,
• la réactivité et l'évolutivité sont compromises ou difficiles à gérer,
• les performances se dégradent notablement avec l'accroissement de la taille du système.
II.3. Workflows distribués
A cause des contraintes imposées par l'architecture classique des workflows, des recherches ont été
menées afin de palier aux limitations structurelles.
Les systèmes multi agents ces études des solutions permettant de s'affranchir de certains problèmes
- 23 -
du modèle classique.
Le principe est basé sur un système d’agents qui effectuent les différentes taches mais qui gèrent
également eux même l’acheminement des données et les flux de contrôles.
Chaque agent dispose d’une logique lui permet de savoir quand s’activer et quand activer les agents
qui le suivent dans la suite du processus.
Ils disposent pour cela d’une base de connaissance qui par un système de dépendance récursif leur
permet de savoir quel est le prochain élément de la chaîne pour parvenir au but final.
C’est le concept de dépendance sociale.
Ci dessous un schéma mettant en évidence les flux de communications dans une architecture
distribuée.
- 24 -
Une telle révolution dans l'organisation des communications engendre des modifications dans les
possibilités d'un workflow:
• le système n'est plus tributaire d'un élément unique,
• la taille du système n'est plus un problème pour les performances,
• les acteurs ont une visibilité accrue du processus auquel ils participent,
• des systèmes différents cohabitent sans générer d'insurmontables problèmes d'interfaçage,
• la morphologie et l'architecture du système peuvent être changées plus souplement et les
communications peuvent être gérées dynamiquement.
II.4. Mise en évidence des apports d'une solution distribué
Architecture
centralisée
Architecture
distribuéeMise en place dans un
environnement hétérogène difficile.
Mise en place dans un
environnement hétérogène facile.Évolutivité réduite et compliquée. Évolution aisée.
Failles rares mais totales.Failles fréquentes mais partielles
avec possibilité de recouvrement.Contrôles concentrés localement. Contrôles répartis et autonomes.Performances dégradée pour les
gros systèmes.
Supporte les systèmes importants
avec de bonnes performances.
Gestion dynamique des flux et des
ressources difficiles.
Gestion dynamique des flux et des
ressources inhérente à
l’architecture.
- 25 -
II.5. Application du modèle distribué à l'architecture GMES
II.5.1. Solution distribuée pour l’infrastructure GMES
Mettons maintenant en oeuvre un modèle autogéré de chaîne de services ou le portail ne joue plus
un rôle prépondérant.
Dans cette organisation le portail n'a qu'un rôle d'annuaire l'utilisateur peut obtenir les coordonnées
du service qu'il recherche.
Chaque fournisseur sait quel autre fournisseur il doit contacter pour obtenir les données qui lui
seront nécessaires pour sa tâche.
- 26 -
On peut envisager de répartir cet annuaire entre les fournisseurs ou encore de régionaliser avec une
structure arborescente de façon à obtenir un haut niveau de disponibilité.
- 27 -
II.5.2. Architecture d'un noeud
Etudions maintenant les mécanismes à mettre en place au niveau de chaque noeud du système dans
ce modèle distribué:
• Le calculateur ou fournisseur effectif du service.
• Un agent chargé de la gestion des requêtes entrantes et effectuant des requêtes vers d'autres
fournisseurs. Cet agent est en contact avec le portail afin de rendre compte des transactions
effectuées, de se mettre à jour de l'environnement des fournisseurs, et de faire part de ses
disponibilités.
• Un annuaire consulté et mis à jour par l'agent servant à joindre les destinataires des requêtes.
• Un serveur de données servant de zone tampon dans le cas où un traitement immédiat ne serait
pas possible, notamment à cause de calculs en cours ou dans l'attente d'autres données.
- 28 -
II.5.3. Transit des données et du contrôle d'une chaîne de services avec unearchitecture distribuée
Détaillons ce modèle dans le cadre de la chaîne de service vu plus haut.
1. Consultation des services sur le portail par l'utilisateur.
2. Retour de la recherche.
3. Requête au fournisseur qui détiendra la donnée finale.
4. Consultation de l'annuaire.
5. Requête vers un fournisseur.
6. Consultation de l'annuaire.
7. Requête vers un fournisseur.
8. Consultation de l'annuaire.
9. Requête vers un fournisseur.
10.Mise à disposition des données.
- 29 -
11.Envois des données.
12.Traitement des données.
13.Mise à disposition des données.
14.Envois des données.
15.Traitement des données.
16.Mise à disposition des données.
17.Envois des données.
18.Traitement des données.
19.Mise à disposition des données.
20.Transfert des résultats vers l'utilisateur final.
- 30 -
III.1. Les organismes normalisateurs dans le géospatial
OGC
ISO
W3C
III.2. Open Geospatial Consortium (OGC)
L’OGC pour Open Geospatial Consortium est une organisation
internationale à but non lucratif chargée de développer des standards
pour les services de localisation et géospatiaux. Avec une politique de
consensus pilotée par ses membres l’OGC œuvre avec des gouvernements, des entreprises et le
monde universitaire pour créer des applications d’interfaces ouvertes pour les systèmes
d’informations géographiques.
III.2.1. Structure de l'OGC
A travers ses programmes de spécifications, d'interopérabilité et d'assistance, OGC développe, édite
et promeut des standards ouverts pour le traitement de données spatiales.
- 32 -
III.2.2. Les programmes de l'OGC
• Programme de spécification
Dans le programme de spécification, le Technical Committee et le Planning Committee travaillent
par consensus afin d'obtenir l'adoption de spécification OpenGIS.
• Programme d'interopérabilité
Le programme d'interopérabilité consiste en une série d'initiatives destinées à accélérer le
développement et l'adoption des spécifications OpenGIS
• Assistance (Outreach & Community Adoption)
L'OGC et ses membres offrent des ressources pour aider les développeurs et les utilisateurs à
exploiter pleinement des standards ouverts de l'OGC. Des documents techniques, du matériel d'essai
et d'entraînement, des implémentations de référence et d'autres ressources développées dans le cadre
du programme d'interopérabilité sont disponible sur le réseau OGC. De plus de par la mise en places
d'articles, de séminaires et de conférences, OGC et ses membres aident les créateurs de technologies
à introduire les caractéristiques plug and play OGC dans leur architecture.
- 33 -
III.2.3. Les principales normes OGC
• WMS : Web Map Service
• WMC : Web Map Context
• GML : Geographic Markup Language
• WFS : Web Feature Service
• WTS : Web Terrain Service
• WCS : Web Coverage Service
• WPS : Web Processing Service
• CAT : Catalogue Services
III.2.3.1. WMS – Web Map Service
Un WMS produit dynamiquement des cartes de données à partir d'informations géographiques.
Ce standard définit une carte (map) comme une représentation des informations géographiques par
un fichier d'une image numérique susceptible d'être affichée sur un écran d'ordinateur. Une map ne
constitue pas la donnée en elle même. Une image générée par un WMS est généralement sous forme
bitmap (PNG, GIF ou JPEG), ou parfois sous forme vectorielle dans des formats tels que SVG ou
WebCGM.
Ce standard définit trois méthodes:
– une méthode retournant des métadonnées sur le service
– une méthode qui retourne la carte dont les paramètres géographiques et de dimensions sont
correctement définis
– et une troisième méthode facultative qui donne des informations sur un élément donné de la carte
Les méthodes d'un WMS peuvent être appelées via un navigateur Web standard en effectuant une
requête par URL. Le contenu de l'URL dépend de quelle méthode est invoquée. En particulier quand
une map est demandée, l'URL indique quelle informations doivent être intégrée à la map, quelle
partie de la terre doit être cartographiée, quel est le système de coordonnées souhaité et les
dimensions de l'image retournée. Quand deux ou plusieurs map doivent être produites avec les
mêmes paramètres géographiques et les mêmes dimensions, les résultats peuvent être exactement
superposés pour obtenir une map composite. L'utilisation de formats d'images gérant les arrières
- 34 -
plans transparents (PNG, GIF) permet à la carte du dessous d'être visible. En outre différentes cartes
peuvent être obtenus de plusieurs serveurs, le WMS va ainsi créer un réseau de serveurs de cartes
distribué permettant au client de construire des cartes personnalisées.
III.2.3.2. WMC - Web Map Context
Un document de contexte (Context document) comprend des informations relatives aux serveurs qui
fournissent les différentes couches de la carte, les bordures et la projection partagée par toutes les
maps, les métadonnées nécessaires au client pour reproduire la carte et les métadonnées
complémentaires afin d'annoter et de décrire la provenance des cartes pour les utilisateurs humains.
Un document de contexte est structuré par XML (eXtensible Markup Language). Il y a plusieurs
utilisations possibles d'un document de contexte :
– Le document de contexte fournit un point de vue de départ pour des catégories spécifiques
d'utilisateurs. C'est alors un document qui devrait avoir une grande durée de vie et être accessible
au public.
Le document de contexte peut sauvegarder l'état du client quand il navigue et modifie les couches
d'une carte. Il n'y a pas que les paramètres courants qui peuvent être sauvegardés mais également
des informations sur chaque couche (formats, styles disponibles) afin d'éviter des requêtes vers le
serveur de cartes une fois que l'utilisateur a choisi une couche.
– Le document de contexte d'une session client peut être sauvegardé et transféré à une autre
application afin de commencer avec le même contexte.
Les contextes peuvent être répertoriés et consultés, fournissant ainsi un niveau de granularité plutôt
que des couches individuelles.
III.2.3.3. GML – Geography Markup Language
GML est une grammaire XML écrite dans un schema XML pour modéliser les transports et le
stockage d'informations géographiques.
Les concepts clés utilisés par GML pour modéliser le monde sont issus de la spécification OpenGIS
Abstract Specification et des normes ISO 19100.
GML fourni une panoplie de types d'objets pour décrire la géographie comme les features, les
- 35 -
systèmes de coordonnées, la géométrie, la topologie, le temps, les unités de mesure, et les nombres
sans dimension.
Une feature géographique est une abstraction d'un phénomène dans le monde réel, et cela associé à
une position par rapport à la terre. Ainsi une représentation numérique du monde réel peut être vu
comme un ensemble de features. L'état d'une feature peut se définir par un ensemble de propriétés,
ou chaque propriété est constituée par un triplet {nom, type, valeur}.
Le nombre de propriétés (property) qu'une feature peut posséder est déterminé par son type. Les
features géographiques géométriques doivent avoir les propriétés du type géographique. Une
collection de features est un ensemble de features qui peut être à son tour vu comme une feature; en
conséquence, une collection de features possède le type feature et peut avoir par récursivité elle
même comme propriété.
Dans GML les features géographiques incluent les couvertures et les observations comme sous
type.
Une couverture est un sous type de feature qui a une fonction de couverture dont le domaine spatial
et les valeurs limites sont exprimée sous forme de tuples d'au moins deux dimensions. Une
couverture peut représenter une feature ou un ensemble de features pour mettre en évidence le
rapport entre une distribution spatiale et un phénomène sur la Terre.
Une observation modélise le fait d'observer, la plupart du temps avec un appareil photo, un
individu, ou toute forme d'instrument. Une observation est considérée comme une feature GML
avec un paramètre temporel du moment où c'est faite cette observation et sa valeur.
Un système de référence fourni une échelle de mesure permettant d'attribuer des valeurs au lieu, au
temps, et à toute autres description quantitative ou qualitative.
Un système de coordonnées de référence est composé d'un système d'axes liés à la terre par une
donnée définissant la taille et la forme de la Terre. Les géométries en GML indiquent quel système
de coordonnées de référence a été utilisé pour leurs mesures. La géométrie mère d'une géométrie
complexe ou composée crée ces indications pour les géométries dérivées.
Un système temporel de référence fourni des unités standard pour mesurer le temps et décrire les
durées. Suivant la norme ISO 8601, le calendrier Grégorien et temps universel coordonné (UTC)
sont utilisés dans GML comme système temporel de référence par défaut.
Un dictionnaire d'unités de mesure définie mesures de quantités numériques et physiques, comme la
longueur, la température, la pression et les conversions entres elles.
- 36 -
III.2.3.4. WFS - Web Feature Service
La norme OGC Web Map Service permet à un client de superposer plusieurs images données par
plusieurs WMS sur internet. Dans le même style, OGC Web Feature Service permet à un client de
retrouver et de mettre à jour des données encodées en GML par plusieurs WFS.
Les caractéristiques d'un WFS sont les suivantes:
• L'interface doit être définie en XML.
• GML doit être utilisé pour exprimer les features dans
l'interface.
• Au minimum un WFS doit pouvoir présenter des
features en utilisant GML.
• Les prédicats et filtres doivent être défini en XML être
dérivés de CQL comme défini dans l'interface de
spécification du catalogue OpenGIS.
• Le datastore utilisé pour conserver les features doit être
opaque aux applications client qui doivent seulement
voir les données à travers l'interface WFS.
• L'utilisation d'expressions Xpath pour référencer les propriétés.
III.2.3.5. WTS - Web Terrain Service
Un Web Terrain Service (WTS) produit des vues sur des données géoréférencées. Une vue est
définie comme la représentation visuelle d'une donnée géographique; une vue n'est pas la donnée en
elle même mais. Les vues sont généralement rendues dans un format graphique 2D tel que le PNG,
le GIF ou le JPEG. Ce standard indique la manière dont les serveurs décrivent les données qu'ils
contiennent. Deux méthodes sont définies:
• GetCapabilities: Renvoie une métadonnée de service utilisable pas une machine ou un humain
décrivant les informations contenues dans le WTS et les requêtes prises en compte.
• GetView: Renvoie une scène 3D dont les paramètres géospatiaux et dimensionnels sont
indirectement définis.
L'opération GetView définie les paramètres pour une requête HTTP GET et un DTD XML pour une
- 37 -
requête HTTP POST. Il est prévu que GetView supporte une forme limitée de Styled Layer
Descriptor pour supporter les styles nommés et les couches utilisateurs. Cela permettra au WTS de
d'extraire les données d'un WFS, de les positionner sur un terrain et d'appliquer le style approprié.
La méthode GetView d'un WTS est normalement exécutée après une réponse à GetCapabilities
indiquant quelles requêtes sont autorisées et quelles données sont disponibles. GetView retourne une
image dans le format spécifié. La syntaxe et la sémantique sont similaires et dérivées de l'opération
WMS GetMap.
III.2.3.6. WCS - Web Coverage Service
Un WCS fournit un accès à de riches et détaillés ensembles d'informations géospatiales utiles pour
le rendu coté client, les couvertures à valeurs multiples et comme entrée à des modèles scientifiques
ainsi que pour les autres clients. Un WCS peut être comparé à un WMS ou un WFS, comme eux , il
permet aux clients de choisir une partie des informations disponibles sur le serveur sur des bases de
contraintes spatiales ou d'autres critères. Par contre par opposition à un WMS qui filtre et représente
les données spatiales avec des cartes statiques, un WCS fourni des données ainsi que leur
description détaillée, permettant ainsi des requêtes complexes sur ces données et retournant des
données avec la sémantique original, à la place de simples images, qui peuvent être interprétées,
extrapolées, etc. - et non simplement affichées. A l'opposition d'un WFS qui retourne des
caractéristiques Géographiques discrètes, un WCS retourne des représentations de phénomènes
variant dans l'espace, qui lient un domaine spatio-temporel à un champ de propriétés.
Un WCS fournit trois méthodes: GetCapabilities, GetCoverage, DescribeCoverage.
• GetCapabilities retourne un document XML décrivant le service et les ensembles de données
dont les clients peuvent demander une couverture. Les clients vont généralement exécuter cette
commande et la mettre en cache pour réutiliser ses résultats tout au long de la session pour
d'autres sessions. Si GetCapabilities ne peut pas retourner de description sur les données
disponibles, ces informations doivent être disponibles par une autre source, comme un catalogue
d'images.
• DescribeCoverage permet au client de demander une description complète d'une ou plusieurs
couvertures données par un serveur WCS. Le serveur répond avec un document XML qui décrit
totalement la couverture. GetCoverage est normalement exécutée après que GetCapabilities et
- 38 -
DescribeCoverage aient montré quelles requêtes étaient permises et quelles données étaient
disponibles.
• GetCoverage retourne une couverture (valeurs ou propriétés d'un ensemble de lieux
géographiques) empaquetée dans un format de couverture connu. La syntaxe et la sémantique
ressemble aux requêtes GetMap et GetFeature WMS, mais certaines extensions permettent la
récupération de couvertures plutôt que de cartes ou de caractéristiques ponctuelles.
III.2.3.7. WPS - Web Processing Service
Un Web Processing Service (WPS) fourni un accès à des calculs ou des models qui manipulent des
donnée spatiales référencées.
Les données requises par le service peuvent être disponibles localement, ou obtenues par le réseau
en utilisant des standards d'échange de données comme GML ou Géolinked Data Access Service
(GDAS). Le traitement peut être simple comme la soustraction d'un ensemble de nombres
représentant des références spatiales à un autre (par exemple déterminer la différences entre les cas
de grippes suivant les saisons), ou aussi compliqué comme le model du changement du climat
global. La spécification WPS à pour but de fournir un mécanisme d'indentification des données
spatiales référencées requises par les calculs, d'amorcer ceux ci et de gérer les résultats de sorte
qu'ils soient accessibles au client. Un WPS peut être destiné aussi bien aux calculs vectoriels de type
bitmap.
- 39 -
L'interface WPS spécifie trois opérations qui peuvent lancées par le client et effectuées par le
serveur WPS:
1. GetCapabilities – Cette opération permet à un client d'effectuer une requête et de recevoir des
métadonnées qui décrivent les possibilités de l'implémentation spécifique du serveur, comme le
nom des procédures qui peuvent être exécutées. Cette opération permet également une
négociation sur la version utilisée pour les interactions client serveur.
2. DescribeProcess – Cette opération permet au client d'obtenir des informations spécifiques sur
une opération Exucute fournie par le WPS avec les paramètres d'entrée et de sortie ainsi que leur
format.
3. Execute – Cette opération permet au client de lancer une procédure WPS spécifiée avec les
valeurs et paramètres adéquates.
Ces opérations ressemblent beaucoup aux autres Web Services OGC comme WMS, WFS, et WCS.
III.2.3.8. CAT - Catalogue Services
Les services catalogues permettent la publication et la recherche d'ensembles d'informations
descriptives (métadonnées), sur les données, les services et les informations liées à ceux ci. Les
métadonnées dans un catalogue montrent les caractéristiques des ressources auxquelles des requêtes
peuvent être faites et présentent ces ressources d'une façon exploitable à la fois par des humains et
des logiciels. Les services catalogues sont nécessaires pour découvrir et fixer des informations
agrées sur les ressources dans une communauté basée sur l'information.
- 40 -
Le model abstrait spécifie une grammaire BNF comme langage minimal, un noyau d'attributs dur
lesquelles ont peut effectuer des requêtes (noms, définitions, types de données), et un format
commun de record qui définie un ensemble minimal qui doit être retourné.
La communauté géospatiale est une communauté à grande échelle qui travaille sur beaucoup
d'environnements différents comme il est montré sur la figure suivante. A une extrémité il y a de
systèmes étroitement liés destinés à fonctionner dans un environnement cloisonné. A l'autre
extrémité, on trouve des services basés sur le Web qui ne connaissent rien sur le client.
- 41 -
Information discovery continuum
III.3. International Organization for standardization (ISO)
III.3.1. Présentation et rôle de l'ISO
ISO (Organisation internationale de normalisation) est le plus grand
organisme de normalisation au monde. L'ISO a pour activité principale
l'élaboration de normes techniques, mais ces dernières ont aussi d'importants
aspects économiques et sociaux. Les normes ISO ont une influence positive,
non seulement pour les ingénieurs et les fabricants, auxquels elles apportent
des solutions à des problèmes fondamentaux de production et de
distribution, mais pour la société dans son ensemble.
Les Normes internationales que l'ISO élabore sont très utiles. Elles sont utiles aux organisations
industrielles et économiques de tout type, aux gouvernements et aux instances de réglementation,
aux dirigeants de l'économie, aux professionnels de l'évaluation de la conformité, aux fournisseurs
et aux acheteurs de produits et de services, dans les secteurs tant public que privé et, en fin de
compte, elles servent les intérêts du public en général lorsque celui-ci agit en qualité de
consommateur et d'utilisateur.
Les normes ISO contribuent à un développement, à une production et à une livraison des produits et
des services plus efficaces, sûrs et respectueux de l'environnement, ainsi qu'à des échanges facilités
et plus équitables entre les pays. Elles fournissent aux gouvernements une base technique pour la
législation en matière de santé, de sûreté et d'environnement. Elles facilitent le transfert de
technologies aux pays en voie de développement. Les normes ISO servent également à protéger les
consommateurs, et les utilisateurs en général, de produits et services - ainsi qu'à leur simplifier la
vie.
- 42 -
L'ISO est un réseau d'instituts nationaux de normalisation de 153 pays, selon le principe d'un
membre par pays, dont le Secrétariat central, situé à Genève, Suisse, assure la coordination
d'ensemble.
L'ISO est une organisation non gouvernementale: ses membres ne sont pas, comme dans le système
des Nations Unies, des délégations des gouvernements nationaux. L'ISO occupe néanmoins une
position privilégiée entre les secteurs public et privé. La raison tient à ce que l'ISO compte dans ses
membres de nombreux instituts faisant partie de la structure gouvernementale de leur pays ou
mandatés par leur gouvernement et d'autres organismes issus exclusivement du secteur privé, établis
par des partenariats d'associations industrielles au niveau national.
L'ISO peut donc agir en tant qu'organisation de liaison permettant d'établir un consensus sur des
solutions répondant aux exigences du monde économique et aux besoins de la société, notamment
ceux de parties prenantes comme les consommateurs et les utilisateurs.
III.3.2. ISO/TC 211
Domaine des travaux:
Normalisation dans le domaine de l'information géographique numérique.
Ces travaux visent à établir un ensemble structuré de normes relatives à l'information sur les objets
ou les phénomènes qui sont directement ou indirectement associés à une localisation terrestre.
Ces normes peuvent spécifier, pour l'information géographique, des méthodes, outils et services
pour la gestion de données (y compris leur définition et leur description), l'acquisition, le traitement,
l'analyse, l'accès, la présentation et le transfert de ces données sous forme numérique /électronique
entre les différents utilisateurs, systèmes et sites.
Les travaux devront être liés aux normes de technologies de l'information et de données et fournir
un cadre pour le développement d'applications sectorielles utilisant des données géographiques.
III.3.3. Les projets ISO/TC 11
• 19101 (15046-1): Geographic information - Reference model
• 19102 (15046-2): Geographic information - Overview
• (Project deleted, see resolution 192 - Adelaide) 19103 (15046-3): Geographic information -
- 43 -
Conceptual schema language
• 19104 (15046-4): Geographic information - Terminology
• 19105 (15046-5): Geographic information - Conformance and testing
• 19106 (15046-6): Geographic information - Profiles
• 19107 (15046-7): Geographic information - Spatial schema
• 19108 (15046-8): Geographic information - Temporal schema
• 19109 (15046-9): Geographic information - Rules for application schema
• 19110 (15046-10): Geographic information - Feature cataloguing methodology
• 19111 (15046-11): Geographic information - Spatial referencing by coordinates
• 19112 (15046-12): Geographic information - Spatial referencing by geographic identifiers
• 19113 (15046-13): Geographic information - Quality principles
• 19114 (15046-14): Geographic information - Quality evaluation procedures
• 19115 (15046-15): Geographic information - Metadata
• 19116 (15046-16): Geographic information - Positioning services
• 19117 (15046-17): Geographic information - Portrayal
• 19118 (15046-18): Geographic information -: Encoding
• 19119 (15046-19): Geographic information - Services
• 19120 (15854): Geographic information - Functional standards
• 19120/Amedmend 1: Geographic information - Functional standards - Amendment 1
• 19121 (16569): Geographic information - Imagery and gridded data
• 19122 (16822): Geographic information/Geomatics - Qualifications and Certification of
Personnel
• 19123 (17753): Geographic information - Schema for coverage geometry and functions
• 19124 (17754): Geographic information - Imagery and gridded data components
• 19125-1: Geographic information - Simple feature access - Part 1: Common architecture
• 19125-2: Geographic information - Simple feature access - Part 2: SQL option
• 19125-3: Geographic information - Simple feature access - Part 3:COM/OLE option
• 19126: Geographic information - Profile - FACC Data Dictionary
• 19127: Geographic information - Geodetic codes and parameters
• 19128: Geographic information - Web Map server interface
• 19129: Geographic information - Imagery, gridded and coverage data framework
- 44 -
• 19130: Geographic information - Sensor and data models for imagery and gridded data
• 19131: Geographic information - Data product specifications
• 19132: Geographic information - Location based services possible standards
• 19133: Geographic information - Location based services tracking and navigation
• 19134: Geographic information - Multimodal location based services for routing and
navigation
• 19135: Geographic information - Procedures for registration of geographical information
items
• 19136: Geographic information - Geography Markup Language (GML)
• 19137: Geographic information - Generally used profiles of the spatial schema and of similar
important other schemas
• 19138: Geographic information - Data quality measures
• 19139: Geographic information - Metadata - Implementation specifications
• 19140: Geographic information - Amendment to the ISO 191** Geographic information
series of standards for harmonization and enhancements
III.4. World Wide Web Consortium (W3C)
III.4.1. Présentation et rôle
Le World Wide Web Consortium, abrégé W3C, est un consortium fondé en octobre
1994 pour promouvoir la compatibilité des technologies du World Wide Web telles
que HTML, XHTML, XML, CSS, PNG, SVG et SOAP. Le W3C n'émet pas des normes, mais des
recommandations.
Sa gestion est assurée conjointement par le Massachusetts Institute of Technology (MIT) aux États-
Unis, le European Research Consortium for Informatics and Mathematics (ERCIM) en Europe
- 45 -
(auparavant l'Institut national de recherche en informatique et en automatique français (INRIA)) et
l'Université Keio au Japon.
Un document W3C traverse plusieurs étapes avant de devenir une Recommendation : Working
Draft (brouillon de travail), Last Call (dernier appel), Proposed Recommendation (recommandation
proposée), et Candidate Recommendation (candidat à la recommandation). Une recommandation
peut être mise à jour par errata édité séparément, jusqu'à l'accumulation de suffisamment de
modifications ; une nouvelle version de la recommandation est alors publiée (XML en est
aujourd'hui à sa troisième version). Parfois, une recommandation recommence le processus, comme
RDF. Le W3C publie aussi des remarques informatives qui ne sont pas destinées à être traitées en
tant que norme.
Le consortium laisse le soin aux fabricants de suivre les recommandations. Contrairement à
l'Organisation internationale de normalisation ou d'autres corps internationaux de standardisation, le
W3C ne possède pas de programme de certification, et beaucoup de standards ne définissent pas
formellement un niveau de conformité. Ils sont ainsi souvent implantés partiellement.
III.4.2. Technologies W3C
L'illustration suivante présente une vue de l'infrastructure du Web avec les différentes technologies
développées par W3C.
- 46 -
Maintenant nous allons présenter les différentes technologies W3C intéressantes pour le géospatial
et susceptibles d'être utilisées dans le cadre du projet GMES.
III.4.2.1. Extensible Markup Language (XML)
L'objectif initial de XML était de faciliter le partage de textes et d'informations structurés, par
exemple au travers de l'Internet, en séparant le contenu (les données) du contenant (la présentation
des données). Il constitue une simplification de SGML bien qu'il apporte des améliorations quant à
la portabilité, notamment grâce à l'intégration d'Unicode.
Les dialectes XML (XSLT, XML Schema, XHTML, RDF/XML, SOAP, SMIL, MathML, SVG)
sont décrits de façon formelle : une structure de données simple est définie avec une DTD
(Document Type Definition), une structure de données détaillée est définie avec un XML Schema
ou tout autre DSDL.
- 47 -
Il existe des outils (qui peuvent être gratuits ou libres) permettant la manipulation de ces définitions
(Processeurs XML). La disponibilité d'une syntaxe standard et d'outils de manipulation réduit
significativement le coût du cycle de développement, permettant à des programmes de modifier et
de valider, sans connaissances préalables, des documents écrits dans ces langages. En effet, avant le
succès d'un langage généraliste de description de données tel que XML, les concepteurs de logiciels
avaient pour habitude de définir leurs propres formats de fichiers ou leurs propres langages pour
partager les données entre programmes. Ceci nécessitait de concevoir et de programmer des
analyseurs syntaxiques dédiés.
Un fichier XML est un fichier texte. Le codage des caractères est défini dans la première déclaration
du document. Par défaut il s'agit de UTF-8, une transcription binaire particulière de Unicode, un
format qui diffère peu de l'ASCII (sur-ensemble).
Le fichier XML est structuré en « éléments » à l'aide de « balises » qui marquent le début et la fin de
chaque élément. Les éléments peuvent contenir du texte et éventuellement d'autres éléments (le mot
« élément » est donc trompeur). L'ensemble des données du document XML est contenu dans un
élément unique appelé « racine », élément qui contient tous les autres éléments.
Outre les éléments et le contenu des éléments, on trouve aussi dans un document XML:
• des commentaires (qui ne font pas partie des données au sens strict),
• des instructions de traitement (directives données au processeur XML),
• des « appels » de caractère (pour coder des caractères qui n'existent pas dans le codage choisi
pour le document tout entier),
• des « appels » d'entités (permet l'appel d'une entité nommée qui est une sorte de « macro » de
texte).
III.4.2.2. Simple Objet Access Protocol (SOAP)
SOAP (Simple Object Access Protocol) définit un protocole permettant des appels de procédures à
distances (RPC) s'appuyant principalement sur le protocole HTTP et sur XML, mais aussi SMTP et
POP. Il permet ainsi de définir des services Web. Les paquets de données circulent sous forme de
- 48 -
texte structuré au format XML (Extensible Markup Language).
Microsoft a basé sur SOAP sa nouvelle architecture services Web .NET. Le protocole SOAP est une
note du Consortium W3C dont Microsoft fait partie, mais qui n'est pas spécifique à Microsoft et
Windows. IBM a également participé à l'élaboration de ce protocole. De plus il existe des
implémentations Java, et Borland vient déjà d'implémenter SOAP sous Windows dans Delphi 6 et
sous Linux avec Kylix.
Le principal avantage de SOAP est qu'il repose sur 2 standards XML (pour la structure des
messages) et HTTP ( pour le transport) bien qu'il soit utilisable avec d'autres protocoles de
transport. Par rapport à tous les autres protocoles de RPC, celui-ci présente l'avantage de
l'interopérabilité, on est indépendant des plates-formes et des langages de programmation. Le
second avantage réside dans le déploiement des applications, principalement dans un contexte
multi-sîtes, pour communiquer entre 2 sociétés via Internet, c'est souvent mission-impossible
d'utiliser autre chose que du HTTP ou du POP/SMTP à cause des Firewalls, car pour les autres
protocoles il faut les reconfigurer, avec tous les trous de sécurité que cela peut engendrer, et cela
implique souvent de longues négociations avec les administrateurs réseaux. SOAP permet de
s'affranchir de tout cela.
Un message SOAP est fondamentalement une transmission unidirectionnelle entre des noeuds
SOAP, d'un émetteur SOAP vers un récepteur SOAP, mais les messages SOAP sont supposés être
combinés par les applications pour implémenter les séquences plus complexes d'interactions, de la
requête-réponse aux échanges multiples "conversationnels" dans un sens et dans l'autre.
Le protocole SOAP est composé de deux parties :
• une enveloppe, contenant des informations sur le message lui-même afin de permettre son
acheminement et son traitement,
• un modèle de données, définissant le format du message, c'est-à-dire les informations à
transmettre.
- 49 -
Ci contre un exemple de message d'une
application de réservation de voyages qui
négocie pour un employé avec le service de
réservation pour un circuit planifié.
III.4.2.3. Web Services
Un service Web est un ensemble de protocoles et de normes informatiques utilisés pour échanger
des données entre les applications.
- 50 -
Les logiciels écrits dans divers langages de programmation et sur diverses plateformes peuvent
employer des services Web pour échanger des données à travers des réseaux informatiques comme
Internet. Cette interopérabilité est due à l'utilisation de normes ouvertes. L'OSI et le World Wide
Web Consortium (W3C) sont les comités de coordination responsables de l'architecture et de
standardisation des services Web. Pour améliorer l'interopérabilité entre les réalisations de service
Web, l'organisation WS-I (Web Services Interoperability) a développé une série de profils pour faire
évoluer les futures normes impliqués.
Les normes employées:
• Web Services Protocol Stack : Les services Web se composent d'une collection de normes que
l'ont regroupe sous ce terme.
• XML : Toutes les données à échanger sont formatées en XML. Ce codage peut être effectué par
SOAP ou XML-RPC.
• Protocoles communs : Des données en XML peuvent être transportées entre les applications en
utilisant des protocoles communs tels que HTTP, FTP, SMTP et XMPP.
• WSDL : L'interface publique au service Web est décrite par ce protocole en cours de
normalisation. C'est une description XML qui décrit la façon de communiquer en utilisant le
service Web.
• UDDI : Le service Web est connu sur le réseau au moyen de ce protocole. Il permet à des
applications de rechercher le service Web dont elles ont besoin.
Avantages des services Web:
• Les services Web fournissent l'interopérabilité entre divers logiciels fonctionnant sur diverses
plateformes.
• Les services Web utilisent des normes et protocoles ouverts.
• Les protocoles et les formats de données sont au format texte dans la mesure du possible,
facilitant ainsi la compréhension du fonctionnement global des échanges.
• Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de nombreux
firewalls sans nécessiter des changements sur les règles de filtrage.
Inconvénients des services Web:
• Les normes de services Web dans les domaines de la sécurité et des transactions sont
- 51 -
actuellement inexistantes ou toujours dans leur petite enfance comparée à des normes ouvertes
plus mûres de l'informatique répartie telles que CORBA.
• Les services Web souffrent de performances faibles comparées à d'autres approches de
l'informatique répartie telles que le RMI, CORBA, ou DCOM.
• Par l'utilisation du protocole HTTP, les services Web peuvent contourner les mesures de sécurité
mises en place au travers des firewalls.
• Rien ne permet pour l'instant d'assurer la qualité d'exécution d'un Service Web. Il n'y a donc
aucune qualité de service ou QoS associée à ces derniers.
Ci dessous une figure présentant l'établissement d'un service Web entre deux agents.
III.4.2.4. Web Services Description Language (WSDL)
Il s'agit d'une tentative de normalisation regroupant la description des éléments permettant de mettre
- 52 -
en place l'accès à un service réseau (Service Web). Il fait notamment référence au langage XML et a
été proposé en 2001 au W3C pour standardisation.
La version 1.1 n'est pas approuvée par le W3C, cependant un travail est en cours sur une nouvelle
version : la version 2.0 qui a pour ambition de devenir un standard officiel approuvé par le W3C.
Le WSDL décrit une Interface publique d'accès à un Service Web. C'est une description basée sur le
XML qui indique « comment communiquer pour utiliser le service »; le Protocole de
communication, et le format de messages requis pour communiquer avec ce service. Les opérations
possibles et messages sont décrits de façon abstraite mais cette description renvoie à des protocoles
réseaux et formats de messages concrets.
Le WSDL est principalement soutenu par Ariba, IBM et Microsoft.
III.4.2.5. Semantic Web
Le Semantic Web a comme ambition d'automatiser au niveau sémantique, non seulement le lien
entre bases de données et le partage des informations entre applications, mais aussi la combinaison
de Services Web. Face à des critiques lui reprochant de négliger la standardisation des Services
Web au profit du Semantic Web, le W3C répond donc que Semantic Web et Services Web sont
complémentaires. L'un ayant en charge le contenu sémantique des données et leur intégration, les
autres, la transmission de ces données, comme HTML pour contenu et HTTP pour transmission.
D'ailleurs, selon Tim Berners-Lee, Directeur Général du W3C, considéré comme le créateur du
Web, les réflexions du W3C sur le Semantic Web, qualifiées par certains de "théoriques", peuvent
parfaitement être aussi très utiles pour les performances des Services Web.
En effet, le Semantic Web est basé sur les assertions RDF, qui permettent de modéliser et décrire le
monde réel, pas seulement des documents, et ainsi faciliter les liens qui enrichissent un Service
Web. Par exemple dans le commerce de l'automobile, la modélisation Semantic Web reliant les
différents types d'objets permettrait à l'application de trouver facilement le lien entre véhicule et
conducteur, entre numéro d'immatriculation et permis de conduire, entre photo du véhicule et
adresse du propriétaire etc. Et cela en remplaçant les arborescences classiques entre objets
théoriques par un Web, une toile, reliant choses, lieux et personnes du monde réel. Pour Tim
- 53 -
Berners-Lee, "your life is a Web, your data is a Web" !
III.4.2.6. Web Ontology Language (OWL)
Le World Wide Web dans son état actuel ressemble à une géographie mal cartographiée. Notre
compréhension des documents et les moyens dont nous disposons se fondent sur des recherches par
mots-clés, que confortent une utilisation astucieuse de la connectivité des documents et les
habitudes. Cette véritable masse de données est ingérable sans l'aide d'un outil puissant. Afin de
cartographier plus précisément ce territoire, les agents calculateurs ont besoin de descriptions,
interprétables par une machine, du contenu et des capacités des ressources accessibles par le Web.
Ces descriptions doivent s'ajouter aux versions de ces informations qui sont lisibles par un humain.
Le langage d'ontologie Web OWL sert à décrire des classes et leurs relations, lesquelles sont
inhérentes aux documents et applications Web.
Le pourquoi de OWL
Le Web sémantique est une vision future du Web selon laquelle les informations reçoivent une
signification explicite, facilitant le traitement et l'intégration automatiques des informations
disponibles sur le Web par des machines. Le Web sémantique reposera sur la capacité de XML à
définir des systèmes de balisage personnalisés et sur la souplesse de RDF à représenter des données.
Un langage ontologique, qui puisse décrire formellement la signification de la terminologie
employée dans les documents Web, représente le premier niveau nécessaire au Web sémantique au-
dessus de RDF. Si on attend des machines qu'elles effectuent des opérations de raisonnement utiles
sur ces documents, alors le langage doit dépasser la sémantique de base du schéma RDF.
Le langage OWL répond au besoin d'un langage d'ontologie Web et il appartient à la famille en
pleine croissance des recommandations liées au Web sémantique.
• Le langage XML procure une syntaxe de surface aux documents structurés mais n'impose aucune
contrainte sémantique sur leur signification.
• Le langage de schéma XML restreint la structure des documents XML en ajoutant le typage des
- 54 -
données à XML.
• RDF, un modèle de données pour des objets (ressources) et leurs relations, fournit une
sémantique simplifiée pour ces modèles de données, qui peuvent être représentés dans une
syntaxe XML.
• Le schéma RDF est un vocabulaire permettant de décrire les propriétés et les classes des
ressources RDF, avec une sémantique pour des hiérarchies de généralisation de ces propriétés et
classes.
• Le langage OWL renforce le vocabulaire de description des propriétés et des classes : entre
autres, les relations entre les classes (par exemple, la disjonction), la cardinalité (par exemple, un
seul exactement), l'égalité, le typage enrichi des propriétés, les caractéristiques des propriétés
(par exemple, la symétrie) et les classes énumérées.
Les trois sous-langages de OWL
Le langage OWL fournit trois sous-langages, d'expressivité croissante, destinés à des communautés
spécifiques de développeurs et d'utilisateurs.
• Le langage OWL Lite est destiné aux utilisateurs ayant principalement besoin d'une hiérarchie de
classification et de contraintes simples. Par exemple, bien qu'obéissant à des contraintes de
cardinalité, il n'admet que des valeurs de cardinalité de 0 ou 1. Il devrait être plus facile de mettre
en œuvre des outils pour OWL Lite que pour ses parents plus expressifs et OWL Lite offre une
voie de migration rapide pour les thésaurus et autres taxonomies. OWL Lite a également une
complexité formelle inférieure à celle de OWL DL.
• Le langage OWL DL est destiné aux utilisateurs qui demandent une expressivité maximale tout
en retenant la complétude du calcul (toutes les inférences sont garanties calculables) et la
décidabilité (tous les calculs s'achèveront dans un intervalle de temps fini). OWL DL comprend
toutes les structures de langage OWL, utilisables avec certaines restrictions cependant (par
exemple, alors qu'une classe peut-être une sous-classe de plusieurs classes, une classe ne peut pas
être une instance d'une autre). OWL DL se nomme ainsi en raison de ses liens avec la logique
descriptive [ndt. description logics], un champ de la recherche qui étudie la logique qui sous-tend
la fondation formelle de OWL.
• Le langage OWL Full est destiné aux utilisateurs qui veulent une expressivité maximale et la
- 55 -
liberté syntaxique de RDF sans garantie de calcul. Par exemple, dans OWL Full, une classe peut
se traiter simultanément comme une collection d'individus ou comme un individu à part entière.
OWL Full autorise une ontologie à augmenter le vocabulaire prédéfini (RDF ou OWL). Il est peu
probable qu'un système de raisonnement puisse mettre en œuvre toutes les caractéristiques de
OWL Full.
Chacun de ces sous-langages représente une extension par rapport à son prédécesseur plus simple, à
la fois par ce qu'on peut légalement exprimer et par ce qu'on peut conclure de manière valide. Les
affirmations suivantes sont vraies. Leurs symétriques ne le sont pas.
• Toute ontologie OWL Lite légale est une ontologie OWL DL légale.
• Toute ontologie OWL DL légale est une ontologie OWL Full légale.
• Toute inférence OWL Lite valide est une inférence OWL DL valide.
• Toute inférence OWL DL valide est une inférence OWL Full valide.
Les développeurs d'ontologies qui adopteront OWL devraient évaluer quel sous-langage convient le
mieux à leurs besoins. Le choix entre OWL Lite et OWL DL dépendra des besoins des utilisateurs,
de la nécessité d'utiliser les structures de restriction plus expressives de OWL DL. Celui entre OWL
DL et OWL Full dépendra principalement des facilités de méta-modélisation offertes par le schéma
RDF (par exemple, en définissant des classes de classes, ou en attachant des propriétés aux classes).
Dans une utilisation de OWL Full, à comparer à OWL DL, la gestion du raisonnement est moins
prévisible car il n'existe pas actuellement de mise en œuvre OWL Full complète.
On peut considérer OWL Full comme une extension de RDF, tandis que OWL Lite et OWL DL
comme des extensions d'une vue restreinte de RDF. Tout document OWL (Lite, DL, Full) est un
document RDF, et tout document RDF est un document OWL Full, mais seuls certains documents
RDF seront des documents OWL Lite ou OWL DL légaux. À cause de cela, on doit se montrer
prudent lors de la migration d'un document RDF vers OWL. Lorsque la capacité d'expression de
OWL DL ou OWL Lite est jugée appropriée, on doit prendre quelques précautions afin de s'assurer
que le document RDF original satisfasse aux contraintes supplémentaires imposées par OWL DL et
OWL Lite. Entre autres, on doit explicitement confirmer toute adresse URI, utilisée comme nom de
- 56 -
classe, comme étant de type owl:Class(idem pour les propriétés), on doit confirmer tout individu
comme appartenant à au moins une classe (même s'il s'agit seulement de la classe owl:Thing), les
adresse URI utilisées pour les classes, les propriétés et les individus doivent être mutuellement
disjointes.
- 57 -
IV. ConclusionCette première expérience professionnelle s'inscrit en complément du savoir et du savoir faire que
j'ai acquis durant mon cursus universitaire. En effet, étant rodé au monde du développement ce
stage de recherche m'aura initié à l'aventure des recherches et des études qui se déroulent en amont
de toute entreprise d'implémentation, me conférant ainsi une vision pertinente sur toute l'étendue
des projets informatiques.
De nos jours la veille technologique et la recherche d'information constituent une pierre angulaire à
maîtriser. Ainsi les nombreuses journées passées à me documenter ont considérablement accru mes
l'efficacité de mes méthodes dans ce domaine.
D'un point de vue technique la multitude de technologies étudiées a significativement enrichi mon
bagage informatique et scientifique.
Sur un plan relationnel l'expérience de la vie en entreprise m'aura été profitable et agréable en
particulier auprès d'une équipe très accueillante et conviviale que je remercie au passage, en
particulier bien sur mon maître de stage M. LEVY.
Cette expérience a été d'autant plus notable qu'elle s'est déroulée au sein d'une entreprise de grande
envergure.
En définitive ces quelques mois à travailler sur un projet de grande envergure auront donc
confortablement fructifié mes compétences informatiques et personnelles.
- 58 -
V. AnnexesV.1. Acronymes
ASCII : American Standard Code for Information Interchange
B2B : business-to-business
B2C : Business to Consumer
BNF : Backus Naur Form (Forme de Backus-Naur)
CAT : Catalogue Services
CGM : Computer Graphics Metafile
CORBA : Common Object Request Broker Architecture
CSS : Cascading Style Sheets (feuilles de style en cascade)
DCOM : Distributed Component Object Model
DESS : Diplôme d'Etudes Supérieurs Spécialisées
DTD : Document Type Definition
DTDL : Document Type Definition Language
EADS : European Aeronautic Defence and Space company
ERCIM : European Research Consortium for Informatics and Mathematics
ESA : European Space Agency (agence spatiale européenne)
ESRIN : European Space Research INstitute
FTP : File Transfer Protocol
GDAS : Géolinked Data Access Service
GIF : Graphics Interchange Format
GIS : Geographical Information System
GMES : Global Monitoring for Environment and Security
GML : Geography Markup Language
GNU : GNU's Not UNIX (acronyme récursif)
GPL : General Public License (Licence publique générale)
HTML : HyperText Markup Language
HTTP : HyperText Transfer Protocol
- 59 -
HTTPS : HTTP over SSL
INRIA : Institut national de recherche en informatique et en automatique
ISO : International Organization for Standardization (Organisation internationale de normalisation)
JPEG : Joint Photographic Experts Group
LC&V : Land Cover & Vegetation
MASS-ENV : Multi-Application Support Service System Environment
MIT : Massachusetts Institute of Technology
OGC : Open Geospatial Consortium
OGSA : Open Grid Services Architecture
OWL : Web Ontology Language
PNG : Portable Network Graphics
POP : Post Office Protocol
QoS : Quality of Service (qualité de service)
R&D : Research and Development
RDF : Resource Description Framework
RMI : Remote Method Invocation
RPC : Remote procedure call
SGML : Standard Generalized Markup Language
SMIL : Synchronized Multimedia Integration Language
SMTP : Simple Mail Transfer Protocol
SOA : Service Oriented Architecture (Architecture Orientée Services)
SOAP : Simple Object Access Protocol
SSE : Srvice Support Environment
SVG : Scalable Vector Graphics
UDDI : Universal Description Discovery and Integration
URL : Uniform Resource Locator
UTC : Temps universel coordonné
UTF-8 : UCS transformation format 8 bits
W3C : World Wide Web Consortium
WCS : Web Coverage Service
WfMC : Workflow Management Coalition
- 60 -
WFS : Web Feature Service
WMC : Web Map Context
WMS : Web Map Service
WPS : Web Processing Service
WSD : Web Services Description
WSDL : Web Services Description Language
WS-I : Web Services Interoperability
WTS : Web Terrain Service
XHTML : eXtensible HyperText Markup Language
XML : eXtensible Markup Language
XMPP : Extensible messaging and presence protocol
XPDL : XML Process Definition Language
XSLT : Extended Stylesheet Language Transformations
V.2. Bibliographie
Quelques-uns des documents et sites qui m'auront servi durant mon stage:
Service Support Environment Architecture, Model and Standards; Decembre 2004
earth.esa.int/rtd/Documents/SSE_Whitepaper_2.pdf
http://www.gmes.info
http://www.w3.org
http://www.iso.org
Workflow Management Coalition The Workflow Reference Model; janvier 1995
www.wfmc.org/standards/docs/tc003v11.pdf
- 61 -
Functionality and Limitations of Current Workflow Management Systems
http://www.almaden.ibm.com/cs/exotica/wfmsys.pdf
Dartflow, a workflow management system on the web using transportable agents; mai 1995
ftp://ftp.cs.dartmouth.edu/TR/TR96-283.pdf
A software architecture for distributed workflow enactment with agents and web services ; 2004
jmvidal.cse.sc.edu/papers/paul-dissertation.pdf
A Data Storage Mechanism for Peer-to-Peer Based Decentralised Workflow Systems
http://www.it.swin.edu.au/personal/yyang/papers/SEKE2003.pdf
Forming Agents for Workflow-Oriented Process Orchestration
http://www.cs.georgetown.edu/~blakeb/pubs/blake_ICEC2003.pdf
The Semantic Web
http://www.scientificamerican.com/print_version.cfm?articleID=00048144-10D2-1C70-
84A9809EC588EF21
A Preliminary Investigation into Dynamic Distributed Workflow
http://www.tffenterprises.com/~dmz/publications/ms_thesis.pdf
SwinDeW - A p2p-based Decentralised Workflow Management System
http://www.it.swin.edu.au/personal/yyang/papers/SwinDeW-TSMC.pdf
- 62 -