I.T. aware

Pour résumer rapidement, après le client lourd où l’applicatif se voyait dupliqué sur chaque poste client, on est passé au client léger où l’applicatif se situe en grande partie sur un serveur d’applications et facilite le déploiement et la maintenance.
Cependant le client léger a été critiqué par les utilisateurs pour son manque d’interaction avec les outils du bureau (en particulier l’Office suite) et sa dépendance au réseau lié au HTML et au principe d’HTTP. Est donc apparu le client riche qui redonne aux utilisateurs des interfaces plus ergonomique et moins dépendante du réseau. L’intelligence logicielle est maintenant répartie équitablement entre le client et le serveur.
Le schéma ci-dessous illustre cette évolution :

Un nouveau concept implique un nouvel acronyme : le RIA pour Rich Internet Application. Utilisé à tout va celui-ci mérite d’être plus clairement défini. Le schéma ci-dessous propose donc de décomposer le RIA en 2 sous ensembles : les RDA pour Rich Desktop Applications (pour les applications orientées bureau, exécutées sur le client et non dans un navigateur Web) et les RWA pour Rich Web Applications (pour les applications orientées Web déployées à travers le navigateur).

Pour aller plus loin, comme le montre le schéma, les deux sous ensembles peuvent être étendus vers la notion de « plate-forme » qui propose de faciliter le développement d’applications en utilisant une base commune, modulable, avec des fonctionnalités classiques (menu, splashscreen, vue, …). Les exemples cités dans le schéma ne sont pas exhaustif et il serait intéressant d’en faire une liste plus compléte.

La question qui se pose est maintenant de savoir laquelle des deux branches, desktop ou web, choisir pour développer son application. Le problème du déploiement (qui a fait le succès du client léger) se pose toujours pour les applications desktop. Encore qu’il n’en est pas un pour les applications Java depuis l’arrivée de Java Web Start. Coté Microsoft et Macromédia la question se pose différemment, WPF/e et Flex permettent de diffuser les applications via un plugin dans le navigateur mais on ne parle plus alors de RDA.
La frontière entre RDA et RWA n’est donc pas toujours évidente. Si l’on prend l’exemple de Firefox et XUL on a un navigateur qui offre des fonctionnalités desktop, comme le ferait une application Eclipse RCP qui inclue un navigateur. Inversement une application Flex n’est liée au navigateur que par le plugin, l’interaction avec celui-ci reste possible mais les composants restent eux totalement indépendants du navigateur. Ce qui nous amène alors au concept de RSP (Rich Server Platform) qui propose de combiner navigateur et desktop en une seule et même application.

D’autre part pour le concept RIA l’architecture applicative à 5 couches reste d’actualité mais elle doit évoluer pour prendre en compte les spécificités du client riche et plus particulièrement pour le RDA.

Les couches application et entreprise doivent se scinder en 2 pour séparer ce qui concerne la partie serveur de la partie cliente. Entre cette séparation viens se glisser la couche de communication. C’est dans cette couche que les services web trouvent leur place mais pas seulement eux. Parmis les framework qui implémente cette couche il faut citer WebObjects EODistribution, Cayenne, Spring remoting. On constate que ces exemples n’utilisent pas les services web, il y a donc d’autres alternatives, c’est d’ailleurs le choix de Microsoft à travers WCF qui se veut être un framework d’échange complet, i.e. pas seulement basé sur les services web mais sur toutes les formes de communications possibles (WCF représente environ 70% de .NET 3.0).
Cette approche est moins vrai pour le RWA car aujourd’hui aucun framework Javascript n’offre la possibilité de mettre en oeuvre des couches, mais cela peut évoluer…

Bref tout cela ne m’aide pas à répondre à ma question, quelle branche choisir ? Le client riche a des avantages ergonomiques et de fonctionnalités au niveau du client, mais les technologies pour le mettre en oeuvre sont nombreuses et pas toujours concurrentes. Il nous faudrait définir une échelle de valeur qui donne en fonction de besoins la technologie, ou du moins la branche la mieux adaptée.

To resume quickly, after the old client/server model where the software was duplicated on each client we passed to the thin client where the software was concentrated on the applications server and make easier deployment and support. But thin client have been criticized by users for the lack of interaction with desktop tools (particulary with the Office suite) and the dependence with the network because of HTML and HTTP. Then the rich client appear : it gives to users better ergonomy and less dependency to the network. The software intelligence is now fairly shared between server and client. The underneath diagram presents this evolution :

Then a new acronym is dedicated for the rich client : RIA. This concept is used a lot and i think have to be more clearly defined. The underneath diagram suggest a decomposition of RIA in 2 subgroup : the RDA (Rich Desktop Applications for oriented desktop applications, executed on the client without a browser) and the RWA (Rich Web Applications for web oriented applications executed in a browser).

This 2 subgroup could be extended to platform concept which suggest to help developers create applications with a pre initialized application and a lot of basics and utils components pluggable like help, preferences, splashscreen, view, …

The question is now which branch i have to choose between desktop or web to develop my application. The still problem is the deployment for desktop application, it have been the success of thin client where no deployment is needed (if you have a browser installed ). It’s not a problem now for Java because of the Java Web Start, for Microsoft and Micromedia the question is different and they suggest to use the browser with the dedicated plugin for WPF/e and Flex but is it really RDA ?
So the frontier between RDA and RWA is not always obvious. In one hand with Firefox/XUL we have a browser where desktop components can be added, in other hand a Flex application is linked to the browser only by the plugin, the interaction is possible but the Flex components are detached of the browser.
It bring us to the RSP (Rich Server Platform) concept which suggest to combine browser and desktop in the same application.

In thie RIA concept the 5 layers software architecture is always aware but have to evolve to take care of rich client features in particularly for RDA.

Application and enterprise layer have to be separate in 2 part : one for the server another for the client. Between this separation a new layer appear for the communication. It’s in this layer web services is used but not only them. Among of frameworks implementing this layer there are WebObjects EODistribution, Cayenne, Spring remoting. They don’t use web services so there is others alternatives. It’s Microsoft choice with WCF which integrate more exchange possibility (WCF represent 70% of the .NET 3.0).
This new approach of architecture not really concern RWA because there is no Javascript framework could integrate this, but it can change …

Well, all of this don’t help me to answer to my question, which branch between desktop or web i have to choose ? The rich client is a real evolution for the client side but there is a lot of technology to implement it and not always concurrent. Maybe we have to define which technology or branch is appropriate for a set of needs.

Nothing new than the Prague’s session in november. I went a new time to see James Gosling, we can’t see him very often in france. His presentation wasn’t really wonderful but its interesting to have his viewpoint of actually java technology. I took the opportunity to see the session i missed last time in particular JavaDB after i have seen the François Orsini’s demo. The use of JavaDB is very interesting, the demo was on a web application and i hope i can migrate my desktop application with this techno to have now a real rich client application which integrate a disconnected mode. So, to be continued …

Rien de neuf par rapport à la session de Prague de Novembre. J’y suis quand même allé pour voir James Gosling, c’est pas tous les jours qu’on à la chance de pouvoir voir le pére de Java. Sa présentation était pas transcendante mais c’était intéressant de voir sa vision de Java aujourd’hui. J’en ai profité pour récupérer quelques sessions que j’avais pas vu notamment celle de JavaDB aprés voir vu la démo de François Orsini. L’utilisation de JavaDB pour le mode déconnecté est trés intéressante, la démo était avec une application Web et j’espère bientôt pouvoir migrer mon application desktop avec cette techno pour avoir une vraie application client riche orientée desktop avec gestion du mode déconnecté. A suivre donc …

Firebug became a necessary tool for the development of javascript “rich” components. Regrettably its use is limited to firefox. To offer a reduced service with the other browsers the team of firebug released Firebug Lite, a competition of the famous console. I have just tested its integration in Rialto. The first report is that the script is very simple and that the offered features are well thought. You can use 4 kind of messages (log, info, warm and error) but also some more as console.time and console.timeEnd which allow to measure the execution time of a block of script. You can also display all the properties of an object with the function console.dir or the contents of a node with the function console.dirxml.

An input text also allows to evaluate any javascript expression. Usefull to check the properties of your objects.

Firebug est devenu un outils indispensable pour le développement de composants “riches” en javascript. Malheureusement son utilisation se limite à firefox. Pour offrir un service minimum dans d’autres navigateurs l’équipe de firebug propose Firebug Lite, une émulation de la célèbre console. Je viens de tester son intégration dans Rialto. Le premier constat est que le script est très simple et que les fonctionnalités offertes sont bien pensées. On retrouve les 4 types de messages (log,info,warm et error) mais aussi des petits plus comme les console.time et console.timeEnd qui permettent de mesurer le temps d’exécution d’un bloc de script. On peut également afficher l’ensemble des propriétés d’un objet avec la fonction console.dir ou le contenu d’un noeud avec la fonction console.dirxml

Un champs texte permet également d’évaluer n’importe quelle expression javascript. Pratique pour vérifier les propriétés de vos objets.

Robert Cooper and Josh Marinacci just reveal their AB5k project. A “widget container”, like we can see now on Vista and had already on MacOSX, to integrate on our desktop a calendar, the weather of the day, last news of the world … In Java 6 and cross-platform.

Robert Cooper et Josh Marinacci viennent de dévoiler leur projet AB5k. Un “widget container” à l’image de ce que l’on a maintenant sur Vista et ce que l’on avait déjà sur MacOSX pour intégrer sur son bureau un calendrier, la meteo du jour, les dernière nouvelles du monde, …. En Java 6 et donc multi plates-formes.

Les 8 et 9 Mars s’est tenu la conférence Desktop Matters qui relate des applications orientées desktop en Java. A première vue Eclipse n’y est pas trés présent (normal l’EclipseCon se tenait au même moment) et c’est plutôt Swing qui a été évoqué. Le résumé des sessions est à suivre sur le blog de Ben Galbraith. A noter :

• 1/3 du code de JIDE devrait passer en open-source
• Nimbus : le futur Java Desktop System de Sun
• Présentation de SwingLabs

8/9 March was Desktop Matters conference, talked about Java Desktop Applications. Eclipse was not very promote (of course it was the EclipseCon at the same time) and Swing was more mentionned. The sessions summary are on the Ben Galbraith’s blog. Be noted :

• JIDE is open-sourcing about a 1/3 of their code
• Nimbus : the future Sun’s Java Desktop System
• SwingLabs presentation