Au cours de la conférence MIX07, microsoft a présenté de multiples démonstration de sa technologie Silverlight (v1.1 alpha - amusant sachant que la version 1.0 est toujours en bêta). Les démos semblent vraiment impressionnantes, la grosse machine qui s'était mise en route il y a quelques temps semble enfin offrir du concret (http://www.fredcavazza.net/index.php?2007/04/30/1507-mix07-las-vegas-jour-1-suite) .
En plus, l'architecture et les concepts ont l'air au point; les RIA (Rich Internet Application) vont-elles enfin percer au delà de l'AJAX mis en place plus ou moins maladroitement et simplement un peu partout ?
Parallèlement, Sun et le monde Java réagissent enfin sur ce créneau qui est à mon avis clé avec JavaFX. On en est par contre ici véritablement aux balbutiements.
Est-ce que la plate-forme Java est maintenant condamnée à être suiveur des technos microsoft? heureusement que la communauté autour de Java est active (Open Laszlo, Adobe Flex, et la multitude de framework Ajax), mais ces initiatives n'ont pas la puissance marketing et l'assise financière d'un projet stratégique de microsoft.
Avec JavaFX, on peut avoir le pire ou le meilleur. La technologie sera apparemment Open Source, donc j'espère bien qu'on finira par quelque chose de plus simple, rapide et utilisable que Swing.
Au final, tout se dirige, selon moi, dans la bonne direction: un langage simple, dédié à l'interface, concis et clair (que ce soit le XAML de microsoft, le MXML + ActionScript de Flex, ou le langage FX-Script de JavaFX qui semble très élégant).
07 mai 2007
13 avril 2007
Vers une généralisation des applications distribuées?
Depuis plusieurs années, les technologies distribuées ont tenté de s'imposer. Si cela marche très bien dans le cas d'applications spécifiquement adaptées (les ERP par exemple), ce type d'architecture n'a jamais été vraiment pertinent dans le cadre d'applications plus traditionnelles (la grosse majorité des applications). J'ai l'impression que ça change.
Globalement, j'ai vu passer 3 étapes:
Etape 1: une première grosse tentative plus ou moins viable
Les concepts intéressants de CORBA (trop complexe pour une application lambda) ont amené un intérêt (surtout de la curiosité) dans le monde de l'entreprise pour ce type d'applications. Cette curiosité a été renforcée par les EJB 1 et 2, un véritable engouement s'est créé.
Malheureusement, CORBA est trop complexe et complètement inadapté pour une application lambda (ça n'a jamais été son but), de même que l'étaient les EJB 1 et 2, inadaptés dans 95% des cas (design Sun de référence pour les applications Web, mais les limites de l'architecture sont trop contraignantes et la complexité est abusive).
Etape 2: de la curiosité à la solution élégante
Faisant suite au rejet des EJB par la communauté des développeurs nouvelles technos, les conteneurs plus léger d'inversion de contrôle (ou injection de dépendance), ont apporté une architecture claire et saine sur ces concepts déjà intéressants.
De manière similaire, la remise en cause de CORBA mène à l'apparition des Web Services, plus légers, basés là encore sur une technologie qui suscite beaucoup de curiosité de la part des décideurs: le XML (dont on parle à tort et à travers, et qui devient la solution miracle à tous les problèmes d'interconnexion - du moins dans la tête des directions informatiques...).
Les technologies de bus de messages se répandent et maturent.
On commence à parler de SOA, architecture orientée services, qui remet en cause le principe d'encapsulation des langages orientés objets ("les attributs des objets et les méthodes sur ces attributs sont dans la classe" devient "l'objet contient uniquement les données - POJO ou Javabean, les traitements sont déportés dans des classes de service"). Cette architecture entraine pour toute application, distributée ou non, de grands bénéfices en terme de maintenabilité et d'évolutivité).
Etape 3: Généralisation
Tout s'intègre très bien: SOA se généralise et bénéficie très bien des concepts de conteneurs légers, se prête très bien à la mise en place de Web Service et cerise sur le gateau, permet une évolution très transparente vers un style distribué: à partir du moment où les services sont clairement et proprement définis, on peut selon les besoins en distribuer certains très facilement.
Les concepts de grilles de calcul et de caches répartis sont connus et les décideurs informatiques s'y intéressent et investissent dessus, le plus souvent avec grand succès. Des startups qui ont développé ces produits enregistrent des succès flamboyants (Datasynape pour les grilles de calcul, Gigaspaces et Tangosol Coherence - racheté par Oracle il y a peu - pour les caches distribués avec haute valeur ajoutée).
J'ai l'impression que ce type d'application est enfin suffisamment simple pour la mise en place, suffisamment bien vu pour l'investissement des décideurs dans ces solutions et suffisamment mature pour se généraliser.
Par contre, cette évolution entraine un autre style de programmation; l'ordonnancement et la synchronisation des process, parfois asynchrones, exigent pour les programmeurs d'être plus malins et de voir l'application de plus loin, les transformant progressivement en architectes logiciel.
Globalement, j'ai vu passer 3 étapes:
Etape 1: une première grosse tentative plus ou moins viable
Les concepts intéressants de CORBA (trop complexe pour une application lambda) ont amené un intérêt (surtout de la curiosité) dans le monde de l'entreprise pour ce type d'applications. Cette curiosité a été renforcée par les EJB 1 et 2, un véritable engouement s'est créé.
Malheureusement, CORBA est trop complexe et complètement inadapté pour une application lambda (ça n'a jamais été son but), de même que l'étaient les EJB 1 et 2, inadaptés dans 95% des cas (design Sun de référence pour les applications Web, mais les limites de l'architecture sont trop contraignantes et la complexité est abusive).
Etape 2: de la curiosité à la solution élégante
Faisant suite au rejet des EJB par la communauté des développeurs nouvelles technos, les conteneurs plus léger d'inversion de contrôle (ou injection de dépendance), ont apporté une architecture claire et saine sur ces concepts déjà intéressants.
De manière similaire, la remise en cause de CORBA mène à l'apparition des Web Services, plus légers, basés là encore sur une technologie qui suscite beaucoup de curiosité de la part des décideurs: le XML (dont on parle à tort et à travers, et qui devient la solution miracle à tous les problèmes d'interconnexion - du moins dans la tête des directions informatiques...).
Les technologies de bus de messages se répandent et maturent.
On commence à parler de SOA, architecture orientée services, qui remet en cause le principe d'encapsulation des langages orientés objets ("les attributs des objets et les méthodes sur ces attributs sont dans la classe" devient "l'objet contient uniquement les données - POJO ou Javabean, les traitements sont déportés dans des classes de service"). Cette architecture entraine pour toute application, distributée ou non, de grands bénéfices en terme de maintenabilité et d'évolutivité).
Etape 3: Généralisation
Tout s'intègre très bien: SOA se généralise et bénéficie très bien des concepts de conteneurs légers, se prête très bien à la mise en place de Web Service et cerise sur le gateau, permet une évolution très transparente vers un style distribué: à partir du moment où les services sont clairement et proprement définis, on peut selon les besoins en distribuer certains très facilement.
Les concepts de grilles de calcul et de caches répartis sont connus et les décideurs informatiques s'y intéressent et investissent dessus, le plus souvent avec grand succès. Des startups qui ont développé ces produits enregistrent des succès flamboyants (Datasynape pour les grilles de calcul, Gigaspaces et Tangosol Coherence - racheté par Oracle il y a peu - pour les caches distribués avec haute valeur ajoutée).
J'ai l'impression que ce type d'application est enfin suffisamment simple pour la mise en place, suffisamment bien vu pour l'investissement des décideurs dans ces solutions et suffisamment mature pour se généraliser.
Par contre, cette évolution entraine un autre style de programmation; l'ordonnancement et la synchronisation des process, parfois asynchrones, exigent pour les programmeurs d'être plus malins et de voir l'application de plus loin, les transformant progressivement en architectes logiciel.
07 février 2007
Le futur des IHM
Il y a quelques mois, dans un précédent billet, je parlais des diverses tendances au niveau de la couche présentation des applications web Java.
Effectivement, tout semble se clarifier dans ce monde très dynamique. En gros, il y a 3 mondes:
Que l'on code directement avec du HTML ou à partir de code Java, on se retrouve avec au final une IHM construite à partir de technologies qui n'était pas initialement prévue pour faire de l'IHM (HTML a été créé pour lire des articles scientifiques, Java a été conçu pour faire des algorithmes, pas du layout ou de la configuration de composants).
Au final, il nous reste Flash, une technologie qui a été pensée dès le départ pour faire de l'IHM, qui le fait bien, de manière légère, cross-platform, avec un rendu identique sur toutes les plate-formes (Windows, Mac OS, Linux 32bits). Bref, pour moi, Flex est un bon aperçu de ce que seront les technologies d'IHM de demain.
La tendance est aux applications riches (RIA - Rich Interface Application), Adobe (Flash & Flex) et Microsoft (Windows Presentation Foundation / Express) l'ont très bien vu.
Je partage tout à fait l'analyse que fait Bruce Eckel sur son blog:
Hybridizing Java - http://www.artima.com/weblogs/viewpost.jsp?thread=193593
Effectivement, tout semble se clarifier dans ce monde très dynamique. En gros, il y a 3 mondes:
- on améliore les concepts existants (JBoss Seam avec Facelets et JSF, Struts 2 basé sur Webwork)
- on écrit le code de l'interface en Java et on compile vers de l'HTML/AJAX/Javascript (Google GWT)
- on se base sur du Flash, généré à partir de code XML compilé (Flex, OpenLaszlo)
Que l'on code directement avec du HTML ou à partir de code Java, on se retrouve avec au final une IHM construite à partir de technologies qui n'était pas initialement prévue pour faire de l'IHM (HTML a été créé pour lire des articles scientifiques, Java a été conçu pour faire des algorithmes, pas du layout ou de la configuration de composants).
Au final, il nous reste Flash, une technologie qui a été pensée dès le départ pour faire de l'IHM, qui le fait bien, de manière légère, cross-platform, avec un rendu identique sur toutes les plate-formes (Windows, Mac OS, Linux 32bits). Bref, pour moi, Flex est un bon aperçu de ce que seront les technologies d'IHM de demain.
La tendance est aux applications riches (RIA - Rich Interface Application), Adobe (Flash & Flex) et Microsoft (Windows Presentation Foundation / Express) l'ont très bien vu.
Je partage tout à fait l'analyse que fait Bruce Eckel sur son blog:
Hybridizing Java - http://www.artima.com/weblogs/viewpost.jsp?thread=193593
Inscription à :
Articles (Atom)