I.T. aware

Je ne vous ferais pas le résumé de cette intéressante conférence qu’était les rencontres Spring, LeTouilleur l’a déjà très bien fait. J’en profite juste pour revenir sur quelques points et notamment la place de Spring dans la communauté française.

Spring n’est pourtant pas le seul conteneur léger de IoC alors pourquoi celui-ci plutôt qu’un autre (Hivemind, Guice, …). Pour ces projets annexes (Security, MVC, WebFlow, …) ? pas vraiment je pense mais plutôt grâce à une forte communauté et un bon évangéliste. Le succès d’un projet open source n’est lié qu’à la taille de sa communauté qui grandit si ses créateurs font une bonne promotion et savent créer un effet de mode. Les développeurs n’adhèrent pas par comparaison avec d’autres frameworks et en jugeant du meilleur (ils n’ont malheureusement pas le temps de faire ça), ils s’orientent vers celui qui est le plus en vogue et pour lequel ils trouveront une reconnaissance soit dans leur travail soit au sein de la communauté.

Il est possible de faire la même chose que Spring dans J2EE nous dis Didier. Si c’est possible c’est très récent ou en projet. Spring voit justement son succès dans les manques de J2EE en terme de mis en en oeuvre du pattern IoC, de l’AOP et de prise en compte de OSGi. Improve Foundation est d’ailleurs un bel exemple de mise en oeuvre d’un framework venant combler les manques de J2EE. Fruit de l’experience des développeurs et de la capitalisation des différentes techniques mise en oeuvre au cours des projets, Improve Foundation aurait pu avoir la même histoire que Spring. Les objectifs des deux frameworks sont au départ les mêmes et tous deux implémentent le pattern IoC. Mais l’un est open source et pas l’autre et les stratégies des sociétés mères ne sont pas les mêmes. Au final Improve Foundation se concentre plus sur les besoins des clients et se focalisent sur la facilité de mise en oeuvre et d’adhésion par les équipes informatiques des SI alors que Sring innove et implémente de nouvelles technologies. Aujourd’hui le coeur IoC de Improve Foundation est remplacé par celui de Spring pour bénéficier des avancées technologiques. Ce fut d’ailleurs un projet open source : KISS framework dont le commiteur principal était Thierry Templier (co-autheur de la deuxième édition du livre français sur Spring et commiteur Spring) mais aujourd’hui abandonné pour être intégré pleinement dans l’offre Improve Foundations.

Spring en tant que tel ne répond pas au besoin des SI où les DSI cherchent des solutions sur 10 ans accessibles à des dévelopeurs de base. En masquant la complexité de Spring, Improve Foundation a une approche qui répond aux attentes des DSI, j’en ai pour preuves les récents succès : Atos Origin, Renault, RSI qui utiliseront maintenant Improve Foundations comme socle technique de tous leur projets. Mais les architectes sont plus durs à convaincre, avec leur âmes de développeurs ils ne veulent pas voir leur échapper la responsabilité de la mise en oeuvre d’une nouvelle technologie qui leur est chère, et bien que cela soit tout à leur honneur ce n’est pas la bonne stratégie.

Spring a de beaux jours devant lui avec sa forte communauté mais sa perennité est mise en jeu si il ne trouve pas des clients pour prendre du support. Or cette démarche, classique aux US, a du mal à se mettre en place en France et ce sont les intégrateurs qui font le support de Spring à la place de SpringSource. Le rapprochement avec des sociétés françaises est donc une nécessité, SpringSource a déjà commencé à investir dans cette voie et c’est la bonne démarche. Aux architectes aussi de s’intéresser à ces intermédiaires pour pouvoir plus se concentrer sur le métier de leur activité et non maintenir un framework.

Les journées de l’utilisabilité organisées par Fred Cavazza pour Paris ont été l’occasion d’aborder les thèmes importants des applications riches. Des présentations intéressantes qui m’ont conforté dans ma vision du RIA et notamment de la relation développeur/graphiste/ergonome/utilisateur.
Ce que j’en retient :
Lire la suite »

To implement the pattern singleton in action script we quickly collide with a limitation of the language: we cannot return a private constructor and it is the base of the pattern.
By looking on internet we find several more or less evolved solutions which allow to protect the usage of the constructor.Often an exception is raised if it is not called by the static getInstance method.
The inconvenience of this approach is that the error is raise only during runtime and not in the compilation. In the book “ActionScript 3.0 Design Patterns” the author proposes another approach.
Lire la suite »

Pour implémenter le pattern singleton en action script on se heurte rapidement à une limitation du langage: on ne peut pas rendre un constructeur privé or il s’agit de la base du pattern. En regardant sur internet on trouve plusieurs solutions plus ou moins évoluées qui permettent de protéger l’usage du constructeur. Souvent une exception est levée si le constructeur n’est pas invoqué par la méthode static getInstance. L’inconvénient de cette approche est que l’erreur est visible uniquement à l’exécution et non à la compilation. Dans le livre “ActionScript 3.0 Design Patterns” l’auteur propose une autre approche.
Lire la suite »

Le Paris JUG était cette fois ci consacré à GWT et à l’implémentation de Restlet pour GWT. Deux présentations rondement menée par Didier Girard et Jerome Louvel. J’ai été impressionné par le nombre de participant, pensant que GWT était déjà dans les moeurs. Bravo à Didier de continuer à promouvoir cette technologie innovante et à Jérôme d’y apporter le concept REST.
Reste que je m’étonne de la vision que les gens ont du RIA. Pour beaucoup j’ai l’impression que RIA veut dire application web riche. Or la notion de “riche” est simplement une reconsidération de l’expérience utilisateur et cela ne passe pas obligatoirement par le navigateur. GWT, Ajax, AppletFX, Flex ou Silverlight n’ont pas le monopole du RIA simplement parce qu’ils s’exécutent dans un navigateur.
Javascript a permis de dépasser les limites de HTML dans le navigateur et a donné une nouvelle dimension aux applications web. Le navigateur devient maintenant un runtime Javascript et utilise comme bibliothèque graphique le HTML. Comme Java avec Swing, C# avec WPF ou Silverlight, AS3 avec Flash et Flex.
iTunes est surement une des premières RIA et ce n’est pas une application web. Comme je le disais déjà il faut simplement différencier Rich Web Application et Rich Desktop Application. Une RWA s’éxecute dans le navigateur, une RDA s’éxecute dans un OS.
Il y a avantages et inconvénients dans les deux approches mais la diffusion et la maintenance qui ont longtemps été les points forts des applications web ne sont plus vrais aujourd’hui.
Comme vous ne vous étonnez plus d’avoir votre Windows automatiquement mis à jour il est aujourd’hui tout à fait possible pour une RDA d’être diffusée et maintenu via le Web. Java Web Start en est un bel exemple et Adobe AIR sait le faire aussi. Mais vous me direz que pour faire tourner du Java ou du Air il faut installer respectivement la JVM et le runtime AIR. Oui c’est vrai comme récemment vous avez installé Chrome ou il y a plus longtemps Firefox. La différence se fait avec Windows qui embarque son navigateur IE et que dès lors que vous achetez un PC en Windows vous l’avez. A un moment donné on installe un runtime et a moins d’être terriblement fainéant personne n’est obligé de se contenter de Windows/IE.
La où il faut être vigilant avec une RDA c’est de ne pas retomber dans l’ancien modèle client/serveur. La RDA doit rester une couche client et ne pas embarquer de métier qui lui doit toujours se trouver coté serveur.
Apple avait déjà expérimenté cela intelligemment avec WebObjects Java Client et continue aujourd’hui à proposer des API similaires pour Cocoa et maintenant IPhone SDK.
Au slogan “the browser is the platform” je réponds “the browser is a platform”. Les architectures de demain ne doivent pas être dépendantes de la couche client car celle-ci doit être développée dans la meilleure technologie pour répondre aux objectifs de l’application et du besoin client en privilégiant ergonomie et performance.
Notre application ResUrgences est en mode web depuis 8 ans maintenant dans un secteur (la santé) ou les applications sont souvent du client/serveur. Pourtant son extension du service d’urgences au SMUR nous oblige à reconsidérer le web car l’utilisation d’une application web sur tablette pc en mode déconnecté, bien que pas impossible, n’est pas adaptée. Notamment quant il s’agit de s’interconnecter avec du matériel de monitoring et d’électro-cardiogramme.
Alors quel choix faire entre RWA et RDA ? La première étape c’est de penser RIA, donc d’avoir un métier coté serveur respectant une architecture SOA et accessible via des services diffusant des formats diverses via des protocoles diverses. A partir de là différents critères vont rentrer en jeu : ergonomie, performance, accessibilité, environnement (OS et matériel), ouverture, sécurité, compatibilité avec un existant … Il n’y a donc pas de réponse évidente. Je cherche depuis un moment faire un tableau qui définit quelle technologie pour quels besoins et au final je pense que c’est inutile.
Ce qu’il faut considérer c’est que :

• l’accès aux resources locales (fichiers, applications, périphériques USB, serie, Bluetooth) est un argument pour pencher vers le RDA. Bien que cela peut être pallié avec un applet et de plus en plus avec Gears (mais cela revient à mixer RDA et RIA, pourquoi pas d’ailleurs c’est ce que je fais) et que le Flash plugin permet déjà l’accès à la caméra.
• la notion de “push”, pour envoyer des données vers un client depuis le serveur est maintenant possible avec des RWA (Comet, reverse Ajax) et bientôt standardisée dans HTML 5 (WebSocket).
• les échanges asynchrones via des MOM avec des queues coté client ne peuvent pas encore se faire en RWA. Gears devrait proposer une API et LifeCycle Data Service ne le propose pas reellement car la queue reste coté serveur.
• l’uniformisation des applicatifs avec une même plate-forme de déploiement indépendante de l’OS est sûrement l’argument le plus percutant pour le SI pour choisir une RWA

The Paris JUG this time was devoted to GWT and implementation of Restlet for GWT. Two presentations greatly performed by Didier Girard and Jerome Louvel. I was impressed by the number of participants, thinking that GWT was already in the soul. Bravo to Didier continue to promote this technology and Jerome to put the concept of REST.
Still, I am astonished at the vision that people have of the RIA. For many I have the impression that RIA means rich web application. But the notion of “rich” is simply a reconsideration of the user experience and this does not necessarily by the browser. GWT, Ajax, AppletFX, Flex or Silverlight do not have the monopoly of RIA simply because they run in a browser.
Javascript enabled to overcome the limitations of HTML in the browser and gave a new dimension to Web applications. The browser now becomes a runtime JavaScript and uses HTML as graphics library. Like Java with Swing, C# with WPF or Silverlight, AS3 with Flash and Flex.
iTunes is probably one of the first RIA and this is not a web application. As I said already we must differentiate Rich Web Application and Rich Desktop Application. A RWA runs in the browser, a RDA runs in an OS.
There are advantages and disadvantages in both approaches but the distribution and maintenance which have long been the strengths of Web applications are no longer true today.
As you do more surprised to have your Windows automatically updated it is now also possible for an RDA to be maintained and transmitted via the Web. Java Web Start is a good example and Adobe AIR knows how to do too. But i herer what you say : to run Java or Air, you have to respectively install the JVM and runtime AIR. Yes it’s true like you do it recently when you installed Chrome or previously installed Firefox. The difference is that Windows come with its own browser and when you buy a PC with Windows you have it. At one time you install a runtime and except if you are terribly lazy person you aren’t obliged to be use Windows/IE only.
Where we must be vigilant with a RDA is to not go back to the old client/server model. The RDA must remain a UI layer and not shipping business that must always be server side.<br /> Apple had already experimented this with WebObjects Java Client and continues today to offer similar APIs for Cocoa and now IPhone SDK.
To the slogan “the browser is the platform” I answer “the browser is a platform”. Future architectures should not be dependent on UI layer because it must be developed in the best technology to meet the objectives of application and customer needs by focusing on ergonomics and performance.
Our application ResUrgences is in web for 8 years now in a sector (health) where applications are often client/server. Now the extension from the emergency department to the mobile emergency department (say SMUR in France) forces us to reconsider the web architecture because using a web application on a Tablet PC offline, although not impossible, is not appropriate. Especially when you have to interconnect with monitoring and electro-cardiogram equipment.
So what choice between RWA and RDA ? The first step is to think RIA, so to have a SOA server side architecture and services accessible through various formats via various protocols. At this point different criteria have to be focus on: ergonomics, performance, accessibility, environment (OS and hardware), openness, security, compatibility with existing … So there is no obvious answer. I’m looking for a long time on a table that defines what technology for what needs and now I think it’s impossible.
What should be considered is :

• access to local resources (files, applications, USB, serial, Bluetooth) is an argument to look to the RDA. Although this can be remedied with an applet and increasingly with Gears (but it’s a RWA/RDA mix, why not is what I do) and that the Flash plugin already allows access to the camera.
• the concept of “push” to send data to a client from the server is now possible with RWA (Comet, reverse Ajax) and soon standarize in HTML 5 (WebSocket).
• exchanges via asynchronous MOM with queues client side cannot yet be in RWA. Gears should propose an API and LifeCycle Data Service does not really do it because the queue is server side.
• uniformity of application with a single platform deployment independent of the OS is probably the most powerful argument for the SI to choose a RWA

C’est un fait le modèle request-response du protocole HTTP n’est plus à la mode. La vague du RIA oblige, il faut plus d’interaction au niveau du navigateur et permettre la remontée de données comme cela est possible dans une application desktop (chat (XMPP), jeux en ligne, applications financières, …). HTML 5 prévoit le coup avec la notion de WebSocket mais il faut un serveur web qui l’implémente. La société Kaazing vient de sortir son serveur web implémentant cette spécification après celui de Michael Carter : Orbited.
Le concept Comet nous permet déjà d’implémenter le push dans le navigateur avec CometD, ou plus simplement avec Pushlet. Attention tous les serveurs web ne le supportent pas.
La récente conférence sur ce sujet a reuni des personnalités mais dommage je l’ai raté et il n’y a pas (encore) de webcast disponible. Par contre il y a le webcast de Jonas Jacobi (co-fondateur de Kaazing).

It’s a fact the request-response HTTP loop is not fashion. The RIA wave oblige, we need more browser interaction and push backed data like we have on desktop applications (chat (XMPP), online gaming, financial app). HTML 5 is looking after that with WebSocket but you need web server which implement it. Kaazing company just release its web server which implement this specification after the Michael Carter’s Orbited.
Comet concept already allow us implement push in the browser with CometD, or more easily with Pushlet. Be carefull not all web server support this.
The recent conference on this subject met personnalities but unfortunately i miss and there is no available webcast yet. But there is the Jonas Jacobi’s webcast (Kaazing co-fondator).