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 plate­forme 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 en­têtes des requêtes HTTP et codent les en­tê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 a­t­il 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 ci­dessus. 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.