Divers concepts pourraient influencer le développement des serveurs d’applications au cours des prochaines années. Un consultant en TIC reconnaît le potentiel des uns, mais recommande la prudence envers d’autres.
La réseautique a littéralement explosé au cours des dernières années, notamment grâce à l’engouement envers Internet. Les serveurs d’applications, qui ont évolué pour tirer parti de la réseautique distribuée, sont susceptibles d’adopter divers concepts qui sont en émergence ou en croissance.
Claude Marson est un consultant français qui collabore régulièrement avec l’entreprise québécoise Technologia Formation pour la prestation de cours spécialisés en TIC. Les serveurs d’applications font partie des contenus de ses formations; nous lui avons demandé de commenter les tendances technologiques potentielles à ce sujet.
Le Web et l’AOS
Le premier constat de l’évolution des serveurs d’applications est l’exécution d’un virage vers le Web sous une architecture à multiples niveaux où les éléments qui composent une application sont diversifiés et distribués dans l’entreprise.
« Les serveurs d’applications ont subi une influence considérable du monde Internet, autant par l’utilisation du protocole HTTP et des systèmes d’adressages IP, explique M. Marson. Ce changement s’est notamment réalisé du côté client, où un simple fureteur permet d’exécuter du code HTML, du XML, ou bien des applications Java exécutées dans une machine virtuelle.
« Un serveur Web sert de plate-forme, de gare de triage pour permettre aux postes clients Internet d’accéder à des applications résidant sur un serveur d’applications Java ou .NET. Ces applications peuvent servir à se connecter à des applications d’héritage qui résident sur des ordinateurs traditionnels et à ce moment le serveur d’applications ne reçoit que des données de routage », indique-t-il.
Les serveurs d’applications sont également influencés par la montée croissante du concept de l’architecture orientée services (AOS), où l’application segmentée a recours à des éléments situés hors de l’architecture de l’entreprise.
« On découpe l’application en composantes élémentaires qu’on appelle ‘services’. C’est une architecture qui sollicite des composantes qui résident soit sur des serveurs d’applications internes, soit sur d’autres machines dans l’entreprise ou ailleurs via l’Internet. On parle alors de mashups [applications Web hybrides] ou du Web 2.0. Par exemple, un site de recherche d’appartement offre une carte de localisation à l’aide d’une composante fournie [par un tiers] », résume-t-il.
La gestion de processus d’affaires
Les serveurs d’applications doivent être adaptés en fonction de l’évolution des façons de faire d’une organisation. À cet effet, une tendance émergente vise l’intégration de fonctions de gestion de processus d’affaires, ou Business Process Management (BPM) en anglais.
L’Office québécois de la langue française définit ce concept comme étant « une gestion de processus qui prend en compte, de façon automatisée, l’ensemble des cas d’enchaînement des processus d’affaires dans une entreprise, de telle sorte que l’on puisse suivre en temps réel l’évolution d’une tâche ou d’une information à l’intérieur de l’entreprise. »
M. Marson affirme que le rôle de la gestion de processus d’entreprise sera important, alors que la sollicitation de composantes réparties à divers endroits sous les architectures orientées services dans un serveur d’applications s’avère être beaucoup plus facile à dire qu’à faire.
« La gestion de processus d’affaires intègre trois fonctions, dont un aspect de modélisation des processus d’entreprise, au moyen d’approches comme IMM (Information Management Metamodel) ou BPMM (Business Process Maturity Model) qui servent à voir s’il existe des composantes aptes à traiter un problème. Il y a aussi un aspect d’orchestration, parce qu’on ne peut lancer n’importe comment dans la nature des traitements qui peuvent dépendre les uns des autres.
« Et il y a un aspect de surveillance de l’activité des processus, avec les outils de BAM (Business Activity Monitoring), pour assurer qu’une application composée d’un certain nombre de services dépendants les uns des autres ne nécessitera pas deux heures et demie pour s’afficher à l’écran! », ajoute-t-il.
Le logiciel libre
Le domaine des serveurs d’applications est également influencé par la philosophie du logiciel libre, alors que plusieurs projets tels que GlassFish, qui est soutenu par Sun, JBoss de Red Hat et Tomcat d’Apache connaissant une popularité croissante.
M. Marson croit que le recours au logiciel libre constitue la solution d’avenir en matière de serveur d’applications.
« Je suis convaincu que tous les serveurs d’application et même les bases de données seront gratuits demain… entre 2010 et 2015, parce que les communautés open source sont en train d’envahir ces domaines, affirme-t-il. Comme dans le domaine des serveurs HTTP, où Apache a délogé Microsoft, tout ce qui est architecture sera gratuit alors que les éditeurs feront de l’argent sur les produits. Oracle est en train de changer sa stratégie pour se position en tant que fournisseur de solutions de gestion client, de solutions financières, de solutions de SIG, etc. »
« D’autant plus que la définition des standards n’appartiendra plus aux éditeurs, car ce sont les communautés du logiciel libre qui le feront. Pour l’instant, on n’a pas encore la même robustesse de production d’applications sur des plates-formes open source, mais ce n’est qu’une question de temps », ajoute-t-il.
Et la virtualisation?
La virtualisation est un autre concept qui suscite grandement l’intérêt dans le domaine des TIC. Plusieurs entreprises y ont recours pour rationaliser le matériel nécessaire, et la tentation de l’appliquer aux serveurs d’application se manifeste déjà.
M. Marson acquiesce que les serveurs d’applications peuvent bénéficier de l’approche de façon indirecte, mais avec modernisation.
« Un serveur d’applications, qui est un fournisseur de service Java ou .NET, peut fonctionner sous n’importe quel système d’exploitation qui peut parfaitement être virtualisé. Il bénéficiera de plus en plus de cette approche où [des combinaisons de serveurs d’applications et de plates-formes] cohabiteront sur le même serveur physique », estime M. Marson.
« Mais il ne faut pas le faire pour le plaisir de le faire! En théorie, on peut faire des choses d’une manière beaucoup plus efficace que par le passé, peut-être en mettant deux machines virtuelles pour appuyer un seul serveur d’applications qui sera ainsi virtualisé… Mais il faut faire preuve de beaucoup de prudence », précise-t-il.
Haro sur les applications patrimoniales
Si l’application de nouveaux concepts aux serveurs d’applications en intéresse certains, d’autres pourraient envisager le transfert d’applications patrimoniales vers de nouvelles applications, sous un prétexte de modernisation ou d’optimisation. Or, M. Marson affirme que dans la plupart des cas ce n’est pas possible, voire que c’est peine perdue.
« Premièrement, il faut être fou furieux de vouloir faire des applications transactionnelles à haut volume en Java ou en .NET, parce que cela ne marche pas, déclare-t-il. Certains éléments de technologie, comme ceux qui sont associés au mapping, soit la mise en correspondance entre la structure des données relationnelles et la structure des objets fabriqués en mémoire lors de l’exécution, fonctionnent très mal. Des solutions émergent, mais c’est très, très risqué.
M. Marson note également l’existence de problèmes dans la réalisation de transactions longues. « N’importe qui est capable de faire des transactions courtes avec une petite mise à jour d’une base de données. Mais faire une transaction longue, avec des écrans qui s’enchaînent et qui fait des accès simultanés à plusieurs types de fichiers, dans la plupart des cas ne sera pas possible. À moins de réécrire une partie des frameworks [cadres d’applications] techniques qui ne marchent pas, mais pour cela, il faut s’appeler Desjardins ou Hydro-Québec… », commente-t-il.
M. Marson ajoute que les applications patrimoniales ont été écrites depuis longtemps et que les compétences de programmation nécessaires à leur modernisation ne sont pas ou plus détenues par les entreprises.
« Dans 70 % des cas, on laissera les applications telles qu’elles sont, mais par contre on écrira une application pour y accéder en tant que service, indique-t-il. On ne touche pas à ce qui est écrit, mais pour les applications nouvelles on réutilise ce qui existe. Je crois qu’on va en rester ainsi pour encore dix à trente ans au niveau des applications. Les machines changeront, mais l’application écrite en COBOL restera comme tel… »
Garder à l’oeil les standards et la performance
Néanmoins, plusieurs nouvelles applications pourront être produites et tirer un bénéfice des avantages offerts par les serveurs d’applications. Afin d’assurer une réussite à long terme de ces applications, M. Marson recommande aux entreprises d’accorder une grande attention sur des aspects qualitatifs au niveau des serveurs d’applications.
« Avant tout, il faut respecter les standards et ne jamais s’en écarter pour ne pas être embêté demain, affirme-t-il. Les serveurs d’applications sont des conteneurs qui sont les porteurs des cadres d’applications, mais il y a des divergences au niveau des serveurs d’applications [offerts par les fournisseurs]. Or, les standards ne sont pas faits par les fournisseurs, mais par la communauté.
« Il faut également surveiller les problèmes de performance, ajoute-t-il. Même si pendant un temps un serveur d’applications marche bien, subitement, il peut afficher un long temps de réponse. Autrefois, [pour une application] il y avait un programme, une machine, un écran et parfois même un fichier. Maintenant, toutes les architectures sont à multiples niveaux, avec des services d’orchestration, de présentation, d’authentification, etc., et tout est découpé ou disséminé. Avant de trouver le problème, je vous garantis que vous aurez des cheveux blancs! C’est une autre raison pour [inciter à] respecter les standards. »
Jean-François Ferland est journaliste au magazine Direction informatique
