JCA: vers la standardisation des connections inter-applicatifs

BOURSE

Infrastructure & Chantiers

JCA: vers la standardisation des connexions inter-applications (Partie 1)

Encore largement limité dans sa première version, JCA devrait constituer à terme l'interface unique de l'univers des serveurs Java. (Lundi 28 janvier 2002)

Voir la deuxième partie de l'article: Les limites de JCA et les promesses de la version 2.0

Mis point par Sun, JCA regroupe un ensemble de spécifications Java qui décrivent une interface: "Java Connector Architecture". "A ne pas confondre avec l'acronyme de Java Cryptography Architecture : une autre interface -également développée par Sun- conçue pour répondre à certains enjeux liés à la sécurité", remarque Marcial Hemery, consultant EAI chez SCI (filiale du groupe Euriware). Quel est l'enjeu de JCA ? Poursuivant à la manière des Web Services le vieux rêve d'une interopérabilité universelle des applications, son objectif principal est de définir une couche de standards permettant à un serveur Java de dialoguer avec des applications basées sur des technologies tierces.

D'ores et déjà intégré à la version 1.3 des spécifications J2EE (Java 2 Enterprise Edition), JCA vise plus concrètement à faciliter la mise au point d'interfaces de

connexions et d'adaptateurs (ou connecteurs) standards. "Schématiquement, les interfaces permettent aux serveurs d'invoquer des fonctions d'autres applicatifs mises à disposition par les adaptateurs. Ces deux briques dialoguant entre elles par le biais d'un langage de contrat, comparable au protocole WSDL utilisé dans les Web Services, détaille Marc Boullier, directeur technique chez Vistali. Au-delà de l'objectif poursuivi, JCA et les Web Services sont également comparables en terme d'architecture."

JCA version 1.0 : une interface JDBC améliorée
La première version de la spécification JCA ne semble constituer qu'une première ébauche du projet. "JCA 1.0 se calque sur le modèle de connectivité de JDBC (Java Database Connectivity). De la même manière, il propose un vocabulaire standard assurant l'appel d'une ressource applicative distante", explique Marcial Hemery. Seule différence fonctionnelle : alors que JDBC reste cantonné aux bases de données relationnelles, JCA étend son mode d'invocation à n'importe quel type d'application (progiciels, systèmes transactionnels, etc.).

Résultat, JCA 1.0 devrait simplifier le travail des intégrateurs. Fini les bibliothèques de centaines de

connecteurs pour répondre aux caractéristiques technologiques de chaque architecture d'intégration. D'un côté, les fournisseurs de serveurs et de solutions d'EAI n'auront plus qu'à mettre en oeuvre une interface standard (appelée Common Connection Interface) pour générer les appels distants et intégrer le langage de contrat nécessaire. De l'autre, le travail des éditeurs de solutions se "résumera" au développement d'un adaptateur unique pour s'ouvrir à l'univers J2EE. "Grâce à cette grande souplesse, JCA offrira mécaniquement une plus grande marge de manoeuvre autour du choix des solutions d'entreprise", commente Jean-Baptiste Bugeaud, consultant technique chez Fi System. Cette couche de standards devrait en effet limiter les développements propriétaires additionnels.

Voir la deuxième partie de l'article: Les limites de JCA et les promesses de la version 2.0

A lire aussi:

J2EE 1.3 se prépare à intégrer les Web Services
QUESTIONS-REPONSES J2EE en sept questions