| |
|
|
Architectures réparties en Java
|
Annick Fron
Les architectures réparties permettent de faire communiquer des logiciels installés sur une même machine ou sur des machines différentes d’un réseau, aussi vaste soit-il. Dans ce domaine, l’univers Java propose aujourd’hui des solutions de développement simples à mettre en œuvre et très puissantes.
Dans Architectures réparties en Java (Dunod, 2007), Annick Fron explore les notions clés qui permettent de faire des choix d’architecture adaptés à chaque besoin et
fait le point sur les différentes techniques de développement et sur les avantages de Java dans ses dernières versions.
Unique en son genre, cet ouvrage sera très utile aux étudiants abordant la programmation des systèmes répartis et aux architectes logiciel.
|
| |
Quels sont les avantages des applications réparties logicielles, à quoi servent-elles concrètement ?
|
| Une application répartie est une application qui fait intervenir plusieurs ordinateurs, ou plusieurs appareils et rajoute une couche d’intermédiation sur le réseau. On voit donc que le champ est large, depuis la communication entre mobiles ou en pair à pair entre ordinateurs jusqu’au travail collaboratif en entreprise ou la répartition de calculs pour les scientifiques. Sans oublier la communication avec des robots dans l’espace ou la surveillance d’outils de production en entreprise.
|
|
Quelles sont les technologies qui interviennent dans ces architectures ?
|
Le but de mon ouvrage est de présenter un panorama étendu des différentes technologies, mais sans entrer dans les détails des optimisations de couches basses sur le réseau.
Selon le type d’application, le concepteur doit pouvoir choisir ses critères d’optimisation, la fiabilité pour une application bancaire, la rapidité pour un système d’alerte...
Le conditionnement médiatique J2EE fait oublier qu’il est possible de faire des choix, et que ces choix sont primordiaux pour un architecte logiciel. Ces choix ne doivent pas être dictés par le marketing, par exemple l’utilisation des services web ouvre le monde, mais pénalise les performances et la richesse du modèle de communication. Dans un monde interne à un système, d’autres technologies plus éprouvées comme Corba sont parfois préférables même si elles ne sont plus à la mode. De plus, elles continuent d’évoluer hors des feux de la rampe.
Par ailleurs, les applications de gestion et de commerce électronique sont mises en avant dans les démonstrations, les présentations d’outils, alors que les applications embarquées, industrielles et scientifiques ont une forte valeur ajoutée et nécessitent un savoir-faire pour le choix d’architecture. Et les optimisations nécessaires pour ces dernières vont parfois à l’encontre des solutions les plus répandues.
|
|
Quelles sont les spécificités des applications réparties en terme de développement ?
|
| En terme de développement, les applications réparties vont nécessiter de nombreux outils de génération annexes au compilateur. Un compilateur n’a d’intérêt que pour une mémoire locale, et joue un rôle secondaire dans une application répartie. Le concept de Model Driven Engineering (Ingénierie dirigée par les modèles) prend alors tout son sens : il faut trouver des représentations en amont du système permettant de générer la glue entre les éléments d’application.
Par ailleurs, le test des applications devient plus difficile, car il faut collecter les informations de plusieurs localisations à la fois, alors que le déroulement s’effectue en parallèle.
Enfin, le déploiement du logiciel (téléchargement sur tous les équipements) devient une problématique nouvelle qu’il faut traiter dès la conception du projet. En effet, lorsqu’un opérateur Télécom déploie des millions de YBox, la configuration et le déploiement du logiciel prennent tout son sens, de même que le déverminage à distance. De même pour des automates en salle blanche.
|
|
Quelles notions clés abordez-vous ?
|
L’ouvrage aborde les notions clés qui permettent de faire des choix d’architecture : communication synchrone (mode téléphonique) ou asynchrone (mode du SMS), la manière de faire transiter les données sur le réseau (marshalling), la notion de stub (souche logicielle), le concept d’activation de serveur et de gestion des threads.
Le livre rappelle également en préambule des concepts avancés de Java comme la sérialisation ou la réflexion, qui aident à comprendre comment fonctionnent de l’intérieur les couches Java réparties.
Il aborde très peu les notions de concurrence (gestion des processus et pseudo-parallélisme) sur lequel il existe des ouvrages de référence remarquables, et dans un souci de simplification il n’aborde pas ou très peu les concepts de sécurité, de transaction, d’équilibrage des charges qui pourraient faire l’objet d’une extension par la suite.
Par contre, l’ouvrage aborde le problème de l’administration de l’application avec JMX, souvent considéré comme un point accessoire, mais qui devient central dans une application industrielle.
|
|
Quels sont les points forts de Java 5 dans ce contexte ?
|
Java 5 est une version qui consacre la maturité de Java dans le domaine des applications réparties. Java s’est intéressé très tôt aux communications en réseau avec le web et les applets, mais l’utilisation d’une machine virtuelle a vite prouvé sa supériorité par rapport à l’utilisation traditionnelle de compilateurs croisés en C ou C++, même si au départ les performances n’étaient pas au rendez-vous. Avec Java 5, les performances ont été profondément améliorées avec la nouvelle bibliothèque NIO et l’optimisation de la sérialisation. Microsoft a d’ailleurs copié le concept de machine virtuelle avec Vista, puisque c’est la clé du développement et du déploiement des applications en réseau.
J’aborde brièvement dans le livre les services web en Java 6, mais en dehors de cela Java 6 n’apporte rien de significatif aux applications réparties.
|
|
Comment cet ouvrage est-il construit ? Est-il résolument pratique ?
|
Cet ouvrage est construit autour de mes cours en école d’ingénieur, un chapitre par technologie. Chaque technologie se compare toutefois aux autres, afin de maintenir le fil conducteur autour des concepts clés. Tous les exemples ont été testés et compilés et sont en téléchargement sur le site des Editions Dunod ainsi que le mien, AFC Europe : cela représente plus de 2 Méga-octets de code.
Pour moi, il n’est plus question de faire un livre sur du code qui ne fonctionne pas. Mais le code en extension dans un livre seulement n’est pas utilisable. L’articulation entre livre et téléchargement est essentielle et permet d’avoir un ouvrage très concis.
|
|
Y a-t-il des ouvrages concurrents ?
|
Les Anglo-saxons ont une culture de spécialisation : on trouvera par exemple des ouvrages complets sur JMS, RMI, ou Corba, mais rarement un ouvrage qui compare les différentes techniques (peut-être à l’exception de celui de Garga chez Springer 2006). Par contre, peu ont été traduits, et cet ouvrage vient faire une mise à jour importante par rapport aux ouvrages existants en français et qui pour l’ensemble datent de plusieurs années.
L’ouvrage collecte également des références pour les lecteurs qui souhaiteraient approfondir une technologie particulière.
|
|
À qui s’adresse cet ouvrage ?
|
| Cet ouvrage a d’abord été écrit pour des étudiants qui abordent la programmation de systèmes répartis avec une bonne connaissance de Java. Mais il présente également des optimisations et des réflexions qui proviennent de mon expérience dans le milieu industriel et peuvent être utiles à des architectes logiciel pour leurs choix de conception.
|
|
|
© DUNOD EDITEUR, 31 Octobre 2007
|
| |
|