Les programmes ont trouvé leur modèle

Délaissé par les éditeurs et les utilisateurs au profit du client léger, c'est à dire un pur site Internet, le client riche (ou client lourd) revient en force. Et ce, pour plusieurs raisons: besoins d'interactivité, nécessité de traitement et d'une interface complexe, et de tirer avantage des nouveaux langages et environnements. Le client riche s'oppose au client léger en HTML, en dépassant les limites du langage web par excellence.

Le client riche n'a de sens que dans le cadre d'un intra ou extranet, il concerne uniquement les programmes d'entreprises et non le site Internet proprement dit que tout utilisateur peut aller visite Internet. Dans ce cas, on utilisera plutôt du Rich Media, avec un soupçon de client riche au niveau interface et interactivité Client - Serveur web. Le risque du client lourd est de fournir une programme difficile à utiliser, d'un coût élevé et finalement, inefficace.

XML et les dérivés ont su dépasser les clients légers basés sur HTML. Même si le client HTML a l'avantage d'être déployable rapidement et partout, il demeure peu convivial et limité.

À l'inverse, le client riche traîne depuis longtemps un coût de déploiement élevé et un besoin en bande passante conséquente. Quand on fait du client riche (et même du Rich Media) mieux vaut s'appuyer sur les players et runtime clients en principe présents sur le poste de l'utilisateur, ou alors qui nécessitent le minimum de téléchargement. Ce socle technique permet de réduire le poids du client riche car, dès lors, les composants du poste client possèdent les fonctions de base du client riche. Le problème est de choisir sa ou ses technologies. Ainsi, pour la description d'interface, les dérivés XML propriétaires ne manquent pas : XUL, XAML, MXML, XDP, etc.

Pour le moment, XUL et MXML se détachent, car ils sont disponibles. XUL est issu de Mozilla et sert déjà dans Firefox. Il peut travailler avec ASP, PHP, Perl, JSP, etc.

Dans le monde Java, on dispose désormais d'un socle client riche fiable et reconnu : Eclipse Rich Client Platform. Tout est conçu pour être le plus léger possible. Il s'installe d'un clic sur le poste de l'utilisateur. Attention tout de même à la dépendance technologique et aux incompatibilités du client riche, si vous êtes en environnement hétérogène. Dans ce cas, utilisez une technologie de type Flash / Flex, java, ou purement XML (CSS, xHTML, Xforms, etc.).

Java web start

II s'agit d'une plate-forme Java facilitant le déploiement d'application, basée sur les technologies serveur webs Web Java. Il fonctionne avec l'ensemble des navigateurs du marché et permet aux utilisateurs de lancer des programmes en toute transparence.

Cependant, quand on utilise une nouvelle programme, on clique sur un lien URL d'une page permettant de déployer l'programme sur son poste (l'programme se télécharge, ex : <a href="/products/java-webstart/docs/MyApp.jnlp">Launch My Programme</a>).

Java web start vérifie à chaque lancement si l'application a été mise à jour. Il s'appuie sur JNPL (attention à la configuration du serveur web pour te fichier .jnpl, le type MIME est : programme/x-java-jnlp-file, le serveur web renvoyant le MIME adéquat afin de reconnaître les fichiers jnpl). Pour pouvoir créer un client riche Java Web start, vous devez implémenter JNPL.

Sur le poste client, Java Web Start joue le rôle d'un lanceur d'applications. Une programme de ce type doit être dans un JAR et contenir l'ensemble des ressources. Java web start transfère uniquement un fichier Jar du serveur web au client. Grâce à un fonctionnement sandbox (= exécution limitée), l'programme aura un accès limité au poste client. Bref, le modèle de développement Java ne change pas, mais l'utilisation d'une programme Java est facilitée pour le client. Il est possible de vérifier si le lanceur est déjà présent ou non. Il suffit de passer par un script JavaScript ou VbScript. Exemple d'une détection Java Web Start dans une page HTML :

<SCRIPT LANGUAGE=nJavascriptn> var javawslnstalled = 0; isIE = "false";
if (navigator.mimeTypes && navigator.mimeTypes.length) { x = navigator.mimeTypes['programme/x-java-jnlp-file']; if (x) javawslnstalled = 1 ;
}else{ isIE = "true";}
fonction insertLink(url, name) { if (javawslnstalled) {
document.write("<a href=" + url + ">"  + name + "</a>"); } else { document.writef'Need to install Java Web Start");
</SCRIPT>

S'il convient aux intra, extranet, programmes C/S d'entreprise, Java Web Start n'est guère approprié aux utilisateurs lambda, mieux vaut passer par des solutions transparentes de type Flash. Si vous utilisez java Web Start en environnement hétérogène sur le poste client, n'oubliez pas de tester le fonctionnement avant tout déploiement. À noter qu'il est possible d'utiliser JNLP dans une archive de type WAR.

En complément : http://java.sun.com/products/javawebstart/index.jsp

FLEX

Flexpiex est un serveur web de présentation, cela ne veut pas dire qu'il permet de faire des PowerPoint, mais plutôt qu'il se situe dans la couche présentation d'une architecture N-Tiers.

En fait, il reprend le modèle d'exécution des pages ASP ou des pages jSP, c'est-à-dire qu'il apparaît en front, afin de mettre en forme des informations venant des composants métiers se trouvant en arrière de l'programme. Seulement, contrairement aux pages jSP ou ASP, Flex intervient sur la mise en forme des informations afin de les envoyer au client au format Flash. Il se positionne en complément d'un serveur web d'application J2EE ou .Net qui, eux, sont présents pour faire la couche Métier de l'programme, et permet d'ajouter une couche applicative pour communiquer avec le Flash envoyé au client. Ainsi le serveur web d'application .Net ou J2EE envoie les informations à Flex qui les transforme et les envoie à Flash.

On aurait deux fichiers, un MXML représentant l'interface et un fichier représentant la mise en forme des informations. Se basant sur Action Script 2.0 et MXML, le développement de Flex reprend des standards et des modèles de développement connu par les programmeurs Flash. Flex Builder permet d'améliorer grandement la productivité.

De plus, à ce serveur web de présentation vient s'ajouter un framework d'utilisation de la plate-forme. Ce framework est composé d'un ensemble de classes permettant de faciliter le développement des programmes. Parmi ces classes, on retrouve des classes permettant de mettre en place des composants sur l'interface utilisateur, mais aussi quelques classes permettant de calculer des règles métier.

Les avantages de Flex sont les suivants : il tourne sur un grand nombre de configurations logiciel (linux, Windows, Unix), il permet la mise en place rapide d'interfaces utilisateur puissantes au format Flash, et le modèle de développement est simple et rapide à mettre en place.

Flex se fait en utilisant un nouveau langage, le MXML. Sorti avant le XAML de Microsoft, le MXML permet de faire une description de l'interface utilisateur au format XML à l'aide de balises spéciales qui font partie du schéma MXML. Ainsi, la séparation de code client riche/serveur web se fait exactement de la même manière qu'elle se ferait en ASP.Net avec le HTML et le code C#.

L'inconvénient majeur est qu'il faut que le client ait au moins la version 7 du player Flash, ce qui restreint la pénétration côté client, même si quelque soit le client, IE6, firefox ou Netscape, le résultat sera identique, sans décalage dans la présentation.

En conclusion, Flex est à Flash ce qu'ASP.Net et J2EE sont au HTML.

La Nouvelle Génération d’interfaces : exemple de XUL

Si le navigateur est la plate-forme (l'occurrence FireFox) il est par exemple possible d'exécuter une programme complexe client / serveur web sans rien installer.

Cette programme, qui pourrait être qualifie de "Thin Client" (si tous les utilisateurs étaient équipés de Firefox) est exécutable telle quelle, de suite. Et ce miracle est dû à XUL (XML User Interface Language, prononcez "zool"). Nous invitons les sceptiques à exécuter l'programme de démonstration "Mozilla Amazon Browser" sous FireFox ou Mozilla. De plus en plus de développeurs choisissent, soit le binôme client /serveur web Mozilla-XUL/PHP, soit Mozilla-XUL/Java.

L'inconvénient majeur de XUL est qu'il ne peut s'exécuter sous Internet Explorer, mais depuis peu il est devenu possible de télécharger des exécutables autonomes via XulRunner. Il s'agit d'une plate-forme "standalone" d'exécution de programme, avec lequelle l'utilisateur peut se passer de Firefox pour exécuter un logiciel XUL !

 Mieux : des versions ont été compilées avec le support activé de SVG (Scalable Vector Graphics)! Des projets sont en développement pour créer des IDE XUL, comme XulMaker, XCUBE ou MozCreator. Concrètement cela donnera quelque chose comme ceci : #xulrunner MonAppli.ini

Vous trouverez sur le site Internet de XulRunner le code source complet d'un programme nommé « mybrowser » qui comme son nom l’indique permet de naviguer.

LES PLUS

•  Sous licence Mozilla, compatible avec HTML, XHTML, XSLT, CSS2, DOM2
•  Pas besoin d'IDE lourds
•  Documentation développeur traduite en français
•  Multi-plate-forme
•  Si l'programme est livrée sous forme de package Xpi (qui peut-être signé pour plus de sécurité), son installation se réalise d'un simple clic (mais avec un redémarrage du navigateur nécessaire)

LES MOINS

•  Incompatible avec XAML de Microsoft
•  Courbe   d'apprentissage   lente  si   développeur débutant
•  Pas d'IDE de développement stable et fiable pour créer rapidement des écrans XUL

ASP.Net

L'apparition de contrôles serveur webs tels les RequiredFieldValîdator,
RegularExpressionValidator, embarquant leurs propres scripts de validation, permet maintenant au développeur de se détacher de ces tâches auparavant fastidieuses et souvent laborieuses.

L'apparition de .NET 1.0 a donc été un soulagement pour bon nombre de développeurs et de sociétés pour qui l'interfaçage client riche n'était pas obligatoirement productif et rentable. Force est de constater que ce n'est pas à l'évidence la bonne solution, car une grande partie des processus qui sont maintenant déportés côté serveur web s'effectuait auparavant avec quelques lignes de scripts côté client et ce, sans rechargement de la page.

L'arrivée du Framework .Net a donc été annoncée par certains comme la mort du JavaScript et des interfaçages clients riches. Cependant, on est bien loin de la fin du ClientSide qui est la clé de la réussite Internet d'une bonne interaction avec l'utilisateur final.

Bon nombre de sociétés l'ont compris et se sont spécialisées dans la création de contrôles serveur webs riches, embarquant css, javascript et .Net, afin de mettre à la disposition des développeurs des outils paramétrables ne nécessitant aucune connaissance particulière dans le scripting client.

Microsoft est sûrement l'une de celles-ci lorsque l'on voit des programmes web du type WebOutlook sous Exchange, WSS (Windows Sharepoint Services) et SPS (Sharepoint Portai Server), ou encore les Blogs MSN Space. Preuve que le ClientSide est bien une des clés de la réussite Internet de votre projet. L'arrivée de .NET 2.0 est une avancée quant à la mise en avant des clients riches.

Cette nouvelle mouture inclut de nouveaux contrôles serveur webs intégrant leurs propres fonctionnalités clientes, comme le Menu dynamique, le WebPart Catalog qui permettra à l'utilisateur final de paramétrer sa mise en page par simple " glis-ser-déplacer ", le gestionnaire de Skins qui permettra la modification visuelle d'une interface en quelques clics, ou encore le ClientCallBack qui permettra de ne recharger qu'une partie d'une page. Ceci est donc prometteur pour l'avenir et l'apparition de définitions comme XAML nous laisse présager l'arrivée d'une plate-forme .Net ne se souciant plus du type de présentation de votre projet (webform ou winform), mais plutôt de l'interaction riche avec l'utilisateur final.