Rapport de stage ETUDE D'ARCHITECTURE DES FUTURS SEGMENTS SOL...

DESS CAMSI2004-2005

Rapport de stage

ETUDE D'ARCHITECTURE DES FUTURSSEGMENTS SOL D'OBSERVATION

Tuteur de stage : François THIEBOLT

[email protected]

Olivier JEAN-THEODORE

mars 2005 – juillet 2005

Maître de stage : Fabrice LEVY

[email protected]

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.3.5. Planning

I.3.5.1. Calendrier des tâches

I.3.5.2. Diagramme de Gantt

- 9 -

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.





10.Mise à disposition des données.

- 29 -

11.Envois des données.

12.Traitement des données.








20.Transfert des résultats vers l'utilisateur final.

- 30 -

III. Organisations et standards dansle domaine géospatial

- 31 -

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 -

Rapport de stage ETUDE D'ARCHITECTURE DES FUTURS SEGMENTS SOL...

Documents

Transcript of Rapport de stage ETUDE D'ARCHITECTURE DES FUTURS SEGMENTS SOL...