Examens corriges · Web viewReposant sur le JDK 1.1.7, à 1.3 selon les plates-formes, les fonctionnalités intègrent en particulier le pool de connexions, la sécurité, le load-balancing

Référence document : Version :

1.1

Date :

10/07/2002

Page :

1/51

Software Design

Références :

Pn : désigne la phase du projetCRXX : désigne le compte rendu de la réunion de la phaseBLXX : désigne le bien livrable de la phase

Objet :

Nom Fonction VisaRédaction : SOPHIE PEENAERT Consultant techniqueValidation SQLI : OMAR MRANI Directeur de ProjetValidation CHU : SERGE ADAM

JÉRÔME EUVRARDDirecteur des systèmes d'InformationResponsable du pôle applicatif

Liste de diffusionMonsieur Serge AdamMonsieur Jérôme EuvrardMonsieur Bruno Grossin Monsieur Lechevallier

Monsieur Daniel JeannoutotMadame Lydie BretillotMonsieur Yves Meslans

HISTORIQUE DES MODIFICATIONSVERSION RELEASE DATE OBSERVATIONS ACTION (*) DEMANDE PAR

1 0 04/07/2002 Version Initiale 1 1 04/10/2002 Annexe serveurs d’applications I

(*) : D = Détruire une page I = Insérer une page R = Remplacer une page

SOMMAIRE

1. Introduction______________________________________________________________________________________3

2. Le contenu du portail médical________________________________________________________________________4

2.1 Identification du professionnel de santé____________________________________________________________4

2.2 Rubrique « Dossier patient »_____________________________________________________________________4

2.3 Rubrique « Traitements » (demandes et résultats)___________________________________________________7

2.4 Rubrique « Examens » (demandes et résultats)______________________________________________________9

2.5 Rubrique « Suivi patient »______________________________________________________________________10

2.6 Rubrique « Planification »______________________________________________________________________11

2.7 Autres fonctionnalités liées au métier du professionnel de santé_______________________________________12

2.8 Autres fonctionnalités__________________________________________________________________________13

3. Les niveaux d’intégration__________________________________________________________________________15

3.1 Intégration forte______________________________________________________________________________15

3.2 Intégration moyenne___________________________________________________________________________19

3.3 Intégration faible______________________________________________________________________________22

3.4 Développement de fonctionnalités en « spécifique »_________________________________________________24

4. Architecture applicative____________________________________________________________________________25

4.1 Identité du patient_____________________________________________________________________________26

4.2 Identité du professionnel de santé________________________________________________________________31

4.3 Localisation du patient_________________________________________________________________________32

5. Liens avec la plate forme régionale___________________________________________________________________34

6. Architecture technique_____________________________________________________________________________37

6.1 Les briques qui constituent l’architecture_________________________________________________________37

7. Annexe : Présentation de trois serveurs d’application.___________________________________________________47

7.1 Oracle IAS, 9iAS______________________________________________________________________________47

7.2 WebSphere d’IBM____________________________________________________________________________49

7.3 WebLogic de BEA_____________________________________________________________________________50

RÉFÉRENCE DOCUMENT : VERSION :1.1 CHU DE BESANÇON – PORTAIL MÉDICAL

SOFTWARE DESIGN

PAGE :3/51

1. INTRODUCTION

Ce document s’inscrit dans le cadre de la mise en place du portail médical du CHU de Be-sançon.

Le portail médical a pour objectif d’apporter à certains professionnels de santé, un outil in-formatique unique pour répondre à pratiquement tous leurs besoins. Les utilisateurs qui ont été identifiés aujourd’hui sont :

- les médecins- les infirmières et aides soignantes

De plus, d’autres utilisateurs sont à prendre en compte car ils ont besoin d’avoir accès au mêmes outils. Ces personnes utiliseront le portail en parallèle avec d’autres applications existantes qui ne seront pas intégrées au portail aujourd’hui.

- les secrétaires médicales- le personnel socio-médical

Le présent document présente les architectures technique et software du portail. Il aborde les su-jets suivants :

- Présentation des fonctionnalités disponibles sur le portail. Ceci a permis de lister les composants/logiciels qui seront utilisés à partir du portail.

- Description des niveaux d’intégration envisagés, et les contraintes liées à chacun de ces niveaux. Ces contraintes techniques ont un impact sur l’ergonomie et la présenta-tion de l’application.

- Schéma d’architecture software, avec en particulier des précisions sur les processus d’identification du patient, de localisation du patient et d’identification du professionnel de santé

- Architecture technique


SOFTWARE DESIGN

PAGE :4/51

2. LE CONTENU DU PORTAIL MÉDICAL

2.1 IDENTIFICATION DU PROFESSIONNEL DE SANTÉ

Rubrique : / Sous rubrique : /Description

Écran d'identification. L’identification se fait de deux façons :o Saisie d’un login et d’un mot de passeo Utilisation de la carte CPS et saisie d’un mot de passeL’identification se fait une seule fois, on utilise des mécanismes de SSO pour partager le profil entre toutes les applications du portail.

Applications existantesGDA et écrans propres aux applications

Intégration dans le portailPour permettre l’identification et le fonctionnement du SSO, deux travaux sont à entreprendre :o Développement d'un composant d'identification utilisant la carte CPS. o Création d'un composant qui remplace partiellement GDA (tant que les applications C/S ne

sont pas intégrées au portail) : Vérification des droits et ouverture du .EXE de l'application client serveur.

Ce sujet est abordé en détail dans le paragraphe « Identité du professionnel de santé » (page 31)

2.2 RUBRIQUE « DOSSIER PATIENT »

Rubrique : Dossier patient Sous rubrique : Sélectionner un patientDescription

Recherche d'un patient à partir de critères. Les critères sont de deux types : o Identité du patient.o Localisation du patient sur une période.

Il est aussi possible de définir des listes de patients personnalisées. Cette fonctionnalité permet aux professionnels de retrouver plus facilement les patients pour lesquels ils travaillent.

Applications existantesChaque application C/S a son module de recherche. Certaines applications affichent directe-

ment la liste des patients présents dans l’UF de l’utilisateur.

Intégration dans le portailDévelopper un composant spécifique pour le portail, en fonction de spécifications communes.

Ce sujet est abordé en détail dans le paragraphe « L’identité du patient sur le portail » (page 26)


SOFTWARE DESIGN

PAGE :5/51

Rubrique : Dossier patient Sous rubrique : Fiche patientDescription

Consultation et modification des données suivantes : o Identité du patient (administratif),o Renseignements médicaux (=antécédent),o Données infirmières,o Dossier de spécialité,o Courriers,o Localisation du patient (Entrées, sorties et mouvements).

Applications existantesCPage permet d'accéder à la partie identité et localisation. D'autres applications C/S per-

mettent de la consulter à parti du SIL répliqué.Les renseignements médicaux et les données infirmières sont sur papier.Le dossier de spécialité et les courriers de certaines UF sont sur l’application C/S copernic.

Les autres informations ne sont pas référencées dans des BDD (ex : antécédents, données in-firmières).

Intégration dans le portailL’identité du patient et sa localisation sont gérées à partir de composants à développer.

Le choix d'un logiciel de gestion du "Dossier Patient de Synthèse" est en cours (fin 2002). Il traitera les parties suivantes :

o Renseignements médicaux.o Dossier de spécialité - Si cette fonctionnalité n’est pas totalement couverte, des projets

d'achats de progiciels spécialisés seront lancés en 2003 et plus (ex: DIAM pour le pôle mère-enfant).

o Courriers.

Le choix d'un logiciel de gestion du "Dossier de Soins" se fera (pas avant 2003). Il traitera la partie suivante :

o Données infirmières.


SOFTWARE DESIGN

PAGE :6/51

Rubrique : Dossier patient Sous rubrique : Historique des venuesDescription

Cette fonctionnalité permet de consulter (pas de saisie) l’historique des données du patient. Il s’agit de toutes les données manipulées sur le portail médical.

L’utilisateur a la possibilité de choisir le dossier et le type des données affichées : o Consultation ou hospitalisation

Eto PMSI, Courriers, Traitements, Examens ou Suivi patient.

Applications existantesPlusieurs applications permettent de consulter des données d’historique aujourd’hui :

o L’application C/S Copernic, pour accéder à des historiques de courrier (partiel, pour cer-taines UF uniquement).

o DEX-MED (C/S) et Chimio (Web) pour d'obtenir des informations partielles sur les traite-ments.

o L'intranet DMC pour afficher la liste des dossiers. Mais les développements ne sont pas finalisés, l’application est difficilement réutilisable.

o REXAL (Web + Business Objects) pour les résultats d'examens biologiques (4 mois d’his-torique uniquement, pas réutilisable).

o DEX-BIO (C/S) pour les demandes d'examens biologiques.

Les autres données sont conservées sur papier.

Intégration dans le portailDévelopper un composant de recherche d'un dossier / RUM spécifiquement pour le portail.

Le choix d'un logiciel de gestion du "Dossier Patient de Synthèse" est en cours (fin 2002). Il traitera tous les besoins de cette rubrique.

Remarques : - Des études sont en cours pour remplacer les SGL (systèmes de gestion des laboratoires). Ceci

aura des impacts sur cette rubrique.- Il serait possible de développer rapidement des solutions pour remplacer REXAL et Intranet

DMC (en intégrant le SSO).

Rubrique : Dossier patient Sous rubrique : PMSIDescription

Saisie des actes et des diagnostics PMSI (Programme de Médicalisation des Systèmes d'Infor-mation)

Applications existantesEntièrement géré dans l'application C/S Copernic

Intégration dans le portailUn composant sera développé pour intégrer ces fonctionnalités


SOFTWARE DESIGN

PAGE :7/51

Rubrique : Dossier patient Sous rubrique : Dossier réseauDescription

Accès au futur portail régional (externe au CHU).Remarque : pas d'intégration des données régionales dans le portail du CHU

Applications existantesRien (hors CHU)

Intégration dans le portailAttendre le portail régional (horizon : septembre 2002)

Étudier la possibilité d'accéder directement au dossier régional du patient sélectionné dans le portail du CHU.

Rubrique : Dossier patient Sous rubrique : Commande d'archivesDescription

Formulaire de saisie d'une demande d’archives

Applications existantesFormulaire existant sur l'intranet du CHU.

Intégration dans le portailIntégration (+ adaptation) de la solution existante dans le portail.

2.3 RUBRIQUE « TRAITEMENTS » (DEMANDES ET RÉSULTATS)

Rubrique : Traitements Sous rubrique : InjectablesDescription

Choix fonctionnels à faire dans le cadre de l'achat des composants.

Applications existantesSolutions non informatisées

Intégration dans le portailEn fonction de la politique d'achat, mise en place d'un logiciel de prescription (2002-2003)


SOFTWARE DESIGN

PAGE :8/51

Rubrique : Traitements Sous rubrique : MédicamentsDescription

Saisie de la prescription

Applications existantesPlusieurs solutions existent :

o DEX-MED (C/S),o Chimio (Web),o Solutions non informatisées.

Intégration dans le portailEn fonction de la politique d'achat, mise en place d'un logiciel de prescription (2002-2003)Intégration de la partie Chimio dans le portail.

Rubrique : Traitements Sous rubrique : Non médicamenteuxDescription

Choix fonctionnels à faire dans le cadre de l'achat des composants.



Rubrique : Traitements Sous rubrique : AutresDescription

Choix fonctionnels à faire dans le cadre de l'achat des logiciels (ex : transfusion)




SOFTWARE DESIGN

PAGE :9/51

2.4 RUBRIQUE « EXAMENS » (DEMANDES ET RÉSULTATS)

Rubrique : Examens Sous rubrique : BiologiqueDescription

Choix fonctionnels à faire dans le cadre de l'achat des logiciels.

Applications existantesPour les demandes : DEX-BIO (C/S).Pour les résultats : REXAL (web) et solutions non informatisées.


Rubrique : Examens Sous rubrique : RadiologiqueDescription

Choix fonctionnels à faire dans le cadre de l'achat des logiciels.Utilisation d'un PACS.

Applications existantesSolutions non informatisées.


Rubrique : Examens Sous rubrique : ConsultationsDescription


Applications existantesSolutions non informatisées.



SOFTWARE DESIGN

PAGE :10/51

2.5 RUBRIQUE « SUIVI PATIENT »

Rubrique : Suivi patient Sous rubrique : HPDDDescription

Planning du patient.


Intégration dans le portailDéveloppement d’un composant spécifique à ce type de prise en charge dans le portail.

Rubrique : Suivi patient Sous rubrique : Surveillance médicaleDescription



Intégration dans le portailEn fonction de la politique d'achat, mise en place d'un de gestion du "Dossier de Soins (pas

avant 2003).

Rubrique : Suivi patient Sous rubrique : Notes d’observationDescription




avant 2003).


SOFTWARE DESIGN

PAGE :11/51

Rubrique : Suivi patient Sous rubrique : Surveillance alimentaireDescription




avant 2003).

2.6 RUBRIQUE « PLANIFICATION »

Rubrique : Planification Sous rubrique : HPDD groupe patientDescription

Planning d’un groupe de patients.

Applications existantesSolutions non standardisées : papier ou MS Excel.

Intégration dans le portailDéveloppement d’un composant spécifique à ce type de prise en charge dans le portail. (idem

HPDD)

Rubrique : Planification Sous rubrique : Planning du serviceDescription

Planning du personnel d’un service.

Applications existantesSolutions non standardisées : papier ou MS Excel.

Intégration dans le portailL'achat d'un logiciel de gestion du temps est en cours. Vérifier qu'il couvre ce périmètre.Sinon, pas de solution à court terme.


SOFTWARE DESIGN

PAGE :12/51

Rubrique : Planification Sous rubrique : PRNDescription

Affectation de un ou plusieurs codes PRN à chaque patient pour chaque jour passé à l'hôpital.

La saisie se fait "en masse" (pour tous les patients d'une UF en même temps). Possibilité de co-pier les saisies faites sur un jour sur les jours suivants

Applications existantesApplication PRN (C/S) + GDA

Intégration dans le portailDéveloppement d'un composant.

2.7 AUTRES FONCTIONNALITÉS LIÉES AU MÉTIER DU PROFESSIONNEL DE SANTÉ

Rubrique : Commandes Sous rubrique :

Quatre sous rubriques : o Repaso Médicamentso Approvisionnementso Demande d'intervention

DescriptionReprendre les fonctionnalités des applications existantes.

Applications existanteso WINREST (C/S)o APPRODI (C/S)o GDA

Intégration dans le portailA terme, mise en place d'un composant intégré au portail (Pas avant 2005)

Dans un premier temps, lien vers les applications existantes. Il faut étudier la possibilité d'utili-ser le SSO, et d'ouvrir les applications directement sur la page souhaitée.


SOFTWARE DESIGN

PAGE :13/51

Rubrique : Documentation Sous rubrique : IndicateursDescription

o Statistiques PMSIo Consolidations PRNo Décisionnel CPage

Applications existantes

Intégration dans le portailDéveloppement d’un composant intégré au portail.

Rubrique : Vigilance Sous rubrique : /Description

Consultation et saisie des notes de vigilance

Applications existanteso Prodsang,o Pharmaco-vigilance,o Traçabilité DMI CAMSP,o Nosocomiale

Intégration dans le portailL'achat d'un logiciel de gestion des notes de vigilance est en cours (objectif oct./nov.

2002)

2.8 AUTRES FONCTIONNALITÉS

Rubrique Sous ru-brique Intégration dans le portail

Gestion Per-sonnelle

Agenda par-tagé Utilisation des outils du portail / Développement.


Présence médicale Utilisation des outils du portail / Développement.


Liste des tâches Utilisation des outils du portail / Développement.

Gestion Per-sonnelle Mémo Utilisation des outils du portail / Développement.

Web Messagerie Lien vers l'application de messagerie présente sur le poste client.Web Internet Ouverture d'une nouvelle fenêtre du browser sur le poste client.Web Wchub Ouverture de l'intranet WCHUB dans une nouvelle fenêtre du brow-

ser.Web DRH/DAM Portage de l'existant dans l'environnement du portailWeb Visio Lien vers une application de visio-conférence présente sur le poste


SOFTWARE DESIGN

PAGE :14/51

Rubrique Sous ru-brique Intégration dans le portail

client.

Bureautique Traitement texte

Ouverture du logiciel de traitement de texte présent sur le poste client.

Bureautique Tableur Ouverture du tableur présent sur le poste client.Bureautique Présenta-

tion Ouverture de l'outil présent sur le poste client.

Documentation Vidal Intégration d’un composant dans le portail.

Documentation Protocoles Dans un premier temps, lien vers les documents. A terme, intégration d'un outil de gestion documentaire

Documentation Guides logi-ciels

Dans un premier temps, lien vers les documents. A terme, intégration d'un outil de gestion documentaire

Favoris Documents Utilisation des outils du portail / Développement.Favoris Liens Utilisation des outils du portail / Développement.

Transverse Actualités Utilisation des outils du portail / Développement.Transverse Recherche Utilisation des outils du portail / Développement.Transverse Annuaire Utilisation d’un composant du marché.

Transverse Support Intégration d’un composant capable de s’interfacer avec l’applica-tion existante.


SOFTWARE DESIGN

PAGE :15/51

3. LES NIVEAUX D’INTÉGRATION

Le paragraphe précédent a montré qu’un certain nombre de logiciels et composants doivent être intégrés au portail. Ceux-ci seront achetés ou développés spécialement pour le portail. Dans le cas où des logiciels sont achetés, l’intégration sera plus ou moins « facile » suivant la na-ture du logiciel acheté.

3.1 INTÉGRATION FORTE

Dans le cas d’une intégration forte, les principales caractéristiques de l’application sont :1. L’application intégrée ne communique pas directement avec le browser du profes-

sionnel de santé. Tous les échanges se font entre le portail et l’application intégrée. Il sont à l’initiative de l’application portail, en mode requête réponse (Le portail en-voie un message et attend une réponse). Les messages sont basés sur des fichiers XML dont le format est imposé par l’application intégrée.

2. La présentation des données est entièrement réalisée sur le portail. Ceci se fait grâce à des feuilles XSL qui sont adaptées à la charte graphique du portail d’une part, et aux données manipulées dans l’application intégrée d’autre part. En fait, il faut créer une feuille XSL par page intégrée au portail.

3. La cinématique de navigation est globalement imposée par l’application intégrée, mais elle peut-être adaptée au portail. Il faut simplement que l’affichage et la vali-dation de chaque écran soit gérée par un ou plusieurs services de l’application inté-grée.

1.1.1 Déroulement d’un appel à l’application inté-grée.

Le schéma ci-dessous présente les composants qui interviennent lors de l’appel d’une ap-plication intégrée :


SOFTWARE DESIGN

PAGE :16/51

L’appel de l’application intégrée se passe comme ceci :- L’internaute active un lien vers l’application intégrée.- L’URL associée au lien correspond à une servlet du portail (comme pour les URL in-

ternes au portail).- Le traitement est délégué à un composant dédié aux interfaces avec l’application X. Ce

composant se charge de o Collecter toutes les données nécessaires à l’appel d’un service de l’application

intégrée. Elles proviennent de l’écran validé par l’internaute, et du contexte de session.

o Envoyer un message à l’application X (via l’EAI si nécessaire).o Attendre une réponse (Si l’appel se fait en asynchrone, l’application X devra ren-

voyer une message après le traitement).o Préparer le fichier XML de données à afficher (il peut s’agir du fichier XML reçu).

- Le controler (modèle MVC) reprend les traitements quand le composant de gestion de l’application X a terminé.

- Un composant d’assemblage génère le code HTML à envoyer au client. Cette généra-tion se fait à partir du fichier XML et d’une feuille de style XSL.

Si l’internaute active un autre lien dans la zone de l’application X, le déroulement est identique.

1.1.2 Sécurité, SSO

Gestion des droits sur les données.Avant de naviguer sur le portail, le professionnel de santé se connecte grâce à sa carte CPS. Par la suite, à chaque fois qu’il utilise une fonctionnalité du site, un contrôle des droits liés à son profil est réalisé. Dans le cadre de l’utilisation des pages avec intégration forte, le contrôle se fait à deux niveaux :

- par l’application portail avant l’ouverture de la page intégrée- par l’application intégrée à la réception du fichier XML. Ce fichier contient donc des in-

formations sur le profil de la personne (son identifiant par exemple)

Sécurité des fluxSi l’architecture technique l’impose, on peut envisager de crypter les fichiers XML échangés entre le portail et l’application intégrée. Pour cela, il faut que cette fonctionnalité soit supportée des deux côtés. (A priori, le portail et les application intégrées sont toutes les deux sur le réseau in-terne du CHU, on ne devrait pas avoir de telles contraintes).Le portail doit s’identifier auprès de l’application intégrée avant de l’utiliser.

SSOLe SSO est obligatoirement géré par cette solution, puisque l’utilisateur ne se connecte pas direc-tement sur l’application intégrée.


SOFTWARE DESIGN

PAGE :17/51

1.1.3 Contraintes techniques

Contraintes sur l’application intégréeL’application intégrée ne gère pas l’affichage des données. Elle est utilisée pour

- traiter les actions qui sont déclenchées par les internautes sur le portail,- fournir les données affichées sur les écrans du portail.

Contraintes sur le portailLe portail doit posséder une bibliothèque de feuille de styles XSL. Celles-ci sont utilisées par le moteur de transformation XSLT, afin de générer des pages HTML contenant :

- les données reçues de l’application intégrée dans des fichiers XML- les balises HTML qui constituent la page sur laquelle on dépose les données.

Ces feuilles de styles sont donc dépendantes- de la charte graphique du portail,- des gabarits de page du portail,- de la cinématique de navigation dans les pages de l’application intégrées,- du contenu des pages de l’application intégrée.

La construction de ces feuilles de style fait partie du travail d’intégration de l’application.

Gestion des échangesLes deux applications doivent être capables de lire et de générer des fichiers XML. Ceci ne pose pas de problèmes pour le portail, de telles fonctionnalités sont supportées par J2EE.

Les deux applications doivent être capables d’échanger des messages contenant des fichiers XML. Les communications sont commencées par le serveur d’application, l’application intégrée envoie une réponse. En fait, l’échange doit se faire de façon synchrone.

Le CHU souhaite acquérir un EAI et l’utiliser pour les échanges entres le serveur d’application et les applications intégrées (entre autres). Il faudra alors s’assurer que des outils sont fournis par l’EAI pour :

- permettre au portail de déposer un message et attendre une réponse- déclencher un traitement sur l’application intégrée.

Ces outils sont simplement des programmes compatibles avec les technologies utilisées sur le serveur d’application et sur les applications intégrées.


SOFTWARE DESIGN

PAGE :18/51

Echanges synchrones entre les deux applications :

Les traits verticaux gris épais symbolisent un traitement qui est en cours et non terminé. Puisque les échanges se font en synchrone, le programme qui envoi un message ne se termine que quand la réponse est renvoyée.

Si les moyens utilisés pour transporter les messages ne peuvent pas assurer un transport syn-chrone, il faudra « simuler » un échange synchrone. Dans ce cas le portail médical envoi un message puis attend de recevoir un autre message, qui contient une réponse à ce qu’il a envoyé. De son côté, l ‘application intégrée reçoit un message, réalise les traitements puis envoi un message contenant une réponse.Il faut donc s’assurer que l’EAI permet aux applications de mettre en place de tels mécanismes.

Echanges asynchrones entre les deux applications :


SOFTWARE DESIGN

PAGE :19/51

3.2 INTÉGRATION MOYENNE

Dans le cas d’une intégration moyenne, les principales caractéristiques de l’application sont :1. L’application intégrée communique directement avec le browser de l’utilisateur. Lorsqu’on

ouvre la première page de l’application intégrée, la requête passe éventuellement par le portail pour ajouter des informations dans la requête. Les appels aux autres pages se font directement sur le serveur web de l’application intégrée.

2. L’application intégrée génère des pages conformes à la charte graphique et aux gabarits du portail médical.

3. Le portail fonctionne en mode « dégradé ». Puisque la totalité de la page est générée par le serveur web, les parties qui ne sont pas gérées directement par l’application sont quasi-ment statiques. Il s’agit des zones à l’extérieur du carré hachuré en vert sur les schémas ci dessous. Ceci implique que la personnalisation et le fonctionnement des portlets ne seront plus actives sur les pages de l’application intégrée.


L’appel de l’application intégrée se passe comme ceci :- L’internaute active un lien vers l’application intégrée.- Ce lien fait appel à une servlet du portail médical- La servlet ajoute des paramètres dans la requête. Ces paramètres seront utilisés par

l’application intégrée pour situer l’appel dans son contexte. Par exemple, on peut ajou-ter des informations sur l’identité de l’utilisateur de l’application, et des informations sur le patient qui a été sélectionné dans le portail.

- La servlet redirige ensuite la requête vers le serveur http de l’application intégrée.- L’application X traite la requête et génère une page HTML de façon autonome.


SOFTWARE DESIGN

PAGE :20/51

Comme le montre le schéma ci-dessus, lorsque l’internaute clique sur un autre lien dans la « zone intégrée », l’appel est envoyé directement au serveur web de l’application intégrée.


Gestion des droits sur les données.Avant de naviguer sur le portail, le professionnel de santé se connecte grâce à sa carte CPS.

Par la suite, à chaque fois qu’il utilise une fonctionnalité du site, un contrôle des droits liés à son profil est réalisé. Dans le cadre de l’utilisation des pages avec intégration forte, le contrôle se fait par l’application intégrée à la réception des requêtes http. Ceci suppose que l’internaute est iden-tifié sur l’application intégrée.

SSOComme indiqué ci-dessus, l’internaute doit être identifié sur l’application intégrée. Il est

donc important de mettre en place le SSO. Pour cela, on fera tout simplement circuler les para-mètres d’identification de l’internaute dans la première requête qui est envoyée à l’application in-tégrée. En effet cette requête a été redirigée par le portail, il peut donc y ajouter des paramètres. Ce mécanisme peut nécessiter la création sur l’application intégrée, d’une servlet dédiée au trai-tement de la requête provenant du portail.

Une autre problématique est à considérer dans ce type d’intégration : puisque les requêtes sont envoyées directement à l’application intégrée, le portail n’est plus sollicité par l’internaute. Si l’in-ternaute utilise longtemps la même application intégrée, la session de l’utilisateur sur le portail expirera.


Transition portail – application intégréePour que le passage d’une page du portail à une page de l’application intégrée se fasse bien, il faut qu’une partie du contexte de la session de l’internaute, soit transmise à l’application inté-grée. En particulier, le nom de l’internaute doit passer d’une application à l’autre.Cette transmission d’informations se fera au moyen d’une requête http contenant des para-mètres.


SOFTWARE DESIGN

PAGE :21/51

Si on veut maîtriser cette liste de paramètres, il sera sans doute nécessaire d’installer sur l’appli-cation intégrée un objet (une servlet par exemple) destiné à lire les données que le portail envoie.Exemples de paramètres qu’il pourrait être intéressant d’utiliser :

- nom, identifiant de l’internaute- identifiant du patient qui a été sélectionné- nom de la page qu’on souhaite afficher (pour que l’internaute n’est pas à « naviguer »

sur plusieurs pages de l’application)- La couleur affectée au profil

Création des pages HTMLLa génération des pages HTML est entièrement gérée par l’appli-cation intégrée.Celle-ci doit donc être adaptée au portail pouro La charte graphiqueo Les gabaritso L’affichage des bandeaux (haut, gauche, droite)o La gestion des couleurs affectées à chaque profil (si possible)

Toutefois, les pages de l’application intégrée ne seront pas aussi complètes que l’application inté-grée :

- Les portlets des bandeaux ne seront pas personnalisées (puisque c’est le portail qui le fait).

- S’il y a des liens dynamiques sur les bandeaux / portlets, on pourrait être amenés à les supprimer. En effet, on ne peut pas redévelopper toutes les fonctionnalités présentes sur le portail, il faudra donc supprimer ces fonctionnalités (par exemple, « Vous avez x nouveaux messages »)

Comme le montrent les schémas ci-dessous, la place réservée à l’application intégrée n’est pas fi-gée. Plusieurs solutions sont envisageables :


SOFTWARE DESIGN

PAGE :22/51

3.3 INTÉGRATION FAIBLE

Dans le cas d’une intégration faible, les principales caractéristiques de l’application sont :4. L’application intégrée communique directement avec le browser de l’utilisateur. Lorsqu’on

ouvre la première page de l’application intégrée, la requête passe éventuellement par le portail pour ajouter des informations dans la requête. Les appels aux autres pages se font directement sur le serveur web de l’application intégrée.

5. L’application intégrée génère des pages ayant un aspect différent des autres pages du por-tail.

6. Les pages de l’application intégrée s’ouvrent dans un nouvelle fenêtre du browser sur le poste de l’internaute. Ainsi, l’utilisateur peut retourner sur la fenêtre du portail en utilisant la barre des tâches windows, ou en fermant la nouvelle fenêtre de son browser.



SOFTWARE DESIGN

PAGE :23/51

L’appel de l’application intégrée se passe comme ceci :- L’internaute active un lien vers l’application intégrée.- Ce lien ouvre une deuxième fenêtre du browser sur le poste client.- La nouvelle fenêtre fait appel à une servlet du portail médical- La servlet ajoute des paramètres dans la requête. Ces paramètres seront utilisés par

l’application intégrée pour situer l’appel dans son contexte. Par exemple, on peut ajou-ter des informations sur l’identité de l’utilisateur de l’application, et des informations sur le patient qui a été sélectionné dans le portail.

- La servlet redirige ensuite la requête vers le serveur http de l’application intégrée.- L’application X traite la requête et génère une page HTML de façon autonome.

Comme le montre le schéma ci-dessus, lorsque l’internaute clique sur un autre lien dans la « zone intégrée », l’appel est envoyé directement au serveur web de l’application intégrée.


Sur ces points, on est dans la même situation que pour une intégration moyenne.


Comme pour l’intégration moyenne, il faut mettre en place un mécanisme pour faciliter la transi -tion d’une page du portail à une page de l’application.Il n’y a pas de contraintes techniques en plus.


SOFTWARE DESIGN

PAGE :24/51

3.4 DÉVELOPPEMENT DE FONCTIONNALITÉS EN « SPÉCIFIQUE »

Pas de problème d’intégration dans le portail, puisque toutes les contraintes sont prises en comptes au moment des développements.

Pour les applications existantes en C/S, il suffit de redévelopper l’interface graphique. On peut conserver

- les écrans d’administration (non utilisés sur le portail),- les traitements de type batch,- la base de données.


SOFTWARE DESIGN

PAGE :25/51

4. ARCHITECTURE APPLICATIVE

Vue d’ensemble des objets métiers du portail :

Aujourd’hui, les composants et logiciels à utiliser sur le portail n’ont pas encore été choisis. Il est donc trop tôt pour modéliser spécifiquement toutes les interfaces entre le portail et chaque com-posant/logiciel. Les schémas présentés dans le paragraphe 3 « Les niveaux d’intégration » dé-crivent les échanges entre le portail et les logiciels en question.

Trois fonctionnalités sont à étudier avec attention car beaucoup de logiciels auront à utiliser les données qu’elles gèrent. Il s’agit de :

- Identité du patient- Identité du professionnel de santé- Localisation des patients


SOFTWARE DESIGN

PAGE :26/51

4.1 IDENTITÉ DU PATIENT

1.1.10Contexte - architecture

Pour bien comprendre la problématique de l’identité du patient, il est nécessaire de faire un rappel sur le contexte.

Aujourd’hui, L’identité du patient est gérée en interne et de façon autonome par l’hôpital. Cpage joue le rôle de serveur d’identité. Cpage est le seul outil utilisé pour créer ou modifier l’identité d’un patient. Les autres applications utilisent les données de Cpage en lecture, grâce au SIL répli-

qué (BDD Oracle)

Le schéma ci-dessous illustre comment les données relatives à l’identité du patient cir-culent :

- La création ou la modification des données se fait toujours dans Cpage- Cpage gère une base « interne » et une base répliquée. Cette dernière est utilisée

en lecture par toutes les applications qui ont besoin d’accéder aux informations sur les patients.


SOFTWARE DESIGN

PAGE :27/51

Le portail médical sera mis en place à un moment où, les principes de partage et de ges-tion de l’identité du patient changent. Il apparaît que Cpage ne doit plus être le serveur d’identité, il sera remplacé par un autre système. Les objectifs sont :

Avoir un système dont le rôle est uniquement la gestion de l’identité des patients du CHU. Permettre aux autres applications du CHU d’utiliser les données du serveur d’identité. Avoir un système cohérent et compatible avec les travaux réalisés au niveau régional. Avoir une meilleure gestion des doublons. Permettre au professionnel de santé de gérer les données d’identité dans Cpage et sur le

portail médical.

Le schéma ci-dessous illustre comment les données circuleraient, suite à la mise en place du portail et du serveur d’identité.

Les numéros (en bleu) correspondent aux échanges avec le serveur d’identité :1. Si le serveur d’identité et l’application qui permet de gérer l’identité sur le portail

sont basées sur les mêmes technologies, on peut envisager de les faire communiquer avec des protocoles propriétaires. Par exemple, utilisation d’un EJB du serveur d’identité en mode remote.

2. Lorsque des créations/modifications sont faites sur Cpage, l’information doit être immédiatement envoyée au serveur d’identité, via l’EAI. L’idéal serait que cet échange se fasse en mode transactionnel, car le serveur d’identité peut refuser l’action. En effet, les règles de ges-tion sont sur le serveur d’identité, tant que celui-ci n’a pas validé la création/modification, les don-nées envoyées par Cpage sont inexploitables.

3. Les données de Cpage doivent aussi être actualisées suite au modifications sur le serveur d’identité. Pour cela, il faudra gérer un flux de données depuis le serveur d’identité vers Cpage, via l’EAI. L’information doit être disponible sur Cpage dès la création sur le serveur d’iden-tité.

4. Les applications qui utilisent aujourd’hui des batchs pour récupérer des données sur Cpage auront aussi la possibilité de récupérer les données du serveur d’identité, via l’EAI.


SOFTWARE DESIGN

PAGE :28/51

5. Les nouvelles applications du portail auront la possibilité de lire les données du ser-veur d’identité (batch et/ou interrogation à la demande)

6. Si nécessaire, la communication entre le serveur d’identité et l’application J2EE (mêmes technologies) peut se faire via l’EAI.

On remarque que ce système risque de poser des problèmes lorsqu’on saisi des données sur l’identité d’un patient dans Cpage. En effet, Cpage n’est pas le serveur d’identité, il n’a donc pas le pouvoir de valider les données saisies sur les écrans de modification de l’identité d’un pa-tient.

Les risques sont d’autant plus importants que le nombre d’opérations traitées par Cpage est grand. Le nombres d’opérations traitées chaque mois est estimé ainsi (moyenne depuis jan-vier 2000) :

Créations d'identités 4 325Mises à jour d'identités 4 762Mouvements de patients 36 143

Pour limiter les risques ; il est conseillé d’interdire la modification/création de l’identité des pa-tients sur Cpage. Le schéma ci-dessous illustre comment les données circuleraient dans ce cas :


SOFTWARE DESIGN

PAGE :29/51

1.1.11L’identité du patient sur le portail

L’identité du patient intervient de plusieurs façons :- Il y aura une rubrique pour permettre aux professionnels de santé de rechercher un pa-

tient à partir de plusieurs critères. La recherche peut renvoyer zéro, un ou plusieurs patients.- Il y aura une rubrique pour créer, visualiser et modifier les données d’identité du pa-

tient.- L’identité du patient devra être conservée dans le contexte utilisateur, afin de per-

mettre aux internautes de visualiser les données d’un même patient dans plusieurs rubriques (par exemple : quand on consulte les prescriptions d’un patient, on peut ensuite éditer son HPDD sans avoir à resélectionner le patient)

- L’identité du patient qui est conservée dans le contexte utilisateur doit être partagée avec les applications intégrées au portail

- Les application intégrées au portail auront la possibilité de lire les données présentes sur le serveur d’identité.

La recherche d’un patient, et la gestion des données d’un patient se fait grâce à un compo-sant à développer.

Si le serveur d’identité CHU repose sur les technologies J2EE, on peut envisager d’appeler un service de ce serveur grâce à un protocole propriétaire (Utilisation d’un EJB via RMI-IIOP).

Si cette solution n’est pas retenue, il faudra utiliser l’EAI. Pour cela, il faudra o installer des API (fournies avec l’EAI) pour que le composant « identité patient » ait des

échanges de type « requête-réponse » avec le serveur d’identité.o Définir la structure des fichiers XML échangés.


SOFTWARE DESIGN

PAGE :30/51

Communication avec une application ayant un niveau d’intégration fort :

La communication entre le portail médical et l’application X se fait grâce à des fichiers XML. Les échanges se font toujours à l’initiative du portail médical. Ce dernier envoie un fichier XML à traiter, il reçoit ensuite un fichier de résultat.

En théorie, l’application XXX n’a pas besoin d’accéder directement au serveur d’identité patient. Le portail peut lui envoyer toutes les informations relatives au patient.

En pratique ce fonctionnement peut poser des problèmes si l’application X n’a pas été conçue pour utiliser un serveur d’identité externe. En effet, il se peut que l’application X lise une table à chaque fois qu’elle a besoin d’informations sur le patient. Dans ce cas, il faudra mettre au point un système pour synchroniser la table utilisée par l’application X.

Dans tous les cas, le composant de gestion de l’application X enverra au moins un identi-fiant (le NIP par exemple). Cet identifiant est stocké sur l’application du portail dans le contexte de session. Il est utilisé par l’application X pour sélectionner le(s) enregistrement(s) sur lequel on travail.


SOFTWARE DESIGN

PAGE :31/51

4.2 IDENTITÉ DU PROFESSIONNEL DE SANTÉ

Aujourd’hui, toutes les applications du CHU demandent une identification. Le portail devra aussi avoir un processus d’identification. Il devra être mieux conçu que les applications exis-tantes, auxquelles on reproche les points suivants :

o Pas d’utilisation d’un annuaire centralisé.o GDA est utilisé par plusieurs applications pour l’authentification, mais il n’y a pas de single

sign ono Les logins ne sont pas toujours personnels (partagés par tous les membres d’un service)o Il n’y a pas de carte CPS

Dans le cadre du projet, il faut développer un composant spécifique pour l’identification. Ce com-posant répond aux demandes suivantes :

o Single Sign Ono Utilisation de la carte CPSo Utilisation d’un annuaire unique

L’utilisation de la carte CPS se fait grâce à un lecteur de cartes connecté au poste client. Lorsque l’utilisateur se connecte au portail, il faut qu’un programme lise les informations sur la carte et les envoie au portail. La lecture se fera probablement grâce à une applet ouverte quand l’utilisateur accède à la page d’identification. Les informations lues sur la cartes sont ensuite transférées comme n’importe quelle autre donnée.

Le single sign on est géré par le portail. Il garde dans le contexte de la session utilisateur des informations sur l’utilisateur qui est connecté. Ces information sont transmises aux applications intégrées au portail. Au démarrage du portail médical, toutes les applications ne seront pas encore intégrées. Pour que le portail ait tout de même une utilité, on étudiera la possibilité de démarrer les applications C/S existantes depuis le portail. Il sera alors intéressant de supprimer l’étape de connexion sur GDA, puisque l’utilisateur sera déjà connecté au portail. Ceci pourra se faire grâce à une applet.


SOFTWARE DESIGN

PAGE :32/51

Lorsque le médecin se connecte, son identifiant et son mot de passe son transmis dans l’ordre aux composants suivants : - serveur HTTP- composant MVC- composant d’identification du professionnel de santé- couche technique d’échange avec LDAP- Annuaire

Ensuite, un message est transmis dans l’autre sens pour autoriser/interdire la connexion. Un composant de gestion de profil est instancié, il permet d’accéder à des informations supplémentaires liées à la per-sonnalisation.

4.3 LOCALISATION DU PATIENT

Aujourd’hui, Cpage gère la localisation du patient. Il est le seul outil utilisé pour définir ou modifier la localisation d’un patient.Les autres application peuvent utiliser cette donnée en interrogeant la BDD SIL-Répliqué.

Quand le portail sera opérationnel, il sera possible de changer les informations de localisation à partir du portail. Le serveur Cpage jouera toujours le rôle de serveur de localisation.

Le schéma ci-dessous présente la circulation des données de localisation des patients :


SOFTWARE DESIGN

PAGE :33/51

Le serveur Cpage est donc utilisé pour toutes les modifications des données relatives à la localisation. Il est aussi fournisseur des informations de localisation, en direct où grâce à des batchs journaliers (selon les besoins des applications).

Le schéma ci-dessous présente les composants qui seront impliqués dans la gestion de la localisa-tion du patient sur le portail :


SOFTWARE DESIGN

PAGE :34/51

5. LIENS AVEC LA PLATE FORME RÉGIONALE

Lors de la mise en place des applications, il faut prévoir des interactions avec les systèmes exis-tants sur la plate forme régionale.

La plate forme régionale offre deux types de services :- des accès aux professionnels de santé pour leur permettre de consulter les dossiers de

spécialité d’un patient, et d’ajouter de nouvelles données.- Des accès aux SI des établissements de la région, pour que ceux-ci synchronisent leurs

données avec celles de la région.

Le schéma ci-dessous présente les fonctionnalités offertes aux professionnels de santé.


SOFTWARE DESIGN

PAGE :35/51

Le professionnel de santé se connecte tout d’abord à la plate forme régionale de Franche Comté. Il est identifié grâce à sa carte CPS. Ensuite, en naviguant sur le portail, il sélectionne un réseau de spécialité. A partir de ce moment, il est redirigé (de façon transparente) vers l’une des applica-tions de gestion des dossiers de spécialité. Ces applications utilisent un SIP commun (fourni par Uni-Médecine), elles gèrent chacune leur DMMP.Le professionnel de santé dois forcément choisir un dossier de spécialité pour accéder aux fonc-tionnalités mentionnées dans le rectangle « Utilisation d’un dossier de spécialité ».

Le schéma ci-dessous présente les composants mis en place pour implémenter les fonctionnalités présentées précédemment.


SOFTWARE DESIGN

PAGE :36/51

La plate forme régionale offre aussi des services au SI des établissements hospitaliers. Dans un premier temps, elle fournira un accès à un serveur d’identité patient (SIP). A l’avenir, des infor-mations médicales seront aussi présentes, mais il est encore trop tôt pour décrire précisément les données qui seront disponibles, ni même les mécanismes qui permettront de les lire/modifier.

Le schéma ci-dessous présentes les fonctionnalités disponibles.

Le schéma ci-dessous présente l’implémentation technique de ces fonctionnalités :


SOFTWARE DESIGN

PAGE :37/51

6. ARCHITECTURE TECHNIQUE

6.1 LES BRIQUES QUI CONSTITUENT L’ARCHITECTURE

Pour mettre en place les architectures présentées dans ce document, il faudra disposer de :- Un serveur d’application avec serveur http, container de servlet et container d’EJB- Une application portail compatible avec le serveur d’application- Une application de Web Content Management (WCM)

De plus, on trouve autour du serveur d’applications d’autres briques qui doivent communiquer avec le serveur d’application choisi :

- SGBDR (pour les bases métiers – PMSI, PRN … -, les bases du WCM et les bases du por-tail - personnalisation-)

- Annuaire LDAP (pour le SSO, la gestion des cartes CPS, et l’annuaire des professionnels de santé)

- EAI- Serveur de messagerie- Applications existantes


SOFTWARE DESIGN

PAGE :38/51

1.1.12 Serveur d’application J2EE et serveur HTTP

Le serveur d’application J2EE est l’une des briques les plus importantes du système, car il se posi-tionne au centre des autres composants, soit parce qu’il les utilise (SGBDR, systèmes existants …) soit parce qu’il leur permet de fonctionner (Développements spécifiques, XML factory, composant de personnalisation …).

Il est important de bien choisir le serveur d’application. A ce titre, voici une liste non exhaustive de critères de choix d’un serveur d’application J2EE :

Intitulé CommentaireInstallation et interfaçage avec les outils1.1 Simplicité d’installation et de mise en œuvre Qualité et simplicité de la procédure d'ins-

tallation ? Palette de compétences originelles re-quises ? Charge d'installation ?

1.2 Qualité de l’intégration entre les outils (Editeur de source, Débogueur, Outils de configurations)

Homogénéité des outils ? Niveau de contraintes pour l'intégration des outils ?

1.3 Interface gestionnaire de sources Interfaçage possible avec Visual Source Safe ? Présence d'un outil de gestion de sources interne ?

1.4 Possibilité de s’interfacer avec CrystalReport/Crystal Clear

1.5 Présence d’un outil de modélisation et/ou possi-bilité de s’interfacer avec Power AMC

1.6 Possibilité de s’interfacer avec B.O.WebIntelli-gence

Génération de l’interface HTML2.1 Présence d’un éditeur graphique HTML et/ou

possibilité de s’interfacer avec DreamWeaver2.2 Assistance à la saisie du HTML2.3 Possibilité de créer des feuilles de style, des

templates, des modèles de page2.4 Assistance à la saisie de langage de script côté

client

2.5 Assistants de génération de pages HTML dyna-miques

Librairies de tags JSP ? Blocs de code paramétrables ?

2.6 Support du multilingueDéveloppement JAVA3.1 Présence d’un éditeur graphique Java Richesse des fonctionnalités ?

Ergonomie ?3.2 Aide à la complétion de code3.3 Analyseur syntaxique3.4 Assistance à la création d’objets (EJB, beans) Richesse et qualité des assistants ?

3.5 Débogueur Ergonomie ? Gestion du mode pas à pas ? Audit de variables ? Action sur l'exécution ?

3.6 Référentiel de composants Présence d'un référentiel ? Richesse du référentiel ?

3.7 Gestion des composants Navigation dans l'arborescence des appli-cations ? Personnalisation des outils de gestion ?


SOFTWARE DESIGN

PAGE :39/51

3.8 Potentiel du serveur d’objets Services de distribution ? de gestion de messages ? de persistance ? de sécurité ?

3.9 Performances3.10 Potentiel transactionnel Gestion des transactions distribuées ?

Contraintes associées ?Respect des standards4.1 J2EE Le serveur est il certifié J2EE ?4.2 JSP JSP supportées ?

Quelle version ?4.3 Servlets Servlets supportées ?

Quelle version ?4.4 EJB4.5 JMS4.6 JNDI4.7 JavaMail4.8 XML Présence d'outils XML (parsers, proces-

seurs) ?Accès aux bases de données5.1 Accès natif aux SGBD Quels SGBD supportés en accès natif ?5.2 Accès via JDBC Quels drivers JDBC apportés ?

Quels SGBD recommandés ?5.3 Support des procédures stockées, avec pas-

sages de paramètres in/out5.4 Gestion des pools de connexionConnectivité et intégration6.1 Ouverture vers les annuaires Connectivité LDAP ?6.2 Ouverture vers les systèmes CRM Connectivité avec des outils de gestion de

contenu ? de personnalisation ? de syndi-cation ?

6.3 Ouverture vers les ERP Connectivité avec les ERP ? avec Oracle ?6.4 Ouverture vers les moniteurs transactionnels Connectivité avec les moniteurs transac-

tionnels ?6.5 Ouverture vers les outils groupware(Lotus DO-

MINO)Connectivité avec les outils de groupware ? avec Lotus Domino ?

6.6 Intégration des développements existants Quelles contraintes pour l'intégration des applications existantes ?

Sécurité7.1 Protocoles supportés Support de SSL ? TLS ? Certificats ?7.2 Gestion des profils utilisateurs Prise en compte de la notion

d'utilisateurs ? Gestion de droits ?7.3 Possibilité d’interfacer le référentiel d’utilisa-

teurs avec un référentiel tiersInterfaçage avec la gestion de profils du système ? Avec une base de données utili-sateurs ?

7.4 Granularité de la sécurité Sécurisation des composants ? Lotisse-ment des applications ?

Déploiement et administration8.1 Serveur d’application multi plates formes: Unix,

Linux, Windows NTQuels systèmes supportés ? Quel type de machines ?

8.2 Ressources nécessaires RAM, disque, processeur ?

8.3 Serveur Web Présence d'un serveur Web intégré ? Quels serveurs Web externes supportés ?

8.4 Console d'administration Richesse fonctionnelle ? Ergonomie ?

8.5 Mode de fonctionnement de la console d’admi-nistration (Web, Client/Serveur)

Quelles fonctionnalités apportées par chaque mode ? Quelle version de navigateur supportée


SOFTWARE DESIGN

PAGE :40/51

pour la console Web ?8.6 Déploiement Facilité du déploiement de composants ?

Présence d'assistants ? Cloisonnement des applications ?

8.7 Possibilité d’interfacer l’outil avec un outil de supervision tiers

8.8 Capacité de load-balancing Fonctionnalités de répartition de charge ? Support d'une répartition logique ? Phy-sique ? Quelles contraintes ?

8.9 Capacité de fail-over Fonctionnalités de reprise sur panne ? Au niveau applicatif ? Au niveau session ?

Support et prestation9.1 Documentation Documentation papier ?

Aide en ligne ? Sites Web ?

9.2 Ressources éditeur Prestations de support ? de conseil ? de développement ? Quelles conditions ?

9.3 Pérennité de l’offre Positionnement de l'offre sur le marché ? Retours terrains

9.4 Version du produit Fonctionnalités pour chaque version ? Evo-lutivité et intérêt des différentes versions ?

9.5 Coût des licences

1.1.13 Le portail

L’application issue du projet est de type « portail », elle regroupe sur un même interface gra-phique des informations et fonctionnalités provenant de divers sources.

Pour éviter toute incompréhension, voici une définition ouverte et simple du portail : Interface web sécurisée offrant un point unique d'intégration, ainsi qu'un accès à l'information, aux applica-tions et aux services, à toutes les personnes impliquées dans l'entreprise - y compris les collabo-rateurs, partenaires, fournisseurs et clients. Il s’agit de l’ « Enterprise Information Portal » ou EIP.


SOFTWARE DESIGN

PAGE :41/51

L’utilisation d’un outil de portail a pour but de faciliter les tâches de développement lors de la mise en place de l’application. Il couvre un périmètre fonctionnel (personnalisation, gestion de contenu, agenda …) et doit s’intégrer dans l’environnement technique du projet (serveur d’appli-cation, BDD, EAI, WCM …). Les besoins couverts peuvent être classés suivant deux axes :


SOFTWARE DESIGN

PAGE :42/51

Dans le cadre du portail médical, les besoins verticaux sont :

Face à ce constat, les entreprises se tournent de plus en plus vers des solutions capablesd’homogénéiser pour l’utilisateur final des sources multiples (données, applications,processus) de l’Intra/Extra/InterNet.Le Portail d’Information d’Entreprise devient la prochaine génération de bureaud’ordinateur pour le tout-internet. On parle de « middle-office » ou "Webtop".


SOFTWARE DESIGN

PAGE :43/51

Une nouvelle panoplie de services se cristallise aujourd’hui autour de 3 couchesPrincipales :

Comment choisir son portail ?

La capacité d'intégration est l'un des facteurs déterminants dans le choix d'un EIP.Certains éditeurs, qui ont tendance à mettre en avant leurs solutions clé en main,répondent à cette problématique avec des adaptateurs prêts à l'emploi et extensiblesportant toute une série de noms (Gadgets, MiniApps, Portlets, E-Clips, etc.). Si cesadaptateurs permettent d'intégrer des applications, informations et services dans lapartie présentation du portail, ils ne permettent pas nécessairement l'interopérabilitéentre les applications réparties dans l'entreprise.D'autres éditeurs, qui ont tendance à se présenter comme des fournisseursd'infrastructures de portails, soulignent l'importance d'intégrer les applications à unniveau plus bas. Ce mode d'intégration touche au domaine de l'EAI (EnterpriseApplication Integration). Bien que plus coûteux et plus long à implémenter, il promet plusde fonctionnalités dont le single-sign on, la recherche universelle et la catégorisation detoutes les ressources de l'entreprise.Nous estimons, dans ces prémices du marché de l'EIP, qu'une attention particulière estaccordée à la qualité et à la quantité de bibliothèques d'adaptateurs clé en main livréesavec les portails. Cela devient l'enjeu majeur de la compétition des éditeurs d'EIP, et l'onpeut s'attendre à ce que ceux d'entre eux se focalisant exclusivement sur les EIPremportent la bataille.


SOFTWARE DESIGN

PAGE :44/51

En observant les offres du marché, nous avons retenu les 2 grilles de critèressuivantes :

Caractéristiques fonctionnelles

InteractionPoint d'entrée unique Un seul login et password pour accéder aux do-

cuments, données ou traitementsMulti-canal Diffusion Web, téléphone, …Contenus Gestion Syndication, Profiling, Stockage, Format,

RévisionsRecherche Moteur plein texte, syntaxique, sémantique ou

langage naturelPersonnalisation Moteur à règles?, Souplesse de l'interface de dé-

finitionBusiness Intelligence Statistiques et traces sur les règles et contenusProfiling Accumulation im/ex-plicite d'information perti-

nente sur l'utilisateurForum Thèmes de discussion en ligneChat Conférences on-lineEmail Sécurisé et en liste de diffusionAgenda Calendrier, Alertes, RdVAbonnement Lettres d'informationNouvelles Interne Groupe, Nationale ou Internationale, Mé-

téo, BourseInformation métier Carnets de Presse, …Liens avec professionnels Fédérations, Journal OfficielPaiement Porte monnaie, Carte bancaire, carte à puceSécurité Cryptage, Authentification, IntermédiairesAutres

Règles et processusGestion Besoins Liste de tâches, demandes, évènementsGestion Clients(CRM) Organigramme, Profils et caractérisation de

clientsGestion Produits (GDT) Nomenclatures, articlesGestion Supply Chain(SCM)

Intégration offres/demandes

Gestion Documents (GED) Workflow, formats, réplicationGestion Ressources (ERP) Inventaire, Stock, matérielGestion Projets (GP) Planification, WBSAutres

IntégrationSGBDRs Oracle, Sybase, SQLServerERPs SAP, Baan, OA

Annuaires LDAP, NT, ODSSources de données LegacyMainFrame CICSMessagerie Mail, SMTP, X400Autres

Composantes techniques

Infrastructure, OuverturePrésentation HTML, SMS, WAP, RTC, XML/XSL, XHTMLMulti-tier Séparation n-tier: IHM, SA (technique et métier),

SGBD, EAIFormats Stockage centralisé, Multimédia, Visualisation

(SVG…), Annotations


SOFTWARE DESIGN

PAGE :45/51

Internationalisation, Localisation Multi-langues, Multi-monnaies, Multi-Zones, Mul-ti-Format

Accès aux Réseaux TCP-IP, TranspacAccès aux données Multi BDD, ODBC, JDBCAccès aux traitements COM, JAVA, J2EE, OSSDistribution messages DCOM, CORBA, SOAPAccès par programmation APIs publiques, choix langages adaptés, Schéma

BDpubliques

Accès aux paramètres Formats/Stockage de paramètres ouverts (i.e. XML)

Moteur de publication Souplesse et modifications sur le processusMoteur d'intégration Connecteurs disponiblesMoteur XML Centralisé ou extérieur. Transformations dispo-

niblesMoteur de classification Mots clé, multi-perspectives/catégoriesMoteur d'indexation recherche plein texte, syntaxique, sémantique,

langage naturel, attributs utilisateursMoteur personnalisation Profils Implicites/explicites. Expression par règlesMoteur de Workflow Etats, Groupe de distribution, Triggers externesAutres

Pérennité, Respect standardsDépendance à l'éditeur Sur quelle(s) couchesNiveau investissement et support de l'Edi-teur

Dynamisme et politique Editeur

Cohérence technique Homogénéité ou HistoriqueUtilisation standards marché Java, Asp, XML…Echange métier/eComerce EDI, Standard métiers (ex UN/SPSC pour classifi-

cation de catalogues), UDDI/XSDLEchanges de paramètres Fichiers propriétaires/plats/DTD/SchemaEchanges de données Fichiers propriétaires/plats/DTD/SchemaEchanges de messages IIOP, RMI, DCOM, SOAPAutres

Performance, RobustesseCapacité transactionnelle (nb pages/sec/CPU)Disproportion SA, SGBD Caching Web, caching BD…Fiabilité Fuite mémoire, % transactions réussies (sur ser-

veur)Outils montée en charge A quel niveauTolérance aux pannes Fail over?: Stockage des sessions, Temps de ré-

cupération de sessionsRobustesse Nb. Utilisateurs concurrents vs config (CPU/

RAM/Réseau/Disque)Autres

DéploiementHébergement Option ou obligatoireScalabilité Passage de 100 à 1000 utilisateursModularité physique Côtés serveursPlate-Formes disponibles Front-EndPlate-Formes disponibles Back-EndPré-requis Clients Plugins, Certificats, …Multiplication Front-End Répartiteur, Mise en clusterMultiplication Back-End Archivage, Ajout disques/BD, Réplication, Distri-

butionRépartition charge Dynamique/Statique/Round-Robin ?Administration, surveillance Quels outils ?Autres

ProductivitéSéparation rôles et outils associésOutils de développement Gestion projets/versions, IDE IHM/Objets


SOFTWARE DESIGN

PAGE :46/51

métiers/Objets Techniques, Feuilles de style, Charte graphique, Templates

Outils de paramétrage Projets type pré-créés, Ajouts spécifiques: Attri-buts,écrans/boutons/onglets/menus/champs

Outils d'Analyse et administration Data-miningOutils de Reporting Editions de rapportsVues restreintes sur fonctionnalités Par taille de projetsAutres

SécuritéCryptage Authentification, Signature électroniqueAnnuaire LDAP, SSO, Droits d'accès par

Groupes/Individus/Pages/Contenus/ObjetsSauvegarde Sécurisée, A valeur juridiqueAutres


SOFTWARE DESIGN

PAGE :47/51

7. ANNEXE : PRÉSENTATION DE TROIS SERVEURS D’APPLICATION.

Nous vous présentons dans cette partie une sélection de serveurs d’applications J2EE.

7.1 ORACLE IAS, 9IAS

Renseignements générauxProduit Oracle9i Application Server

Vendeur Oracle

Version Release v9.02

SGBD supportés Oracle and any other JDBC compatible database

Plates-formes de déploiement Windows NT/2000, Sun Sparc Solaris, Linux (Intel)

Support des EJB 2.0 (non certifié)

Support des JSP 1.2

Support du JDK J2EE 1.3 compliant.

J2EE supports Enterprise Java Beans (EJB) 2.0; Servlets 2.3 JavaServer Pages (JSP) 1.2;

JTA 1.0; JNDI 1.2; JMS 1.0; JDBC 2.0 Extension; JavaMail 1.2, JAF 1.0, JAXP 1.1, Connector 1.0 (JCA) , and JAAS 1.0.

Le produit

ORACLE offre une solution intégrée complète pour une architecture multi-niveau.En effet, iAS fournit un serveur applicatif et WEB capable d’accélérer les applications WEB grâce au cache dynamique, de fournir des fonctions intégrées de reporting et d’interrogation pour l’ana-lyse stratégique et de permettre la gestion de l’ensemble du système d’information depuis une console unique.La solution s’appuie sur ORACLE8i.iAS héberge aussi :- un outil de construction de portails- des applications transactionnelles- des analyses stratégiques (reporting, historisation, interrogations ad-hoc, …)


SOFTWARE DESIGN

PAGE :48/51

Architecture

L’offre s’appuie sur les standards de l’OMG paquagés par ORACLE.Le déploiement de JSP, Applet Java avec la même JVM est celle que l'on trouve dans la base Oracle8i.Une offre intégré comprenant: - Apache - le serveur d'application (Jserv)- le portail (Oracle Portal, outil de création et de gestion de portail intégrant de l'info et des applications) - des outils de reporting (Oracle Report) et de navigation décisionnelle (Oracle Discoverer) - un cache Web de pages dynamiques pour améliorer les performances - un cache de données, de manière à ne pas accéder systématiquement à la base pour les données les plus souvent consultées, d'où là encore amélioration des performances.

La solution s’appuie sur le serveur WEB Apache, le moteur Apache JServ pour les servlet/JSP et in-tègre une solution plug&play permettant l’intégration de blocs PLSQL existant (mod_plsql).


SOFTWARE DESIGN

PAGE :49/51

7.2 WEBSPHERE D’IBM

Renseignements générauxProduit Websphere Application Server

Version actuelle 4.0

SGBD supportés Toute base avec driver JDBC (Oracle, Sybase, Informix, MS SQL Server). Les EJB entity bean CMP ne fonctionnent qu'avec DB2 et Oracle.

Plates-formes de déploiement Windows NT 4, AIX, Solaris, HP-UX

Licence de déploiement Tarification basée sur le nombre total de processeurs du système

Support des EJB 2.0 (non certifié)

Support des JSP 1.2

Support de J2EE J2EE 1.2 (Java 2 Enterprise Edition platform) certification

J2EE JMS 1.02, JSP 1.2, Servlet 2.3, EJB 2.0, Java 2 Connectors, etc.

Le produit

IBM joue la carte de la standardisation en offrant dans Websphere le support des servlets, des JSP et des EJB. L'administration est faite à partir d'une applet Java ergonomique et se révèle d'une bonne richesse fonctionnelle. Le serveur HTTP préconisé en frontal est Apache mais le choix d'un autre serveur est laissé à l'utilisateur lors de l'installation.Par le support des EJB, JSP et servlets, il propose ainsi le modèle MVC (Modèle Vue Contrôleur) dans lequel les EJB jouent le rôle du modèle, les JSP celui de la vue et les servlets celui du contrô-leur. L'architecture MVC définit trois types d'objets. Le modèle représente les objets de l'applica-tion. La vue représente la présentation à l'écran et le contrôleur définit la façon dont l'interface ré-agit en fonction des actions de l'utilisateur. Le respect de la norme JSP permet de franchir un nou-veau pas dans la séparation des rôles entre les développeurs et les concepteurs de sites Web. Par l'intermédiaire de tags, le concepteur d'interfaces HTML peut récupérer des informations des beans du serveur, voire développer un peu de code Java à l'intérieur de la page HTML. Cependant, l'offre IBM ne comprend pas un outil unique permettant de développer à la fois la logique métier et les JSP.L'administration du serveur d'applications s'effectue par l'intermédiaire d'une console d'adminis-tration. Côté serveur Web, les principaux serveurs HTTP sont supportés tels que Apache, Nets-cape, Microsoft, IBM et Lotus.

Concernant les montées en charge, la version 4.0 de Websphere a montré des améliora-tions sensibles. La version 2.0 de Websphere ne tenait pas la charge. La version 3.0 s'est révélée plus robuste et a supporté aisément la charge sur 200 automates.

Architecture

Websphere respecte les notions de client universel mais permet également d'accéder aux objets serveur via RMI (Remote Method Invocation). Du côté serveur, Websphere respecte les spécifica-tions des servlets, des JSP et des EJB. Avec VisualAge, IBM offre l'ouverture vers le monde du site central (ex : SAP R3) ou base de données (ex : Oracle) avec des connecteurs inclus dans l'environ-nement de développement.

http://www7b.boulder.ibm.com/wsdd/products/supportstds.html


SOFTWARE DESIGN

PAGE :50/51

7.3 WEBLOGIC DE BEA

Renseignements générauxProduit Weblogi

Version actuelle 4.0

SGBD supportés Toute base avec driver JDBC (Oracle, Sybase, Informix, MS SQL Server)

Plates-formes de déploiement Windows NT 4, Sparc Solaris, HP 9000 Red Hat Linux

Licence de déploiement Tarification basée sur le nombre total de processeurs du système

Support des EJB 2.0 (supporté)

Support des JSP 1.2

Support de J2EE J2EE 1.2 (supporté)

Standards supportés HTTP 1.1__ J2EE Connector Architecture 1.0 __ J2EE EJB 2.0 __ J2EE JDBC 2.0 __ J2EE JNDI 1.2 __ J2EE JSP 1.2 __ J2EE JTA 1.0.1a __ J2EE JMS 1.0.2b __ J2EE RMI 1.0 __ RMI/IIOP 1.0 __ J2EE Servlet 2.3 __ LDAP 2 __ SSL 3

Le produitWeblogic Server est un serveur d'applications basé sur Java. Il permet aussi bien la mise en

place d'applications Web HTTP que d'applications client/serveur trois tiers avec clients Java. Une des caractéristiques majeures du produit est qu'il s'articule entièrement autour de Java 2 Enter-prise Edition (J2EE). Cette spécification récente , mais très prometteuse, est promue par Sun. Il s'agit d'une extension de la plate-forme Java standard visant à répondre aux besoins spécifiques des systèmes d'information d'entreprise. Elle comprend notamment une douzaine de frameworks objet, comme les servlets pour la génération dynamique des pages HTML. Java Database Connec-tivity (JDBC) pour l'accès de bas niveau aux bases de données. Java Messaging Service (JMS) pour l'échange asynchrone de messages ou encore Enterprise Java Bean (EJB) comme modèle de com-posants métier.

Weblogic se positionne résolument comme l'un des plus fervents supporters de J2EE, inté-grant la plupart des éléments de cette spécification encore en évolution (on note en particulier le support des frameworks cités ici). Il s'agit de l'un des atouts majeurs du produit. J2EE étant soute-nu par un nombre grandissant d'éditeurs, en dépit des velléités financières de Sun. Produit puis-sant à bien des égards, Weblogic incorpore le savoir-faire de BEA dans le domaine du middleware. Weblogic semble être considéré comme l'une des possibilités les plus sérieuses par les entre-prises faisant le choix de la plate-forme J2EE.

En revanche, Weblogic se révèle moins bien adapté dans deux situations précises : les pro-jets ayant une contrainte de time to market forte et les projets mettant en œuvre une approche de développement par objets métier. Dans le premier cas, le manque d'outils de développement et le faible niveau d'intégration des ateliers tiers, ainsi que l'aspect bas niveau et parfois imma-ture de certains éléments de J2EE ne permettent pas à Weblogic Server d'offrir une forte producti-vité en développement. Les projets qui requièrent un déploiement rapide restent aujourd'hui l'apanage des pionniers de serveur d'applications RAD. Pour ce qui est du deuxième point, les pro-jets basés sur une approche objets métier, Weblogic patit de son choix de la technologie EJB, en-core immature et inadaptée à une modélisation objet d'envergure. Dans ce domaine, les acteurs proposant des solutions éprouvées ne font pas légion.

Weblogic n'inclut pas d'atelier de développement mais se concentre sur la partie serveur. Un ensemble de Javabeans est néanmoins fourni pour faciliter l'intégration avec des outils tiers. N'importe quel IDE Java peut être choisi comme atelier de développement, tel que Visual Age, Jbuilder ou Symantec Visual Café.

ArchitectureCôté middleware et serveur, Weblogic offre de nombreuses fonctionnalités dont la plupart sont basées sur les recommandations J2EE. Reposant sur le JDK 1.1.7, à 1.3 selon les plates-formes, les fonctionnalités intègrent en particulier le pool de connexions, la sécurité, le load-balancing et les Enterprise JavaBeans (EJB). La connexion aux bases de données est assurée par la technologie


SOFTWARE DESIGN

PAGE :51/51

JDBC de l'éditeur, qui exploite ici son expérience reconnue en matière de middleware. On note aussi les technologies de load-balancing et de tolérance aux pannes introduites par la version 4, en avance dans ce domaine sur de nombreux concurrents.

Côté Web, le produit offre son propre serveur HTTP tout en laissant la possibilité d'utiliser d'autres serveurs. On trouve aussi un moteur de servlets, éprouvé et validé sur le terrain, la technologie Java Server Pages (JSP) peut être utilisée pour générer des servlets. Pour ce qui concerne la tech-nologie objet, le système de communication distribuée est RMI. BEA offre la possibilité d'utiliser une nouvelle implémentation de RMI réalisée par l'éditeur, celle de Sun livrée en standard dans le JDK étant connue pour être peu performante, en particulier lorsque le nombre d'utilisateurs est élevé.