Encore de nombreuses limites...
Pour l'heure, la version actuelle de JCA comporte encore de nombreuses limites. En premier lieu, elle interdit toute transaction assynchrone. En conséquence, les requêtes qu'elle autorise ne peuvent être initiées que par le serveur d'applications. A l'instar de JMS (Java Messaging System), JCA ne peut donc prétendre jouer le rôle d'un middleware d'EAI ou d'un broker de message -notamment en vue de synchroniser des processus d'entreprise ou de gérer les montées en charge en environnement distribué. "Cette caractéristique s'explique par une philosophie applicative qui reste encore assez proche de JDBC (appel/réponse)", reconnaît Marcial Hemery. Autre faiblesse : la relative pauvreté du langage d'invocation livré dans JCA impliquerait de préciser la granularité des appels de fonctions par des développements additionnels. Chose qui au total rendrait la logique applicative du serveur et l'adaptateur correspondant peu souples l'un vis à vis de l'autre.

...dans l'attente de la version 2.0
"Avant de passer réellement en production dans les entreprises, il est nécessaire d'implémenter JCA à la fois dans les environnements de développement, et dans les serveurs d'applications Java", prévient Jean-Baptiste Bugeaud. Pour ce faire, ces derniers doivent migrer vers la version 1.3 de J2EE. Au delà de cette première remarque, certains experts estiment que l'entrée de JCA en phase de production reste conditionnée par l'arrivée de sa spécification 2.0. "Cette version devrait intégrer les transactions asynchrones, mais également divers services supplémentaires tels que les garanties de mises à jour au sein d'architecture distribuées ou encore le chiffrement (avec le support de SSL notamment) : un ensemble de services utiles aux problématiques relatives à l'EAI et l'intégration BtoB", confie Marc Boullier.

La sortie de la version 2.0 de JCA pourrait ainsi annoncer la disparition définitive des interfaces de programmation d'applications Java (API) dites "entrantes". "Cette méthode d'invocation d'applications très restrictive ne prend en charge que les appels de fonctions unidirectionnels, c'est-à-dire celles initiées uniquement depuis le serveur", explique Marc Boullier. Et Jean-Baptiste Bugeaud d'ajouter sur ce point : "Il est vrai qu'une API traditionnelle -telle que la passerelle CICS (IBM)- ne nécessite pas de modifier l'applicatif que l'on désire requêter. Cependant, l'enchaînement et la forme des réponses qu'elle renverra seront souvent très dépendants du processus de présentation de cet applicatif (écran verts, etc.)." Ce qui n'est pas le cas de JCA 2.0 puisque celui-ci permet d'invoquer une fonction de manière native et bi-directionnelle.

Principal concurrent : les Web Services
Au total, JCA 2.0 devrait permettre aux éditeurs de solutions d'EAI (webMethods, etc.) de s'affranchir de la couche de connexions pour se concentrer sur les niveaux supérieurs : "la gestion et la modélisation des processus métier en l'occurence", indique Marc Boullier. Dans le domaine BtoB, JCA pourrait également contribuer à simplifier les travaux. Portant l'API d'entreprise, sa force serait de fournir potentiellement accès à l'ensemble des fonctions d'un système interne. Face à cette solution, seuls les Web Services sembleraient posséder les atouts nécessaires pour se poser en concurrent. Leur avantage : couvrir n'importe quel type de serveur -et pas seulement J2EE. Cette supériorité pourrait-elle tuer dans l'oeuf JCA ? "Pour le moment, note Marc Boullier, je ne m'avancerai pas sur la réponse".

Retourner à la première partie de l'article:
Les fondamentaux de JCA

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