Ajax est il un framework qui a profité de l'effet mode et de la ruée des entreprises vers le déploiement des nouveaux gadgets pour favoriser la croissance ou un véritable framework qui répond à des besoins imposés par la diversification des canaux et l'innovation ? D'emblée, les deux hypothèses sont vraies. Mais sur le plan architectural c'est la deuxième hypothèse qui doit être retenue. En fait, la saga qu'affichent certaines entreprises vers le déploiement des nouvelles technos et des nouveaux framework entraînent l'aboutissement à des SI très complexes et difficiles à maintenir. Rappelons le, un bon architecte est celui qui se laisse guider par l'évolution des besoins plutôt que l'évolution de la techno. Les technos ne sont que des moyens et pas l'inverse. Revenons à notre problématique : la force d'Ajax réside dans sa capacité à faire exécuter les interfaces au niveau des clients tout en garantissant un rafraîchissement partiel des interfaces là où le besoin se présente. Ce étant, Ajax reste une solution très efficace pour les applications J2EE dont les clients sont riches ou les clients qui nécessitent des va et viens fréquents vers le serveur qui les a infantés. Le développement ahurissant du web sociologiques, le besoin croissant de développer des applications qui gèrent le Multimédia (vidéo, image, son, ...) et le besoin d'accéder à l'info en temps réels (notamment pour le cas des réseaux d'information, la géolocalisation, la gestion du trafic en temps réel, les applications de bourse) présentent des cas typiques où Ajax pourrait vachement améliorer les performances. En en un mot, il me semble que tout ce que nous faisions avant avec les applets est à refaire en Ajax. Vue les faiblesses et les limites des Applets (sécurité, lourdise, compatibilité avec les browsers, communication exclusive avec le serveur d'origine...), Ajax se présente comme un bon successeur de ce moyen de gérer l'interactivité et le temps réel. Toutefois, comme tout framework, Ajax a des faiblesses. Nous citons la lourdise qu'engendre l'utilisation de certaines librairies dédiées Ajax et l'interférence entre la couche métier et la couche présentation que les développeurs Ajax ont tendance à adopter par soucis de facilité. Un outil incontournable qui facilite la vie en travaillant avec Ajax : Google Awt permet de gagner du temps tout en respectant les règles de la J2EE. Alarme : les décideurs en SI ont toujours horreur de dépendre de solutions appartenant à des parties tierce, mais s'il s'agit de Google (que les acteurs du monde Télécom le juge comme un concurrent féroce plutôt qu'un partenaire). Un avis perso : Primo, voulons le ou pas Google se présente aujourd'hui comme un acteur incontournable de la techno J2EE. Secondo, Google affiche un engagement sans précédent quant à la disponibilité et la fiabilité des outils et des solutions qu'ils offrent et se présente comme une Méga plateforme capable d'héberger les détails de ce monde avec ses quelques milliards d'habitants et ses centaines de milliars d'objets (faune et flore confondues). Tertio, je pense qu'il vaut mieux suivre le leader plutôt que de nager en sens inverse. Last but not least, en informatique un vieux wisdom stipule qu'il ne faut jamais créer la roue lorsqu'elle existe. Autre faiblesse d'Ajax, on se retrouve facilement avec un code de type "if clientBrow='IE' Then .... else if clientBrow='FireFox' ..." ou "if clientOS='Win' Then else if clientBrow='Mac'..."; une Cata en terme de qualité de code. En définitive, malgré des petites faiblesses Ajax présente une solution technologique architecturalement robuste et qui répond à de nombreux exigences imposées par la gestion de l'interactivité, la diversité des canaux et la richesse croissante des interfaces web. Cependant, il impératif de l'utiliser là où le besoin s'impose et pas partout; de plus il est indispensable de favoriser la maintenabilité du code et le respect des règles de la J2EE en codant Ajax. L'outil Flex d'adobe est il une solution qui complète Ajax ou une thecno capable d'évoluer pour le remplacer ?
Ajax est il un framework qui a profité de l'effet mode et de la ruée des entreprises vers le déploiement des nouveaux gadgets pour favoriser la croissance ou un véritable framework qui répond à des besoins imposés par la diversification des canaux et l'innovation ? D'emblée, les deux hypothèses sont vraies. Mais sur le plan architectural c'est la deuxième hypothèse qui doit être retenue. En fait, la saga qu'affichent certaines entreprises vers le déploiement des nouvelles technos et des nouveaux framework entraînent l'aboutissement à des SI très complexes et difficiles à maintenir. Rappelons le, un bon architecte est celui qui se laisse guider par l'évolution des besoins plutôt que l'évolution de la techno. Les technos ne sont que des moyens et pas l'inverse. Revenons à notre problématique : la force d'Ajax réside dans sa capacité à faire exécuter les interfaces au niveau des clients tout en garantissant un rafraîchissement partiel des interfaces là où le besoin se présente. Ce étant, Ajax reste une solution très efficace pour les applications J2EE dont les clients sont riches ou les clients qui nécessitent des va et viens fréquents vers le serveur qui les a infantés. Le développement ahurissant du web sociologiques, le besoin croissant de développer des applications qui gèrent le Multimédia (vidéo, image, son, ...) et le besoin d'accéder à l'info en temps réels (notamment pour le cas des réseaux d'information, la géolocalisation, la gestion du trafic en temps réel, les applications de bourse) présentent des cas typiques où Ajax pourrait vachement améliorer les performances. En en un mot, il me semble que tout ce que nous faisions avant avec les applets est à refaire en Ajax. Vue les faiblesses et les limites des Applets (sécurité, lourdise, compatibilité avec les browsers, communication exclusive avec le serveur d'origine...), Ajax se présente comme un bon successeur de ce moyen de gérer l'interactivité et le temps réel. Toutefois, comme tout framework, Ajax a des faiblesses. Nous citons la lourdise qu'engendre l'utilisation de certaines librairies dédiées Ajax et l'interférence entre la couche métier et la couche présentation que les développeurs Ajax ont tendance à adopter par soucis de facilité. Un outil incontournable qui facilite la vie en travaillant avec Ajax : Google Awt permet de gagner du temps tout en respectant les règles de la J2EE. Alarme : les décideurs en SI ont toujours horreur de dépendre de solutions appartenant à des parties tierce, mais s'il s'agit de Google (que les acteurs du monde Télécom le juge comme un concurrent féroce plutôt qu'un partenaire). Un avis perso : Primo, voulons le ou pas Google se présente aujourd'hui comme un acteur incontournable de la techno J2EE. Secondo, Google affiche un engagement sans précédent quant à la disponibilité et la fiabilité des outils et des solutions qu'ils offrent et se présente comme une Méga plateforme capable d'héberger les détails de ce monde avec ses quelques milliards d'habitants et ses centaines de milliars d'objets (faune et flore confondues). Tertio, je pense qu'il vaut mieux suivre le leader plutôt que de nager en sens inverse. Last but not least, en informatique un vieux wisdom stipule qu'il ne faut jamais créer la roue lorsqu'elle existe. Autre faiblesse d'Ajax, on se retrouve facilement avec un code de type "if clientBrow='IE' Then .... else if clientBrow='FireFox' ..." ou "if clientOS='Win' Then else if clientBrow='Mac'..."; une Cata en terme de qualité de code. En définitive, malgré des petites faiblesses Ajax présente une solution technologique architecturalement robuste et qui répond à de nombreux exigences imposées par la gestion de l'interactivité, la diversité des canaux et la richesse croissante des interfaces web. Cependant, il impératif de l'utiliser là où le besoin s'impose et pas partout; de plus il est indispensable de favoriser la maintenabilité du code et le respect des règles de la J2EE en codant Ajax. L'outil Flex d'adobe est il une solution qui complète Ajax ou une thecno capable d'évoluer pour le remplacer ?
Il est vrai qu'Ajax a fait de belles percés; mais je pense qu'il a introduit un niveau supplémentaire de complexité. Toutefois, je suis tout d'accord avec toi sur le fait qu'il s'agit d'une solution architecturalement bien fondée qui permet de gérer au mieux le temps réel et l'interactivité.
ReplyDeleteA +