Admin CliCours
Architecture des applications distribuées
Les applications informatiques ont pris une place centrale dans la plupart des entreprises. Les premières applications étaient monolithiques, d’une seule pièce. Ce type d’architecture se prête mal à la demande des entreprises. L’entreprise va demander à l’application informatique de lui fournir de nouveaux services en fonction de l’évolution de son environnement. Il est complexe d’ajouter de nouvelles fonctionnalités à une application monolithique, sans provoquer une régression de certaines parties du code. De plus, Internet a révolutionné le besoin de connectivité visàvis de l’entreprise. En quelques années, les équipes de conception logicielle ont dû revoir leur mode de travail : connectivité, modélisation objet, utilisation de frameworks, etc. L’architecture des applications d’entreprise a largement évolué car le mode d’utilisation de ses applications a changé. De nombreux postes informatiques sont maintenant reliés en réseau, ce qui permet à plusieurs salariés de travailler sur la même application. Des succursales de l’entreprise peuvent se connecter sur l’application, via Internet, pour gérer des données techniques, suivre les statistiques de ventes, effectuer des saisies, etc. Les clients de l’entreprise peuvent avoir accès, via son site web, à des données les concernant : factures, vérification de leurs cordonnées, changement de compte bancaire… Ils peuvent aussi être prévenus par SMS ou mail du suivi de leur commande, état de leur compte… Les concepteurs d’applications doivent faire face à plusieurs défis : ● des types variés de moyens de saisie et d’affichage de l’information : clients lourds, navigateurs, téléphone mobile… ● des fonctionnalités qui évoluent : de nouveaux traitements doivent être ajoutés, des modifications de règles législatives, de nouveaux services client… ● des règles de sécurité différentes pour les salariés, les succursales, les clients finaux, les partenaires… ● Internet qui a considérablement modifié l’architecture avec l’utilisation de serveurs web, un nombre de connexions difficile à prévoir, la gestion des montées en charges, les connexions aux bases de données… La conception d’une application amène à réfléchir sur : ● ce qui est du domaine du métier de l’entreprise : gestion des clients, de la fabrication, des stocks… ● ce qui est du domaine du support de l’application : base de données, gestion de la sécurité, transactions, réseau… Il faut remarquer que ces derniers points sont communs à toutes les applications. Une architecture en couche permet de mieux maîtriser l’évolution de l’application, que ce soit au niveau fonctionnel, ou au niveau logique. Le développeur n’a pas à se soucier du codage des contextes de transactions ou de ceux de l’authentification et sécurisation. Toutes ces fonctionnalités, présentes quelle que soit l’application et transversales aux couches applicatives, sont mises à disposition par le serveur. Il peut se consacrer au développement métier en utilisant les services précédemment décrits. Sun, via la plateforme JEE (Java Enterprise Edition), a mis en place une standardisation de ses services et la manière de les utiliser. Le développeur pourra se consacrer au codage des couches de présentation et métier, grâce à des © ENI Editions – All rigths reserved – Kaiss Tag – 1 – enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA5MzczMzc5IC0gS2Fpc3MgVGFnIC0gZWNhNTA5YTUtMDdkMC00NDU1LTgzYjItZGFmOTViNjc0ZWMzE0DYdKGRzIgLAA==-enidentnumber composants pris en charge par le serveur d’application. Ces composants sont principalement : ● Les servlets, qui décodent les entêtes des requêtes HTTP et codent les entêtes de réponses HTTP, gèrent les sessions HTTP, mettent à disposition du développeur des objets prenant en charge le cycle de vie de l’application Web. Les servlets sont complétées par d’autres composants et technologies : les JSP (Java Server Page), les balises personnalisées, l’EL (Expression Language), les JSF (Java Server Face)… Ces composants sont pris en charge par le serveur Web. ● Les EJB (Enterprise Java Bean) qui sont des composants dont le cycle de vie est géré par le conteneur d’EJBs. Le conteneur va, par ces composants, gérer les objets et services métier, la persistance, l’envoi et la réception de messages, les transactions… Le développeur doit se préoccuper uniquement de la logique métier : ● comment calculer la facture ● gérer un panier d’achat Le conteneur prend en charge les aspects comme la sécurité ou les transactions. ● l’utilisateur atil le droit de calculer la facture ? ● le paiment n’est pas validé sur le panier d’achat si un problème réseau survient. Il existe deux grandes spécifications pour les EJB : celle des EJB 2 liée à J2EE, et celle des EJB 3 liée à JEE. La connaissance de ces deux spécifications est actuellement nécessaire car un certain nombre de projets ayant vu le jour avant les EJB 3, il faut donc continuer à les faire vivre, les déployer et les administrer. Les technologies incluses dans JEE permettent, entre autres : ● la communication entre objets ; ● la gestion des objets de réponses aux requêtes HTTP ; ● la gestion des transactions ; – 2 – © ENI Editions – All rigths reserved – Kaiss Tag enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA5MzczMzc5IC0gS2Fpc3MgVGFnIC0gZWNhNTA5YTUtMDdkMC00NDU1LTgzYjItZGFmOTViNjc0ZWMzE0DYdKGRzIgLAA==-enidentnumber ● la persistance des objets avec les EJB entité ; ● la communication asynchrone par message avec les EJB orienté message ; ● la réalisation d’interface graphique ; ● la gestion de la sécurité ; ● la gestion de la répartition de charge. Un serveur d’application JEE peut être vu comme la réunion : ● d’un conteneur Web qui gère le cycle de vie des servlets et JSP ; ● d’un conteneur EJB qui gère le cycle de vie des objets métier ; ● d’un ensemble de services : accès aux bases de données, gestion des transactions…
L’invocation de méthodes distantes : RMI
Les objets des différentes couches sont susceptibles d’être invoqués par des objets situés sur une autre machine virtuelle. L’objet dont les méthodes peuvent être invoquées, est dit « objet serveur », l’objet invoquant les méthodes de l’objet serveur est dit « objet client ». Il est évident que dans la réalité, les objets sont couramment serveur et client. L’invocation directe d’une méthode dans une même machine virtuelle est simple : il s’agit d’un appel en mémoire vers une adresse, les arguments de la méthode appelée et sa valeur de retour sont passés en tant que références. C’est simple, efficace et rapide. MonCalendrier cal = new MonCalendrier(); Integer annee = new Integer(2008); Date paques = cal.getDatePaques(annee); L’invocation d’une méthode d’un objet situé dans une machine virtuelle différente est plus complexe. Nous n’avons comme lien entre les deux machines virtuelles que le réseau, sous protocole TCP/IP. Il faut donc : ● connaître l’IP de la machine où se trouve l’objet serveur ; ● que l’objet serveur soit à l’écoute des demandes sur un socket de type serveur ; © ENI Editions – All rigths reserved – Kaiss Tag – 3 – enidentnumber-AAEAAAD/////AQAAAAAAAAAMAgAAAE1FTkkuRWRpdGlvbnMuTUVESUFwbHVzLCBWZXJzaW9uPTEuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAJ0VOSS5FZGl0aW9ucy5NRURJQXBsdXMuQ29tbW9uLldhdGVybWFyawIAAAAHcGlzVGV4dAlwaWR0ZURhdGUBAA0CAAAABgMAAAA5MzczMzc5IC0gS2Fpc3MgVGFnIC0gZWNhNTA5YTUtMDdkMC00NDU1LTgzYjItZGFmOTViNjc0ZWMzE0DYdKGRzIgLAA==-enidentnumber ● que l’objet client initie une demande vers l’objet serveur via un socket ; ● que les échanges soient effectués sur un protocole commun. Donc, nous sommes loin de l’utilisation de l’opérateur point (.) pour invoquer la méthode distante. Le développeur passera sûrement plus de temps à élaborer un protocole de communication entre objets, qu’à se consacrer à l’écriture de son application ! Heureusement, nous pouvons utiliser la technologie RMI (Remote Method Invocation) qui va masquer, pour nous, l’ensemble des opérations décrites cidessus. Une interface expose les méthodes distantes. Elle est implémentée par l’objet serveur et est utilisée par l’objet client. RMI est construit sur trois couches. La première couche comprenant les stubs et skeletons est une couche proxy, ce qui permet au développeur de ne pas connaître les détails d’implémentation de RMI et d’utiliser l’opérateur point (.) pour l’invocation de la méthode distante. La classe stub, côté client, est créée par le compilateur rmic, présent dans le répertoire bin du JDK. Cette classe va sérialiser les paramètres passés à la méthode distante, et désérialiser la valeur de retour de la méthode distante. La classe skeleton, côté serveur, est chargée de désérialiser les paramètres reçus pour les transmettre à la méthode appelée, et de sérialiser la valeur de retour. Il faut donc que les classes des paramètres et de la valeur de retour soient sérialisables. Le passage des paramètres se fait alors par copie et non par référence. La seconde couche, RRL (Remote Reference Layer), est chargée de la localisation de l’objet distant. Elle permet d’obtenir une référence à l’objet distant, à partir de la référence locale (le stub). Ce service est lié à un service de nommage, qui peut être un service JNDI (Java Naming and Directory Interface) ou un service de base appelé RMI registry, lancé avec la commande rmiregisty, situé dans le répertoire bin du JDK. La troisième couche de transport est basée sur TCP/IP. Cette couche utilise les classes Socket et SocketServer. La compréhension de RMI est primordiale pour aborder les applications distribuées en Java car RMI est utilisé pour la communication avec les EJB. Il faut noter qu’il existe des différences notables entre l’implémentation de RMI dans le JDK 1.1 et dans JDK 1.5. Les lecteurs intéressés pourront trouver plus de renseignements sur le site de Sun (http://java.sun.com). Le processus de développement d’une application RMI est le suivant : ● définir l’interface exposant les méthodes distantes ; ● implémenter les méthodes distantes ; ● développer le client ; ● compiler les classes ; ● générer les classes stub avec rmic ; ● lancerrmiregistry ; ● lancer l’application serveur ; ● lancer l’application cliente.
Télécharger le document complet
