Passer au contenu

L’architecture JCA ébranle le secteur de l’EAI

Parmi les éditeurs de serveurs d’applications, BEA est le premier à miser sur cette architecture, ouvrant ainsi le marché de l’EAI.

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 ” : JCA 1. 0 (J2EE Connector Architecture). 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, de gestion de la relation client, 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 Al-fred Chuang, président de BEA System. Tout en affirmant 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 doucement à JCA

BEA dégaine le premier en éditant cet été Weblogic Integration Server 1. 0. Disponible en téléchargement sur son site, ce logiciel 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 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.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 Bean), 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 ins-tallée MQ Series.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. A 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.


Samuel Cadogan