| Penser en Java 2nde édition | - | Sommaire | Préface | Avant-propos | Chapitre : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Annexe : A B C D | Tables des matières | - | Thinking in Java |
Quand un objet est créé, il existe aussi longtemps qu'on en a besoin, mais en aucun cas il continue d'exister après que le programme se termine. Bien que cela semble logique de prime abord, il existe des situations où il serait très pratique si un objet pouvait continuer d'exister et garder son information même quand le programme ne tourne plus. A l'exécution suivante du programme, l'objet serait toujours là et il aurait la même information dont il disposait dans la session précédente. Bien sûr, on peut obtenir ce comportement en écrivant l'information dans un fichier ou une base de données, mais dans l'esprit du tout objet, il serait pratique d'être capable de déclarer un objet persistant et que tous les détails soient pris en charge.
Java fournit un support pour la « persistance légère », qui signifie qu'on peut facilement stocker des objets sur disque et les récupérer plus tard. La raison pour laquelle on parle de « persistance légère » est qu'on est toujours obligé de faire des appels explicites pour le stockage et la récupération. De plus, JavaSpaces (décrit au Chapitre 15) fournit un type de stockage persistant des objets. Un support plus complet de la persistance peut être amené à apparaître dans de futures versions.
Java n'étant qu'un autre langage de programmation, on peut se demander pourquoi il est si important et pourquoi il est présenté comme une étape révolutionnaire de la programmation. La réponse n'est pas immédiate si on se place du point de vue de la programmation classique. Bien que Java soit très pratique pour résoudre des problèmes traditionnels, il est aussi important car il permet de résoudre des problèmes liés au web.
Le Web peut sembler un peu mystérieux au début, avec tout ce vocabulaire de « surf », « page personnelles », etc... Il y a même eu une réaction importante contre cette « Internet-mania », se questionnant sur la valeur économique et les revenus d'un tel engouement. Il peut être utile de revenir en arrière et voir de quoi il retourne, mais auparavant il faut comprendre le modèle client/serveur, un autre aspect de l'informatique relativement confus.
L'idée primitive d'un système client/serveur est qu'on dispose d'un dépôt centralisé de l'information - souvent dans une base de données - qu'on veut distribuer à un ensemble de personnes ou de machines. L'un des concepts majeurs du client/serveur est que le dépôt d'informations est centralisé afin qu'elles puissent être changées facilement et que ces changements se propagent jusqu'aux consommateurs de ces informations. Pris ensemble, le dépôt d'informations, le programme qui distribue l'information et la (les) machine(s) où résident informations et programme sont appelés le serveur. Le programme qui réside sur la machine distante, communique avec le serveur, récupère l'information, la traite et l'affiche sur la machine distante est appelé le client.
Le concept de base du client/serveur n'est donc pas si compliqué. Les problèmes surviennent car un seul serveur doit servir de nombreux clients à la fois. Généralement, un système de gestion de base de données est impliqué afin que le concepteur répartisse les informations dans des tables pour une utilisation optimale. De plus, les systèmes permettent généralement aux utilisateurs d'ajouter de nouvelles informations au serveur. Cela veut dire qu'ils doivent s'assurer que les nouvelles données d'un client ne contredisent pas les nouvelles données d'un autre client, ou que ces nouvelles données ne soient pas perdues pendant leur inscription dans la base de données (cela fait appel aux transactions). Comme les programmes d'application client changent, ils doivent être créés, débuggués, et installés sur les machines clientes, ce qui se révèle plus compliqué et onéreux que ce à quoi on pourrait s'attendre. C'est particulièrement problématique dans les environnements hétérogènes comprenant différents types de matériels et de systèmes d'exploitation. Enfin, se pose toujours le problème des performances : on peut se retrouver avec des centaines de clients exécutant des requêtes en même temps, et donc un petit délai multiplié par le nombre de clients peut être particulièrement pénalisant. Pour minimiser les temps de latence, les programmeurs travaillent dur pour réduire la charge de travail des tâches incriminées, parfois jusque sur les machines clientes, mais aussi sur d'autres machines du site serveur, utilisant ce qu'on appelle le middleware (le middleware est aussi utilisé pour améliorer la maintenabilité).
L'idée relativement simple de distribuer de l'information aux gens a de si nombreux niveaux de complexité dans son implémentation que le problème peut sembler désespérément insoluble. Et pourtant il est crucial : le client/serveur compte pour environ la moitié des activités de programmation. On le retrouve pour tout ce qui va des transactions de cartes de crédit à la distribution de n'importe quel type de données - économique, scientifique, gouvernementale, il suffit de choisir. Dans le passé, on en est arrivé à des solutions particulières aux problèmes particuliers, obligeant à réinventer une solution à chaque fois. Elles étaient difficiles à créer et à utiliser, et l'utilisateur devait apprendre une nouvelle interface pour chacune. Le problème devait être repris dans son ensemble.
Le Web est en fait un système client/serveur géant. C'est encore pire que ça, puisque tous les serveurs et les clients coexistent en même temps sur un seul réseau. Vous n'avez pas besoin de le savoir d'ailleurs, car tout ce dont vous vous souciez est de vous connecter et d'interagir avec un serveur à la fois (même si vous devez parcourir le monde pour trouver le bon serveur).
Initialement, c'était un processus à une étape. On faisait une requête à un serveur qui renvoyait un fichier, que le logiciel (ie, le client) interprétait en le formatant sur la machine locale. Mais les gens en voulurent plus : afficher des pages d'un serveur ne leur suffisait plus. Ils voulaient bénéficier de toutes les fonctionnalités du client/serveur afin que le client puisse renvoyer des informations au serveur, par exemple pour faire des requêtes précises dans la base de données, ajouter de nouvelles informations au serveur, ou passer des commandes (ce qui nécessitait plus de sécurité que ce que le système primitif offrait). Nous assistons à ces changements dans le développement du Web.
Le browser Web fut un grand bond en avant en avançant le concept qu'une information pouvait être affichée indifféremment sur n'importe quel ordinateur. Cependant, les browsers étaient relativement primitifs et ne remplissaient pas toutes les demandes des utilisateurs. Ils n'étaient pas particulièrement interactifs, et avaient tendance à saturer le serveur et l'Internet car à chaque fois qu'on avait besoin de faire quelque chose qui requérait un traitement il fallait renvoyer les informations au serveur pour que celui-ci les traite. Cela pouvait prendre plusieurs secondes ou minutes pour finalement se rendre compte qu'on avait fait une faute de frappe dans la requête. Comme le browser n'était qu'un afficheur, il ne pouvait pas effectuer le moindre traitement (d'un autre côté, cela était beaucoup plus sûr, car il ne pouvait pas de ce fait exécuter sur la machine locale de programmes contenant des bugs ou des virus).
Pour résoudre ce problème, différentes solutions ont été approchées. En commençant par les standards graphiques qui ont été améliorés pour mettre des animations et de la vidéo dans les browsers. Le reste du problème ne peut être solutionné qu'en incorporant la possibilité d'exécuter des programmes sur le client, dans le browser. C'est ce qu'on appelle la programmation côté client.
Le concept initial du Web (serveur-browser) fournissait un contenu interactif, mais l'interactivité était uniquement le fait du serveur. Le serveur produisait des pages statiques pour le browser client, qui ne faisait que les interpréter et les afficher. Le HTML de base contient des mécanismes simples pour récupérer de l'information : des boîtes de texte, des cases à cocher, des listes à options et des listes de choix, ainsi qu'un bouton permettant de réinitialiser le contenu du formulaire ou d'envoyer les données du formulaire au serveur. Cette soumission de données passe par CGI (Common Gateway Interface), un mécanisme fourni par tous les serveurs web. Le texte de la soumission indique à CGI quoi faire avec ces données. L'action la plus commune consiste à exécuter un programme situé sur le serveur dans un répertoire typiquement appelé « cgi-bin » (si vous regardez l'adresse en haut de votre browser quand vous appuyez sur un bouton dans une page web, vous verrez certainement « cgi-bin » quelque part au milieu de tous les caractères). Ces programmes peuvent être écrits dans la plupart des langages. Perl est souvent préféré car il a été conçu pour la manipulation de texte et est interprété, et peut donc être installé sur n'importe quel serveur sans tenir compte du matériel ou du système d'exploitation.
Beaucoup de sites Web populaires sont aujourd'hui bâtis strictement sur CGI, et de fait on peut faire ce qu'on veut avec. Cependant, les sites web bâtis sur des programmes CGI peuvent rapidement devenir ingérables et trop compliqués à maintenir, et se pose de plus le problème du temps de réponse. La réponse d'un programme CGI dépend de la quantité de données à envoyer, ainsi que de la charge du serveur et de l'Internet (de plus, le démarrage d'un programme CGI a tendance à être long). Les concepteurs du Web n'avaient pas prévu que la bande passante serait trop petite pour le type d'applications que les gens développèrent. Par exemple, tout type de graphisme dynamique est impossible à réaliser correctement car un fichier GIF doit être créé et transféré du serveur au client pour chaque version de ce graphe. Et vous avez certainement déjà fait l'expérience de quelque chose d'aussi simple que la validation de données sur un formulaire. Vous appuyez sur le bouton « submit » d'une page, les données sont envoyées sur le serveur, le serveur démarre le programme CGI qui y découvre une erreur, formate une page HTML vous informant de votre erreur et vous la renvoie ; vous devez alors revenir en arrière d'une page et réessayer. Non seulement c'est lent et frustrant, mais c'est inélégant.
La solution est la programmation côté client. La plupart des machines qui font tourner des browsers Web sont des ordinateurs puissants capables de beaucoup de choses, et avec l'approche originale du HTML statique, elles ne font qu'attendre que le serveur leur envoie parcimonieusement la page suivante. La programmation côté client implique que le browser Web prenne en charge la partie du travail qu'il est capable de traiter, avec comme résultat pour l'utilisateur une interactivité et une vitesse inégalées.
Les problèmes de la programmation côté client ne sont guère différents des discussions de la programmation en général. Les paramètres sont quasiment les mêmes, mais la plateforme est différente : un browser Web est comme un système d'exploitation limité. Au final, on est toujours obligé de programmer, et ceci explique le nombre de problèmes rencontrés dans la programmation côté client. Le reste de cette section présente les différentes approches de la programmation côté client.
L'une des plus importantes avancées en terme de programmation orientée client a été le développement du plug-in. C'est une façon pour le programmeur d'ajouter de nouvelles fonctionnalités au browser en téléchargeant une partie de logiciel qui s'enfiche à l'endroit adéquat dans le browser. Il indique au browser : « à partir de maintenant tu peux réaliser cette nouvelle opération » (on n'a besoin de télécharger le plug-in qu'une seule fois). De nouveaux comportements puissants sont donc ajoutés au browser via les plug-ins, mais écrire un plug-in n'est pas une tâche facile, et ce n'est pas quelque chose qu'on souhaiterait faire juste pour bâtir un site Web particulier. La valeur d'un plug-in pour la programmation côté client est qu'il permet à un programmeur expérimenté de développer un nouveau langage et d'intégrer ce langage au browser sans la permission du distributeur du browser. Ainsi, les plug-ins fournissent une « porte dérobée » qui permet la création de nouveaux langages de programmation côté client (bien que tous les langages ne soient pas implémentés en tant que plug-ins).
Les plug-ins ont déclenché une explosion de langages de script. Avec un langage de script, du code source est intégré directement dans la page HTML, et le plug-in qui interprète ce langage est automatiquement activé quand le page HTML est affichée. Les langages de script tendent à être relativement aisés à comprendre ; et parce qu'ils sont du texte faisant partie de la page HTML, ils se chargent très rapidement dans la même requête nécessaire pour se procurer la page auprès du serveur. La contrepartie en est que le code est visible pour tout le monde (qui peut donc le voler). Mais généralement on ne fait pas des choses extraordinairement sophistiquées avec les langages de script et ce n'est donc pas trop pénalisant.
Ceci montre que les langages de script utilisés dans les browsers Web sont vraiment spécifiques à certains types de problèmes, principalement la création d'interfaces utilisateurs plus riches et attrayantes. Cependant, un langage de script permet de résoudre 80 pour cent des problèmes rencontrés dans la programmation côté client. La plupart de vos problèmes devraient se trouver parmi ces 80 pour cent, et puisque les langages de script sont plus faciles à mettre en oeuvre et permettent un développement plus rapide, vous devriez d'abord vérifier si un langage de script ne vous suffirait pas avant de vous lancer dans une solution plus complexe telle que la programmation Java ou ActiveX.
Les langages de script les plus répandus parmi les browsers sont JavaScript (qui n'a rien à voir avec Java ; le nom a été choisi uniquement pour bénéficier de l'engouement marketing pour Java du moment), VBScript (qui ressemble à Visual Basic), et Tcl/Tk, qui vient du fameux langage de construction d'interfaces graphiques. Il y en a d'autres bien sûr, et sans doute encore plus en développement.
JavaScript est certainement le plus commun d'entre eux. Il est présent dès l'origine dans Netscape Navigator et Microsoft Internet Explorer (IE). De plus, il y a certainement plus de livres disponibles sur JavaScript que sur les autres langages, et certains outils créent automatiquement des pages utilisant JavaScript. Cependant, si vous parlez couramment Visual Basic ou Tcl/Tk, vous serez certainement plus productif en utilisant ces langages qu'en en apprenant un nouveau (vous aurez déjà largement de quoi faire avec les problèmes soulevés par le Web).
Si un langage de script peut résoudre 80 pour cent des problèmes de la programmation côté client, qu'en est-il des 20 pour cent restants ? La solution la plus populaire aujourd'hui est Java. C'est non seulement un langage de programmation puissant conçu pour être sur, interplateformes et international, mais Java est continuellement étendu pour fournir un langage proposant des caractéristiques et des bibliothèques permettant de gérer de manière élégante des problèmes traditionnellement complexes dans les langages de programmation classiques, tels que le multithreading, les accès aux bases de données, la programmation réseau, l'informatique répartie Java permet la programmation côté client via les applets.
Une applet est un mini-programme qui ne tourne que dans un browser Web. L'applet est téléchargée automatiquement en temps que partie d'une page Web (comme, par exemple, une image est automatiquement téléchargée). Quand l'applet est activée elle exécute un programme. Là se trouve la beauté de la chose : cela vous permet de distribuer le logiciel client à partir du serveur au moment où l'utilisateur en a besoin et pas avant. L'utilisateur récupère toujours la dernière version en date du logiciel et sans avoir besoin de le réinstaller. De par la conception même de Java, le programmeur n'a besoin de créer qu'un seul programme, et ce programme tournera automatiquement sur tous les browsers disposant d'un interpréteur interne (ce qui inclut la grande majorité des machines). Puisque Java est un langage de programmation complet, on peut déporter une grande partie des traitements sur le client avant et après avoir envoyé les requêtes au serveur. Par exemple, une requête comportant une erreur dans une date ou utilisant un mauvais paramètre n'a plus besoin d'être envoyée sur Internet pour se voir refusée par le serveur ; un client peut très bien aussi s'occuper de gérer l'affichage d'un nouveau point sur un graphe plutôt que d'attendre que le serveur ne s'en occupe, crée une nouvelle image et l'envoie au client. On gagne ainsi non seulement en vitesse et confort d'utilisation, mais le trafic engendré sur le réseau et la charge résultante sur les serveurs peut être réduite, ce qui est bénéfique pour l'Internet dans son ensemble.
L'un des avantages qu'une applet Java a sur un programme écrit dans un langage de script est qu'il est fourni sous une forme précompilée, et donc le code source n'est pas disponible pour le client. D'un autre côté, une applet Java peut être rétroingéniérée sans trop de problèmes, mais cacher son code n'est pas souvent une priorité absolue. Deux autres facteurs peuvent être importants. Comme vous le verrez plus tard dans ce livre, une applet Java compilée peut comprendre plusieurs modules et nécessiter plusieurs accès au serveur pour être téléchargée (à partir de Java 1.1 cela est minimisé par les archives Java ou fichiers JAR, qui permettent de paqueter tous les modules requis ensemble dans un format compressé pour un téléchargement unique). Un programme scripté sera juste inséré dans le texte de la page Web (et sera généralement plus petit et réduira le nombre d'accès au serveur). Cela peut être important pour votre site Web. Un autre facteur à prendre en compte est la courbe d'apprentissage. Indépendamment de tout ce que vous avez pu entendre, Java n'est pas un langage trivial et facile à apprendre. Si vous avez l'habitude de programmer en Visual Basic, passer à VBScript sera beaucoup plus rapide et comme cela permet de résoudre la majorité des problèmes typiques du client/serveur, il pourrait être difficile de justifier l'investissement de l'apprentissage de Java. Si vous êtes familier avec un langage de script, vous serez certainement gagnant en vous tournant vers JavaScript ou VBScript avant Java, car ils peuvent certainement combler vos besoins et vous serez plus productif plus tôt.
A un certain degré, le compétiteur de Java est ActiveX de Microsoft, bien qu'il s'appuie sur une approche radicalement différente. ActiveX était au départ une solution disponible uniquement sur Windows, bien qu'il soit actuellement développé par un consortium indépendant pour devenir interplateformes. Le concept d'ActiveX clame : « si votre programme se connecte à son environnement de cette façon, il peut être inséré dans une page Web et exécuté par un browser qui supporte ActiveX » (IE supporte ActiveX en natif et Netscape utilise un plug-in). Ainsi, ActiveX ne vous restreint pas à un langage particulier. Si par exemple vous êtes un programmeur Windows expérimenté utilisant un langage tel que le C++, Visual Basic ou Delphi de Borland, vous pouvez créer des composants ActiveX sans avoir à tout réapprendre. ActiveX fournit aussi un mécanisme pour la réutilisation de code dans les pages Web.
Le téléchargement automatique et l'exécution de programmes sur Internet ressemble au rêve d'un concepteur de virus. ActiveX en particulier pose la question épineuse de la sécurité dans la programmation côté client. Un simple click sur un site Web peut déclencher le téléchargement d'un certain nombre de fichiers en même temps que la page HTML : des images, du code scripté, du code Java compilé, et des composants ActiveX. Certains d'entre eux sont sans importance : les images ne peuvent causer de dommages, et les langages de script sont généralement limités dans les opérations qu'ils sont capables de faire. Java a été conçu pour exécuter ses applets à l'intérieur d'un périmètre de sécurité (appelé bac à sable), qui l'empêche d'aller écrire sur le disque ou d'accéder à la mémoire en dehors de ce périmètre de sécurité.
ActiveX se trouve à l'opposé du spectre. Programmer avec ActiveX est comme programmer sous Windows - on peut faire ce qu'on veut. Donc un composant ActiveX téléchargé en même temps qu'une page Web peut causer bien des dégâts aux fichiers du disque. Bien sûr, les programmes téléchargés et exécutés en dehors du browser présentent les mêmes risques. Les virus téléchargés depuis les BBS ont pendant longtemps été un problème, mais la vitesse obtenue sur Internet accroît encore les difficultés.
La solution semble être les « signatures digitales », où le code est vérifié pour montrer qui est l'auteur. L'idée est basée sur le fait qu'un virus se propage parce que son concepteur peut rester anonyme, et si cet anonymat lui est retiré, l'individu devient responsable de ses actions. Mais si le programme contient un bug fatal bien que non intentionnel cela pose toujours problème.
L'approche de Java est de prévenir ces problèmes via le périmètre de sécurité. L'interpréteur Java du browser Web examine l'applet pendant son chargement pour y détecter les instructions interdites. En particulier, les applets ne peuvent écrire sur le disque ou effacer des fichiers (ce que font la plupart des virus). Les applets sont généralement considérées comme sûres ; et comme ceci est essentiel pour bénéficier d'un système client/serveur fiable, les bugs découverts dans Java permettant la création de virus sont très rapidement corrigés (il est bon de noter que le browser renforce ces restrictions de sécurité, et que certains d'entre eux permettent de sélectionner différents niveaux de sécurité afin de permettre différents niveaux d'accès au système).
On pourrait s'interroger sur cette restriction draconienne contre les accès en écriture sur le disque local. Par exemple, on pourrait vouloir construire une base de données locale ou sauvegarder des données pour un usage futur en mode déconnecté. La vision initiale obligeait tout le monde à se connecter pour réaliser la moindre opération, mais on s'est vite rendu compte que cela était impraticable. La solution a été trouvée avec les « applets signées » qui utilisent le chiffrement avec une clef publique pour vérifier qu'une applet provient bien de là où elle dit venir. Une applet signée peut toujours endommager vos données et votre ordinateur, mais on en revient à la théorie selon laquelle la perte de l'anonymat rend le créateur de l'applet responsable de ses actes, il ne fera donc rien de préjudiciable. Java fournit un environnement pour les signatures digitales afin de permettre à une applet de sortir du périmètre de sécurité si besoin est.
Les signatures digitales ont toutefois oublié un paramètre important, qui est la vitesse à laquelle les gens bougent sur Internet. Si on télécharge un programme buggué et qu'il accomplisse ses méfaits, combien de temps se passera-t-il avant que les dommages ne soient découverts ? Cela peut se compter en jours ou en semaines. Et alors, comment retrouver le programme qui les a causés ? Et en quoi cela vous aidera à ce point ?
