PROPOSITION DE DOSSIER D ARCHITECTURE LOGICIELLE ET TECHNIQUE (D.A.1.)

PROPOSITION DE DOSSIER D ARCHITECTURE LOGICIELLE ET TECHNIQUE (D.A.1.) en date du 24 novembre 2006 relatif à l appel d offre pour la réalisation du lot 5 de l inventaire national spatialisé des émissions de polluants dans l air Le présent D.A.1. comprend 42 pages numérotées de 1 à 42

SOMMAIRE Documents applicables...4 Documents de référence...4 1. Introduction...5 1.1. Objet...5 1.2. Evolutions du document d architecture... 5 1.3. Audience du document...5 1.4. Contenu du document...5 1.5. Notation...5 1.5.1. Les diagrammes de classe... 6 1.5.2. Les diagrammes de cas d utilisation...7 1.5.3. Les diagrammes de processus...7 1.5.4. Les diagrammes d activités...8 1.5.5. Les diagrammes de déploiement...9 1.6. Acteurs projet...10 1.7. Positionnement du document...10 2. Cadre d élaboration d architecture...11 2.1.1. Principes d architecture...11 3. Cadre fonctionnel...12 3.1. Identifications des acteurs...12 3.1.1. Les utilisateurs INS...12 3.1.2. Acteurs non nominaux...13 3.2. Modèle de domaine INS...14 3.3. Système A et système B...15 3.4. Cycle d alimentation des données INS...15 3.5. Système A et système B...16 3.6. Cas d utilisation...17 3.6.1.1. Cas d'utilisation «Administration»...17 3.6.1.2. Cas d'utilisation «Gestion des extractions»...18 3.6.1.3. Cas d'utilisation «Mise à jour INS»...19 3.6.1.4. Cas d'utilisation «Intégration données non spatialisées»...20 3.6.1.5. Cas d'utilisation "Restitution accès libre»...21 3.6.1.6. Cas d'utilisation "Restitution Utilisateurs habilités»...21 3.6.1.7. Cas d'utilisation "Gestion des scénarios»...22 3.7. Contraintes fonctionnelles...23 3.7.1. Disponibilité de l application...23 3.7.2. Sécurité...23 3.7.3. Sécurité des échanges avec les systèmes connexes...23 3.7.4. Temps de réponse des demandes interactives...23 3.7.5. Temps de réponse des requêtes non interactives...24 3.8. Eléments de volumétrie...24 3.8.1. Volumétrie de données non spatialisées (Système A)...24 3.8.2. Volumétrie de données spatialisées (Système B)...24 3.8.3. Profil des demandes interactives...24 3.9. Trace et journalisation...24 3.10. Configuration des applications...25 3.11. Formats de données dans les échanges...25 3.12. Sauvegarde, archivage, purge des données...25 3.12.1. Purge des données...25 3.12.2. Sauvegarde...26 2

4. Architecture logique...26 4.1. Le système A (INSA)...26 4.2. Le système B (INSB)...27 4.3. Communication Système A Système B...27 4.3.1. Décomposition fonctionnelle du système B...27 4.3.2. Découpage logique du système B...28 4.3.3. Communication entre INSB_UH et INSB_AL...29 4.4. Architecture logicielle...29 4.4.1. Architecture Web SIG...29 4.5. Les logiciels de base préconisés(sgbd,serveurs applicatifs, systèmes d exploitations)31 4.6. Le domaine de données INS...32 4.6.1. Catégories de données...32 4.6.1.1. Les données géographiques (GEO))...32 4.6.1.2. Les données des émissions (EMS)...33 4.6.1.3. Les données des scénarios ou données de simulation (SIM)...33 4.6.1.4. Les données précalculées (CALC)...33 4.6.2. Bases de données INS...33 5. Architecture de déploiement...35 5.1. N uds de déploiement...35 5.2. Déploiement des composants...36 5.2.1. Plate forme INSA...36 5.2.2. Plate forme INSB...37 5.3. Eléments de dimensionnement...40 5.3.1. Spécification et dimensionnement des n uds de déploiement...40 5.4. Dimensionnement des espaces de stockage...42 3

Documents applicables Document Description Version Auteur Date [DA1] Dossier d architecture logicielle et technique 1.0 Synapse 27/10/2006 Documents de référence Document Description Version Auteur Date [DR1] CCTP_ INS_20050629.doc : CCTP relatif à l appel d offre pour la réalisation d un inventaire national spatialisé des émissions de polluants dans l air 1.0 Ministère de l Ecologie 29/06/2005 [DR2] Referentiel_General_Interoperabilite_V olet_technique_v0.90.pdf 0.90 Ministère délégué au budget 07/04/2006 [DR3] Charte_Ergonomique_Application_Cart ographie_juin04.pdf MEDD Juin 2004 Table de matières des figures Figure 1 - Exemple de diagramme de classe...6 Figure 2 - Exemple de diagramme de cas d'utilisation...7 Figure 3 - Exemple de digramme de processus...8 Figure 4 - Exemple de diagramme d'activité...9 Figure 5 - Exemple diagramme de déploiement...10 Figure 6 - Acteurs nominaux INS...12 Figure 7 - Acteurs non nominaux INS...13 Figure 8 - Acteurs non nominaux et leurs relations...14 Figure 9 - Entités du domaine INS...15 Figure 10 - Cycle d'alimentation des données...16 Figure 11 - Décomposition INS en systèmes A et B...17 Figure 12 - Cas d'utilisation "Administration"...18 Figure 13 - Cas d'utilisation "Gestion des extractions»...19 Figure 14 - Cas d'utilisation "Mise à jour INS"...20 Figure 15 - Cas d'utilisation «Intégration données non spatialisées»...21 Figure 16 - Cas d'utilisation "Restitution en accès libre»...21 Figure 17 - Restitution vers Utilisateurs habilités...22 Figure 18 -Cas d utilisation «Gestion des scénarios»...23 Figure 19 - Alimentation du système A à partir des sources existantes...26 Figure 20 - Communication Système A - Système B...27 Figure 21 -Modules fonctionnels INSB...28 Figure 22 - Décomposition logique du système B (INSB)...29 Figure 23 - Mise à disposition des données vers le système INSB_AL...29 Figure 24 - Architecture logicielle WEB SIG pour INS...30 Figure 25 - Catégories de données INS...32 Figure 26 - Base de données du système A...34 Figure 27 - Bases de données du système B...35 Figure 28 - N uds de déploiement INS...36 Figure 29 - Déploiement de la plate forme INSA...37 Figure 30 - Déploiement de la plate forme B...39 Figure 31 - Exemple de dimensionnement des noeuds INSA...40 Figure 32 - Exemple de dimensionnement des noeuds INSB...41 4

1. Introduction 1.1. Objet Ce document décrit les orientations en termes d architecture logicielle et de déploiement pour l Inventaire National Spatialisé des Emissions, projet initié par le Ministère de l Ecologie et Du Développement Durable. 1.2. Evolutions du document d architecture Les orientations d architecture contenues dans ce document devront être affinées lors de la phase de consolidation de besoin par le prestataire informatique retenu, aussi bien pour l architecture logicielle que pour l architecture de déploiement. Parmi les éléments non définis à ce jour d architecture logicielle, on peut notamment citer le Système d Information Géographique cible. 1.3. Audience du document Les instances de pilotage de l INS ainsi que le prestataire informatique du lot 5. 1.4. Contenu du document Ce document s articule autour des chapitres suivants : Cadre fonctionnel L architecture d un système doit répondre en premier lieu aux contraintes fonctionnelles de celui-ci. Ce chapitre fait un rappel des principaux éléments fonctionnels influant sur les orientations d architecture proposées. Ces éléments sont exprimés sous la forme de cas d utilisation, de la description des acteurs et de celle des principaux flux. Architecture logicielle Ce chapitre identifie les principaux modules et sous-systèmes de l INS, ainsi que les responsabilités et les interactions entre ces modules. Architecture de déploiement (technique) Les éléments d architecture logicielle identifiés précédemment sont associés à des n uds et des machines (serveurs et postes clients). Ce chapitre fournit également un premier dimensionnement de la plate-forme de déploiement, quant aux machines et aux espaces de stockage associés. 1.5. Notation La notation UML 2.0 1 est utilisée pour la plupart des schémas présentés dans ce document, afin de faciliter la communication entre les différents acteurs concernés par l architecture de l INS. Les différents types de diagrammes utilisés permettent d exprimer plusieurs vues du système : une vue statique - à travers des diagrammes de cas d utilisation, diagrammes de classe et diagrammes de déploiement ; une vue dynamique - à travers de diagrammes d activité et de processus. 1 Unified Modeling Language : langage (conventionnel) pour la modélisation des systèmes sous forme graphique 5

1.5.1. Les diagrammes de classe Les diagrammes de classe décrivent le système du point de vue statique. Ils contiennent des entités ou des acteurs. Une entité est une notion forte du système. Les acteurs sont des sujets bénéficiaires - des fonctionnalités - du système mais ils peuvent représenter également des systèmes connexes. Comme les classes, les acteurs peuvent se trouver en relation d association les uns avec les autres : en relation d association simple, en relation d héritage s ils partagent des caractéristiques communes. Les classes et les acteurs peuvent être manipulés au niveau générique, mais aussi en terme d instances (exemple : «Polluant SO2» est une instance de la classe «Polluant»). Les classes et les acteurs peuvent être d ordre abstrait (représenté en italique) ce qui signifie qu ils sont là seulement pour permettre de classifier plus facilement l information sans avoir pour autant une réalité en termes d instance. Les classes et les acteurs peuvent se trouver en relation d héritage (ou généralisation si elle est observée dans le sens inverse), pour signifier que les caractéristiques et le comportement d une classe sont hérités dans l autre classe. Exemple : l «administrateur» est un «utilisateur habilité» (i.e. l administrateur hérite des caractéristiques d un utilisateur habilité comme l identifiant, le mot de passe, les droits sur les fonctionnalités, etc.). Dans la Figure 1, la «Classe n 2» hérite de la classe «Classe n 1», ou dans le sens inverse «Classe n 1» est une généralisation de la «Classe n 1». Figure 1 - Exemple de diagramme de classe 6

1.5.2. Les diagrammes de cas d utilisation Les diagrammes de cas d utilisation montrent la manière dont les différents utilisateurs du système (les acteurs) bénéficient des différentes fonctionnalités du système, par des associations entre les deux. L ensemble des cas d utilisation décrit l utilisation du système du point de vue de ses utilisateurs. La notation permet également d inclure les cas d utilisation les uns dans les autres, d étendre les cas en les «branchant» les uns dans les autres ou même d utiliser des relations d héritage (de manière similaire aux relations d héritage entre les classes et les acteurs). Nous utilisons ici les associations simples entre les acteurs et les cas d utilisation, ainsi que l inclusion des cas d utilisation, pour signifier le découpage d un cas d utilisation en plusieurs cas de niveau plus réduit. Figure 2 - Exemple de diagramme de cas d'utilisation 1.5.3. Les diagrammes de processus Les diagrammes de processus représentent les différentes tâches d un processus, et mettent en évidence les groupements de ces tâches sur un même site ou même système. Les tâches peuvent produire ou peuvent être alimentées par des objets. Des événements de plusieurs types permettent de mettre en évidence le déclenchement ou la terminaison de processus, ou des événements apparaissant pendant le déroulement du processus. Le présent document utilise peu de diagrammes de processus. Ces derniers sont habituellement utilisés dans les descriptions fonctionnelles des systèmes. 7

Figure 3 - Exemple de digramme de processus 1.5.4. Les diagrammes d activités Les diagrammes d activités contiennent des activités qui s enchaînent. Des objets peuvent se trouver en entrée ou en sortie de certaines activités. Les activités sont réalisées par un exécutant non spécifié, mais il est possible de spécifier des acteurs exécutant des activités ; dans ce cas, chaque exécutant (une instance de classe, d acteur) bénéficie d un «couloir de nage» contenant ses propres activités. 8

Figure 4 - Exemple de diagramme d'activité 1.5.5. Les diagrammes de déploiement Les diagrammes de déploiement (ou d implémentation) définissent les configurations de déploiement du système, en montrant comment les artefacts sont répartis sur les n uds du système. Les n uds de déploiement sont des machines, des équipements réseau ou de stockage. Un type de n ud est également utilisé («environnement d exécution») pour représenter les logiciels de base présents sur les machines, comme un système d exploitation, un SGBD, un SIG. Les n uds peuvent être reliés pour faire apparaître les connexions de communication comme par exemple la communication entre un serveur applicatif et un serveur de base de données. Comme pour les classes et les acteurs, les diagrammes de déploiement permettent de travailler à un niveau logique (les n uds type) et au niveau des instances des n uds. 9

1.6. Acteurs projet Figure 5 - Exemple diagramme de déploiement Les acteurs suivants sont identifiés au niveau du projet : le prestataire du lot 5 (MOE : Maîtrise d uvre) ; les prestataires des lots 1, 2, 3 et 4 ; le MEDD (MOA : Maîtrise d Ouvrage) ; l exploitant INS (EXP : Exploitant) ; le comité de pilotage du projet (Copil) ; le groupe de travail de suivi des travaux (GT5). 1.7. Positionnement du document Ce document exprime les principales orientations d architecture de l Inventaire National Spatialisé. Ces orientations représentent des clauses techniques particulières pour la partie architecture du système, complétant les clauses de niveau fonctionnel et organisationnel contenues dans le document DR1. Pour atteindre le niveau d une architecture opérationnelle pour un projet de développement (architecture détaillée), certains éléments peuvent nécessiter davantage de détails lors de la phase de conception ou des choix peuvent être ajustés par rapport à l évolution du contexte du projet. De manière générale, l architecture du système vit tout au long d un projet et fait l objet d un travail permanent d audit et d évolutions, malgré son caractère fondateur dans les phases amont du projet. 10

2. Cadre d élaboration d architecture Ce chapitre répertorie les éléments à la base des orientations d architecture, en termes de principes d architecture (ingénierie), mais surtout du point de vue fonctionnel. 2.1.1. Principes d architecture L adéquation fonctionnelle Une architecture doit répondre avant tout à un besoin fonctionnel donné, qui va guider les principaux choix et la structure. Les cas d utilisation, ainsi que les principales contraintes fonctionnelles présentées dans ce document, synthétisent le besoin fonctionnel déterminant les choix d architecture. Modularité Le système doit être modulaire afin de maîtriser sa conception initiale et sa maintenance par la suite. Applications de standards Les spécifications du système doivent être basées sur des standards techniques existants ou sur des solutions standard incluant : protocoles de communication (http, SOAP) ; spécification des interfaces de services (Web services, composants J2EE)) ; formats de représentation externe des données (XML) ; standards et solutions industrielles pour la partie SIG, incluant : o les services de présentation ; o les services de données. Orientation service L orientation service fait référence à l architecture SOA (Architecture Orienté Service), devenue une orientation de fond des SI (Système d Information) actuels. Le futur système doit identifier une couche d interaction de niveau service exposant ses fonctionnalités à ses propres modules (de présentation) et constituant également un point d interopérabilité du système. Orientation composants Le système sera structuré sous la forme de composants, implémentés de manière standard en fonction de la plate-forme cible. Intégration dans l infrastructure SI existante La solution devra s intégrer dans l infrastructure SI existante à chaque fois que la réutilisation d une brique existante du SI actuel peut apporter une réponse satisfaisante. Intégration dans l infrastructure d exploitation L architecture de déploiement INS doit s intégrer et bénéficier de l infrastructure mise à disposition par l exploitant de la solution. Ceci inclut : les logiciels de sauvegarde pour les bases de données ; les systèmes de surveillance d applications ; l infrastructure réseau. 11

3. Cadre fonctionnel 3.1. Identifications des acteurs On identifie un premier niveau d acteurs du futur système, incluant les utilisateurs nominaux et les systèmes externes à INS. 3.1.1. Les utilisateurs INS Les utilisateurs définissent un profil d utilisation du système, en termes de fonctionnalités utilisées et type d utilisation. «intégrateur données INS» Figure 6 - Acteurs nominaux INS Utilisateur spécialisé dans l intégration des données en entrée de l INS, en provenance des systèmes alimentant INS. «accès libre» Utilisateur anonyme accédant par Internet pour consulter les rapports, cartes et données pré calculées de l INS mis à sa disposition. «utilisateur habilité» Il s agit d utilisateurs bénéficiant d une habilitation pour accéder au système. Les utilisateurs habilités ont accès à l ensemble des données non confidentielles ainsi qu à l ensemble des fonctionnalités du système. Les différentes spécialisations des utilisateurs habilités sont : «administrateur» : ce profil a accès à toutes les fonctionnalités INS, incluant les fonctionnalités administratives ; «mission de service public» : ce profil a accès à l ensemble des fonctionnalités INS, hormis les fonctionnalités administratives. 12

3.1.2. Acteurs non nominaux Ce diagramme classifie les acteurs de type système, en identifiant : système INS - le système INS lui-même ; système externe INS - l ensemble des systèmes à l extérieur de l INS. Ceci inclut les systèmes alimentant INS en données d inventaire et les systèmes destination de flux de données en provenance de l INS ; système source INS - les systèmes fournisseurs de données d inventaire pour l INS ; système destination INS - des systèmes ; système PREV AIR - le système de prévisions de la qualité de l air, un des clients majeurs de INS, représenté comme un cas particulier de «Système destination INS». Figure 7 - Acteurs non nominaux INS 13

Les trois systèmes sont positionnés du point de vue des flux échangés en amont/aval les uns par rapport aux autres : 3.2. Modèle de domaine INS Figure 8 - Acteurs non nominaux et leurs relations Le modèle de domaine capte les principales notions de l INS sous la forme d entités, comme : les données de référence (nomenclatures d activités ou de spéciation, clés de temporalisation) ; les polluants ; les émissions et données associées telles que d activité, les facteurs d émission, etc. ; les scénarios de calcul ; les paramètres de scénario ; les sources d émission ; la référence spatiale ; etc. La Figure 9 présente un exemple de modèle de domaine pour, la spécification complète de ce modèle devant être réalisée en mode projet. 14

3.3. Système A et système B Figure 9 - Entités du domaine INS En termes de traitement des données faisant l objet de l inventaire est prévue une phase de consolidation et de validation des données en provenance des différentes sources de données par le biais d un système dédié : le système A (INSA) ne manipule pas des données spatialisées dans le sens SIG du terme ; la partie opérationnelle de l inventaire spatialisé, incluant le support pour le calcul des scénarios et la restitution des données spatio-temporalisées, est assurée par un deuxième système, le système B (INSB). Le diagramme suivant représente l INS en tant qu agrégats des systèmes A et B. 3.4. Cycle d alimentation des données INS Les données en entrée de l inventaire rentrent dans deux grandes catégories : les données des émissions et les référentiels fonctionnels, en provenance des bases de données des inventaires existants au niveau national et régional ; les données de référence pour la partie SIG, en provenance des fournisseurs des bases de données SIG. 15

Ces deux catégories de données sont intégrées dans l INS dans cet ordre et à des stades différents, tel que présenté dans la Figure 10. En final, sont mises à disposition des utilisateurs et du système PREV AIR les données de l inventaire national spatialisé. 3.5. Système A et système B Figure 10 - Cycle d'alimentation des données En termes de traitement des données faisant l objet de l inventaire est prévue une phase de consolidation et de validation des données en provenance des différentes sources de données par le biais d un système dédié : le système A (INSA) ne manipule pas des données spatialisées dans le sens SIG du terme ; 16

la partie opérationnelle de l inventaire spatialisé, incluant le support pour le calcul des scénarios et la restitution des données spatio-temporalisées, est assurée par un deuxième système, le système B (INSB). Le diagramme suivant représente l INS en tant qu agrégat des systèmes A et B. 3.6. Cas d utilisation Figure 11 - Décomposition INS en systèmes A et B Les cas d utilisation captent les grandes fonctionnalités que le futur système de l INS doit exposer, et considérées comme représentatives pour la définition de l architecture. Le dossier de conception générale du système contiendra l intégralité des cas d utilisation. 3.6.1.1.Cas d'utilisation «Administration» L «administrateur» de l INS gère les demandes des utilisateurs demandeurs d un accès habilité. Une acceptation de demande débouche ensuite sur la création d un nouvel utilisateur habilité et des tâches administratives. L «administrateur» supervise également l exécution des requêtes lourdes, soumises par les utilisateurs habilités en fonction de leurs droits. 17

Figure 12 - Cas d'utilisation "Administration" 3.6.1.2.Cas d'utilisation «Gestion des extractions» Le système A doit mettre à disposition du système B les données non spatialisées. Le système B doit mettre à disposition : les données de l inventaire national spatialisé pour le système PREV AIR ; les résultats des requêtes différées sur les sites de ses utilisateurs ; les requêtes en ligne relatives aux utilisateurs en «accès libre». 18

Figure 13 - Cas d'utilisation "Gestion des extractions» 3.6.1.3.Cas d'utilisation «Mise à jour INS» Le diagramme suivant identifie les responsabilités des acteurs systèmes lors d une mise à jour de l INS, au niveau des systèmes externes (sources INS) et des systèmes A et B. Le diagramme offre une vue cas d utilisation du diagramme concernant le cycle d alimentation de l INS présenté dans le diagramme Figure 10 - Cycle d'alimentation des données. 19

Figure 14 - Cas d'utilisation "Mise à jour INS" 3.6.1.4.Cas d'utilisation «Intégration données non spatialisées» L intégration des données non spatialisées dans le système A concerne un nombre restreint d utilisateurs, effectuant l importation et surtout la validation des données importées. L utilisateur «Intégrateur de données de l INS» est amené à travailler avec des procédures standard mises à disposition par le système (batch d importation), mais aussi par des requêtes spécifiques sur la base de données du système A. 20

Figure 15 - Cas d'utilisation «Intégration données non spatialisées» 3.6.1.5.Cas d'utilisation "Restitution accès libre» L utilisateur «en accès libre» accède aux données de l inventaire à travers une interface de type client SIG Web, lui permettant de spécifier les données à restituer et les paramètres de présentation. Le système applique pour l utilisateur en «accès libre» des restrictions concernant la résolution des données consultables et le type des données consultables en termes de confidentialité. Figure 16 - Cas d'utilisation "Restitution en accès libre» 3.6.1.6.Cas d'utilisation "Restitution Utilisateurs habilités» La restitution vers les utilisateurs «habilités» (i.e. «Mission de service public» et «administrateur») est soumise à des restrictions en fonction des droits attribués par l administrateur - fonctionnel - du système. En règle générale : l «administrateur» de l INS a accès à toutes les fonctionnalités et au niveau confidentiel des données ; 21

les utilisateurs «Mission de service public» bénéficient d un accès aux fonctionnalités réglementé par des droits attribués par l «administrateur», mais ils n ont pas accès au niveau confidentiel des données. Figure 17 - Restitution vers Utilisateurs habilités 3.6.1.7.Cas d'utilisation "Gestion des scénarios» Les requêtes de scénarios sont des requêtes lourdes en termes de : ressources consommées sur la base de données et du serveur de traitement (CPU notamment) ; coûteuses en temps d exécution ; elles peuvent durer plusieurs heures, voire plusieurs jours. Compte tenu de ces éléments, une requête de scénario passe par une demande d exécution, traitée par l «administrateur» de l INS pour les aspects : rejet / acceptation de la demande ; planification d exécution de la demande ; restitution des résultats du scénario. 22

Figure 18 - Cas d utilisation «Gestion des scénarios» 3.7. Contraintes fonctionnelles 3.7.1. Disponibilité de l application Le niveau de disponibilité varie en fonction des fonctionnalités de l application. Ainsi, les fonctionnalités accessibles par Internet sans habilitation doivent assurer une qualité de service élevée vis à vis de l utilisateur final, compatible avec les applications Internet. Les fonctionnalités de la partie destinés aux utilisateurs habilités devront être disponibles au moins dans une extension des heures ouvrables. 3.7.2. Sécurité L utilisateur «en accès libre» accède librement à l INS, via Internet, bénéficiant seulement des fonctionnalités de restitution restreintes. Les autres profils utilisateur doivent être authentifiés, et en fonction de leur identité (leur profil) ils auront des restrictions d accès sur les axes suivants : le niveau d agrégation des données ; le périmètre des données ; les fonctionnalités (exemple : exécution des scénarios). 3.7.3. Sécurité des échanges avec les systèmes connexes Parmi les systèmes connexes on peut énumérer PREV AIR, les fournisseurs de données d émissions, les sites FTP utilisés pour le dépôt des résultats des requêtes. Aucun mécanisme concernant l authentification, l intégrité ou la confidentialité de ces échanges n est prévu actuellement. Les mécanismes de sécurité devront être négociés avec les systèmes connexes en mode projet. 3.7.4. Temps de réponse des demandes interactives Les temps de réponse pour la partie «en accès libre» doivent être compatibles avec les applications cartographiques accessibles sur Internet. La restitution d une carte pourra ainsi prendre jusqu à 10 secondes en fonction du nombre de couches demandées par l utilisateur. 23

Les opérations d administration ordinaires (par exemple : gestion des droits des utilisateurs) ou les opérations de gestion des scénarios (hors exécution) se situeront en dessous de 5 secondes. 3.7.5. Temps de réponse des requêtes non interactives Les demandes non interactives peuvent donner lieu à des traitements lourds, nécessitant des temps de traitement prévisibles de l ordre plusieurs heures (les requêtes de scénario notamment). 3.8. Eléments de volumétrie 3.8.1. Volumétrie de données non spatialisées (Système A) Le volume des données de référence non spatialisées est estimé actuellement à 60 Go, avec un stockage dans une base de données. Cette base sera utilisée pour dimensionner l espace de stockage dans la partie Architecture de déploiement. 3.8.2. Volumétrie de données spatialisées (Système B) La base d estimation pour les données spatialisées est de 3 To par année. 3.8.3. Profil des demandes interactives Les demandes du système B sont hiérarchisées en plusieurs catégories. Même si l effort de calcul dans l absolu reste difficile à évaluer à ce stade, la hiérarchisation des demandes est une base pour la définition de l architecture logique et de déploiement du système B. Les demandes utilisateur courantes sont présentées ci-dessous : Tâche / Requête Niveau de la charge induite Tâches d administration applicative Création / modification de scénarios Faible Faible Restitution cartographique des données préelevée calculées Restitution cartographique des données demoyen référence de l inventaire Exécution des scénarios Elevé 3.9. Trace et journalisation L INS comprend une infrastructure de journalisation applicative, permettant de tracer : des événements fonctionnels configurables (exemple : la création d un utilisateur, l exécution d un scénario, etc.) ; les erreurs survenues dans l application ; des informations de support pour le diagnostic, à la demande. Le format et le contenu des traces disponibles doivent être traités dans les dossiers de conception détaillée de l application. 24

3.10. Configuration des applications L INS comprend une infrastructure de configuration, basée sur l utilisation d un fichier de configuration au niveau de chaque application déployée au niveau serveur. Ceci inclut les systèmes INSB_AL et INSB_UH. La spécification des paramètres de configuration doit être traitée dans les dossiers de spécifications détaillées. 3.11. Formats de données dans les échanges Les flux générés par l INS utilisent le format XML et les standards XML 1.0. La définition des schémas XML correspondant aux différents flux doit être traités dans le dossier de spécifications générales. Des interfaces existantes dans les systèmes connexes à l INS peuvent justifier l utilisation de formats de données autres que XML. 3.12. Sauvegarde, archivage, purge des données La sauvegarde opérationnelle des données (images de sites Web, sauvegardes de bases de données) sont hors périmètre applicatifs (prise en charge par l exploitant du système). L archivage des données et la purge des données font partie du périmètre applicatif. La spécification des modules d archivage et de purge doit être intégrée dans le dossier de spécifications détaillées de l application 3.12.1. Purge des données La période de rétention des données est de 3 ans. A partir de la quatrième année un traitement de purge annuel doit être réalisé. Le tableau suivant présente le nombre d années en lignes pour les différents catégories de données INS, en régime de croisière : A_Ref - l année de référence de l inventaire, l année 2004 ; A-1, A-2, - les deux dernières années disponibles, etc. ; A_Sup - une année supplémentaire pour le rechargement possible d une année archivée. Catégorie de données Données «en accès libre» Années en ligne 4 A-1 Détail des années de rétention A-2 A_Réf A_Sup Données en accès habilité 3 A-1 A-2 A_Ref 25

3.12.2. Sauvegarde Compte tenu des volumes importants des données, une sauvegarde systématique de toutes les données des bases peut être lourde à gérer. Des techniques de sauvegarde incrémentale (proposés par le SGBD utilisé) combinées avec des sauvegardes complètes lors de jalons d extraction / intégration dans les sous-systèmes INS peuvent assurer une gestion efficace des sauvegardes. En mode projet, le dossier de mise en exploitation doit spécifier une stratégie de sauvegarde appropriée pour éviter les pertes de données de l INS. 4. Architecture logique 4.1. Le système A (INSA) Le rôle du système A est la consolidation des données d inventaire en provenance des différentes sources et l homogénéisation de ces données. Dans le système A, les données ne sont pas spatialisées dans le sens SIG du terme. Elles sont néanmoins géoréférencées, afin de permettre leur spatialisation ultérieure dans le système B. Le diagramme d activité suivant présente l alimentation de INSA à partir des flux générés par les systèmes sources. Figure 19 - Alimentation du système A à partir des sources existantes 26

4.2. Le système B (INSB) Le système B est le système «opérationnel» de l INS, dont les principales fonctionnalités sont la restitution des informations de l inventaire et le support pour la création des scénarios à partir des données de l inventaire. 4.3. Communication Système A Système B Le système A alimente le système B une fois par an, avec un flux contenant les données non spatialisées et non temporisées de l inventaire pour l année précédente (A-1). Figure 20 - Communication Système A - Système B 4.3.1. Décomposition fonctionnelle du système B Le diagramme suivant présente une décomposition fonctionnelle (possible) de plus haut niveau du système B en plusieurs modules ou sous-systèmes. Ce découpage est à consolider par le futur prestataire du lot informatique. Import / Export Cette partie est responsable de l intégration des données non spatialisées en provenance du système A (voir Communication INSA- INSB) et de l export des données vers PREV AIR. Gestion diffusion Ce module est responsable de la diffusion des requêtes de restitution, vers les systèmes destinataires. Restitution de l INS Il s agit du sous-système central de l INS, réalisant la restitution vers les utilisateurs nominaux (i.e. «en accès libre» et la catégorie des utilisateurs habilités). Ceci inclut les restitutions interactives de type SIG, les restitutions interactives des données numériques, les résultats des requêtes de scénarii. Gestion scénarios La gestion des scénarios comprend la planification et la surveillance des requêtes de scénario. Habilitation Le module Habilitation assure des fonctionnalités d acceptation/rejet des demandes d habilitation, la création de ces utilisateurs et la gestion de leurs droits 27

Figure 21 -Modules fonctionnels INSB 4.3.2. Découpage logique du système B Les fonctionnalités du système B peuvent être groupées en deux grandes catégories ayant des contraintes différentes en termes de disponibilité, d habilitation et de traitements. On distingue ainsi une partie spécialisée pour l accès libre (AL) et une partie spécialisée pour les utilisateurs habilités (UH). La décomposition du système B en deux systèmes séparés dédiés au service «en accès libre» et des utilisateurs habilités est une orientation majeure d architecture motivée principalement par : les contraintes de disponibilité : l utilisateur de la partie «AL» est un utilisateur anonyme, accédant via Internet à l INS. Cette partie de l application doit adopter une politique propre aux applications Internet en terme de disponibilité, les clients de l application n étant pas identifiés (impossible de les notifier par exemple) ; la consommation de ressources sous-jacente : les ressources consommés par les utilisateurs AL sont à priori moindres que celles consommées par une requête émise par un utilisateur habilité. Ces données sont en effet pré calculées pour la plupart. Le fait de laisser en compétition l utilisateur «en accès libre» avec les utilisateurs habilités pénalise systématiquement les utilisateurs «en accès libre» ; le périmètre de données accessible (sécurité) : dans la politique d accès aux données de l inventaire on remarque une restriction forte lors du passage des profils habilités (identifiés) au profil «en accès libre» (anonyme). La séparation en deux systèmes permet de simplifier les problèmes de sécurité en mettant à disposition des utilisateurs anonymes uniquement les données auxquelles ils ont droit, et de mettre en place une sécurité applicative traitant uniquement des utilisateurs identifiés. On distingue ainsi deux systèmes : INSB_AL la partie en accès libre ; INSB_UH la partie en accès habilité. 28

Figure 22 - Décomposition logique du système B (INSB) Dans la suite de ce document nous considérerons que le système B est constitué de ces deux systèmes séparés, cette séparation étant prolongée dans la partie Architecture de déploiement également. 4.3.3. Communication entre INSB_UH et INSB_AL La séparation en deux systèmes différents fait apparaître un flux d alimentation de la partie INS_AL, contenant les données de mise à jour de l inventaire à destination des utilisateurs «en accès libre». Ces données sont des données agrégées pour la plupart. Figure 23 - Mise à disposition des données vers le système INSB_AL 4.4. Architecture logicielle 4.4.1. Architecture Web SIG L INS adopte une architecture de type WEB SIG, telle que présentée dans le diagramme suivant : 29

Figure 24 - Architecture logicielle WEB SIG pour INS Par rapport à une architecture Web n tiers classique, on remarque la présence des services SIG applicatifs de type WMS et WFS, en suivant les orientations Open GIS. Le client INS Plusieurs types de clients sont envisageables, en fonction des profils d utilisation de l application et du type d application. Un client Web (navigateur Web) permet d accéder au Frontal Web pour le contenu Web classique (pages HTML dynamiques) sur les applications des deux systèmes INS_AL et INS_UH ou pour exploiter des services WMS en s appuyant sur des plugins spécifiques. Des clients lourds pourront exploiter également les services WFS pour des fonctionnalités avancées. Frontal Web Le frontal Web assure la partie présentation des applications INS Services SIG applicatifs Structurer les services SIG applicatifs sous la forme de services WMS et WFS assurent un alignement sur les standards SIG actuels et un fort potentiel d évolution des applications INS par rapport à l intégration avec des clients SIG capables de consommer des services standards. Moteur SIG Le moteur SIG supporte aussi bien l implémentation de services «métier» que celle des services SIG créés par l application. Le niveau de support diffère en fonction du périmètre couvert par le produit. Par exemple, les fonctionnalités d analyse nécessaires au calcul des scénarios peuvent ne pas être prises en compte par le produit SIG. Dans ce cas, les services métier devront compenser ce manque de fonctionnalités. 30

Services métier Cette couche assure des services comme les services d habilitation, calcul de scénarios, gestion des diffusions, etc. On insiste sur l orientation service de la couche, sans forcement faire appel à une implémentation de type Web services (une implémentation conventionnelle sur la plateforme cible comme classes.net ou composants COM+ pour Windows, classes POJO ou EJB pour Java Entreprise peuvent suffirent). Toujours au niveau implémentation, les services «métier» incluent une couche structurée d accès aux données, non mise en évidence sur le schéma pour des raisons de simplifications. Base de données Il s agit d une base de données relationnelle. Ressource système de fichiers Compte tenu des volumétries manipulées par l INS, l espace de stockage des fichiers est une ressource significative. Les principales utilisations sont : espace FTP de mise à disposition des résultats de scénarios ; espace de réception des flux entrants et de production des flux sortants. 4.5. Les logiciels de base préconisés (sgbd, serveurs applicatifs, systèmes d exploitations) Les logiciels de base dépendent, d une part, des solutions SIG et applicatives retenues et, d autre part, du référentiel technique de l exploitant. Le tableau suivant liste les logiciels de base compatibles avec la solution, le choix précis restant à faire en mode projet. Logiciel de base Produit Systèmes cibles Système d exploitation Linux INSB_AL, INSB_UH Windows INSA, INSB_AL, INSB_UH SIG Non spécifié à ce jour INSB_AL et INSB_UH Non spécifié à ce jour INSB_AL et INSB_UH SGBD Non spécifié à ce jour INSB_AL, INSB_UH 31

4.6. Le domaine de données INS La base de données INS (le domaine INS) est essentiellement une base SIG, supportant également les fonctionnalités décrites en 3.6. 4.6.1. Catégories de données Figure 25 - Catégories de données INS 4.6.1.1.Les données géographiques (GEO)) Cette catégorie comprend l ensemble des données décrivant la géométrie dans le sens SIG du terme, incluant : les différentes classes d entités décrivant les régions, les départements, les communes, etc. ; les topologies ; les réseaux. Les données géométriques sont relativement stables dans le temps. 32

4.6.1.2.Les données des émissions (EMS) Les données des émissions comprennent l ensemble des données de référence pour les émissions. Ce sont des données de référence de l inventaire, elles ne changent pas dans le temps. Les données de référence sont géoréférencées. Dans la terminologie SIG ce sont des données attributaires par rapport à la catégorie de données GEO. A une fréquence annuelle, les données de référence sont : enrichies avec les données des émissions de la dernière année (A-2), en provenance du système A ; purgées afin de limiter le périmètre à deux années glissantes plus l année de référence. Les données de référence sont mutualisées par l ensemble des utilisateurs, avec des restrictions concernant : la résolution des objets géographiques auxquels ces données sont attachées (niveau région, département, commune, etc.) ; le périmètre de habilitation. 4.6.1.3.Les données des scénarios ou données de simulation (SIM) Les données de simulation sont des données calculées à la demande des utilisateurs en «accès libre». Elles n ont pas un caractère permanent, mais une durée de vie limitée. Les données de simulation sont structurées en jeux de données de simulation, définis par l utilisateur ayant initié leur calcul. Les utilisations possibles d un jeu de données de simulation sont : la création (le calcul) ; l exportation (l extraction) à destination de l utilisateur du jeu de données, par téléchargement (ftp, http) ; la visualisation du jeu de données à travers les fonctionnalités cartographiques du système. 4.6.1.4.Les données précalculées (CALC) Les données précalculées représentent le moyen d accélérer les requêtes de restitution dans le système INSB, en simplifiant également l implémentation de ces requêtes au niveau de l application. 4.6.2. Bases de données INS Le découpage au niveau données suit le découpage en grands sous-systèmes présenté précédemment. Il y a ainsi trois bases de données logiques pour les système A et B. Pour le système A : BD_INSA La base de données du système A. Pour le système B : BD_INSB_UH la base de données de l INS pour la partie dédiée aux utilisateurs habilités. Cette base est la base de référence de l INS. Elle accueille les flux entrants de l INS et fournit les données pour les flux sortants de l INS ; 33

BD_INSB_AL une base de données spécialisée pour la partie «en accès libre». Cette base de données est essentiellement une base de données accédée en lecture uniquement. Elle contient une restriction des données de la base BD_INSB_UH. Les diagrammes suivants présentent les bases de données INS par grand sous-système, avec les principales catégories de données contenues dans chaque base. Figure 26 - Base de données du système A 34

5. Architecture de déploiement 5.1. uds de déploiement Figure 27 - Bases de données du système B La configuration de déploiement INS contient les plates formes INSA et INSB, déployées sur deux sites distincts. La plate forme du système A comprend une machine unique. La plate forme B comprend : SGBD INSB - une machine évolutive, hébergeant toutes les bases de données de la plate forme B (i.e. partie «AL» et «UH») ; serveur applicatif INSB_UH - hébergeant les modules applicatifs INSB_UH pour la restitution interactive et excluant les modules de calcul des scénarios ; serveur applicatif INSB_UH_SC - machine dédiée pour les modules de gestion/calcul des scénarii et mise à disposition des résultats ; serveurs applicatif INSB_AL - machine dédiée aux modules applicatifs de INSB_AL, hormis la base de données ; Switch Baie SAN et Baie SAN - les équipements de stockage SAN. La plate forme B fait apparaître également une partie infrastructure, constituée d un serveur d infrastructure (de sauvegarde) et un robot de sauvegarde, assurés normalement par l infrastructure du site d exploitation 35

5.2. Déploiement des composants 5.2.1. Plate forme INSA Figure 28 - N uds de déploiement INS Sur le diagramme de déploiement INSA, l unique machine de la plate forme héberge les modules applicatifs et la base de données du système. 36

5.2.2. Plate forme INSB Figure 29 - Déploiement de la plate-forme INSA Le diagramme de déploiement présente un déploiement possible des différents modules applicatifs. On distingue ainsi : les trois serveurs applicatifs de la plate forme, un pour la partie AL et deux autres pour la partie UH ; le serveur applicatif INSB_UH est spécialisé pour les traitements de restitution interactive, alors que INSB_UH_SC prend en charge : o les traitements des flux d alimentation ainsi que les exports vers PREV AIR et INSB_AL ; o les traitements (lourds) de calcul différé pour les scénarios ; o la diffusion des résultats issus des calculs de scénarios. 37

Le partage des modules entre INSB_UH et INSB_UH_SC peut varier par rapport à la configuration présentée. Ce que la configuration propose de structurant est la séparation entre les traitements lourds de calcul et les traitements de restitution interactive. Elle favorise également la disponibilité des ressources pour la partie interactive (SIG essentiellement) en plaçant tous les modules qui peuvent être décorélés des demandes interactives sur la machine INSB_UH_SC (Import/ Export, Gestion des diffusions). La machine INSB_SGBD est l unique SGBD de la plateforme INSB. La machine INSB_UH_SC devra être une machine évolutive, afin d offrir l option de montée en charge par augmentation de la puissance de la machine («scale up») si nécessaire. La structuration de la base de données en deux bases logiques (AL et UH) offre également la possibilité de montée en charge par déploiement de la base AL sur une machine séparée (scale out). 38

Figure 30 - Déploiement de la plate forme B 39

5.3. Eléments de dimensionnement 5.3.1. Spécification et dimensionnement des n uds de déploiement Les diagrammes suivants donnent un exemple de dimensionnement pour les éléments composant les deux plates formes avec des machines biprocesseurs et quadri-processeurs. Figure 31 - Exemple de dimensionnement des n uds INSA 40

Figure 32 - Exemple de dimensionnement des n uds INSB 41

5.4. Dimensionnement des espaces de stockage Les éléments à la base de ce dimensionnement sont : la taille des données non spatialisées de 60 Go dans le système INSA ; la base d estimation pour les données spatialisées est de 3 To par année (système INSB) ; la qualification du type de stockage comme temporaire et permanent, en fonction de la nature des informations stockées ; l utilisation des coefficients permettant de déduire les différents types d utilisation. Si l évaluation proposée peut être fiable quant à la manière d utiliser l espace de stockage, la taille des données initiale et les coefficients doivent être revus en mode projet en fonction de : la taille des données pré calculées ; la politique de gestion des jeux de données de simulation, issus des scénarii de calcul; en effet, des paramètres de type quotas ou de type durée de vie déterminera des volumes de données plus ou moins importantes. 42