Tout d'abord, je passe le majeur remerciement à, celui qui me donne tous les aides pour faire ce projet. Puis je donne mes remerciements à toutes les personnes qui me donnent la main-forte dans ce projet, au premier mon encadreur Monsieur DR.GUEZOULI; celui qui a fait tous les efforts pour m aider à comprendre et faire une meilleure présentation de ce mémoire, aussi tous les autres qui m'ont aidé du début à la fin dans mon travail. Enfin je passe mes remerciements aux membres de jury pour leur intérêt à ce mémoire, leur lecteur et leurs observations.
Table des matières INTRODUCTION GENERALE 1. INTRODUCTION GENERALE 6 CHAPITRE I: JEE (JAVA ENTREPRISE EDITION) 1. PRESENTATION DE JEE 9 2. UN BREF HISTORIQUE DE J2EE [15] 9 3. LES AVANTAGES D UTILISER JEE 10 4. LES COUCHES LOGICIELLES JEE 10 CHAPITRE II: SPECIFICATIONS DE LA PLATE FORME JEE 1. INTRODUCTION 13. 2 LES APIS 13 1. Définition 13 a. Les composants 13 b. Services d'infrastructures 20 c. Services de communication 21 2. Les conteneurs (en anglais containers) 22 a. Types des conteneurs 22 b. Descripteur de déploiement 23 c. Architecteur d'un conteneur 23 d. Services d'un conteneur 23 3. CONCLUSION 24. 3 LES SERVEURS D'APPLICATIONS 24 1. Le rôle d'un serveur d'application (ou bien les services) 25 a. Service de nommage 26 b. Services de gestion de transaction 26 c. Service de gestion de la disponibilité des applications 26 d. Service de sécurité 26 e. Service d'administration 26 f. Service d'accès aux données 26 g. Service de gestion de messages 26 2. Avantages d'un serveur d'application 27 3. Comment travaille un serveur d'application (fonction et architecture) 27 4. Quelques types de serveurs d'application 28-2-
5. Notre choix 29 4. IDE (L ENVIRONNEMENT DE DEVELOPPEMENT) 29 5. CONCLUSION 29 CHAPITRE III: MISE EN ŒUVRE - GESTION D'UN CABINET MEDICAL. 1 PROBLEMATIQUE 32 2. LES TECHNOLOGIES UTILISEES DANS CE PROJET 32. 3 CONSTRUCTION DE LA BASE DE DONNEES 32 4. LES CLASSES IMPORTANTES DANS CE PROJET 34 5. LES EXEMPLAIRES ECRANS DE L EXECUTION DE L APPLICATION 34 CONCLUSION GENERALE 1. CONCLUSION GENERALE 45 REFERENCES BIBLIOGRAPHIES..46-3-
Liste des figures Figure 1 Architecture trois tiers..11 Figure 2 Communication entre client et serveur...15 Figure 3 Fonctionnement d une servlet 16 Figure 4 Les composants WEB 17 Figure 5 Architecture EJB 19 Figure 6 Séparation logique de JEE.20 Figure 7 Les protocoles utilisés 22 Figure 8 Architecture de JEE 24 Figure 9 Architecture d un serveur d application..25 Figure 10 Serveur d application WEB 27 Figure 11 Eléments d une application JEE 30-4-
-5-
1. Introduction générale La gestion d un cabinet médical est un emploi complexe. Cependant, les premières années de construction des cabinets médicaux et les médecins s orientaient à un objectif bien déterminé, celui-ci se résumait à comment travailler avec les patients à l aide de moyens faciles et rapides. Mais malgré tous les efforts des médecins il reste des difficultés, parmi les quelles : L archivage des dossiers des patients sur des feuilles peut engendrer leur perte et perdre beaucoup de temps pour trouver un dossier ; La modification d un élément dans un dossier peut obliger le médecin à refaire un nouveau dossier. A cause de ces difficultés, les médecins préfèrent s approprier des bénéfices liés à l informatisation de la gestion de leurs cabinets médicaux dans le but de simplifier, sécurisé et minimisé leur travail. Dans ce but, nous proposons une solution basée sur la plateforme orientée entreprise appelée JEE (Java Entreprise Edition) ou J2EE (Java 2 Platform, Enterprise Edition), basée sur le JDK (Java Développement Kit) et J2SE (Java 2 Standard Edition). C est une plateforme indépendante qui permet de développer, déployer et gérer des applications d entreprise multi-tiers en ajoutant la possibilité de fournir une plateforme complète, stable, sécurisée et rapide. La plateforme JEE propose des spécifications pour une infrastructure dans laquelle s exécutent les composants. Cette plateforme est composée d un ensemble de spécifications pour l environnement dans lequel s exécutent les composants écrits en java. Elle se nomme Serveur d application. Un serveur d application à pour objectif de simplifier le développement des applications à architecture distribuée, en permettant une séparation entre les niveaux de l application (présentation, logique et données) et un ensemble d API qui assurent le développement coté serveur offrant la possibilité de s interfacer avec le système d information existant grâce aux nombreuses API. Dans notre rapport nous commençons par une introduction générale où nous définissons notre besoin et les techniques utilisées pour proposer une solution. Le reste du rapport est divisé en quatre parties : Partie 1 : Cette partie commence par une petite définition des APIs de JEE et le rôle de chacune de ces APIs. Partie 2 : Cette partie donne la définition d un serveur d'application, les différents types existants, leur utilisations et enfin le choix de l un de ces serveurs d'applications. -6-
Partie 3 : Ça concerne l'implémentation de notre application de gestion d un cabinet médical en utilisant JEE sous ECLIPSE et WEBSPHERE. Partie 4 : Une conclusion générale. -7-
JEE : Java Enterprise Edition
1. Présentation de JEE[7] JAVA Entreprise Edition, ou J2EE JAVA 2 Platform, Enterprise Edition, est une norme proposée par la société Sun, portée par un consortium de sociétés internationales, visant à définir un standard de développement d applications d entreprise multi niveaux basées sur des composants. On parle généralement de <<plate-forme J2EE>> pour désigner l ensemble de services (API <<Application Programming Interface>>) offert et l infrastructure d exécution. J2EE comprend notamment : Les spécifications du serveur d application qui définit finement les rôles et les interfaces pour les applications ainsi que l environnement dont lequel elles seront exécutées. Cet environnement permet à des entreprises tierces de développer des serveurs d application conformes aux spécifications ainsi définies, sans avoir à re-développer les principaux services. Des services à travers des API, c est-à-dire des extensions Java indépendantes permettant d offrir en standard pour un certain nombre de fonctionnalités. Sun fournit une implémentation minimale de ces API appelée J2EE SDK (J2EE Software Développement Kit). 2. Un bref historique de J2EE [15] L environnement Java pour l entreprise a commencé à émerger assez rapidement après les débuts de Java au milieu des années 90. A son origine, Java était destiné aux environnements contraints (par exemple des petits équipements électroniques). Il a en fait percé dans l environnement du Web, notamment dans les navigateurs pour les supports d interfaces graphiques riches la notion d appliquette Java (en anglais applet). Les premières déclinations de Java dans l environnement des serveurs sont apparues en 1997 avec les servlets, dont l objectif est la construction programmatique de pages Web, puis avec les Entreprise Java Bean (EJB) dont l objectif est le support de code métier (API) nécessitant un contexte d exécution transactionnel. Après ces premiers pas et un relatif succès de ces technologies, Sun a structuré l offre technique autour des serveurs d applications Java à travers le standard J2EE. L objectif de ce dernier est de fédérer dans un cadre cohérent toutes les technologies nécessaires à la mise en œuvre des applications de l entreprise (applications orientées <serveur>). Sun à décidé de rebaptiser son langage «Java 2» est introduire la première version 1.2 des spécifications de J2EE en 1999. Cette version est suivie alors la version 1.3 de J2EE en 2001, puis la version 1.4 en 2003 incluant un support complet des standards XML et le support des services Web. Mais pour des raisons de marketing, Sun a décidé de rebaptiser cette plateforme «Java Entreprise Edition» (en suppriment le 2) à compter de la version 1.5, qui elle-même été changée en «5» et elle est devenu JEE5. -9-
3. Les avantages d utiliser JEE[14] L utilisation de JEE pour développer et exécuter une application représente plusieurs avantages : Une architecture d application basée sur les composants qui permet un découpage de l application et donc une séparation des rôles lors du développement. La possibilité de s interfacer avec le système d information existant grâce à de nombreuses API : JDBC, JNDI, JMS, JCA La possibilité de choisir les outils de développement et le ou les serveurs d applications utilisés qu ils soient commerciaux ou libres. 4. Les couches logicielles JEE[4] La plateforme JEE utilise un modèle d application distribuée multi tiers pour des applications d entreprise. La logique d application est divisée en composants selon la fonction. Les composants divers qui composent l application JEE sont installés sur des machines différentes en fonction du niveau de l environnement JEE multi tiers auquel le composant d application appartient, montre deux types d applications JEE réparties dans des niveaux décrits comme suis : -La couche client : ces composants s exécutent sur la machine du client. -La couche WEB : ces composants s exécutent sur le serveur JEE. -La couche métier : ces composants s exécutent sur serveur JEE. -La couche EIS (Entreprise information System) : s exécutent sur le serveur EIS. Bien qu une application JEE peut être constituée par trois ou quatre couches comme montrées dans Figure1suivante. Les applications JEE multi tiers sont généralement considérées comme des applications 3-tiers, parce qu elles sont distribuées sur trois emplacements : -La machine client. -La machine pour serveur JEE. -Et la machine pour serveur de base de données. Les applications à 3-tiers qui fonctionnent de cette façon étendent le standard 2-tiers : client/serveur en plaçant un serveur d application entre l application de client et le stockage principal. -10-
Java JEE application 1 Java JEE application 2 Couche client Machine client Application Client Pages HTML dynamiques Jsp pages Couche web Entreprise Bean Entreprise Beans Couche métier Base d Serveur java ee Base de données Base de données Couche EIS Serveur bases de données Figure 1 Architecture trois-tiers Figure 1 Architecteur trois_tiers -11-
SPECIFICATIONS DE LA PLATE FORME JEE.
1. Introduction Comme nous avons dit dans l'introduction, JEE comporte des spécifications qu on peut les regroupées en deux grands parties : Les APIs. Les serveurs d'applications. 2. LES APIs 1. Définition Les APIs sont des extensions Java, forment une collection d outils logiciels permettant d'offrir en standard un certain nombre de fonctionnalités, Sun fournit une implémentation minimale de ces APIs nommée J2EE SDK (JEE SOFTWARE DEVELOPMENT KIT). On peut regrouper ces APIs en trois groupes principales : Composants ;[4] Services d'infrastructures ;[2] Services de communications.[2] a. Les composants Un composant est un fichier simple, contant généralement du code compilé. Il est possible de créer des composants avec la majorité des langages. Aussi il peut être vu comme unité qui regroupe un certain nombre de fonctionnalités qui peuvent être appelées depuis un programme externe ou client. Remarque: Pour les composants JEE écrite en java et compilées sont assemblés en une application JEE déployés, exécutés et gérés par le serveur JEE. On peut faire une séparation entre les composants existants selon leur exécution : -Composants exécutés sur le client (clients et applets). -Composants exécutés sur le serveur (web et les composants métiers). Composants exécutés sur le client Peuvent être application client ou applet. Client JEE Un client JEE peut être client web ou application client. Client web Un client web est appelé client léger qui n'a généralement pas de requête de BDD. L'utilisation de client web permet de charger les opérations lourds au niveau de -13-
l entreprise beans et sont exécutées sur le serveur JEE où ils peuvent exploitées les avantages des technologies JEE (sécurité, la vitesse, les services ) sur le serveur. Un client web a besoin de deux fonctionnalités principales : Les pages web dynamiques avec les différents langages à balisage (HTML, XML..), ces pages sont générés par les composants web au niveau du client web. Le navigateur web qui affiche les pages reçus par le serveur. Application client L'application client fonctionne au niveau de la couche métier, et peut accéder directement à l entreprise bean. Généralement les utilisateurs possède une interface graphique (GUI) pour exécuter l application client (on utilisant l'api Swing ou Abstract windwos toolkit). Applet L'applet est considéré comme une petite application écrit en java et s exécute dans JVM (Java Virtual Machine) qui est installé dans le navigateur web. Cependant, les systèmes de client auront besoin probablement un dossier de politique de sécurité pour que l'applet s exécute avec succès dans le WEB. Les composants WEB sont l'api préféré pour créer un programme client WEB. En outre, les composants WEB apportent une conception modulaire de l'application parce qu'ils permettent de séparer les parties programmation de la conception des pages WEB. Le personnel impliqué dans la conception des pages WEB n'a pas besoin de comprendre la syntaxe du langage de programmation de JAVA pour faire sont travail. Communication des composants au niveau client La Figure 2 explique comment le client communique avec le niveau métier par deux méthodes; à travers les servlets ou JSP ou bien directement. Donc, l'application JEE peut choisir entre un client léger et un client lourd. Pour utiliser l un des deux, il faut être conscient des compromis entre : garder les fonctionnalités sur le client à proximité de l'utilisateur (client lourd), et de décharger le plus de fonctionnalités que possible sur le serveur (client léger). L'avantage de charger les fonctionnalités sur les serveurs est de pouvoir facilement distribuer, déployer et gérer l'application. Cependant, maintenir plus de fonctionnalités sur le client peut apporter des avantages avec une bonne expérience de l'utilisateur. -14-
Application client et des composants Navigateur web, pages web, Applet et des composants JavaBean Couche client Couche Web Couche Métier Serveur J2EE Figure 2 Communication entre Client et Serveur Composants exécutés sur le serveur Sont des composants web ou bien EJB. Composants WEB : Sont des servlets, JSP ou JSF. Servlet Une servlet est un composant du coté serveur, considérée comme une classe qui permet une communication avec un protocole «requête / réponse». Autrement dit, une servlet est un programme qui s'exécute coté serveur en tant qu'une extension du serveur. Elle reçoit une requête du client, elle effectue des traitements et renvoie le résultat. L'utilisation des servlets permet la génération de pages web dynamiques qui utilisent le protocole HTTP, ou aussi n'importe quel autre protocole reposant sur le principe de servlet. Remarque : Une servlet peut être appelée plusieurs fois répondre à plusieurs requêtes. On peut trouver une servlet dans la partie du milieu (architecture 3 tiers) entre le client léger et la source de données. La portabilité et l'accès à tous les APIs sont des avantages des servlets. -15-
Les servlets sont chargées et exécutées dans la JVM par un serveur d'application. C'est une extension du serveur WEB. Le serveur d'application contient un moteur de servlets qui se charge de gérer les servlets qu'il contient en saisissant l URL qui désigne la servlet dans un navigateur web. Cycle de vie d une servlet[6] Comme le montre la Figure 3, le travail d'une servlet se résume dans les points suivants : - Réception de la requête HTTP qui nécessite une servlet. - L'instanciation des servlets et les stockées sous forme de «fichier.class». - La servlet reste en mémoire jusqu'à l'arrêt du serveur (des serveurs permettant aussi d'instancier des servlets dés le lancement du serveur). - Dans la mémoire on peut appeler la servlet par plusieurs threads lancés par le serveur pour chaque requête. - Création de deux objets : un objet représente la requête HTTP et l'autre représente la réponse. - L'envoie des deux objets précédents à la servlet. - Création de page HTML à partir la réponse que le serveur d'application envoie par le biais de la servlet (requête du client, fichier ou BDD). - Récupération de l'objet réponse et l'envoie de la page HTML au client par le serveur. Serveur Code servlet Charger Code servlet Serveur Demande de Client de poignée Client Client Serveur Code servlet Charge d un Figure 3 Fonctionnement d une Servlet JSP : est l'acronyme de «Java Server Page». -16-
Une JSP est une page HTML contenant des morceaux de code Java et/ou des balises JSP spécifiques permettant d'effectuer des traitements et d'intégrer des données afin de générer dynamiquement des pages HTML. Une page JSP est donc un modèle de génération de contenu dynamique. Techniquement il est possible de faire dans une JSP les mêmes traitements que dans une servlet (JSP est une extension de servlet simplifiant la génération dynamique du code HTML). Cependant, l'utilisation des JSP permet dans une application WEB multi-niveaux de séparer la partie logique en intégrant des données à l'aide de balises JSP spécifiques. Sur le serveur, une JSP est interprétée puis compilée en une servlet ayant ensuite les mêmes caractéristiques et comportements. Depuis l'introduction de Java servlet et de la technologie de JSP, des technologies et les cadres additionnels de Java pour des applications interactives WEB ont été développés. JSF : est l'acronyme de «Java Server Face». JSF par défaut utilise JSP, mais aussi peut utiliser d autres technologies telles que XUL (XML based User interface Langage). JSF est comme Swing ou SWT dans l'enregistrement de l'état d'un composant au moment du retour de la page pour être ensuite restauré au retour de la requête, donc JSF est basé sur les composants. La Figure 4 schématise la situation des composants WEB. Figure 4 les composants WEB Composants métiers (EJB) Ceux sont des composants non visuels encapsulant un logique métier et ils sont utilisés dans la création d'applications distribuées. EJB est un modèle de composants pour le CTM (Component Transaction Monitors), le type de serveur d'application le plus avancé. -17-
Le terme CTM fut inventé en 1999 pour décrire des serveurs d'applications à base d'objets distribués. CTM fournissent une infrastructure qui prend en charge automatiquement les transactions, la distribution des objets, la concurrence, la sécurité, la persistance et la gestion des ressources. Alors après ça nous trouvons que EJB est tout simplement un modèle de composants du coté serveur qui permet de développer des objets métiers pouvant migrer d'un conteneur EJB (serveur EJB) à un autre. Un bean métier présente un modèle de programmation simple permettant aux développeurs de se concentrer sur l'aspect métier. En plus, chaque instance d'un EJB se construit dans un conteneur EJB qui est un environnement d'exécution fournissant des services (sécurité, communication, cycle de vie ), d une manière à ce qu un client n'accède jamais directement à un composant, mais il doit passer par une interface distante décrivant le cycle d'existence du composant en définissant des méthodes pour le trouver, le créer et le détruire. L'interface distante spécifie les méthodes que ce composant présente au monde extérieur. Les composants coté serveur des EJB sont de trois types : les beans entité, les beans session et les beans orienté message tel que les deux premiers basés sur RMI (Remote Method Invocation). On y accède à l'aide des protocoles d'objets distribués. Les beans entités Ça correspond à des objets réels tels que ces objets sont généralement des enregistrements persistants stockés dans une BDD. On peut aussi dire que les beans entités sont des moyens de modélisation des concepts métier pouvant être désignés par des noms, par exemple : un bean entité peut représenter un client ou un objet stocké. Les beans session Ceux sont une extension de l'application client et ils sont responsables de la gestion des processus ou des tâches. Les beans orientés message Un bean session fournit une interface distante afin de définir les méthodes que l'on peut invoquer, alors que bean orienté message attend des messages asynchrones spécifiques auquel il répond. Alors généralement, un EJB récupère également les données stockées, les traitent et les envois au programme du client. La Figure 5 schématise l architecture des EJB -18-
Firewall Clien Clien t Client Couche client Client Conteneur web (Servlet, page jsp, HTML, XML) Conteneur EJB Couche métier Entreprise bean Entreprise bean Entreprise bean JNDI, JMS, JavaMail Système d informati on d entreprise (RDBMS, ERP, Legacy Applicatio) Couche EIS Figure 5 Architecture EJB Note : Les serveurs JEE permettent de mettre en place une application à trois niveaux logiques comme le montre la Figure 6 : Niveau présentation : L'interface graphique pour l'utilisateur. Niveau métier : Recouvre le logique métier (aussi appelée logique applicative). Niveau données : Les données de l'application (serveur de BDD, documents XML, serveur LDAP ). -19-
b. Services d'infrastructures On trouve les services suivants : Figure 6 Séparation logique de JEE JDBC «Java DataBase Connectivity» C est une API qui permet aux programmes java d'interagir avec les bases de données SQL. Les serveurs fournissent en plus un mécanisme qui permet de réutiliser les connexions crées avec les BDD. Cela réduit le nombre de lignes à écrire et optimise son utilisation. JTA/JTS «Java Transaction Api / Java Transaction Services» C'est une API définissant des interfaces standard avec un gestionnaire de transaction, c'est_à dire permettant à des applications et à des serveurs JEE d'accéder à des transactions. JCA «JEE Connector Architecture» C est une API de connexion au système d'information de l'entreprise, notamment aux systèmes dits "legacy" tel que les ERP (Entreprise Ressource Planning). JMX «Java Management Extension» Permet de développer des applications WEB de supervision d'applications à partir des extensions. JNDI «Java Naming and Directory Interface» C est une extension java standard qui fournit une API permettant de localiser et d'utiliser des ressources; il peut y avoir un appel à des services CORBA, DNS, NIS, LDAP -20-
c. Services de communication JMS «Java Message Service» A pour rôle l'envoi et la réception des messages entre deux composants d'application JEE. JAAS «Java Authentification And Autorisation Service» Permet aux applications JEE d'authentifier et autoriser l'exécution par les utilisateurs. Java Mail TM Technology Permet l'envoi des e-mails d'une manière indépendante de la plate forme et du protocole, donc envoi de courrier électronique. RMI-IIOP «Remote Method Invocation/Internet Inter-Orb Protocol» Cette API permet la communication synchrone entre objets. Web Services Les web services permettent de partager un ensemble de méthodes qui pourront être appelées à distance. Cette technologie utilise XML ce qui permet d'être utilisé par n'importe quel langage et n'importe quelle plate forme. XML N'est pas vraiment une API de JEE mais son utilisation dans cette plate forme est de plus en plus importante comme son utilisation pour les fichiers de configurations. XML est la base d'un nouveau mode de communication entre les applications. Ces APIs sont dans le cas général, il existe des APIs qui sont apparues dans l'architecture JAVA JEE 5. REMARQUES L'architecture de JEE peut être séparée comme suit : - La couche présentation qui correspondant à l'interface home-machine (IHM) ; - La couche métier qui contient l'essentiel des traitements de données en se basant sur des API existantes ; - Et enfin la couche de données qui correspondent aux informations de l'entreprise stockées dans des fichiers, dans des bases de données relationnelles ou XML, dans des annuaires d'entreprise ou encore des systèmes d'information complexes. -21-
IIOP JRMP http SSL JRMP IIOP JRMP IIOP http SSL http SSL SOAP HTTP SOAP HTTP EGB/iiop/ssl Conteneur Applet Conteneur Application Client Conteneur Web Conteneur EJB Base de données Plate forme J2EE JRMP SOAP http IIOP HTTP SSL Figure 7 Les protocoles utilisés 2. Les conteneurs (en anglais containers)[5] C est l'environnement d'exécution qui a pour rôle de gérer des composants applicatifs et leur offrir des accès aux API JEE. Un conteneur est une entité qui fournit aux composants la gestion de cycle de vie, la sécurité, les services de déploiement et d'exécution. Chaque type de conteneur (EJB, WEB, JSP ) fournit aussi des services spécifiques à ces composants. a. Types des conteneurs Il existe plusieurs types de conteneurs qu on peut citer : Conteneur web Il est composé deux grandes parties : un moteur de servlets et un moteur de JSP, donc ce conteneur permet d'exécuter les composants JSP et les servlets de l'application JEE. -22-
Conteneur EJB Comme dit avant, l'ejb s exécute sur le serveur et aussi leurs conteneurs, ce type de conteneur permet de gérer l'exécution d EJB. Conteneur d'application client Il permet de gérer l'exécution des composants de l'application client. Il s exécute sur le client. Conteneur d'applets C est une composition de deux parties : navigateur web et java plug-in qui fonctionnent ensemble sur le client, donc ce conteneur permet de gérer l'exécution des applets. b. Descripteur de déploiement[12] Le rôle d un descripteur de déploiement est d écrire les composants applicatifs et les informations sur ces composants (droits d'accès ). Il est sous forme d un fichier XML. Avec JEE 5 la technologie des descripteurs de déploiement XML sont maintenant facultatives. Au lieu d écrire ces composants et leurs informations en XML, on peut les écrire comme des annotations directement dans le code source JAVA. Le serveur d application JEE configure le composant et le déploie au cours de l exécution. c. Architecteur d'un conteneur[5] Un conteneur se divise en quatre parties comme suit : Les interfaces des composants : Sont des interfaces où les composants applicatifs doivent être implémentés et spécifiés par le conteneur. APIs des services du conteneur : Sont des APIs de services supplémentaires. Services déclaratifs : Introduits par les applications. Autres services du conteneur : Par exemple; garbage collector, le pooling des connexions BDD d. Services d'un conteneur[2] Un conteneur est une interface entre un composant et les fonctionnalités du bas niveau de JEE qui prend en charge le composant. Ces conteneurs fournissent un ensemble de services parmi lesquels on cite : Service de sécurité de JEE : C est un modèle de configuration d'un composant web ou composant EJB tel que les ressources du système ne soient accessibles que par les utilisateurs autorisés. Service de transaction JEE : c est un modèle qui précise les relations entre les méthodes qui constituent la même opération tel que toutes les méthodes en une seule transaction sont traitées comme une seule unité. Les services de la consultation JNDI : Ces services fournissent une interface pour le nommage multiple. -23-
Le modèle des connectivités distantes de JEE : Quand EJB crée le client, il invoque les méthodes comme si elles étaient dans la même machine virtuelle, donc ce modèle autorise une communication entre EJB et client. 3. CONCLUSION[2] En conclusion de cette partie, On peut donner un schéma global de l architecture des APIs de la version 1.5 de JEE. La Figure 8 montre schématise cette architecture. Figure 8 Architecture de JEE 3. Les serveurs d'applications Ils existent plusieurs définitions d'un serveur d'application parmi lesquelles on cite :[8] Généralement, un serveur d'application est un logiciel d'infrastructure offrant un contexte d'exécution pour des composants applicatifs. Le terme est apparu dans le domaine des applications WEB, dans le sens strict où les composants hébergés par le serveur d'application ne sont pas de simples procédures ou scripts mais de réels composants logiciels conformes à un modèle de composants (EJB, COM, Fractal, etc.). Les clients des serveurs d'applications sont des programmes autonomes (stand- alone application), des applets ou d'autres composants. -24-
La structure en couches des différents composants mis à disposition par le serveur d'application permet une prise en compte des besoins métier et des interactions avec les utilisateurs des connexions avec les bases de données. Les serveurs d'applications peuvent être définis comme suit : Ils sont des logiciels occupant la couche centrale dans une architecture multi couches, qu'elle soit classique 3-tiers (postes client, serveur de données, serveur d'application) ou étendue (n-tiers) lorsqu'elle intègre des serveurs d'acquisitions (données de terrain, données de traitement, de back-office, etc.) et/ou des serveurs d'interface (gateways, systèmes coopérants externes, etc.). Et comme définition plus large, un serveur d'application peut être une machine servant à héberger des applications soit pour permettre leur exécution depuis un poste client (mode client serveur de données, généralement partage de fichiers et politiques de gestion des accès) ou pour déporter l'affichage sur le poste client (mode clients serveur d'affichages). Donc généralement, un serveur d'application est l'environnement d'exécution des applications côté serveurs. Il prend en charge l'ensemble des fonctionnalités qui permettent à plusieurs clients d'utiliser une même application. La Figure 9 définit les différents éléments nécessaires d'un serveur d'applications : Navigateur web Modèle de serveur d application Serveur web Serveurs d applications Base de données Internet Clientweb Couche données Couche de web server couche application server Figure 9 Architecteur d un serveur 1. Le rôle d'un serveur d'application (ou bien les services)[1] Le rôle d'un serveur d'application est d héberger des applications distribuées, fabriquées à base de composants Java (Servlet, JSP, EJB) et de les rendre accessibles à des clients web (navigateurs) et à des applications d'entreprise écrites en Java. Le serveur d'application doit être performant et fiable pour satisfaire aux exigences des applications d'entreprise. Le serveur offre différents services utiles applications : -25-
a. Service de nommage C est le service le plus important dans un serveur d'application implémentant l'interface SPI (Service Provider Interface) et utilise généralement le protocole LDAP (Lightweight Directory Access Protocol). Ce dernier fournit des mécanismes de recherche, de localisation et de liaison. Le service de nommage permet de stocker des références sur des ressources d'objets (EJB, DataSource JDBC, JMS, JTA, informations de configuration) de façon hiérarchique où les clients peuvent effectuer dans l'annuaire des recherches sur ces ressources pour travailler avec les objets distants correspondants. b. Services de gestion de transaction Il permet de gérer des transactions locales mais surtout il prend en charge la gestion des transactions distribuées, indispensable pour les applications JEE. Plusieurs composants et plusieurs sources de données peuvent partager la même transaction. Une transaction doit respecter les propriétés ACID (Atomic, Consist, Isolated, Durable). c. Service de gestion de la disponibilité des applications Il permet de gérer un grand nombre d'accès et de requêtes simultanés. Plusieurs requêtes simultanées peuvent invoquer la même ressource, donc il faut vérifier qu'une ressource soit capable de satisfaire aux requêtes des clients dans un temps minimal. d. Service de sécurité L'administrateur du serveur d'application peut configurer des domaines de sécurité en définissant des utilisateurs (nom, mot de passe), des groupes d'utilisateurs, puis les permissions accordées sur différents élément par rapport aux composant et/ou aux ressources de l'application JEE. e. Service d'administration L administrateur a la possibilité de consulter, de modifier, et d'ajouter des éléments à la configuration des applications d'entreprises et du serveur d'application. f. Service d'accès aux données Ce service est une implémentation des extensions de L'API JDBC 2.0. Il permet de configurer des sources de données et de déléguer la gestion des pools de connexions au serveur d'application ou à la présentation de la plate forme JEE. g. Service de gestion de messages C est une implémentation de l'api JMS, il permet de gérer une file de messages de traitements asynchrones. -26-
2. Avantages d'un serveur d'application[13] La nécessité d'un serveur d'application justifie les grands avantages de ce serveur d'application. Parmi ces avantages nous citons : Client léger ; Intégrité de données et de code ; Configuration centralisée ; Sécurité ; Intégration. 3. Comment travaille un serveur d'application (fonction et architecture)[9] Un serveur d'application est un logiciel personnalisé qui permet à des applications d'inter-communiquer avec diverses qualités de service (fiabilité, sécurité ). Il fournit également ses APIs aux programmeurs. La communication se fait par le WEB en HTML ou XML sous forme de lien aux bases de données Généralement les serveurs d'application travaillent avec un serveur web et sont appelés serveurs d'application web. La Figure 10 en donne un exemple : Figure 10 Serveur d application web Les fonctions d un serveur d application les plus importantes sont : Un utilisateur se connecte par l'intermédiaire de son navigateur et du protocole HTTP au serveur d'application web ; Le serveur d'application web établit une session d'utilisateur et vérifie l'information d'ouverture d'accès aux bases ; -27-
Une page web est crée par le serveur d'application web, permettant à l'utilisateur d'envoyer une requête à la base de données ; Des requêtes sont envoyées au serveur d'application, ce dernier établit un lien à la machine et recherche les données demandées ; Le serveur d'application collecte les données et établit une nouvelle page web pour l'utilisateur ; Des demandes des fichiers HTML statiques sont redirigées par le serveur d'application. 4. Quelques types de serveurs d'application[9]+[3] On peut distinguer deux grands ensembles de serveurs : OPEN SOURCE : Evolue grâce à la communauté. PROPRITAIRE: Evolue selon l'éditeur. Les plus connus dans les deux catégories sont : En OPEN SOURCE : a. TOMACT[11] C est un serveur d'application intégrant le serveur web APACHE. Il implémente les technologies suivantes : Servlet, JDBC, JNDI. b. Jonas Implémente les technologies : JSP, JDBC, JTA, JMS, JMX, JNDI, JAAS, Java mail. JonaS, signifie «Java Open Application Server», est un serveur d'application open source, multi plate formes et multi bases de données. Il est exploité dans de les grandes organisations (banques, ministères, défense, industrie ). c. JBOSS Le serveur d application JBOSS est libre et il est entièrement écrit en Java. d. GLASS FISH C est un serveur d'application open source de Sun. C'est le premier qui a offert une exécution robuste commerciale, compatible avec JEE5. En PROPRIETAIRE : a. WEB SPHERE d IBM C est une plate forme applicative générique couvrant un ensemble de solutions développées par IBM, qui permet de développer, de déployer et d'utiliser des applications d'entreprise même dans des cas complexes. b. WEB LOGIQUE de BEA -28-
C est un serveur d'application purement Java, supportant de toutes les dernières avancées du langage de Sun. La solution de «BEA systems» constitue le socle d'une plate forme d'intégration assez complète. c. WEB OBJECT d APPLE C est le premier serveur d'application orienté objet. Il utilisait avant le langage «objective caml», mais actuellement il est pur Java. d. ORACLE APPLICATION SERVER ORACLE à l'origine est placé sur le marché de serveurs de bases de données. Il présente maintenant une concurrence sur le marché des serveurs d'application grâce à son produit serveur d'application. 5. Notre choix Pour nos applications nous avons choisi le serveur d'application WEB SPHERE d IBM. Nous avons choisi WEB SPHERE pour les caractéristiques suivantes : Il communique efficacement avec le serveur web (http). Il est gratuit pour utilisation personnelle. Il est conforme avec la spécification JEE. Il est compatible avec Windows. Ce choix n est pas peut être modifié, car notre application fonctionne avec n importe quel serveur d application. 4. IDE (L environnement de développement)[10] Pour développer des applications complexes il faut impérativement un IDE. Nous avons choisi ECPLISE qui est le plus utilisé pour JAVA et il possède une version pour les projets JEE. 5. Conclusion Les serveurs d'applications deviennent à nos jours une nécessité pour les applications distribuées. Il y a des serveurs plus utilisés que d autres selon leurs propriétés et aussi selon le domaine des applications. Une application JEE nécessite divers types de compétences, que l'on trouve rarement chez une même personne car la réalisation d une application va de la conception jusqu'à la supervision de l'application en passant par le développement et le déploiement. -29-
Pour cela l architecture JEE adopte l'approche de partage des responsabilités. Précisément les EJB définit les niveaux de responsabilités suivants : Le fournisseur d EJB est l acteur qui fournit des composants métiers réutilisables. L'assembleur d'application construit l application à partir des composants fournis par le fournisseur d EJB. Le déployeur récupère l'application construite et s'occupe de son déploiement dans un serveur d'application. L'administrateur vérifie le fonctionnement d'un serveur d'application et assure la supervision des applications. Une application JEE se compose de 4 modules :[13] Le module EJB : Contient les fichiers du code Java de la partie métier. Le module web : Contient des pages JSP, Servlets, pages HTML, et images. Le module client : Contient des fichiers de classe Java destinés aux clients de l application. Le module des connecteurs : Contient diverses éléments (interface Java, classes ) permettant de connecter les différents composants des autres modules. Et la Figure 11 schématise les différents éléments d'une application JEE. Racine d Assemblage META-INF Module WEB Module EJB Module Application Module Adaptateur de Ressource Application.xml Sun_application.xml Figure 11 Eléments d une application JEE -30-
GESTION D UN CABINET MEDICAL -31-
1. Problématique La gestion du nombre important de dossiers des patients dans un cabinet médical manuellement devient très difficile. Un médecin doit se souvenir des problèmes de ses patients, suivre le développement de leur état médical surtout pour les maladies chroniques et avoir en tête tous ce que se trouve dans leurs dossiers médicaux au moment de la consultation. Dans ce but, nous avons pensé à développer une application de gestion d un cabinet médical pour faire face à de problème. Le médecin tape la référence du patient sur cette application pour avoir tout le dossier sur son écran. 2. Les technologies utilisées dans ce projet Pour développer notre application nous avons utilisé le serveur d application WEBSPHERE et l environnement de développement ECLIPSE. Les données seront stockées sur la base de données intégrée sur WEBSPHERE et l accès se fait à l aide de SQL «Structured Query Langage». Nous avons utilisé le langage de programmation JAVA. 3. Construction de la base de données La base de données contient un certain nombre de tables. Les tables dont nous avons besoin pour notre projet nous les avons définis comme suit : MEDECIN, PATIENT, ORDONNANCE, TRAITEMENT, MALADIE. -32-
PATIENT NSS_PAT PRIMERYKEY NOM _PAT PRENOM_PAT DATE_NAIS LIEU_NAIS NATIONALITE ADRESSE PROFESSION NUM_TEL ANTECEDANTS DATE_INSCRIPTION MEDECIN NSS_MED PRIMERYKEY NOM _MED PRENOM_MED DATE_NAIS LIEU_NAIS NATIONALITE ADRESSE SPECIALITE NUM_TEL Faire Réserver TRIATEMENT NSS_MED PRIMARYKEY NSS_PAT PRIMARYKEY DATE_CONSULTATION PRIMARYKEY ID_MALADIE ID_ORD Faire ORDONNANCE COMPORTE ID_ORD PRIMARYKEY NOM_MALADIE NOM_MED NOM_PAT MEDICAMENTS MALADIE ID_MALADIE PRIMARY KEY NOM_MALADIE MEDICAMENT -33-
4.Les classes importantes dans ce projet Après la création des tables nécessaires de la BDD et les remplis, nous avons Crès les classes nécessaires. En générale pour chaque table il y a une classe par exemple pour la table MEDECIN on génère la classe Médecin etc. Tel que dans chaque classe on crêt les objets vides. Donc on a cinq classes mais en exception dans les classes médecin et patient nous mettons une classe mère (base) dont à partir de cette classe nous héritons les deux classes médecin et patient, et celle-ci la classe Personne qui contient tout les caractéristiques communes entre médecin et patient. Aussi nous générons la classe DBManager qui fait la connexion au notre base de données en outre qui comporte des méthodes permettent de ressortir les résultats, ces résultats ne sont pas affichées à l écran mais sont organisées dans une liste. Il y a d autres classes que nous ajoutons pour le fonctionnement des notre pages web, par exemple la classe PropertyHandler qui autorise l utilisation du bouton «OK» (permet de lire et écrire à partir des champs des formulaires). 5. Les exemplaires écrans de l exécution de l application Comme nous avons dit la classe DBManager retourne des listes qui comportent des résultats différents tels que chaque résultat répond à une question bien déterminée. Par exemple la liste qui contient les medecins répond à la question quels sont les médecins inscrit dans ce cabinet médical? et afin de mettre ces résultats visibles «afficher à l écran» il faut faire des jsp. Les jsp permettent de gérer des pages web dont chaque page affiche les résultats qui convient. Pour notre application il y a les jsp suivants : index.jsp. rech_pat.jsp. rech_med.jsp. rech_consult.jsp. Patient.jsp et Medecin.jsp. a/index.jsp Cet index contient des liens vers les autres pages web, dont à partir de ces liens on peut passer à la page qui cherche des medecins, qui cherche des patients ou qui cherche des consultations alors au niveau de cette page nous mettons les liens à l aide des balises : -34-
<a href ="le lien"> le nom de lien</a> On peut aussi ajouter des écritures dans cette page pour organiser ces pages. Le titre que nous donnons à cet index se trouve en haut de la page «LIEN NECESSAIRES» et chercher un médecin, chercher un patient et chercher une consultation sont les liens vers des autres pages. Et pour accéder à une page on peut accéder directement comme on peut l ouvrir dans une nouvelle page. -35-
b/ rech_pat.jsp Dans ce lien on trouve un formulaire qui contient trois champs NSS, NOM et PRENOM où on peut saisir des informations afin de trouver des patients soit tout les patients ou un patient bien déterminé. Quant on ne fait aucune saisie on trouve tout les patients ça c est le cas où les trois champs précédents sont vides alors on exécute l instruction «SELECT * FROM PATIENT» dans la classe DBManager. -36-
Dans le cas où nous avons cherché un patient précis nous remplissons un parmi les trois champs existants et selon la donnée de chaque champ on trouve les résultats, alors nous avons utilisé dans DBManager «dans la méthode getpatients» l instruction de choix suivante : «SELECT * FROM PATIENT WHERE NSS_PAT="+nss+" OR NOM_PAT='"+nom+"' OR PRENOM_PAT='"+prenom+» c est-à-dire si on saisit le nom on trouve les patients qui ont le même nom, si on saisit le prénom on trouve les patients qui ont le même prénom et enfin si on saisit le NSS on trouve un seul patient. Par exemple si on saisit un nom du patient dans le champ Nom et puis clique sur le bouton «OK» comme suit : -37-
Donc tous les autres patients dans la table disparaitront et reste seulement les patients qui ont le même nom saisi. c/ rech_med.jsp Dans ce lien il y a presque la même chose du lien rech_pat sauf qu on trouve un formulaire qui permet la recherche des ou du médecin(s) alors la saisie dans cette formulaire sera le nom, le prénom et le NSS des médecins. Le but de ce lien est de -38-
d afficher les informations des médecins. Par exemple si on cherche un médecin précis on saisit le NSS de ce médecin tel que le résultat sera unique «afficher les informations d un seul médecin». Ces informations sont affichées sous forme d une table ça c est notre choix pour afficher les résultats tel que ce format d affichage permet d afficher soit tout les médecins ou un seul. Alors le résultat comme suit : -39-
d/ rech_consult.jsp Cette page permet de rechercher une consultation. Elle diffère des deux premiers car son formulaire est une composition des informations extraites à partir les deux tables MEDECIN et PATIENT et aussi la table TRAITEMENT. Ce formulaire comporte trois champs un pour le nom du médecin, le deuxième pour le nom du patient et l autre pour la date de consultation, mais leur but est de ressortir toutes les informations dans la table TRAITEMENT, alors comment on fait ça? Comment le réaliser à partir du nom du médecin et le nom du patient malgré dans la table TRAITEMENT on trouve les NSS? Les deux méthodes getmédecins() et getpatients() donnent les listes des médecins et les listes de patients ; la méthode gettraitement() faire un appel à ces deus méthodes afin d extraire les NSS des médecins et des patients à partir de leurs noms. Donc l appel à getmédecins() par l attribut «nommedecin» nous donne le NSS du médecin et de la même manière pour le patient. Alors la requête SQL est comme suit : SELECT * FROM TRAITEMENT WHERE NSS_MED="+nss_med+" OR NSS_PAT="+nss_pat+" OR DATE_CONSULTATION='"+dateconsultation+. Alors le but est si on saisit le nom du médecin, le nom du patient et la date de consultation on trouve toutes les consultations d un patient avec un médecin précis à la date précisée. -40-
Il y a aussi des liens au niveau de ce formulaire soit vers un patient, médecin, il suffit de cliquer sous le lien une autre page qui sera affichée. Par exemple dans le champ NSS_MED on peut accéder à medecin.jsp qui permet de lire les informations d un médecin déterminé comme le peut l ajouter d un nouveau médecin dans la BDD. exemple si en cliquer sous le NSS_MED «111» on trouve les informations de SAADI comme suit. Il y a aussi d autre méthode permet d ajouter un médecin par exemple dans la BDD çà est travers le lien création dossier médecin avec le remplir les informations du nouveau médecin nécessaires puis l accepter «OK». -41-
e/le bouton Réinitialiser Ce bouton est de type reset permet d effacer notre saisie dans les champs et ça est utile dans le cas ou nous faisons des erreurs. Il suffit de cliquer sur ce bouton pour effacer tout et mettre les valeurs par défauts du formulaire. Après quand on clique sur le bouton Réinitialiser on retourne aux valeurs initiales. -42-
-43-
1. Conclusion générale La plate forme JEE est une technologie qui s'est imposée comme un standard à cause des serveurs d'application. Elle permet de répondre aux problématiques d'intégration et d'architecture multi-niveaux, donc JEE permet une grande flexibilité dans le choix de l'architecture de l'application en combinant les différents composants, tel que le choix se fait selon les besoins aux quels répondre l'application et aussi en combinant les différents APIs de JEE. L'architecture JEE est basée sur la souplesse de Java dont elle réunit les diverses spécifications (Servlets ) autour d'une démarche unifiée de développement. Dans ce sens JEE va au-delà des architectures distribuées CORBA et COM. Son seul concurrent sérieux pourrait bien être.net de Microsoft. On peut séparer une application JEE à trois parties distinctes (ou bien d'une ou plusieurs unités applicatives dont il faut respecter le modèle générale de développement et chaque unité contient un ensemble de composants "EJB, pages JSP "). Ces trois parties peuvent être librement déployées sur de multiples systèmes au sein d'une architecture distribuée. Nous avons proposé une solution à notre problématique, citée dans l introduction générale, qui se résume en la sécurité des informations des patients qui sont confidentielles et il ne faut pas les perdre, et de faciliter la recherche de l information pour le médecin. Avec notre solution proposée, incluant les fonctionnalités de la plate forme JEE, le médecin ne confond plus entre ses patients, surtout quand le nombre est élevé, et ne perd pas de temps dans la recherche des dossiers des patients. -45-
Références bibliographiques : [1] Ben jamain AUMAILLE, SERVELETS «Programmation d application web avec java (JEE)», Edition ENI-Mai 2004. [2] Joni cyril, Introduction à JEE connaître l environnement jee, edition 29 avril 2010. [3Elysée fontep et Phuong anh hoang, les serveurs d applications, edition December 2006. [4] Santa Clara, the java EE5 tutoriel For Sun java System Application Server 9.1, Part NO : octobre 2008. [5] Jean Michel DOUDOUX, développons en java, Mars 2000. [6]http://www.commentcamarche.net/contents/servlets/servvar.php3. [7]sun.com [8] http://www.01net.com/article/213634.html. [9] http://www.softeam.fr/formation_java_admjb.php. [10] http://www-igm.univ-mlv.fr/~dr/xpose2003/alexandrebole/jboss_4.html. [11] http://fr.wikipedia.org/wiki/apache_tomcat. [12] http://www.3ie.fr/nouvelles_technologies/fiche/fiche_j2ee.htm. [13] http://www.softeam.fr/technologies_j2ee.php. [14] java.sun.com/j2ee/tutorial [15] P. Déchamboux, «Intergiciel et Construction d'applications Réparties», 2006. -46-