Tous les spécialistes de la mise en ?”uvre de serveurs d’applications sont d’accord : l’architecture de l’application guide tous les choix technologiques. Il ne sert à rien de prendre le serveur d’applications le plus puissant si l’application ne le nécessite pas.
À quelles fins utiliser un serveur d’applications ?
“Si la recherche de performances constitue le critère de choix principal, la question même de l’utilisation d’un serveur d’applications doit être posée. En effet, les serveurs d’applications actuels autorisent des performances globalement inférieures de 30 % à celles des moniteurs transactionnels. Toutefois, nous ne remettons bien évidemment pas en cause le fait de privilégier les serveurs d’applications, qui apportent un modèle de programmation beaucoup plus souple, permettant la création d’applications plus complexes. La différence de performances est comblée par la croissance de la puissance des machines serveurs, explique Roger Parrié, directeur adjoint de la division Conseil technologique du consultant Valtech. De même, nous ne sommes pas partisans d’une optimisation consistant à intégrer le serveur d’applications dans les systèmes d’exploitation, car on perdrait alors l’un des principaux intérêts de Java : l’indépendance des applications Java par rapport aux différentes machines serveur.”Le critère des performances seul ne suffit donc pas pour choisir un serveur d’applications. “Le premier critère de choix d’un serveur d’applications réside dans son aptitude à intégrer l’existant. Les entreprises équipées de CICS ou de MQSeries utiliseront naturellement le serveur d’applications WebSphere, d’IBM. Celles qui sont munies de Tuxedo éliront WebLogic Server, de BEA Systems. L’architecture standard de connecteurs JCA ne devrait pas avoir d’impact sur ce critère de choix, bien que les connecteurs JCA soient utilisables sur les serveurs d’applications conformes à J2EE 1.3. Les entreprises préféreront, en effet, un fournisseur unique pour le système existant, le connecteur et le serveur d’applications, vers lequel elles pourront se retourner en cas de problème”, indique Roger Parrié.“Il faut également prendre en compte les différents types de terminaux d’accès à Internet, la disponibilité garantie, les outils d’administration livrés en standard avec le serveur d’applications, l’aptitude à communiquer avec de multiples sources de données, la flexibilité apportée tant en ce qui concerne la phase de développement qu’en ce qui concerne la phase de production (changement des paramètres de configuration ou de la version de l’application sans arrêt du serveur, par exemple)”, ajoute Robert Pavillet, architecte senior J2EE de la société AlphaCSP. De plus, selon le type d’application réalisée et la pérennité recherchée par les clients, le choix pourra varier fortement.
Serveur de scripts contre serveur de composants
“Selon que nos clients souhaitent investir ou non sur la durée, le type d’architecture sera différent, précise Roger Parrié. Pour nos clients souhaitant capitaliser sur leurs investissements, nous préconisons l’utilisation de composants métiers Enterprise JavaBean ou COM+, couplée à une modélisation en UML de leurs métiers. En revanche, dans le cas d’applications de courte durée de vie, le recours à des composants métiers n’est pas utile, et alourdit les développements. L’utilisation de servlets et de JSP (Java server pages) ou des pages ASP.NET sera alors préférable.” Le type de serveur d’applications à retenir sera donc très différent dans deux cas : serveur de scripts ou serveur de composants. Toutefois, un certain nombre d’entreprises utilisent des serveurs d’applications dépassant leurs besoins, ce qui a permis au GartnerGroup de déclarer que le marché des serveurs d’applications était entièrement stimulé et piloté par les éditeurs. Ainsi, le choix du serveur ne doit être découplé ni de l’architecture technique ni des méthodes de travail des entreprises qui les utilisent.“Il existe un fossé entre les possibilités offertes par les plates-formes J2EE ou.NET et l’utilisation qui en est faite. Beaucoup de malentendus concernent l’utilisation des objets et des composants en informatique de gestion. Les développeurs ont souvent reproduit le modèle client-serveur avec un terminal Web déporté. Ce phénomène est vrai à la fois dans l’environnement Microsoft, où dominent les pages ASP, et non les composants COM+ ou.NET, et dans l’environnement J2EE, dans lequel plus de 80 % des projets n’exploitent qu’une logique JSP-Servlet, et pas d’EJB”, affirme Dominique Jocal, responsable du pôle WebApps, d’Octo Technology. À cela les éditeurs répondent en général que tous les cahiers des charges qu’ils reçoivent demandent la fourniture d’un serveur d’applications intégrant une technologie de composants métiers. “Sans modification des pratiques de développement, la technologie ne tiendra aucune de ses promesses, en particulier pour la tant attendue “réutilisabilité”. Cela n’est pas nouveau, mais il est plus facile, aujourd’hui, de bâtir un portail de services avec des transactions CICS bien écrites (séparant, notamment, l’interface homme-machine et les traitements informatiques) que de tenter d’agréger des applications dernier cri mal écrites ! En ce sens, l’émergence de méthodologies adaptées et reconnues doit demeurer une priorité”, complète Dominique Jocal. Le problème d’utilisation des serveurs d’applications s’étend également aux hommes constituant la direction informatique. Microsoft a connu un fort succès avec Visual Basic, les développeurs procéduraux pouvant s’adapter assez facilement à ce langage. Avec Visual Basic.NET, cette migration sera plus complexe, car ce langage est orienté objets, ce qui posera plus de problèmes aux développeurs concernés.
Le facteur humain doit aussi être pris en compte
La plate-forme J2EE génère également ce genre de difficultés pour la migration des développeurs d’entreprise, ce qui raréfie les compétences disponibles et freine sa progression.“Le passage de l’environnement Cobol à un environnement 100 % objets représente un changement de mode complet pour les informaticiens-développeurs en entreprise. Il existe un taux de rejet important qu’il ne faut pas nier. Une très forte demande de la part de nos clients sur l’aspect méthodologique et sur la formation pour faire évoluer leurs développeurs est présente”, conclut Pierre Dubery, p.-d.g. d’Improve.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
