Stratégie technologique
Conseil et Solutions

Les applications riches sortent à peine des boîtes des éditeurs que leurs noms sont déjà sur toutes les bouches. Quelles conséquences leur emploi a-t-il sur les choix de langages de programmation ? Le Génie Logiciel doit-il lui aussi se préparer à un virage 2.0 ?

Ajoutez donc une couche

Du plus bas niveau jusqu’au plus haut, l’informatique fonctionne selon des modèles de couches empilées ou interconnectées par des services. Les applications riches n’inventent rien de plus qu’une réorganisation de ces couches, en plaçant d’avantage de transport entre les couches métiers, données et présentation. À savoir une pile touchant au bas niveau venant s’intercaler aux plus hautes couches des applications.

Conséquence immédiate de ce chamboulement : l’apparition de contraintes et de notions sagement reléguées aux DSI et à leurs amis au coeur de nos applications : ping, QoS, mode connecté… les applications riches vont donc faire travailler ensemble les hommes des réseaux avec les équipes de développement logiciel. L’objectif étant de définir et de garantir une qualité de service pour chacun des produits logiciels.

À l’heure du tout P2P, le client-serveur prend sa revanche mais cherche encore ses langages

Les applications riches ont donc réintégré un modèle client-serveur malmené entre les couches de présentation, métiers et données. Depuis, la guerre des langages est ouverte pour imposer un langage back-end et front-end, et le support de leur communicaiton.

Le front-end a évidemment remis Javascript et le DOM au coeur des enjeux. Cependant, les frameworks riches des éditeurs apportent chacun leur langage (Silverlight et les langages .NET, JavaFX et Java, Flex et Actionscript) aussi le choix devient maintenant pluriel.

Le back-end est aussi le théâtre de luttes entre les langages ancestraux (PHP, Perl) et les nouveaux venus (Ruby). Le choix de la nouveauté est ici essentiellement politique, étant tout aussi performant, plus productif et plus robuste de maintenir les équipes dans leurs langages back-end de prédilection, tant que ceux-ci savent communiquer avec l’extérieur !

Cette communication avec l’extérieur – quelques années auparavant – chacun l’aurait naturellement associée avec XML. Mais voilà que JSON grignote son hégémonie. La raison est sa légereté et son interprétation native par Javascript… au détriment de nombreux apports de XML ! Attention ici au nivellement technologique par le bas !

Révolution de coton

En résumé, l’architecte d’applications riches doit maintenant composer avec les contraintes réseaux mais s’offrent à lui des opportunités plus souples en terme de langages et d’échanges de données. Charge à lui de faire les choix les plus judicieux pour une application homogène et pérenne !