Java connector architecture

L’admissibilité de cette page est actuellement débattue.

Vous êtes invité à donner votre avis sur cette page de discussion, de manière argumentée en vous aidant notamment des critères d’admissibilité ou en présentant des sources extérieures et sérieuses.

Merci de ne pas retirer cet avertissement tant que la discussion n’est pas close.

Après avoir apposé le modèle {{Admissibilité}} sur une page, suivez les étapes expliquées sur Wikipédia:Débat d'admissibilité/Aide :

1.	Créez la page de débat d'admissibilité.	Sauvegardez d’abord la page pour l’initialiser puis indiquez votre motivation.
2.	Important : ajoutez une entrée dans la section Débat d'admissibilité du jour.	Utilisez ce texte : *{{L\|Java connector architecture}}
3.	Pensez à informer les contributeurs principaux de la page et les projets associés lorsque cela est possible.	Utilisez ce texte : {{subst:Avertissement débat d'admissibilité\|Java connector architecture}}~~~~

Cet article est une ébauche concernant l’informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

JCA, abréviation de Java Connector Architecture, s'adresse principalement à ceux dont le besoin est d'accéder de manière très étroite à des logiques métier de système d'information d'entreprise (EIS). JCA utilise les technologies actuelles permettant ainsi de s'intégrer dans les divers systèmes d'informations en gérant les aspects de sécurité, transactionnels et les pools de communication.

JCA est majoritairement utilisé aujourd'hui pour établir des communications synchrones du type demande / réponse avec un serveur. JCA n'empêche pas d'utiliser un mode asynchrone et bi-directionnel.

Certains développements de JCA sont plus poussés et sont capables d'appeler un service JCA en fonction d'une logique métier.

Histoire

Depuis 1999 et la création de Java 2, les applications utilisant la plateforme d'entreprise J2EE respectaient des spécifications connues sous le nom de Java Community Process. À ce moment là, J2EE fonctionnait comme un serveur d'application, que les entreprises intégraient à leur façon dans leurs propres systèmes d'information^[1].

En 2001, la JCA est créée, dans le but de spécifier des contrats et des interfaces standards pour les entreprises. De cette façon, les développeurs peuvent intégrer leurs logiciels dans les systèmes des entreprises sans avoir à s'adapter à ceux-ci : le serveur d'application devient une plateforme d'intégration^[1]^,^[2].

Description

La mise en forme de cette section ne suit pas les recommandations de Wikipédia (juin 2024) : découvrez comment la « wikifier ».

Les applications J2EE sont constituées de :

modules web ;
modules EJB ;
modules client d’application d’entreprise

Les systèmes d’informations d’entreprise (EIS) sont constitués de :

ERP ;
mainframes ;
SGBD ;
applications anciennes écrites en C, C++, COBOL…

JCA est la solution de J2EE pour résoudre le problème d’intégration entre le monde J2EE et le système d’information d’entreprise (EIS).

Pour mettre en œuvre une telle intégration JCA propose une architecture basée sur les éléments suivants :

un Resource Adapter ;
des contrats applicatifs entre les modules J2EE et le Resource Adapter ;
des contrats système entre les serveurs d’applications J2EE (AS) et le Resource Adapter.

Un Resource Adapter est un pilote entre le serveur d’applications et le système d’information d’entreprise. Il est composé de :

jars permettant d'emmailloter l’accès aux ressources du système d’information ;
bibliothèques natives (.dll, .so) fournissant l’accès aux ressources du système d’information ;
un descripteur de déploiement ra.xml.

Les contrats systèmes définissent :

la connectivité du serveur d’applications vers l’EIS (dans la version 1.0 de JCA ) ;
la connectivité de l’EIS vers le serveur d’applications (dans la version 1.5 de JCA) ;
la gestion du cycle de vie du Resource Adapter (dans la version 1.5 de JCA) ;
la gestion des threads (dans la version 1.5 de JCA).

Parmi ces contrats on distingue donc :

contrat de gestion de connexions : définit comment obtenir une connexion à l’EIS depuis l’AS, le pooling des connexions est transparent pour l’application ;
contrat de gestion de transactions : permet à l’AS d’utiliser un gestionnaire de transactions supportant l’accès à divers gestionnaires de ressources de l’IES. Les invocations de services au sein de l’EIS sont enveloppées dans des transactions distribuées (XA Transaction définie par l’Open Group). Les transactions XA sont globales et peuvent contenir des appels à divers types de ressources de l’EIS ;
contrat de gestion de la sécurité : fournit des mécanismes permettant de gérer l’authentification, l’autorisation, les communications sécurisées entre le serveur J2EE et les ressources protégées de l’EIS ;
contrat de gestion de transactions inflow : permet de propager une transaction démarrée dans l’EIS vers le serveur d’application ;
contrat de gestion de messagerie inflow : permet à l’EIS de délivrer des messages à des composants du serveur d’application ;
contrat de gestion du cycle de vie : permet l’arrêt et le démarrage du Resource Adapter ;
contrat de gestion des threads : permet à l’EIS de soumettre des tâches à l’AS. Ainsi le Resource Adapter s’exonère de la gestion directe des threads.

Les contrats applicatifs sont définis par le Common Client Interface (CCI). Cette interface permet à des composants applicatifs J2EE, à des frameworks d’intégration d’applications d’entreprises de piloter les interactions entre des ressources hétérogènes de l’EIS via l’utilisation d’une API commune.

Notes et références

↑ ^{a et b} (en) Piyush Maheshwari et Ji-Ho Kim, « Analysing Reusability Aspects in Java Connector Architecture », 11th Asia-Pacific Software Engineering Conference, IEEE,‎ 2004, p. 678–685 (ISBN 978-0-7695-2245-6, DOI 10.1109/APSEC.2004.31, lire en ligne , consulté le 30 juin 2024)
↑ (en) Beom-Su Seo, SeungWoog Jung, SungHoon Kim et Joong-Bae Kim, « The implementation of the work management contract and the message inflow contract in the java connector architecture 1.5 », The 6th International Conference on Advanced Communication Technology, 2004., IEEE, vol. 2,‎ 2004, p. 997–1002 (ISBN 978-89-5519-119-6, DOI 10.1109/ICACT.2004.1293017, lire en ligne , consulté le 30 juin 2024)

Voir aussi

Bibliographie

Publications par Oracle et Sun Microsystems

(en) Rahul Sharma, Beth Stearns et Tony Ng, J2EE Connector Architecture and Enterprise Application Integration, Addison-Wesley Professional, 2001 (ISBN 978-0-201-77580-8)

(en) Inderjeet Singh, Designing Enterprise Applications with the J2EE Platform, Addison-Wesley Professional, 2002 (ISBN 978-0-201-78790-0, lire en ligne ), p. 43-44

Autres publications

(en) Peter Späth, « Connectors », dans Pro Jakarta EE 10: Open Source Enterprise Java-based Cloud-native Applications Development, Apress, 2023, 351–372 p. (ISBN 978-1-4842-8214-4, DOI 10.1007/978-1-4842-8214-4_28 )
(en) Atul Apte, Java Connector Architecture: Building Custom Connectors and Adapters, Sams Publishing, 2002 (ISBN 978-0-672-32310-2, lire en ligne)

Liens externes

Les Transactions XA : Specification (en Anglais)

Portail de l’informatique

[:0-1] {a et b} (en) Piyush Maheshwari et Ji-Ho Kim, « Analysing Reusability Aspects in Java Connector Architecture », 11th Asia-Pacific Software Engineering Conference, IEEE,‎ 2004, p. 678–685 (ISBN 978-0-7695-2245-6, DOI 10.1109/APSEC.2004.31, lire en ligne , consulté le 30 juin 2024)

[2] (en) Beom-Su Seo, SeungWoog Jung, SungHoon Kim et Joong-Bae Kim, « The implementation of the work management contract and the message inflow contract in the java connector architecture 1.5 », The 6th International Conference on Advanced Communication Technology, 2004., IEEE, vol. 2,‎ 2004, p. 997–1002 (ISBN 978-89-5519-119-6, DOI 10.1109/ICACT.2004.1293017, lire en ligne , consulté le 30 juin 2024)

[1]

[2]