Evaluation Idéopass Cahier d analyse technique

Transcription

1 Evaluation Idéopass Cahier d analyse technique Version 1 GMSIH 374, rue de Vaugirard Paris. Tel : Fax :

2 Auteur(s) du document : Contrôle Qualité GMSIH Date : 17/03/2005 Statut : Validé Par : GMSIH Date Version Commentaires Statut 17/03/ Publication Validé 17/03/05 2/32 Pr143CAH_ANT_IDEO_V1.doc

3 TABLE DES MATIÈRES 1. Introduction Description des concepts et des technologies associés à Idéopass Architecture multi-niveaux La plate-forme J2EE Modélisation et conception UML Design Pattern EJB JSP Le protocole SOAP La technologie RMI-IIOP Architecture et composition d Idéopass Architecture fonctionnelle d Idéopass Architecture technique d Idéopass Modélisation et conception Les composants logiciels fonctionnels J2EE Moyens de communication et points d entrée Mécanismes de stockage et de persistance des données Synthèse et analyse critique Avantages et inconvénients de la solution Idéopass Analyse SWOT Conclusion de l analyse /03/05 3/32 Pr143CAH_ANT_IDEO_V1.doc

4 LISTE DES FIGURES Figure 1 Architecture multi-niveaux...7 Figure 2 Composants de l architecture J2EE...8 Figure 3 Invocation d un EJB par RMI-IIOP...14 Figure 4 Architecture applicative de la solution Idéopass...17 Figure 5 Architecture fonctionnelle Idéopass...18 Figure 6 Cinématique d accès à Idéopass par les web services /03/05 4/32 Pr143CAH_ANT_IDEO_V1.doc

5 1. Introduction Ce document constitue un cahier d analyse technique de la solution logicielle Idéopass, développée par les établissements de santé de la région Franche-Comté. Le logiciel Idéopass propose une solution globale aux établissements de santé sur leurs problématiques d identification des patients. Le produit résultant est dénommé «Serveur d Identification Patient (SIP)», et assure le service d identification des patients et le rapprochement des identités en provenance de différents domaines d identification. La solution respecte le modèle OSS (Open Source Software) et repose ainsi sur des produits et technologies apparentés à l Open Source. L objectif de cette analyse est de présenter, de manière exhaustive et intelligible, le contexte technique, la composition et le fonctionnement de la solution Idéopass, ainsi qu un avis critique sur cette dernière. Cette analyse s appuie, d une part, sur l étude des documents et des codes «source» référencés ciaprès fournis par l équipe projet Idéopass, et d autre part sur notre expertise et nos retours d expérience en matière de conception et de développement logiciel. Le présent cahier d analyse technique s articulera donc autour des axes suivants: La description des concepts et des technologies associées et utilisées par Idéopass L architecture et la composition de la solution d Idéopass La synthèse de l étude et l analyse critique du produit Idéopass Documents de référence [DR1] SIP- Document de cadrage 1.0, Idéopass, 23/12/02 [DR2] SIP- Présentation 1.0, Idéopass, 30/04/03 [DR3] SIP- Description générale 1.1, Idéopass, 22/07/03 [DR4] SIP- Spécifications fonctionnelles 2.0, Idéopass, 28/06/04 [DR5] SIP- Cahier de recette 0.3, Idéopass, 10/03/03 [DR6] SIP- Spécifications techniques 1.0, Idéopass, 30/04/03 [DR7] SIP- Spécifications des messages 1.2, Idéopass, 25/03/04 [DR8] SIP- Description des messages 1.0, Idéopass, 15/07/03 [DR9] SIP- Spécifications techniques Connecteur CPAGE 1.0, Idéopass, 17/01/03 [DR10] SIP- Manuel utilisateur 1.0, Idéopass, 17/06/03 [DR11] SIP- Notice d installation 1.0, Idéopass, 28/06/04 [DR12] Rapport de stage - Réalisation d un outil de prise en main du Serveur d Identité Patient, Jordi Barrère, 28/06/04 [DR13] Identification du patient Services d identificcation du patient Tome1- [DR14] Spécifications fonctionnelles générales version 1, GMSIH, 28/02/02 Identification du patient Services d identificcation du patient Tome2- Spécifications détaillées des services d idnetification et de rapprochement version 1, GMSIH, 18/02/02 [DR15] Evaluation Idéopass - Catalogue des fonctionnalités - Synthèse 1.0 [DR16] Code source et exécutables Idéopass v2, Idéopass 17/03/05 5/32 Pr143CAH_ANT_IDEO_V1.doc

6 2. Description des concepts et des technologies associés à Idéopass Les principaux concepts et technologies associés et employés par Idéopass sont : L architecture multi-niveaux ; La plate-forme J2EE ; L outil de modélisation UML ; Les composants techniques Enterprise Java Bean (EJB) ; Les pages Web dynamiques JSP (Java Server Pages) ; Le protocole SOAP ; La technologie RMI-IIOP. Afin de permettre au lecteur de mieux appréhender les rouages et arcanes de la solution Idéopass, nous proposons dans ce chapitre une description sommaire des sujets susmentionnés, accompagnée d un encart présentant les intérêts de la notion expliquée Architecture multi-niveaux La représentation de l architecture multi niveaux situe les différents services fonctionnels de l architecture client/serveur multi-tiers. L architecture multi-tiers met en œuvre un serveur contenant toute la logique applicative (serveur d applications) et des clients dits «légers» ne se chargeant que de la présentation des données. L architecture multi-niveaux répartit les composants logiciels suivant cinq couches : L interface utilisateur, chargée de gérer les interactions entre l'utilisateur et l'application (application de bureau, navigateur Internet,...) ; La logique de présentation, permettant de définir le contenu de l'interface utilisateur et la manière dont les requêtes utilisateur doivent être traitées ; La logique métier, qui modélise les règles métiers de l'entreprise ; Les services d'infrastructure, qui fournit un ensemble fonctionnalités techniques, à savoir : o o o o o la connexion au réseau des terminaux et des serveurs ("Connexion et hébergement"), la désignation et la localisation des ressources disponibles ("Adressage et nommage" et "Annuaires"), la sécurisation des communications et des informations ("Sécurité"), la maîtrise des informations par l'utilisateur ("Protection de la vie privée et des données personnelles"), la classification des informations accessibles ("Etiquetage du contenu"). Les données, couche contenant les données de l'entreprise. 17/03/05 6/32 Pr143CAH_ANT_IDEO_V1.doc

7 Le schéma ci-après illustre la segmentation des couches du modèle sus décrit, dans le cas particulier d un environnement Java: Clients WEB (navigateur) Requêtes HTTP Niveau Client Conteneur de Servlet/JSP Serveur WEB Routeur Web Service Niveau Présentation Appels services métier Appels services métier API Session Conteneur d objets métier Entité Message Niveau Métier Appels services techniques Accès BD Accès Annuaire Infrastructure technique Accès Messagerie Communications Intégration Niveau Infrastructure Requêtes SOAP Invocation API Applications Base de données Figure 1 Architecture multi-niveaux 2.2. La plate-forme J2EE L architecture J2EE est basée sur le langage Java qui permet le déploiement de composants sur diverses plateformes indépendamment de leur langage de programmation. Elle propose essentiellement un environnement fournissant : une infrastructure d'exécution d applications ; un ensemble de services techniques accessibles via les API J2EE. Le serveur d application J2EE constitue une implémentation de la norme J2EE. Il apporte un environnement complet de développement et d exécution aux applications écrites sous forme de composants objets ainsi que le support des interconnexions, normalisées, avec le monde extérieur (bases de données, annuaires, messageries, services réseaux, etc ). Ce serveur gère les applications distribuées en multi-processing et multi-threading, la sécurité des applications ainsi que l équilibrage de charge et la haute disponibilité. 17/03/05 7/32 Pr143CAH_ANT_IDEO_V1.doc

8 Son infrastructure orientée objet permet la réalisation de composants réutilisables et la factorisation de services applicatifs ou de services systèmes techniques et/ou fonctionnels pour de multiples applications. La plateforme J2EE introduit la notion de conteneur qui correspond à un environnement d exécution chargé de gérer des composants applicatifs et de donner accès aux API (Application Programming Interface) J2EE. L architecture J2EE rend disponible deux types de conteneur : un conteneur Web hébergeant les JSP (Java Servlet pages) et les servlets ; un conteneur EJB recueillant les composants EJB (Enterprise Java Bean) et offrant à ces composants des services tels que la gestion des transactions, des autorisations et de la persistance. Figure 2 Composants de l architecture J2EE 17/03/05 8/32 Pr143CAH_ANT_IDEO_V1.doc

9 La spécification J2EE définit un ensemble d API standard et plusieurs modèles de programmation pour le développement des applications, dont : Enterprise JavaBeans (EJB), composants Java pour les applications distribuées multi-niveaux. Cette extension fournit un moyen standard pour définir les composants côté serveur et définit une vaste infrastructure d exécution pour l hébergement de ces composants ; JDBC (Java DataBase Connectivity) qui fournit un accès transparent aux bases de données ; Java Server Pages (JSP) qui permet de valoriser davantage les applications Web J2EE en générant des pages HTML dynamiquement ; Java Messaging Service (JMS) qui permet d accéder à un service de messages, et de publier et de souscrire à divers types de middleware orientés message (MOM) ; Java RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol). L emploi de ce protocole permet l appel de fonctionnalités à distance ; Java API for XML Parsing (JAXP) qui permet d analyser des documents XML. La plate-forme J2EE est extensible et dispose d API complémentaires pour certains traitements spécifiques. Les APIs JAXM (Java API for XML Messaging) et HAPI (HL7 Application Programming Interface) constituent des extensions de la plateforme, respectivement dédié au traitement des messages XML et des messages HL7. L API JAXM est basée sur le protocole SOAP 1.1 et les spécifications SOAP with Attachments. Elle repose sur le service JMS (Java Messaging Service) proposé en standard par le framework J2EE. L API JAXM supporte notamment les fonctions suivantes : One-way asynchronous messaging, qui correspond à l envoi de messages asynchrones utilisé par les fonctionnalités d abonnement ; Routage des messages vers plus d une partie ; Messagerie fiable avec des mécanismes tels que la livraison garantie. Intérêts La complétude de cette plateforme et son respect des normes, des langages et protocoles Internet standards (HTTP, SSL, RMI, Corba, JMS, XML, ) permettent au développeur de se concentrer exclusivement sur les composants métier de son application sans se préoccuper de la gestion du système, et ainsi de : réduire les coûts de développement et de déploiement en centralisant les développements sur le serveur, faciliter les évolutions fonctionnelles et techniques grâce à la réutilisation de composants (capitalisation) dans le cadre d une architecture multi niveaux, permettre une montée en charge progressive du nombre d utilisateurs et une augmentation par étapes du nombre de serveurs. 17/03/05 9/32 Pr143CAH_ANT_IDEO_V1.doc

10 2.3. Modélisation et conception La solution utilise les outils de conception suivants : UML ; Design Pattern UML Le langage UML (Unified Modelisation Language) permet d élaborer des modèles objet indépendamment du langage de programmation utilisé. Il constitue un langage de modélisation objet et définit une norme et un cadre méthodologique pour les développements de programmes objet. Son support formel, le métamodèle UML, décrit de manière très précise tous les éléments de modélisation (les concepts véhiculés et manipulés par le langage) et la sémantique de ces éléments (leur définition et le sens de leur utilisation). De cette manière UML normalise les concepts objet. Intérêts Le langage UML offre aux développeurs un gain de précision et un gage de stabilité quant aux applications engendrées. Il représente un support de communication performant qui facilite la compréhension de représentations abstraites complexes et cadre l analyse. En effet, un autre avantage d UML est qu il offre une approche visuelle de la modélisation qui facilite la représentation et la compréhension de solutions objet. Sa notation graphique permet ainsi d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'évaluation de solutions. Les graphiques UML se déclinent en différentes vues complémentaires appelées diagrammes, qui permettent d inspecter un modèle selon différentes perspectives et guident l utilisation des éléments de modélisation. Ces différentes figurations présentent une vue complète des aspects statiques et dynamiques du système. De plus, l'aspect formel de la notation UML limite les ambiguïtés et les incompréhensions Design Pattern Dans le domaine de l'analyse et de la conception orientée-objet, un design pattern est une manière de construire la structure d'une classe. Plus généralement, un motif de conception est un document qui décrit une solution générale à un problème qui revient souvent. Les motifs sont basés sur des expériences passées avec les mêmes structures. Intérêts Constituant un catalogue de méthodes de résolution de problèmes récurrents, les design patterns sont ainsi des techniques permettant d'augmenter la productivité en adoptant certaines structures établies et réutilisables. Le recours à ces modèles prédéfinis réduit la complexité du code et rend la construction du code de meilleure qualité 17/03/05 10/32 Pr143CAH_ANT_IDEO_V1.doc

11 2.4. EJB Les Enterprise JavaBeans (EJB) sont des composants Java portables et réutilisables s'exécutant dans un conteneur d EJB coté serveur. Ils constituent des briques applicatives écrites en Java formant la logique métier de l architecture multi-niveaux J2EE, et relient ainsi la couche de présentation d'une application aux systèmes d'informations dorsaux d'une entreprise, tels que les bases de données ou les mainframes. Leur utilité s avère généralement lors la mise en place de transactions sécurisées et le stockage d objets Java. Ces composants simplifient les processus en prenant à sa charge la gestion des transactions, de la sécurité et des accès aux bases de données Les EJB se déclinent en trois catégories, chacune ayant ses propres caractéristiques et étant adaptée à une situation particulière : Les EJB «Session», utilisés pour représenter les données d un client et les comportements qui leur sont associés. Ils fonctionnent de façon éphémère en ne laissant aucun enregistrement a posteriori de la session terminée. Cette catégorie d EJB est elle-même divisée en deux classes : o o Stateless session bean, ou EJB session «sans état», qui n'ont aucune connaissance du client ou d'un semblant de contexte concernant la requête et sont de ce fait appropriés pour une utilisation unique. Par exemple, ils peuvent être employés dans un système de suivi des bugs où l'utilisateur recherche tous les bugs ouverts. L'application cliente contacte un Stateless Session Bean, lui transmettant les paramètres de recherche. Le bean accède alors à une base de données, sélectionne les entrées correspondant aux critères et retransmet les enregistrements au client. Lorsque la communication s'achève, le bean ne conserve aucun souvenir de l'interaction. Statefull session bean, ou EJB session «avec état», associent les requêtes à un client spécifique en maintenant les informations relatives à ce dernier en mémoire. Le bean «panier d achat» d un site de vente en ligne illustre parfaitement l emploi de ce type de composant. L'utilisateur effectue les tâches standards en ajoutant des produits au panier, en saisissant son adresse et en émettant la commande. Le bean du panier conserve l'état et, par conséquent, la connaissance de toutes ces variables, les associant à un client unique. Les EJB "Entity" (en français «entité») représentent des données ou des objets métier persistants ayant une existence au niveau d un support de stockage telle une base de données relationnelle. Ils perdurent après la fin d'une session en prenant la forme d'enregistrements uniques dans une base de données, mais peuvent être stockés dans un autre support, tel qu'un fichier. Un objet représentant un utilisateur (nom, coordonnées, choix de la langue) illustre l utilisation typique d un EJB «entity». Les EJB "Message-Driven" permettent la mise en œuvre d applications basées sur un traitement asynchrone de messages. Pour ce faire, l application utilisant ce type d EJB devra s appuyer sur le service de messagerie Java JMS (Java Message Service). Typiquement, en utilisant JMS, un client produit un message et le publie dans une file d attente de messages. L EJB «Message-Driven» extrait ensuite le message et exécute son contenu. Ainsi la communication des évènements ou des données a lieu de manière asynchrone, ni le client ni le bean ne dépend de la réponse directe de son interlocuteur. 17/03/05 11/32 Pr143CAH_ANT_IDEO_V1.doc

12 Intérêts Les composants EJB ont pour mission d'encapsuler des objets et concepts métier, permettant aux développeurs de se concentrer sur les détails des solutions. Ils contiennent la logique applicative, ce qui allège et assouplit les applications clientes, en les affranchissant de l implémentation de routines contenant les règles métiers ou les accès aux bases de données. Ils définissent un standard facilitant la réutilisation et l interopérabilité des composants middleware, et par conséquent le développement et l intégration d applications distribuées. Session Stateless bean : Avec ce comportement, plusieurs clients distincts peuvent accéder simultanément à un Stateless Session Bean sans impact négatif JSP JSP (Java Server Pages) est un standard permettant de développer des applications Web interactives (i.e. dont le contenu est dynamique). Une page web JSP a un contenu pouvant être différent selon certains paramètres (des informations stockées dans une base de données, les préférences de l'utilisateur,...) tandis que page web "classique" affichera continuellement la même information. Il s'agit en réalité d'un langage de script puissant exécuté du côté du serveur (langage de «server-side scripting» comme CGI, PHP, ASP,...) à la différence du JavaScript et de l applet qui s exécutent coté client. Les JSP sont intégrables au sein d'une page Web en HTML à l'aide de balises spéciales. Le serveur Web détecte ces balises et déclenche l interprétation du code compris à l'intérieur de celles-ci afin de renvoyer le code HTML résultant au navigateur du client. Intérêts Les principes retenus ont deux avantages principaux : Ils évitent de créer, et donc de maintenir, un formulaire HTML pour chaque étape, Ils permettent de séparer les règles de gestion et de faciliter par la même, l évolutivité du système Le protocole SOAP SOAP (Simple Object AccessProtocol) est un protocole de communication inter-applicatif transportant des messages via HTTP pour assurer des appels de procédures à distance (RPC). Il définit une enveloppe dans laquelle sont placées les données en édictant un certain nombre de règles pour structurer ces messages. En outre, il assure l interaction entre les services web en transportant des données structurées au format XML au sein d architectures distribuées orientées objet. Ces données structurées formant des messages SOAP peuvent être véhiculées soit en mode RPC soit en mode messagerie. 17/03/05 12/32 Pr143CAH_ANT_IDEO_V1.doc

13 Le message SOAP transitant sur Internet est codé en XML et encapsulé dans un flux HTTP. Il transporte à la fois des données métiers échangées entre les deux objets distants et les données techniques nécessaires à la bonne exécution de l appel : nom de la méthode appelée, type des données métier transportées, etc. Intérêts L objectif premier de SOAP est de normaliser les échanges de données en fournissant un framework de messagerie, un standard d encodage (XML) et un mécanisme d invocation de procédures à distance (RPC). Il permet la mise en place de web services et par conséquent vise à : Automatiser facilement les processus métiers, Faciliter l interopérabilité entre les systèmes et les plateformes hétérogènes, Aider l intégration d applications et de nouveaux services. Par ailleurs, l encapsulation des données XML dans un flux HTTP permet à SOAP de traverser les firewalls et autres équipements réseaux La technologie RMI-IIOP Les clients légers traditionnels tels que les applets ou les applications Java se connectent à la couche EJB à travers le protocole Internet Inter-ORB Protocol (IIOP) plutôt qu avec les services web, car généralement les clients légers peuvent être écrits dans la même organisation que l application J2EE, et par conséquent, le recours aux services web n est plus nécessaire. La technologie RMI-IIOP permet aux applications de provoquer l'exécution de procédures appartenant à des applications Java distantes et ce, de façon transparente. Les transactions mettent en jeu des objets qui sont transférés d'une application à une autre en conservant leur intégrité. La transmission de données se fait à travers un système de couches, basées sur le modèle OSI afin de garantir une interopérabilité entre les programmes et les versions de Java. 17/03/05 13/32 Pr143CAH_ANT_IDEO_V1.doc

14 Figure 3 Invocation d un EJB par RMI-IIOP Le stub (traduisez souche) et le skeleton (traduisez squelette), respectivement sur l application cliente et le serveur Idéopass, assurent la conversion des communications avec l'objet distant. La couche de référence (RRL, remote Reference Layer) est chargée du système de localisation afin de fournir un moyen aux objets d'obtenir une référence à l'objet distant. Elle est assurée par le package java.rmi.naming. On l'appelle généralement registre RMI car elle référence les objets. La couche de transport permet d'écouter les appels entrants ainsi que d'établir les connexions et le transport des données sur le réseau par l'intermédiaire du protocole TCP. Les packages java.net.socket et java.net.socketserver assurent implicitement cette fonction. Ainsi, l invocation d EJB Idéopass basée sur RMI met ainsi en oeuvre trois composantes : une application cliente implémentant le stub ; Idéopass implémentant le skeleton (squelette) ; une application médiatrice (le registre RMI) servie par un processus tiers (rmiregistry). Lorsque l application cliente souhaite accéder à des méthodes des EJB Idéopass, elle effectue les opérations suivantes : il localise l'objet distant grâce à un service de désignation : le registre RMI 17/03/05 14/32 Pr143CAH_ANT_IDEO_V1.doc

15 il obtient dynamiquement une image virtuelle de l'objet distant (appelée stub ou souche en français). Le stub possède exactement la même interface que l'objet distant ; Le stub transforme l'appel de la méthode distante en une suite d'octets, c'est ce que l'on appelle la sérialisation, puis les transmet au serveur instanciant l'objet sous forme de flot de données. On dit que le stub "marshalise" les arguments de la méthode distante ; Le squelette instancié sur le serveur "désérialise" les données envoyées par le stub (on dit qu'il les "démarshalise"), puis appelle la méthode en local ; Le squelette récupère les données renvoyées par la méthode (type de base, objet ou exception) puis les marshalise ; le stub démarshalise les données provenant du squelette et les transmet à l'objet faisant l'appel de méthode à distance. Intérêts L utilisation de RMI-IIOP est sécuritaire (les classes de gestion de la sécurité sont disponibles et le programmeur peut, s'il le désire, programmer les siennes) et la création d applications Java utilisant les classes RMI est relativement simple et rapide. En outre, ce protocole rend possible l interopérabilité entre les applications RMI et CORBA (autre framewrok de distribution des applications), de par le support des spécifications IIOP. Son utilisation permet la déportation des traitements système et une meilleure répartition des charges, mais les appels aux méthodes sont plus «coûteux» que traditionnellement. Le transfert de comportements (objets) d'une application à une autre permet d'exploiter toute la force des Design Patterns, puisque ces derniers s appuient généralement sur des comportements. Après ces brèves explications techniques des concepts et technologies ayant trait à Idéopass, la partie suivante s attachera à présenter la mise en oeuvre de ces technologies dans la conception et le développement de la solution. 17/03/05 15/32 Pr143CAH_ANT_IDEO_V1.doc

16 3. Architecture et composition d Idéopass L application Idéopass respecte le modèle d architecture client/serveur «multi-tiers» en obéissant au modèle de découpage des couches présenté précédemment au chapitre 2.1. La solution Idéopass a été conceptualisée à l aide du langage de modélisation UML et à partir de Design Pattern. Le choix de l environnement d exécution d Idéopass respecte les contraintes du modèle de développement Open Source. La solution est hébergée sur une plateforme J2EE et les tests menés par l équipe Idéopass permettent de garantir le fonctionnement de la solution sur les serveurs d application JBOSS et JONAS (excepté pour les fonctionnalités d abonnement qui n ont pas été testées sur cette dernière), couplé au moteur de servlet Tomcat. La couche présentation de la solution s appuie sur le serveur Web Open Source Apache. Le noyau fonctionnel d Idéopass, constitué de composants logiciels EJB, est accessible de quatre façons différentes, et accroît ainsi son interopérabilité avec les applications tierces : L interface utilisant Gidéopass développée en JSP (Java Server Pages). Les Web services reposant sur le protocole SOAP et utilisant le format de message HL7 préconisé par l initiative IHE. L appel aux EJB via des fonctionnalités d appel de méthodes à distance s appuyant sur le mécanisme Java RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol). L accès au noyau Idéopass directement au niveau de la couche transport grâce au support du protocole MLLP (Minimal Lower Layer Protocol). Ce protocole permet l acheminement de messages au format HL7. L emploi de messages au format HL7 dans les échanges SOAP et MLLP, et l implémentation qui en est faite, a permis à la solution Idéopass de réussir les tests de conformité à l initiative IHE appelés Connectathon et de prétendre à la conformité au profil PIX IHE à travers un «Integration Statement» (déclaration de conformité faite par l éditeur). Les données accédées et/ou enregistrées par les EJB fonctionnels d Idéopass sont stockées dans une base de données relationnelle. Les fonctionnalités de persistance de données d Idéopass supportent les bases Oracle, MySQL, PostGrèSQL et Caché. L ensemble des éléments logiciels Idéopass énoncés ci-dessus sont présentés ci-après dans l architecture multi-couches. 17/03/05 16/32 Pr143CAH_ANT_IDEO_V1.doc

17 Applications Applications Applications Browser Client Browser Client Routeur MLLP RMI- IIOP HTTP/SOAP Conteneur Java Web Service HTTP/HTTPS Conteneur JSP/Servlet Web Services Conteneur EJB Session Beans Session Beans Message-Driven Beans Logique Métier Accès Base Erreur Trace MLLP HL7 SOAP HL7 Infrastructure technique M M M JMS Base de données Log File d attente Figure 4 Architecture applicative de la solution Idéopass 3.1. Architecture fonctionnelle d Idéopass La solution Idéopass a été développée sur un modèle multi-couches à partir des spécifications fonctionnelles relatives à l identification du patient et publiées par le Groupement pour la Modernisation du Système d Information Hospitalier (GMSIH). Les orientations prises par les concepteurs du système Idéopass ont abouti à l architecture logicielle ciaprès, exposant la répartition des briques fonctionnelles de la solution : 17/03/05 17/32 Pr143CAH_ANT_IDEO_V1.doc

18 Sous-système INTERFACES Interface Client Interface Client léger léger Interface SOAP Interface SOAP Interface Interface RMI-IIOP RMI-IIOP Interface Interface MLLP MLLP Sous-système METIER Sous-système ADMINISTRATION Services Gestion Gestion Identité Identité Données Identité Identité Rapprochement Rapprochement Domaines de Domaines de Rapprochement Rapprochement Domaines Domaines d'identité d'identité Gestion Gestion Rapprochement Rapprochement Abonnement Abonnement Code Code HL7 HL7 Profil Profil Référentiel Référentiel Utilisateur Utilisateur Applications Applications Sous-système SERVICES Abonnement Abonnement Trace Trace Connecteur Connecteur DAO DAO Recherche Recherche Figure 5 Architecture fonctionnelle Idéopass Le système Idéopass est découpé en plusieurs sous-systèmes : Sous-système INTERFACES Ce sous-système se compose d interfaces d accès à l application Idéopass : l interface permettant la consultation et la mise à jour via un client léger (navigateur Web) par un utilisateur : «Interface client léger» ; l interface d accès aux données au travers de Web Services : «Interface SOAP» grâce aux API JAXM ; l interface d accès aux données au travers du protocole RMI-IIOP «Interface RMI-IIOP» ; l interface d accès aux données au travers du protocole MLLP «Interface MLLP» grâce aux HAPI. Sous-système METIER Ce sous-système donne accès aux services métier offerts par les composants métier. Ce sont la gestion de l identité et le rapprochement. Ce sous-système permet la manipulation des concepts suivants : 17/03/05 18/32 Pr143CAH_ANT_IDEO_V1.doc

19 L identité ; Le rapprochement ; L abonnement des applications ; Le codage HL7 grâce aux HAPI ; Le référentiel de données ; Les utilisateurs du système. Sous-système ADMINISTRATION Ce sous-système permet la gestion des éléments suivants à travers une interface (IHM) Web de consultation et de modification : Les domaines d identités ; Les domaines de rapprochements ; Les profils ; Les applications. Sous-système SERVICES Ce sous-système fournit des fonctionnalités techniques suivantes: La gestion des abonnements aux travers de files de messages (Abonnement aux identités, liens et rapprochements) ; La gestion des traces applicatives à travers une file de messages ; Les communications basées sur des connecteurs MLLP, SOAP ; Les algorithmes de recherche ; La persistance et l accès uniformisé aux données applicatives. L intérêt d une telle architecture est de séparer les couches entre elles. Dans la solution Idéopass, chaque composant distribué situé dans la couche de service implémente une logique métier bien particulière. Plus précisément, chaque EJB Session correspond à un contrôleur de Use Case UML. 17/03/05 19/32 Pr143CAH_ANT_IDEO_V1.doc

20 3.2. Architecture technique d Idéopass Modélisation et conception UML Les diagrammes utilisés pour la conception n ayant pas été fournis, l étude de la modélisation peut se faire uniquement sur la base des diagrammes présentés dans les différents documents (cf [DR3], [DR4], [DR5], [DR6], [DR9]). Les documents de spécifications fonctionnelles [DR4] contiennent les diagrammes de cas d utilisation utilisés pour modéliser la solution Idéopass. Ces derniers, plus communément appelés «usecase», se doivent de représenter l ensemble des fonctionnalités requises par le cahier des charges de la solution. En effet, la complétude des diagrammes des cas d utilisation UML est directement liée à la couverture fonctionnelle du produit résultant. Ainsi, au vu du schéma de couverture fonctionnelles p.7 du document [DR15] et de la matrice p.55 du document [DR3], il semblerait, par extrapolation (puisque nous ne disposons probablement pas de tous les diagrammes dans la documentation fournie) que les diagrammes de cas d utilisation sont globalement exhaustifs et conformes aux spécifications fonctionnelles du GMSIH ([DR13] [DR14]), base du cahier des charges d Idéopass. En outre, conformément aux paradigmes de modélisation UML, les «usecase» Idéopass ont servi de support à l élaboration des scénarii de tests du cahier de recette [DR5]. Présentant les aspects dynamiques du système à un niveau assez général, les diagrammes d activité d Idéopass apparaissent dans de nombreux documents et viennent généralement appuyer les diagrammes de cas d utilisation. Le document de spécifications techniques d Idéopass [DR6], riche en supports graphiques hérités de la modélisation UML d Idéopass, présente : les diagrammes de séquence de certains cas d utilisation considérés comme «type «par l équipe de développement Idéopass. Ces diagrammes fournissent ainsi une représentation temporelle des objets métier et de leurs interactions pour les fonctionnalités suivantes : o Recherche multi-critère d une identité ; o Modification d une identité ; o Création d un rapprochement. un modèle de package présentant les liens entre les différents packages (groupement de classes) de la solution ; des diagrammes de classes constituant des représentations statiques, de bas niveau, en terme de classes et de relations entre ces classes ; le modèle conceptuel de données (MCD) des éléments persistants d Idéopass (enregistrements) qui représente la structure du référentiel de données. La multitude des vues conçues lors de l élaboration d Idéopass laisse à penser qu Idéopass a bénéficié d un cadre d analyse solide, intégrant tous les aspects statiques et dynamiques du système, engendrant ainsi un modèle UML plutôt complet. 17/03/05 20/32 Pr143CAH_ANT_IDEO_V1.doc

21 La démarche de modélisation UML utilisée pour Idéopass est succinctement expliquée au paragraphe 2.2 du document de spécifications techniques [ref]. Elle respecte les préconisations de modélisation UML en se concentrant sur les besoins utilisateur et l architecture logicielle, et en adoptant un cycle itératif. Cependant, la conception d Idéopass reste peu détaillée quant au processus d élaboration des modèles UML de la solution, indicateur de qualité puisqu il représente la base de la modélisation et n est pas cadrée par la démarche UML Design Patterns Les développeurs de l application Idéopass ont eu recours à des schémas de codage prédéfinis, les «design pattern», qui réduisent la complexité du code et assurent d une bonne construction logicielle. Ces structures de code prédéfinies ont été mis en place conformément aux «Best practice», ou «Blueprints» publiées sur le site de Sun ( Les schémas de codage ci-après ont été distingués lors de cette étude : Le Design Pattern MVC (Model-View-Controller), qui constitue un modèle de conception structurant l architecture du programme pour l adapter au modèle multi-niveaux et répartir, dans un premier temps, les composants suivant trois catégories : les objets «Model» représentation logique de l interface utilisateur, «View» représentation visuelle de l objet «model», et «Controller» gérant l interaction avec l utilisateur. Les objets «Model» Idéopass correspondent aux données stockées dans la base de données (ex : identité patient). L objet «View» correspond à l application GIdéopass et l objet «Controller» à l ensemble des services du noyau Idéopass. Le Design Pattern DAO et le design Pattern FastLaneReader qui offre un cadre prédéfini pour le codage des accès aux sources de données en lecture et en écriture, indépendamment de la base de données mise en place. Le Design Pattern Factory, ou modèle de fabrique de classes, spécialise un objet unique à la création d autres objets. Ce modèle est notamment combiné avec le modèle DAO dans Idéopass pour créer un objet spécifique à un type de base de données. Le Design Pattern Facade qui unifie et simplifie l'interface d'un sous système cohérent et forme donc un point d'entrée simplifié dans une API. Le Design Pattern Value-Object qui permet l échange de données par valeur entre la couche de présentation et la couche de service. L utilisation des design pattern faite par les développeurs d Idéopass respecte les «BluePrints» édictés par Sun Microsystems en matière de nommage et de codage, bien que le nommage des services et des règles reste à uniformiser et à préciser au niveau des interfaces métier. Au vu du code fourni par l équipe Idéopass, les trois couches du modèle MVC semblent bien délimitées et structurées. Globalement, le code Java de la solution Idéopass est modulable, correctement structuré en modules applicatifs (EJB, MLLP,SOAP, HL7), permettant ainsi de cibler les changements sur le code développé. La bonne lisibilité et structuration du code offre un bon facteur de «maintenabilité» du code. Cependant, le manque d abstraction des classes et d héritage implique un faible taux de réutilisation des classes. Le code est peu commenté et les documentations technique et fonctionnelle du produit sont elles aussi peu fournies. 17/03/05 21/32 Pr143CAH_ANT_IDEO_V1.doc

22 Les composants logiciels fonctionnels J2EE Répondant aux problématiques fonctionnelles posées par le choix de l architecture et les services métier, la solution Idéopass implémente deux types d EJB : Les EJB «session sans état», pour traiter toutes les transactions faisant appel aux services métier du noyau Idéopass : identification et rapprochement d identités. Les EJB «message-driven», qui permettent d envoyer des messages de manière asynchrone. Ces composants fonctionnels se chargent de la synchronisation d Idéopass avec les clients abonnés et permettent le suivi d activité de la solution à travers les fonctions de trace. L emploi du design pattern «façade» définit des interfaces de services accessibles indépendamment de l implémentation qui en est fait. Cette structure minimise les impacts sur les déploiements et l adhérence applicative des composants EJB Services métiers Idéopass : Identification et rapprochement d identités Les services métiers sans état offerts par la solution Idéopass sont accessibles à travers des composants EJB session «sans état», de deux types IdentiteManagerBean et RapprochementManagerBea. Ces composants proposent les services métiers suivants qui correspondent aux fonctionnalités du produit : 17/03/05 22/32 Pr143CAH_ANT_IDEO_V1.doc

23 Composant Fonction Type Services IdentiteManagerBean Métier EJB session sans état getidentite creationidentiteforcee creationidentite creationlienidentite defusion fusion modificationidentite listdravecrapprochement listdoublonidentite rechercheidentitemulti recherchelienidentite suppressionlienidentite suppressionphysiqueidentite getnewclepatient RapprochementManagerBean Métier EJB session sans état creationidentitefederatrice creationrapprochement demconfrapproch getdetailrapprochements getidentitescandidates modificationrapprochement suppressionphysiquerapp Service d abonnement et de suivi d activité Dans le cadre de l application Idéopass les données sont traitées de manière asynchrone par des EJB de type message «Message-Driven Bean». Un Message-Driven Bean est un EJB qui permet de traiter des messages de manière asynchrone. En fait, cet EJB va réagir aux messages reçus au travers de JMS (Java Message Service). Les EJB «Message-Driven» implémentés par Idéopass offrent des services techniques de synchronisation et de «bufferisation» (mise en mémoire tampon) par messages lors d envoie de 17/03/05 23/32 Pr143CAH_ANT_IDEO_V1.doc

24 messages aux applications abonnées. Ces messages mettent aussi en œuvre les fonctions de trace du noyau pour proposer un suivi d activité de la solution. Les composants orientés message de l application Idéopass sont décrits dans le tableau suivant : Composant Fonction Type Services TraceBean Technique EJB orienté message AbonnementIdentiteBean Technique EJB orienté message AbonnementLienBean Technique EJB orienté message AbonnementRapprochementBean Technique EJB orienté message Ce composant n offre pas de service métier. Il se contente de logger le contenu du message dans un fichier de log Ce composant se charge de la synchronisation entre le SIP et les applications abonnées lors d échanges d informations d identité Ce composant se charge de la synchronisation entre le SIP et les applications abonnées lors d échanges d informations sur les liens Ce composant se charge de la synchronisation entre le SIP et les applications abonnées lors d échanges d informations sur les rapprochements Dans le cadre de la solution Idéopass, l utilisation des EJB est recommandée pour les raisons suivantes: La montée en charge des services sans état au travers de pool d EJB session sans état. Afin de ne pas pénaliser les performances du système, un nombre défini d EJB session sont instanciés au démarrage du serveur. Lors de la demande d exécution d un service métier on vérifie la disponibilité d un EJB. Si aucun n est disponible la demande est mise en attente. Les services sont accessibles depuis de nombreux type de clients à travers les protocoles RMI et IIOP. La centralisation de la logique applicative permet d'assurer l'intégrité des données et le respect des règles métiers Moyens de communication et points d entrée La gestion du dialogue utilisateur IHM Gidéopass Le dialogue avec l utilisateur, qu il soit avec ou sans assistance, est basé sur des feuilles HTMLs générées dynamiquement en fonction des actions et du contexte des utilisateurs. Cette génération dynamique est réalisée à travers des Java Server Pages (JSP) par l application Gidéopass. 17/03/05 24/32 Pr143CAH_ANT_IDEO_V1.doc

25 Ces pages HTMLs seront générées dynamiquement en respectant une logique fonctionnelle et technique. De plus des feuilles de styles (CSS) permettent d adapter le graphisme de l application en fonction de la charte graphique en vigueur. Cependant, on constate que dans le package «Gidéopass» les paradigmes du modèle MVC2 n a pas été entièrement respecté puisque la couche présentation fait appel à des DAO Accès aux services web La partie métier du noyau Idéopass peut être appelée par différentes applications utilisant différentes technologies et localisées dans différentes parties du réseau, éventuellement à travers des pare-feux. Les services Web offre un mode de communication synchrone appelable par des applications pas nécessairement développées en Java. La solution proposée met en œuvre des services métiers (implémentés avec des EJB de type Session) exposés sous forme de Web Services (description WSDL). Un Service Web qui expose l implémentation EJB d une fonctionnalité métier permet d offrir : Une visibilité et un accès à l information, que ce soit interne ou externe, Une intégrité des données et des processus métiers, Une adaptabilité de comportement en fonction du contexte, Une automatisation des services grâce à un accès programmable aux flux d information (client intelligent). L avantage de mettre en œuvre des services Web est d avoir à disposition des services métiers qui sont utilisables soit par un utilisateur, au travers d une interface Web, soit par une ou plusieurs applications périphériques. Le mode de fonctionnement des services web offerts par Idéopass est le suivant : 1. Un client envoie un message SOAP (contenant des instructions d'invocation d'un service de type RPC, conformément au WSDL de ce dernier) au serveur HTTP (ou HTTPS). 2. La servlet en charge de la gestion des services SOAP de type RPC (associée avec le service) reçoit le message, ouvre l'enveloppe SOAP et identifie l'ejb cible de la requête. Cette servlet décompose les paramètres et les attache aux objets Java appropriés. Elle invoque alors l'ejb en lui passant ces paramètres. 3. L'EJB effectue le travail demandé par le service et renvoie le résultat (s'il y en a un) à la servlet appelante. 4. La servlet SOAP rassemble les valeurs de retour dans un message SOAP et l'envoie au client. 17/03/05 25/32 Pr143CAH_ANT_IDEO_V1.doc

26 Conteneur Conteneur EJB EJB EJB session sans état 3 2 RPC SOAP Servlet Conteneur Conteneur WEB WEB 1 HTTP/HTTPS 4 Client Client SOAP SOAP Figure 6 Cinématique d accès à Idéopass par les web services En cas d erreur la servlet SOAP renvoie un message SOAP «error» au client SOAP. La solution Idéopass implémente ces services Web grâce à l API Java JAXM (Java API for XML Processing) qui permet l envoi et la réception de manière standard de messages SOAP. Dans le cas d un message HL7 encapsulé, après transformation et récupération des informations du message SOAP, l API HAPI (HL7 API) analyse et rend exploitable au système le message HL7 résultant. De la même manière, lors d un envoi de message, l API HAPI encapsule les informations dans un message HL7 et le transmet à l API JAXM pour l envoi d une réponse à l application interlocutrice Invocation des EJB à distance via RMI-IIOP Idéopass propose aux applications distantes clientes (ex : CPAGE) d invoquer directement à travers le réseau et grâce au protocole RMI-IIOP les EJB en charge des fonctionnalités métier. Les fonctionnalités métier sont accessibles à travers les interfaces EJB : IdentityManager ; RapprochementManager. Grâce au support du protocole RMI-IIOP, les services métier du noyau Idéopass sont invocables à distance par toutes les applications indépendamment de leur langage de programmation. 17/03/05 26/32 Pr143CAH_ANT_IDEO_V1.doc

27 Les services appelables à travers RMI-IIOP correspondent aux services décrits en Support du protocole MLLP Pour assurer l accès à Idéopass par la couche transport un connecteur MLLP a été développé. Ainsi les messages HL7 sont transités directement sur ce protocole de niveau 4 du modèle OSI (Open System Interconnection). Les messages sont analysés et formés grâce à l API Java OpenSource HAPI (HL7 API). Celle-ci supporte les messages HL7 dans leur version 2.4, au format pipe et au format XML. Les communications MLLP se font en mode synchrone par l intermédiaire de sockets instanciées entre le noyau Idéopass et l application interlocutrice. Les différents moyens d accès à Idéopass permettent à la solution d être inter-opérable avec un grand nombre d applications clientes, indépendamment de leur plate-forme d exécution et de leur langage de programmation. Les clients légers Java sont tous de même favorisés dans la variété des moyens de communication avec le serveur Idéopass (EJB et RMI, SOAP, MLLP). Un framework de tests automatisés a même été prévu pour tester la solution, en intégrant les outils d injection propres à l initiative IHE (MesaTools). Cependant, la gestion des erreurs de communication est peu ou prou traitée dans Idéopass et reste purement applicative et différée, du fait du recours à des fichiers batch de reprise sur erreur. L application ne propose aucun support asynchrone dans le dialogue inter-applicatif. Ce type de support pourrait être intégré par le biais de l API JMS, présente en standard sur la plateforme J2EE, et qui permettrait de garantir la livraison des messages et la reprise sur erreur en cas d échec de transmission. En outre, la solution Idéopass n offre pas de solution de haute disponibilité de type failover applicatif. Par ailleurs, le protocole SOAP encapsulant les messages dans un flux HTTP, les services Web permettent de plus la sécurisation des échanges client/serveur, par le biais du protocole HTTPS, dans l hypothèse où le serveur Web a été configuré pour utiliser celui-ci. Dans le cas contraire, Idéopass ne prévoit pas le chiffrement des communications, pour aucun des moyens de communications proposés par la solution Mécanismes de stockage et de persistance des données L accès aux données Idéopass a été implémenté suivant le design pattern DAO (Data Access Model). Idéopass définit une interface générique sous forme de package contenant : la factory DAO (fabrique) qui crée des objets enregistrements ; les classes correspondant à chacun des types d enregistrement (identité, application, domaine ). Ensuite pour chaque type de base de données supporté un package spécifique a été implémenté conformément à l arborescence du package générique et à ses interfaces. Cette construction confère à Idéopass une couche de données modulable et réutilisable tout en assurant son indépendance technique par rapport à la couche de service. L emploi des DAO permet l abstraction du type de base de données sous-jacent, et des nouveaux types de base peuvent être supportés par Idéopass en implémentant simplement de nouveaux DAOs correspondants. 17/03/05 27/32 Pr143CAH_ANT_IDEO_V1.doc

28 En pratique, la réalisation d une couche d accès aux données via des objets DAO présente les inconvénients suivants : les implémentations DAO pour chaque type de base étant relativement similaires, le code est redondant d un DAO à l autre. le codage «en dur» des requêtes SQL n est pas sécuritaire puisqu il offre une visibilité sur la structure des tables de données. la moindre modification de la structure de la base de données obligera à revoir l implémentation des DAOs correspondants. Par ailleurs, les DAOs n ont pas pour objectif de gérer des concepts plus complexes que l encapsulation des scripts d accès aux bases et de rendre ainsi transparent au développeur l accès au système de données. Ainsi, la gestion des transactions, de la concurrence et du cache doit être réalisée complémentairement pour chaque modèle de base de données supporté. Dans le cadre d Idéopass ces mécanismes n ont pas été prévu, et cette absence peut impacter les performances de la solution. Pour pallier à ces manques, l utilisation d un framework de persistance tel Hibernate ou Castor pour améliorer la couche d accès aux données d Idéopass est conseillée et permettra : l automatisation du mapping objet/ table ; l accès aux données sans se soucier des méthodologies d accès au serveur de base de données sous-jacent (aucune connaissance du langage de script de la base requise) ; l utilisation d un cache d objet améliorant sensiblement les caractéristiques de montée en charge ; la gestion simplifiée des accès concurrents ; la gestion des transactions et d interceptions des erreurs associées. 17/03/05 28/32 Pr143CAH_ANT_IDEO_V1.doc

29 4. Synthèse et analyse critique Concluant cette étude, une analyse de la solution Idéopass basée sur notre expertise et nos retours d expériences dans le domaine de la conception et du développement logiciel est proposée ci-après. Elle comprend trois parties distinctes : Notre avis technique exprimé en termes d avantages et d inconvénients ; Notre analyse SWOT de la solution Idéopass ; La conclusion de l étude Avantages et inconvénients de la solution Idéopass Le tableau suivant présente les avantages et les inconvénients de la solution Idéopass : AVANTAGES INCONVENIENTS Bonne séparation des trois couches, conformément au modèle MVC, minimisant ainsi l impact d évolutions futures. Bonne modularité du code JAVA Découpage correctement structuré en module applicatif (EJB, MLLP, SOAPHL7) qui permet de cibler les changements sur le code développé Lisibilité et structure du code offre un bon facteur de maintenabilité de celui-ci Respect des «Blue Prints» édictés par SUN en terme de nommage et de codage Architecture se prêtant bien au test automatisé : mise en place d un framework de tests automatisés (MesaTools) Implémentation du «design pattern» «façade» d EJB session. Ceci minimise les impacts sur les déploiements et l adhérence applicative. Support synchrone à travers les communications SOAP et MLLP Ouverture de la solution à des infrastructures non JAVA à travers l adoption des Web Services Ouverture au monde JAVA via le standard RMI- IIOP Interopérabilité avec les applications Corba MODELISATION ET STRUCTURE DU CODE COMMUNICATIONS Code très peu documenté. Pas de Javadoc. Manque de richesse dans les documents de spécifications techniques et d architecture technique. Nommage des services à uniformiser et règles à préciser notamment sur les interfaces métier Taux de réutilisation des classes faible en raison d un certain manque d abstraction. Notion d héritage peut utilisée entre les classes. Aucun support asynchrone proposé dans le dialogue inter-applicatif (bus de message par exemple) La gestion des erreurs de communication est peu évoluée, purement applicative et traitée en temps différé (batch de reprise des erreurs) 17/03/05 29/32 Pr143CAH_ANT_IDEO_V1.doc

30 Java via IIOP Support des EJB pour les applications tout Java Mise en œuvre du «design pattern» DAO pour la persistance des données. Ceci permet d accéder aux données de manière uniforme indépendamment de la base de données mise en place ACCES AUX DONNEES SECURITE Pas de mécanisme de fail-over applicatif Aucun support transactionnel Aucune gestion de pool d accès aux bases de données Gestion de cache peu sophistiquée au niveau du serveur d application Pas mise en œuvre de Framework logicielle de persistance des données indépendant de la base de données sous-jacente (type JDO Open Source Castor, Hibernate, etc.) L implémentation du «design pattern» DAO implique beaucoup de développement dupliqué en cas de support d une autre base de données Pas de mise en œuvre de protocole fort de sécurité (cryptage et signature). Simple implémentation de la fonction d encodage JAVA (hash code). 17/03/05 30/32 Pr143CAH_ANT_IDEO_V1.doc

31 4.2. Analyse SWOT Cette méthode permet d analyser les environnements externe et interne d un projet. L analyse est scindée par type environnement pour lequel on détermine les points positifs et les points négatifs. Dans l environnement externe ces éléments sont considérés comme des opportunités et des menaces. Les opportunités constituent le domaine d'action dans lequel le projet peut espérer jouir d'un avantage différentiel. Les menaces correspondent à un problème posé par une tendance défavorable ou une perturbation de l'environnement externe au projet. Dans l environnement interne ces éléments sont considérés comme des forces et des faiblesses qui s évaluent suivant deux critères : la performance et l importance. Le tableau suivant présente l analyse SWOT de l architecture technique de la solution Idéopass : FORCES FAIBLESSSES Forts évolutivité et caractère réutilisable de l architecture logicielle Respect des recommandations de développement JAVA Conception UML et adoption de modèle de conception Interopérabilité de la solution avec les environnements non JAVA via les Web Services Absence de framework applicatif notamment au niveau de l interface Web Capacité à monter en charge de la stratégie de persistance des données Manque de support de communication asynchrones inter-applicatives. Connecteurs applicatifs non standards OPPORTUNITES MENACES Plate-forme J2EE portable, ouverte et pérenne Support d une communauté OpenSource très active Support des serveurs d applications (JBOSS, JONAS) et intégration des bases de données (Oracle, MySQL et PostGres) du marché Architecture centralisée i.e. Single Point Of Failure Manque de visibilité sur l industrialisation de la solution (gestion de la configuration, documentation, ) Difficulté de la solution à adapter les développements aux évolutions des normes métiers (dialectes métiers, règles de gestion) Exploitabilité de la solution par manque d outils de suivi et de supervision technique et fonctionnelle 17/03/05 31/32 Pr143CAH_ANT_IDEO_V1.doc

32 4.3. Conclusion de l analyse La solution Idéopass est globalement bien conçue et correctement développée. Son architecture est à la fois ouverte au changement et à l intégration de nouvelles fonctionnalités. Elle repose sur un socle technique solide et riche en services techniques. Le support de protocoles techniques standardisés comme RMI-IIOP et SOAP et métier comme MLLP confère à la solution un fort caractère ouvert et inter-opérable. Le serveur Idéopass a été conçu pour répondre à une problématique à l échelle régionale, avec les volumes de données et de requêtes qu une telle utilisation sous-tend. Dans l hypothèse d une extension de la couverture de la solution à une échelle nationale, il serait préférable qu Idéopass intègre plus largement des bibliothèques et des frameworks applicatifs abondants dans le monde J2EE de la même façon qu elle bénéficie des implémentations OpenSource comme MLLP, HL7, etc. En effet, une réserve est néanmoins posée sur la capacité de montée en charge de la solution Idéopass selon le volume des flux envisagés. Afin de garantir la globalisation de cette solution, il est nécessaire de réaliser des tests de charge et d envisager à terme l évolution de la couche de persistance vers une solution plus évolutive et plus performante. Enfin, le support du mode synchrone dans les échanges entre applications (bus JMS) devrait à terme rendre plus robuste la solution et faciliter la supervision technique des flux. 17/03/05 32/32 Pr143CAH_ANT_IDEO_V1.doc