Référence Etnic Architecture des applications

Transcription

1 Référence Etnic Architecture des applications Table des matières 1. Introduction Architecture Démarche générale Modèle d architecture Découpe d une architecture applicative Principes des règles d accès Règle 1 : Accès à une couche extérieure Règle 2 : Accès à plusieurs couches extérieures Règle 3 : Accès d un business à un autre business Aspects techniques Vue Bibliographie Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 1/11

2 1. Introduction Le présent document s adresse aux différents responsables de projet souhaitant exprimer les contraintes de l Etnic dans les marchés public. Son objectif est de définir les grands principes de construction, d intégration et de déploiement des applications, dans un souci d harmonisation des pratiques et de mutualisation des moyens. Le document décrit l architecture générale des systèmes d information et détaille ses composants. 2. Architecture 2.1 Démarche générale La contribution de la technologie aux objectifs de l Etnic permet d élaborer un cadre de cohérence qui se concrétise par : Le décloisonnement des systèmes d information : ce décloisonnement (cfr doc. Normes et Standards) permet d une part l informatisation de bout en bout de processus métiers portés par plusieurs projets, et d autre part une mutualisation des moyens qui peut être mise en œuvre par : o des spécifications communes de composants du SI o la réutilisation de composants o le partage de composants o la mise en place de centres de ressources Une fédération et une mutualisation des ressources rendues possibles par les architectures orientées service (SOA) o la mise en œuvre d une fédération d un service permet de fournir un service à plus forte valeur ajoutée ou à plus forte cohérence. Une garantie du respect du maintien de la confidentialité pour les données concernant liées à des citoyens par la mise en place : o d une gestion d identité respectueuse de la confidentialité de chacun (fédération des identités numériques) o d une infrastructure de sécurité Les spécifications d interfaces élaborées devront permettre : o Une interopérabilité sémantique qui se traduit par la normalisation des données, documents échangés et données de description de ces documents (méta données). Ces travaux doivent commencer par l élaboration d un modèle de données communes et la publication des schémas XML (fichiers XSD). o Une interopérabilité technique et applicative portée par : La définition d un protocole d échanges commun entre les applications des protocoles applicatifs compatibles, standard et ouverts o Une automatisation des processus transverses. o Une interopérabilité organisationnelle par une gestion cohérente des identités et des droits d accès (habilitations) o Une interopérabilité entre les domaines de confiance Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 2/11

3 2.2 Modèle d architecture Les démarches d architecture à l Etnic sont généralement basées sur le modèle SOA («Oriented Architecture»). Ce modèle d architecture a été adopté car il permet de limiter le couplage entre les services (séparation de l interface par rapport à l implémentation) et d être agnostique par rapport à la technologie. Dans ce sens, la mise en œuvre de services basée sur ce modèle d architecture permet de satisfaire pleinement aux trois grands principes énoncés précédemment. Il n existe pas de taxonomie des services d infrastructure constitutifs de l architecture SOA qui seront gérés par l ESB. En règle générale, sont généralement mis en avant les services suivants: Le service de transport et de messagerie sécurisée Le service d intermédiation : ce service porte sur l adressage, la transformation, l enrichissement et le routage des messages entre les points d extrémité (c'est-à-dire entre les fournisseurs et consommateurs de services) L orchestration de processus et la gestion d évènements : traditionnellement, la définition et l exécution des processus relèvent du domaine applicatif, dans le sens où ils constituent la base même de la logique applicative. Les services de sécurité incluant en particulier les services d identité et d authentification, d autorisation. La gestion des accès aux données faisant partie intégrante de l application métier. Toutefois, à la demande spécifique de l application, il est possible que l architecture SOA gère cet aspect. Les services de signature de documents XML et de validation de certificats (via OCSP et/ou CRL). Les services d enregistrement et de publication des services au travers de répertoires et d annuaires. Ces dispositifs permettent d une part à un fournisseur de services de décrire de manière structurée les caractéristiques du service et au consommateur de l invoquer. Des services évolués d administration incluant le suivi des activités, les contrats de services, la définition et le suivi des exigences de service, Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 3/11

4 2.3 Découpe d une architecture applicative Vue globale de l architecture d un projet : Explorateur internet Contrôle d accès sécurisé Couche présentation (partie web) Accès extérieur (liens internet url) Couche métier (partie business) service Couche données (partie data) Vue Architecture d une application Couche pour accès extérieur Aucun accès possible en direct Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 4/11

5 Une application devra toujours contenir ces différentes couches : Une couche Présentation : cette couche permet à une application de dialoguer avec un utilisateur. Une couche Métier : elle contient tous les éléments métiers gérés au sein de l application. Une couche Données : elle est la couche de persistance des données métiers et/ou utilisateur. Une couche : elle est dédiée uniquement à la communication avec les applications extérieures. Elle permet à l application d exposer sa couche métier à d autres applications mais aussi d accèder aux couches métiers des autres applications (voir règle 3 dans le chapitre suivant) Une couche Vue : dans les rares cas où une application extérieure est autorisée à accéder directement aux données de l application sans passer par sa couche métier alors la réalisation de vues (vues au sens base de données d un SGBDR 1 ) devient obligatoire. L accès ne pourra être autorisé que sur des données non sécurisée et ne sera possible que sur une autorisation préalable du responsable du projet. Pour plus de détails, des explications complètes et réalisées dans un contexte d entreprise mais aussi dans celui des administrations publiques, sont fournies dans la partie Théorie et retour d expériences sur les architectures informatiques dans la bibliographie. Au lecteur avisé qui souhaite connaître les nouvelles problématiques et leurs solutions de ce type d architecture, nous lui conseillons de se référer à la partie Théorie sur les architectures SOA toujours dans la bibliographie. Comme indiqué dans ces documents et comme l expérience en développement de projet le montre, l exposition de services qui date des années 80 apporte de nombreux avantages mais ne résout pas un des inconvénients majeurs des applications en entreprise : La dépendance entre applications. C est pourquoi il faut ajouter à cette découpe d architecture des règles d accès aux différentes couches. 1 SGBDR : Système de Gestion de Bases de Données Relationnelles Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 5/11

6 3. Principes des règles d accès 3.1 Règle 1 : Accès à une couche extérieure Définition Une couche de niveau N ne peut accéder qu à une couche inférieure de niveau N-1 et être atteinte par une couche de niveau N+1. Représentation graphique : Explorateur internet Web Web Business Business Data Vue Data Projet X Projet Y Matrice des interactions possibles entre les couches : Prj X \ Prj Y Browser Web Vue Browser Oui Non Non Web Oui (1) Oui (3) Oui Non Business Non (2) Oui Non Vue Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 6/11

7 Les cases grises représentent les interactions non applicable car une impossibilité technique existe (par exemple un business faisant appel à une partie web n est pas faisable car un business ne peut pas créer de session web) Les couches Data ne sont pas représentées car elle ne sont jamais accessible directement de l extérieur. La couche Business appelée (ici celle du projet Y ) n est pas représentée car elle n est pas accessible directement de l extérieur. Remarques sur la matrice : (1) C est le seul moyen pour une partie web d accéder à l autre partie web d un autre projet. Le procédé est appelé «redirect». (2) Techniquement cela est possible. Toutefois pour éviter les dépendances fortes entre projet, il est préférable de mettre une interface qui gérera spécialement la dépendance (cfr chapitre Orchestration ). (3) Via du Javascript. 3.2 Règle 2 : Accès à plusieurs couches extérieures Définition Une couche de niveau N peut accéder à plusieurs couches inférieures de niveau N-1 que via une couche intermédiaire afin d avoir un couplage faible entre couches. Représentation graphique : Web Projet W Business Projet T Projet Y Data Projet X Projet Z Dans le cas d un business qui veut accéder à plusieurs vue, le schéma reste le même sauf qu au lieu d avoir des services, nous aurons des vues. Le service du projet T ci-dessus qui est contacté par la couche Web du projet X est appelé coordinateur ou orchestrateur. Ce projet sera géré au niveau transversal dans certains cas il peut être géré par le projet d un service qui a le plus d exigence en terme de contraintes métiers. L architecture SOA (via un ESB) pourra gérer ou intégrer le projet T comme indiqué par la règle 3. Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 7/11

8 3.3 Règle 3 : Accès d un business à un autre business Dans le cas de Business à Business où les impacts en modification peuvent avoir des conséquences très grave sur les coûts de maintenance, de gestion de planning ainsi que sur la stratégie d entreprise, nous conseillons l utilisation de l orchestration fournie dans un ESB. Définition Une couche Business ne peut accéder à au moins une couche que via uniquement une orchestration. Représentation graphique : Vue statique Web S ervice W Projet W Business ESB Y P rojet Y Data S ervice Z P rojet X P rojet Z Orchestration T P rojet T Vue dynamique Orchestration Business Y Z W Cette solution assure un couplage faible parfait entre les business. L orchestration - dans un ESB en particulier - peut prendre en compte le routage, la transformation, la validation, Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 8/11

9 l enrichissement. Elle facilite aussi la gestion du changement par la possibilité d implémenter une gestion des variantes (pattern context aware ou en français de passage de contexte). 4. Aspects techniques L aspect technique permet d aborder le choix de la technologie la mieux appropriée pour réaliser les vues et les services. 4.1 Vue La technique à employer est dépendante du type de SGBDR. 4.2 Les services seront toujours accessibles en accès distant, de ce fait les EJB (technologie proposée par les serveurs J2EE) et les webservices seront les technologies les plus appropriés pour ce genre d accès. D autres technologies auraient pu être utilisée mais elles n offrent pas autant de possibilité d interopérabilité. Les EJB peuvent être utilisés avec un ESB et aussi pour des échanges entre des serveurs J2EE. Par contre si des messages XML sont échangés alors les webservices en mode message uniquement doivent être utilisés. Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 9/11

10 5. Bibliographie Théorie et retour d expériences sur les architectures informatiques (en entreprise et dans les administrations publiques). Microsoft : Architecture d application pour.net : Conception d applications et de services sdn/technologies/technos/net/info/ _apparch_0.html ADAE : Principes d architecture applicative DPSM : Architecture commune d applications-guide de conception-réalisation pour les applications internet ou intranet IESN : Cours de Karl Nobben en graduat informatique SUN : J2EE 1.4 Tutorial (en anglais) SUN : Core pattern J2EE (en anglais) SUN : Core pattern J2EE catalog (en anglais) Théorie sur les architectures SOA Orchestra Networks : Guide de référence SOA Partie 1 : Partie 2 : ADAE : Principes d architecture applicative EIP : Modèles des architectures SOA (en anglais) Théorie sur les web services Orchestra Networks : Guide de référence SOA Partie 1 : Partie 2 : Orchestra Networks : Slides séminaires SOA-WS Partie 1 : Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 10/11

11 Partie 2 : Méthodologie SOA (dans le cadre de conception de Système d information) PRAXEME : Guide général PRAXIME h ttp://pie.bonnet.ifrance.com/pxm02-ggen.pdf Théorie sur le versionning XML.com : Versioning XML Vocabularies (en anglais) h ttp:// Théorie sur le XML Belgif.be : Recommandations techniques XML Schema h ttp:// Version : 1.0 / Mise à jour le :13/02/2008 Crée le 08/05/2006 Page 11/11