Le serveur d’applications Java emportera-t-il tout sur son passage ? Aujourd’hui, c’est au tour des éditeurs d’outils d’EAI (intégration d’applications d’entreprise) de faire les frais de son inéluctable montée en puissance. La ” menace ” s’appelle JCA ( J2EE Connector Architecture) version 1.0.Ses spécifications, accouchées par la Java Community Process (JCP), arrivent à maturité.Le but : fournir, à partir d’un serveur d’applications, des connecteurs standards pour un parc d’applications hétérogène ?” progiciels de gestion intégrés, outils de gestion de la relation client, logiciels maison résidant sur grands systèmes, etc.Le huis-clos propriétaire dans lequel ont vécu les éditeurs d’EAI risque donc de voler en éclats. De longue date, chacun a imposé aux développeurs l’apprentissage de nouvelles interfaces de programmation.” Il existe autant de connecteurs et de bus de messagerie que d’éditeurs de plates-formes d’EAI “, ne manque pas de souligner Alfred Chuang, président de BEA System. Qui affirme aussi que la dernière génération d’offres d’EAI n’a pas été en mesure de tenir ses promesses au sein de l’entreprise.
Les éditeurs d’applications se rallient à JCA
BEA dégaine le premier en éditant cet été Weblogic Integration Server 1.0. Disponible en téléchargement sur son site, il intègre une première mouture des spécifications JCA 1.0 et un kit de développement de connecteurs JCA.En face, IBM a lancé Websphere Business Integrator. ” Mais le constructeur n’est pas encore prêt à intégrer la JCA, et il a du mal à positionner cette offre “, affirme Henry Peyret, analyste architecture et intégration pour le Giga Group.” De toute façon, précise-t-il, la version actuelle de JCA ne sera certifiée qu’avec l’adoption prochaine de J2EE 1.3. “ Des éditeurs d’applications comme Siebel, SAP ou Peoplesoft, et des sociétés de services partenaires, se sont déjà ralliés sous la bannière JCA et projettent d’étoffer la liste des vingt-cinq connecteurs JCA déjà existants.
Avec JCA l’intégration se fait par un serveur d’applications Java
En l’état actuel, JCA 1.0 définit trois niveaux de contrats de service ?” sécurité, connexion et transaction ?” pour les échanges entre un connecteur et le serveur d’applications.Avec, comme possibilité, l’agrégation, à partir d’un composant EJB (Enterprise Java Beans), de plusieurs sessions simultanées.La CCI (Common Client Interface) définit, quant à elle, les interfaces du serveur d’applications vers le connecteur. Le standard JMS (Java Messaging Service) peut aussi être utilisé en conjonction avec JCA 1.0 pour des services de messages asynchrones.
La version 2.0 devrait combler les lacunes actuelles
Mais la jeunesse de la JCA 1.0 offre aussi un sursis aux éditeurs d’EAI. Car, a priori, seule la version 2.0 sera réellement en mesure de combler les lacunes actuelles.C’est le cas pour le support des mécanismes de flux bidirectionnels, la recherche sur des métadonnées et le support de XML.Parallèlement, BEA reconnaît que l’arrivée de JCA le contraindra à mettre sous le boisseau ses outils propriétaires, tel eLink. Alors qu’IBM devra jongler, entre autres, avec sa base installée MQ Series (un système de communication en mode message, et comme tel concurrent de JMS).
Vers une fusion des serveurs d’intégration et des serveurs d’applications ?
Les éditeurs d’EAI n’adoptent encore JCA 1.0 que du bout des lèvres. Seul Tibco, qui prévoit le basculement de son architecture d’EAI en EJB, est membre de la JCP. Mais la mayonnaise monte, et Sybase, Silverstream et iPlanet emboîtent le pas à BEA.Ce qui préfigure l’intégration de services d’EAI en natif dans les serveurs d’applications et la possibilité de résorber le handicap majeur des serveurs d’EAI, à savoir (selon Alfred Chuang) leur mauvaise tenue face aux montées en charge importantes.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
