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