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

Transcription

1 DESS CAMSI Rapport de stage ETUDE D'ARCHITECTURE DES FUTURS SEGMENTS SOL D'OBSERVATION Olivier JEAN-THEODORE mars 2005 juillet 2005 Maître de stage : Fabrice LEVY fabrice.levy@astrium.eads.net Tuteur de stage : François THIEBOLT thiebolt@irit.fr

2 Table des matières I.Présentations... 4 I.1.Présentation du DESS... 4 I.2.Présentation d'astrium... 4 I.2.1.L'entreprise... 5 I.2.2.Le département Systèmes Sol, Applications & Services...5 I.3.Présentation du stage...7 I.3.1.Sujet...7 I.3.2.Objet du stage...7 I.3.3.Déroulement du stage... 7 I.3.4.Environnement logiciel...8 I.3.5.Planning... 9 I Calendrier des tâches... 9 I Diagramme de Gantt...9 I.4.Présentation du projet GMES I.4.1.Le besoin d'une infrastructure I.4.2.Une solution existante, MASS/SSE I Contexte et rôle du portail SSE I Éléments constituants d'une chaîne de services...13 I Chaîne de services utilisant SSE...14 I Architecture du portail SSE I 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 II.Étude des workflows II.1.Présentation générale sur les workflows...19 II.1.1.Définition...19 II.1.2.Modèle de référence WfMC II.1.3.Quelques acteurs du marché II.2.Workflows centralisés classiques II.3.Workflows distribués...23 II.4.Mise en évidence des apports d'une solution distribué...25 II.5.Application du modèle distribué à l'architecture GMES II.5.1.Solution distribuée pour l infrastructure GMES...26 II.5.2.Architecture d'un noeud...28 II.5.3.Transit des données et du contrôle d'une chaîne de services avec une architecture distribuée III.Organisations et standards dans le domaine géospatial...31 III.1.Les organismes normalisateurs dans le géospatial... 32

3 III.2.Open Geospatial Consortium (OGC) III.2.1.Structure de l'ogc...32 III.2.2.Les programmes de l'ogc Programme de spécification...33 Programme d'interopérabilité...33 Assistance (Outreach & Community Adoption) III.2.3.Les principales normes OGC...34 III WMS Web Map Service III WMC - Web Map Context...35 III GML Geography Markup Language III WFS - Web Feature Service...37 III WTS - Web Terrain Service...37 III WCS - Web Coverage Service III WPS - Web Processing Service III CAT - Catalogue Services...40 III.3.International Organization for standardization (ISO) III.3.1.Présentation et rôle de l'iso III.3.2.ISO/TC III.3.3.Les projets ISO/TC III.4.World Wide Web Consortium (W3C) III.4.1.Présentation et rôle III.4.2.Technologies W3C III Extensible Markup Language (XML) III Simple Objet Access Protocol (SOAP)...48 III Web Services...50 III Web Services Description Language (WSDL)...52 III Semantic Web III Web Ontology Language (OWL) IV.Conclusion V.Annexes...59 V.1.Acronymes...59 V.2.Bibliographie...61

4 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-

5 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 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-

6 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-

7 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-

8 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-

9 I.3.5. Planning I Calendrier des tâches I Diagramme de Gantt -9-

10 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 :

11 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 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

12 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 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

13 I É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

14 Ci dessus un exemple type de workflow modélisé avec le workflow SSE. I 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

15 I 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

16 I 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

17 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 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

18 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. HumAid Risks Ocean LC&V Water Atmosph. Ci dessus une représentation schématique des différents domaines intervenant dans le contexte GMES

19 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

20 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

21 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

22 II.2. Workflows centralisés classiques Comme 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

23 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

24 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

25 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 Architecture centralisée distribuée Mise en place dans un Mise en place dans un environnement hétérogène difficile. environnement hétérogène facile. Évolutivité réduite et compliquée. Évolution aisée. Failles fréquentes mais partielles Failles rares mais totales. avec possibilité de recouvrement. Contrôles concentrés localement. Contrôles répartis et autonomes. Performances dégradée pour les Supporte les systèmes importants gros systèmes. avec de bonnes performances. Gestion dynamique des flux et des Gestion dynamique des flux et des ressources difficiles. ressources inhérente à l architecture

26 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

27 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é

28 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

29 II.5.3. Transit des données et du contrôle d'une chaîne de services avec une architecture 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

30 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

31 III. Organisations et standards dans le domaine géospatial

32 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

33 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

34 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 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

35 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 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 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 GML fourni une panoplie de types d'objets pour décrire la géographie comme les features, les

36 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

37 III 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 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

38 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 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

39 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 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

40 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 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

41 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

42 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

43 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 ( ): Geographic information - Reference model ( ): Geographic information - Overview (Project deleted, see resolution Adelaide) ( ): Geographic information

44 Conceptual schema language ( ): Geographic information - Terminology ( ): Geographic information - Conformance and testing ( ): Geographic information - Profiles ( ): Geographic information - Spatial schema ( ): Geographic information - Temporal schema ( ): Geographic information - Rules for application schema ( ): Geographic information - Feature cataloguing methodology ( ): Geographic information - Spatial referencing by coordinates ( ): Geographic information - Spatial referencing by geographic identifiers ( ): Geographic information - Quality principles ( ): Geographic information - Quality evaluation procedures ( ): Geographic information - Metadata ( ): Geographic information - Positioning services ( ): Geographic information - Portrayal ( ): Geographic information -: Encoding ( ): Geographic information - Services (15854): Geographic information - Functional standards 19120/Amedmend 1: Geographic information - Functional standards - Amendment (16569): Geographic information - Imagery and gridded data (16822): Geographic information/geomatics - Qualifications and Certification of Personnel (17753): Geographic information - Schema for coverage geometry and functions (17754): Geographic information - Imagery and gridded data components : Geographic information - Simple feature access - Part 1: Common architecture : Geographic information - Simple feature access - Part 2: SQL option : 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