Les Applettes

Présentation

Les applettes sont des programmes java (sous la forme de .class ou archivés dans des archives « .jar ») qui s’intègrent dans une page Web, de type HTML par exemple. Elles sont comparables à des applications Flash. Le programme Java est téléchargé depuis un serveur via HTTP et exécuté sur le poste client. Les applettes sont apparues dans les débuts d’Internet dans trois buts principaux :

• L’interactivité. A l’époque les pages Web se limiter tout bonnement à de simples pages HTML statiques. Les applettes ont été une des premières solutions permettant de dynamiser une page Web en affichant, par exemple, des graphiques, une vidéo, etc.
• Le second objectif a été de déléguer l’exécution du code à un client afin de répartir la charge entre le serveur et le client. Il ne faut donc pas les confondre avec les servlettes, qui elles, sont exécutées côté serveur (et ne répondent pas du tout à la même problématique).
• Enfin, le dernier objectif était d’utiliser le langage Java pour permettre l’exécution sur différents systèmes d’exploitation, mais également afin de gommer la variété des navigateurs utilisés pour surfer sur l'Internet.

Lire une applette

Pour interpréter une applette, il faut, dans un premier temps écrire une page web et insérer l'applette via une balise HTML.
Pour cela, on peut utiliser, au choix :

• <object> (valide W3C).
• <applet> (préconisée par SUN).

On remarquera que SUN et W3C n’ont pas réellement réussi à se mettre d’accord. Quoi qu'il en soit, les deux balises sont reconnues par tous les navigateurs. De plus, leur syntaxe ne change que très légèrement, il est donc aisé de passer d’une balise à l’autre.
En pratique, on utilisera intuitivement <applet>. <object> s'utilise pour obtenir un site validé par W3C ou pour bénéficier d'un mécanisme d’installation automatique d’une Machine Virtuelle Java, si celle-ci n'est pas présente sur la machine cliente.

Pour lire une applette, il faut impérativement utiliser un programme, car les applettes ne sont pas autonomes. Il faut, au choix :

• Un navigateur. C'est la méthode classique.
• AppletViewer, logiciel fourni par le JDK et accessible avec la commande : appletviewer http://localhost/MonApplet.html. Très pratique, pendant la phase de développement, pour le débogage, car il permet de s'affranchir des problèmes de mises en cache liés au navigateur. Lors d'une modification du code de l'applette, la prise en compte est assurée. Cet outil est d’ailleurs utilisé par Eclipse. En effet, cet IDE génère une page HTML puis l’interprète avec AppletViewer
• Dans les deux cas, toutes les applettes de la page HTML sont exécutées.

Ainsi, le navigateur, muni d’un interpréteur Java, va pouvoir télécharger puis exécuter l’applette à rencontre la balise <applet> ou <object>.

Voici un exemple avec <applet> :

<applet 	codebase="http://localhost:8080/Projet/" 
		archive="archive1.jar, archive2.jar" code="MonApplet.class" 
		name="A1"
		width="200" height="200">
		<param name="arg1" value="value1"/>
		<param name="arg2" value="value2"/>
</applet>

Seuls les attributs et balises les plus importants sont montrés ici :

• L’attribut « name » identifie l’applette par un nom (indispensable pour certains dialogues).
• « code » précise la classe principale à exécuter.
• L’attribut « archive » permet de lister les différents « .jar », séparés par une virgule, dont l’application dépend.
• Pour la mise en forme : les attributs classique qu’offre HTML, « width » et « height » pour respectivement la largeur et la hauteur de l’applette. Il en existe de nombreux autres comme « vspace » ou « hspace » pour l’espacement vertical et horizontal entre la balise applette et un autre conteneur HTML.
• Enfin, la balise « param » sert à passer des arguments à l’applette avec « name » le nom de l’argument et « value » la valeur.

Principe de fonctionnement

Comme nous pouvons le voir, le principe de fonctionnement d'une applette est relativement simple.

Créer une applette

Pour créer une applette, il faut créer un programme Java donc la classe principale hérite de l’objet Applet ou JApplet. Cette classe principale est celle dans laquelle il aurait fallu implémenter la méthode public static void main() pour une application java classique.

Il faut ensuite redéfinir quatre méthodes qui, par défaut, ne font rien :

• init(), invoquée lorsque l’applette est chargée pour la première fois. C’est dans cette méthode que l’initialisation de la classe s'écrit, et pas dans le constructeur.
• start(), appelée lorsque l’applette est visible.
• stop(), losqu'elle n'est plus visible (iconification de l'applette).
• destroy(), appelée lorsque l’utilisateur ferme la page contenant l'applette. Il est donc possible, très facilement, de lancer certains traitements avant la destruction de l’applette.

Ces méthodes sont appelées par le programme qui interprète l’applette (soit appletviewer, soit le navigateur) et définissent le cycle de vie de l’applette.

AppletViewer respecte ce cycle de vie. Il exécute dans l’ordre la méthode init(). Pendant l’exécution, il alterne entre les méthodes start() et stop() lorsque l’applette est visible ou non, puis finit avec destroy().
En revanche, dans les navigateurs récents (firefox 3 ou ie7), ce cycle de vie a légèrement changé sans réelle explication. A chaque fois que l’applette devient visible, les méthodes init() et start() sont exécutées. Lorsqu'elle est invisble les deux méthodes stop() et destroy() sont invoquées. Il n’est donc plus vraiment utile de redéfinir les quatre méthodes, deux peuvent suffire (init() et destroy()).

Bien entendu, il existe d’autres méthodes à redéfinir telles que paint() qui permet de dessiner directement dans l’applette. Ceci est possible du fait que l’objet Applet hérite lui-même de l’objet Panel.

Voici la structure d'une applette :

	public class MyFirstApplet extends Applet {	
		@Override 
			public void init() {…}
		@Override 
			public void start() {…}
		@Override 
			public void stop() {…}
		@Override 
			public void destroy() {…}
		@Override 
			public void paint() {…}
	}
	

Différents dialogues possibles

Du fait qu’elles soient intégrées dans une page HTML, les applettes peuvent effectuer plusieurs dialogues :

• Avec d’autres applettes d’une même page en invoquant getAppletContent(). Cette méthode récupère une applette par son nom, définit par l’attribut « name ».
• Depuis javascript il est possible d'appeler des méthodes Java contenues dans l’applette. Pour cela, il faut récupèrer l’applette par son nom, définie par l’attribut « name », (mais cette fois-ci en Javascript). Dès lors, il est possible d'exécuter une méthode publique de l’applette.
• L’inverse est également possible. A partir de l’applette, l'appel de méthodes Javascript est réalisable. Par contre, dans ce sens c’est un peu plus compliqué. Il faut spécifier l’attribut mayscript="true" lors de la déclaration de l'applette. Côté Java, il faut importer l’archive « plugin.jar » présente dans la JRE, puis utiliser l’objet JSOBject et sa méthode call().
• Enfin, les applettes peuvent dialoguer avec des machines distantes à la manière de JavaScript combiné avec de l’Ajax. Ce dialogue nécessite d'ouvrir une connexion avec l’objet URLConnection puis d'utiliser, par exemple, les objets ObjectInputStream ou ObjectOutputStream pour envoyer ou recevoir des objets Java.

Voici une petite démonstration montrant les trois premiers dialogues :

Applette 1	Applette 2	Commentaires
		Dialogue Javascript -> Applette Switch color Applet 1 permet de changer dynamiquement la couleur de l'applette 1 en générant trois nombres pour les couleurs R (Red) - G (Green) - B (Blue). Dialogue Applette -> Javascript Call Javascript est un bouton Java qui exécute une fonction javascript pour afficher la couleur de l'applette 1 (au format RGB) et la transmettre à la page HTML. Dialogue Applette -> Applette Call Applet 2 transmet la couleur de l'applette 1 à l'applette 2.

Pour tester la démo, commencez par appuyer sur le bouton Switch color Applet 1 situé en bas du tableau :

Sécurité

Nous avons vu ce que l’applette peut faire, nous allons maintenant voir ce qu’elle ne peut pas faire. En effet, par défaut, le comportement de l’applette est bridé. Le but est d'assurer, aux clients, une exécution sécurisée et de leur éviter, par exemple, l’intrusion de virus. Ces limitations sont de la reponsabilité de la « sandbox », ou « bac à sable », qui oblige l’applette à s’exécuter dans un environnement restreint. Ainsi, elle ne peut pas :

• Accèder aux fichiers (même pas en lecture) ni aux périphériques du client.
• Exécuter une commande système.
• Etablir une connexion réseau sauf avec le serveur qui l’héberge.
• Etc.

La sandbox lève une SecurityException, dès qu'une applette souhaite réaliser l'une de ces opérations.

Cependant, ces restrictions peuvent être gênantes lorsqu'un programme a besoin de ces accès pour son fonctionnement (sauvegarde de fichiers côté client, impression, etc.). Il existe pour cela deux solutions. La première consiste à modifier les politiques de sécurité du client. La seconde consiste à signer numériquement l’application.

Les politiques de sécurité

Le but des politiques de sécurité est d’étendre les droits d’une applette particulière ou d'un ensemble d'applettes.
Pour cela, il suffit d’éditer un fichier sur la machine cliente. Ce fichier peut être écrit à la main ou, graphiquement, grâce à l'outil policytool disponible dans les JRE. Voici un exemple d'une politique de sécurité écrite dans le fichier « mypolicy » :

	grant codeBase "http://localhost:8080/AppletServlet/MstscNS.jar" {
		  permission java.io.FilePermission "c:\\windows\\system32\\mstsc.exe", "execute";  
	};
	

Dans ce cas, l'applette dont le codeBase est « http://localhost:8080/AppletServlet/MstscNS.jar », acquiert l'autorisation d'exécuter le programme MSTSC.exe.
La prise en compte de cette nouvelle politique de sécurité peut alors s'effectuer de deux manières différentes :

• Avec « appletviewer », il suffit de passer en argument la nouvelle politique de sécurité.
  • appletviewer –H-Djava.security.policy=« mypolicy » http://.../file.html
• Pour être prise en compte par le navigateur, il faut impérativement nommer le fichier « .java.policy » et le placer dans le répertoire de l’utilisateur du client : {USER.HOME}/.java.policy.

Cette première méthode est idéale pour un réseau local d’entreprise dans lequel il est envisageable de modifier la politique de sécurité par défaut. L'autre avantage, non négligeable, est d'avoir une gestion fine des permissions (autoriser l'exécution d'un programme pour une applette donnée, etc.).

La signature numérique

Une autre méthode pour lever les interdictions consiste à signer numériquement l’applette. Cette solution nécessite la réalisation de trois étapes :

• Archiver l’application sous la forme d’un ou plusieurs « .jar ».
• Créer un certificat avec l’outil keytool outil fournit par le JDK
  • keytool -genkey -keystore myKeystore.ks -alias mykey
• Signer numériquement les archives avec le certificat précédemment généré, à l’aide de l’outil jarsigner également contenu dans le JDK.
  • jarsigner –keystore myKeystore.ks myappli.jar mykey

Une fois l'applette signée, son exécution affiche un message d'alerte demandant à l’utilisateur s'il souhaite ou non l'exécuter. S’il accepte, l’applette sort de la « sandbox » et bénéficie de tous les droits (lecture et écriture de fichiers, accès aux périphériques, etc.).

Cette méthode convient parfaitement dès lors qu'il n'est pas possible de modifier les politiques de sécurité de la machine cliente. De plus, la signature numérique utilise un système de clés asymétriques et de hachage des données. Ainsi, elle assure que les données transmises n'ont pas été modifiées ou altérées durant le transfert (vérification de l'intégrité), mais également que les données proviennent bien de l'émetteur que l'on pense (non-répudiation). Cependant, cette technique a le défaut de ne pas permettre une gestion fine des permissions. Il faut donc être vigilant quant à la provenance d'une applette signée puisque celle-ci n'a aucune restriction.

Conclusion

En conclusion, je vais citer quelques avantages des applettes :

• Technologie mature : elle existe depuis plus d'une dizaine d’années maintenant.
• S’intègre facilement dans une application Web existante, puiqu'il n'y a qu'une seule référence à ajouter : la balise <applet>.
• Permet de s’affranchir des limitations de HTML : en codant en Java, le développeur bénéficie d’une bibliothèque très riche en API.

Enfin, les applettes ne sont pas mortes. En effet, nous risquons de voir les applettes encore quelques années avec l'arrivée de JavaFX.

Java Web Start & Les Applettes

• Accueil

Java Web Start

• Présentation
• Avantages
• Déployer une application
• Principe de fonctionnement
• Le fichier JNLP
• Lancer une application JWS
• Le gestionnaire d'application
• Sécurité
• Conclusion

Les Applettes

• Présentation
• Lire une applette
• Créer une applette
• Principe de fonctionnement
• Différents dialogues possibles
• Sécurité
• Conclusion