Evolution de l’architecture Agora

Présentation au sujet: "Evolution de l’architecture Agora"— Transcription de la présentation:

1 Evolution de l’architecture Agora
Agora: le contexte La logique d’évolution Nouvelle architecture: Vue globale Communications en XML Serveur Web Serveurs d’application Les annuaires EAI Les flux externes Conclusion Bibliographie - URL

2 Agora: le contexte Les atouts Les défis
Une couverture fonctionnelle étendue 30 millions de lignes de code COBOL Une architecture bien charpentée Les défis Le Web Ouverture et flexibilité Sécurité

3 Atout architecture AGORA : une architecture bien charpentée:
Présentation service générique d’affichage SAGA Navigation pilotée par les TPR (sur action utilisateur ou sur dynamique programmée) Traitements métiers modules fonctionnels, TPR et batchs (COBOL) Accès aux données modules d’accès et SGBD

4 La logique d’évolution
Garder l’existant métier Créer une infrastructure Web Communications XML intégrant anciens et nouveaux services, et partenaires Progressivement ouvrir de nouveaux services en techniques Orientées Objet Au point de vue architecture, les agents et les adhérents seront traités de la même façon; ceci concerne les accès Web et annuaires. L’infrastructure Web implique de traiter les problèmes de sécurité. La bonne nouvelle pour les agents, c’est qu’ils auront probablement Internet sur leur bureau!

5 Nouvelle architecture: Vue globale
Format d’échange: XML L’IHM: techniques Web Le moteur: des SA Les filtres: annuaires utilisateurs Les tuyaux: EAI Ne changent pas: Les réservoirs: SGBDR L’existant COBOL L’OS Unix A noter que XML n’est qu’un moyen, il n’apparaît pas dans les nouvelles orientations. Le fluide dans les tuyaux: du XML Les pompes: des SA Les manomètres: le Web Les filtres: annuaires utilisateurs Les tuyaux: EAI Eventuellement faire un graphisme avec ces métaphores. L’EAI viendra un peu + tard, et d’abord pour les flux externes. Les mécanismes SA (RMI/IIOP) de communication (synchrone) seront utilisés dans un premier temps pour le transactionnel applicatif.

6 Communications en XML Internet, HTTP HTML XML XML XML XML JDBC
Extranet, Intranet HTTP HTML XML Présentation Applications =navigation Partenaires XML XML XML services métier existants services métier SA applicatif Entre les couches "Présentation" et "Applications et Données Métier" on aura une communication en XML avec un format XML unique, qui débouchera soit sur les anciens services Cobol, soit sur de nouveaux services Java EJB. XML est donc un fil conducteur qui permet aux briques d’être interchangeables, et notamment, les anciens et nouveaux services. Les messages XML assurent une extensibilité et flexibilité maximum, XML favorisant une évolution indépendante de la présentation, de la navigation et des traitements métiers. Les référentiels existants seront réutilisés et mis à la sauce XML: Communication Applicationsservices métier JDBC SGBDR

7 Utilisation des techniques Web
Pages d’accueil (statiques) JSP ou XSP pour les pages dynamiques Mélange de HTML pour les parties statiques, et de balises ou morceaux de code accédant à la logique métier Navigation: suivant les entrées de l’utilisateur, aiguillage par une servlet sur la page suivante. Appel à l’annuaire pour l’authentification Contrôle à l’entrée On signale que les le détail des techniques (JSP, servlets…) n’est pas actuellement décidé. Dire que le référentiel de fenêtres existant sera réutilisé et mis à la sauce JSP ou XSP. Un formalisme et une implémentation de type machine à états finis pourra être utilisé pour la navigation.

8 Liaison Web  logique métier
Présentation « Front-office » Annuaire Adhérents F i r e W a l l Internet Serveur WEB Contrôle d’Accès Navigation des employeurs, adhérents XML Extranet Connecteurs XML (classes) Logique et Données Métier « Back-office » Référentiel de pages Web Pages statiques C a c h e Serveur WEB Contrôle d’Accès Navigation des agents MSA XML XML est donc un format d’échange, fil conducteur qui permet aux briques d’être interchangeables, et notamment, les anciens et nouveaux services. Dire que que les SA sont très souples pour le déploiement. On peut avoir tout sur une machine, ou 4 machines, ou 8. Ici on considère, pour simplifier, que le moteur de servlets (e.g. Tomcat), où réside la navigation, est une partie du serveur Web. C’est en fait une couche indépendante entre le serveur Web HTTP et le conteneur d’EJB qu’est le serveur d’application. Intranet Annuaire Agents

9 Serveurs d’application
Web XML SA Présentation Applications =navigation Partenaires XML XML XML services métier existants services métier SA SA applicatif XML JDBC Le SA est là pour assurer transactions, sécurité et scalabilité. Des nouveaux services seront développés en Java et seront des Enterprise Java Bean (EJB). Les partenaires auront probablement aussi des SA, mais vu que les communications se feront par services Web, leur implémentation est indifférente. Complément technique: Des EJB session côté front-office enverront des messages XML à des EJB entités côté back-office . On considère souvent que le serveur Web fait partie du Serveur d’Application. Question de terminologie. Pour être précis on peut parler de conteneur d’EJB, d’une part et serveur Web (HTTP) d’autre part. SGBDR

10 SA: vers de nouveaux services sous forme d’objets
Applications et Données Métier « Back-office » Logique applicative Objets métier Services adhérents - employeurs Nouveaux Services Batchs commités Nouveaux Accès XML XML SA Présentation « Front-office » On a ici la partie «  back-office » du diagramme précédent. On a 2 SA logique applicative, 1 pour agents, 1 pour adhérents, le SA services métier; éventuellement un SA dédié EAI et flux extérieurs . Là encore, on a toute latitude de déploiement, ceci est une configuration possible. SA SA Données de Production XML XML Services spécifiques aux agents

11 Les annuaires - sécurité
Adhérents et agents: même architecture Authentification unique (Single Sign On) Pas seulement un contrôle à l’entrée, mais permet un contrôle d’accès très précis aux services et données: habilitation par l’infrastructure technique (automatique) habilitation par les applications (par programme) Fédération d’annuaires existants Sécurité J2EE pour les nouveaux services: Chaque client J2EE est associé à un rôle via l’annuaire Chaque appel de méthode transmet le rôle Contrôle d’accès : On a vu que dans l’architecture J2EE on peut associer un rôle de sécurité au niveau de la méthode. Les annuaires existants doivent continuer à exister pour des anciens applications. On n’échappera probablement pas à une problématique de réplication. On a vu que les permissions (habilitations) passaient par la spécification de rôles, tels qu’administrateurs, agents, etc, et que dans les meilleurs cas, le code n’a même pas besoin de se référer au rôle, puisque c’est le SA qui gère cela. Donc l’annuaire servira (entre autres) à affecter un rôle applicatif à chaque utilisateur habilité. On rappelle que dans la norme EJB, une API de type annuaire (JNDI) permet de trouver les implémentations.

12 EAI Démarche progressive échanges entre applications: mécanisme unique
Prend en charge toute la tuyauterie: Publication-Abonnement Files d’attentes Traduction de messages Accusé et garantie de réception A terme: intégration de progiciels dans le produit Agora  Le déploiement d’un EAI est la dernière phase à l’horizon Tout n’est pas encore décidé, mais ce sera très structurant. On rappelle la flexibilité apportée par les files d’attentes de messages. Une application de type « prestations » pourra publier un message de type « remboursement » sans rien savoir d’un autre application de type « comptabilité adhérents » qui va, elle, s’abonner à ces messages. Une 3ème application de type « comptabilité praticiens » pourra aussi s’abonner à ces messages, tout à fait indépendamment de la précédente application. On voit que la structuration se fera en termes d’un dictionnaire de messages.

13 Administration EAI On pourra déclarer une association entre:
Un récepteur (=abonné) Un partenaire avec une adresse Internet, un protocole Un type de message Un format de message Les émetteurs doivent être déclarés Ensuite ils envoient des messages auto-explicatifs Que l’EAI transmet Que les abonnés traitent en différé Les « messages » peuvent être des fichiers. Les messages pourront être soit des messages orientés données métiers, soit la simple traduction en XML d’un appel de fonction OO (Soap ou XML-RPC). Il y a une analogie avec un raccordement de tuyaux : c’est un raccordement entre un type de message et un abonné. Remarque: WSDL et UDDI permettront de simplifier encore ce raccordement de tuyaux.

14 Les flux externes Echanges de données avec l ’extérieur
Pour : Echanges de données avec l ’extérieur Répondre à l’intensification des flux en nombre et en diversité Enrichir les fonctionnalités de l’interface actuelle de gestion des flux (SGFE) Flux asynchrones entre applications Une évolution vers des applications intégrées par des messages Diminuer les impacts en cas d ’évolution Canaliser les échanges entre applications sur un mécanisme unique

15 Etape 1 : Web + services existants via XML
Présentation « Front-office » Annuaire Adhérents F i r e W a l l Logique et Données Métier « Back-office » Internet Serveur WEB Contrôle d’Accès Navigation des employeurs, adhérents Données de Production XML Extranet Connecteurs XML (classes) Référentiel de pages Web Pages statiques APPLICATIONS TRANSACTIONNELLES COBOL (TPR) Batchs commités SAGA Batchs C a c h e Serveur WEB Contrôle d’Accès Navigation des agents MSA XML C/S Intranet Annuaire Agents

16 Moyen terme: Web + services Cobol / Tuxedo
Présentation « Front-office » Annuaire Adhérents F i r e W a l l Logique et Données Métier « Back-office » Internet Serveur WEB Contrôle d’Accès Navigation des employeurs, adhérents Données de Production XML Extranet Connecteurs XML (classes) Référentiel de pages Web Pages statiques SERVICES COBOL Batchs commités SAGA Batchs C a c h e Serveur WEB Contrôle d’Accès Navigation des agents MSA XML C/S Intranet Annuaire Agents

17 Long terme: Web + nouveaux services objet
Présentation « Front-office » Annuaire Adhérents Logique applicative Objets métier F i r e W a l l Internet Serveur WEB Contrôle d’Accès Navigation des employeurs, adhérents Services adhérents - employeurs Nouveaux Services Batchs commités Nouveaux Accès XML XML Extranet SA Connecteurs XML (classes) Référentiel de pages Web Pages statiques SA Données de Production XML C a c h e Serveur WEB Contrôle d’Accès Navigation des agents MSA XML Services spécifiques aux agents Intranet SA Annuaire Agents

18 Questions Réponses Conclusion
Appui sur des techniques éprouvées et standard: XML, Web J2EE LDAP Réutilisation au mieux de l’existant Une infrastructure avec un potentiel d’évolution pour de nombreuses années Questions Réponses

19 Bibliographie Java Le language Java, par Arnold et Gosling, les créateurs du language Java examples in a nutshell, par D. Flanagan, Éditions O’Reilly les didacticiels Java de Sun java.sun.com Orienté Objet Conception logicielle Orientée Objet, de Bertrand Meyer (le langage Eiffel est un précurseur de C++ et Java) Design patterns [titre français -;)] par E. Gamma et al., souvent cités comme "la bande des 4" (the gang of four), éditions Intern. Thompson Publishing. Modélisation Objet avec UML, par P.A. Muller, éditions Eyrolles EJB: Enterprise Java Beans, par R. Monson-Haefel, chez O'Reilly J2EE in a nutshell, par D. Flanagan, Éditions O’Reilly EAI Intégration d’applications, par Avignon, Joguet, Pezzardi, éditions Eyrolles XML XSLT - programmers's reference, par Michael Kay (le créateur de Saxon, un moteur XSLT 100% java), chez Wrox Serveurs d’Application Serveurs d’Application, par Brethes, Hisquin, Pezzardi, éditions Eyrolles

20 URL XML xml.org (OASIS) Web Orienté Objet Java, EJB, J2EE Serveurs Web
XMLfr Mutu-xml.org (Mutualiser l'effort de montée en compétences sur XML ) didacticiels XML: zvon.org ( Didacticiel XML Schema en Français (HTML), voir lien dans XML Schema au W3C Didacticiel XSLT en Anglais (.PPT) xml.org (OASIS) Web W3C (World Wide Web Consortium ) : Orienté Objet Cetus-links : 18,452 Links on Objects and Components OMG : Java, EJB, J2EE Serveurs Web apache.org Les flux externes - (EDI Santé, Français, on y trouve des travaux sur XML par le CNAMTS ) - (organisme international pour une norme dans le monde de la santé, membre du W3C. on trouvera sur le site quelques documents et exemples intéressants pour une norme XML mais aussi pour une démarche UML)