La migration du client-serveur conventionnel vers le développement web peut-elle s’opérer sans peine ? S’il s’agit simplement de rhabiller à la sauce web les applications client-serveur, les ateliers client-serveur savent le faire depuis longtemps. En revanche, si l’intention est de refondre un processus applicatif entier, il faudra probablement abandonner tout ou partie de l’ancien code L4G et repenser ses modèles architecturaux et la stratégie de déploiement. L’ampleur du saut technologique à accomplir dépend des technologies d’origine et de celles que l’on veut adopter.Le développement internet d’entreprise impose, en effet, un mode de développement multicouche avec prise en compte de modèles architecturaux à trois, voire quatre niveaux, qui n’avaient pas forcément cours dans le client- serveur d’il y a trois à cinq ans. Les développeurs qui ont mis en pratique les outils client-serveur de deuxième génération ont certes été préparés à modulariser leurs applications et à séparer méthodes d’accès aux données, logiques de traitement et interfaces graphiques. Pour eux, la transition vers internet se fera en douceur. D’autant que le passage aux ateliers web se réclamant de technologies Java,.Net ou propriétaires n’implique pas nécessairement une révolution conceptuelle radicale.Certes, dans le monde Java, le recours aux technologies de composants transactionnels EJB impose une discipline rigoureuse dans la modélisation et le développement orienté objet. Mais si l’on se contente d’utiliser les technologies Servlet/JSP (Java Server Page), on ne fait que transposer le modèle C/S conventionnel sur l’internet. La grande différence étant que la couche de présentation ne sera plus traitée sur le poste client, mais au niveau du serveur web.
Bien peser le choix d’une interface HTML
Bien sûr, le passage au web impose de s’adapter à un large lot de spécificités techniques. Il conviendra, par exemple, de bien peser les avantages et les inconvénients du mode transactionnel déconnecté qu’impose le dialogue HTTP, de bien mesurer l’impact du cryptage SSL sur les performances des échanges, et de s’adapter au mode de programmation par page.La conception des écrans HTML n’est d’ailleurs pas forcément plus simple à aborder que la génération des écrans du client-serveur “lourd”, car nombreuses sont les options de développement. Sur quels types de navigateurs tester et déployer ? Privilégiera-t-on un client pur HTML ou acceptera-t-on d’étendre les fonctions du navigateur par des applets Java ou des composants ActiveX ? Dans le premier cas, il faudra s’assurer que le client HTML apporte une richesse fonctionnelle équivalente à celle qu’offrait le client-serveur et qu’il supporte ?” si nécessaire ?” les opérations de saisie massive. Dans le deuxième cas, il vaudra mieux s’assurer que l’on contrôle parfaitement les configurations des postes clients.Enfin, les développeurs auront aussi à s’accoutumer à de nouveaux types d’environnements de déploiement. Dans le monde des technologies Java d’entreprise, par exemple, l’environnement d’exécution d’une application n’est plus seulement une machine virtuelle Java, mais tout un ensemble de services d’entreprise ?” transactionnel, équilibrage de charge, sécurité, gestion des sessions, reprise sur incidents, etc. ?”, qu’il conviendra d’utiliser à bon escient.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
