Java Business Integration
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Pour les articles homonymes, voir JBI.
Java Business Integration (JBI) est une norme édictée dans la JSR 208 dans le cadre du Java Community Process. JBI est basé sur une approche SOA.
Le problème initial est l'intégration de données en provenance de sources différentes au sein d'un système d'information composé d'applications disparates. JBI définit une architecture qui permet la mise en place de solutions d'intégration basées sur l'utilisation de composants qui communiquent via des messages. Les Enterprise Service Bus sont une implémentation de cette norme.
JBI est une spécification normalisant ces intégrations via un jeu d'API permettant à tout fournisseur les respectant de pouvoir se connecter à un conteneur JBI pour échanger des messages avec le reste du S.I..
Architecture modifier
Concepts modifier
JBI est une approche orientée composant qui permet de router les messages de composants en composants et reposant sur des concepts suivants.
Component modifier
Les composants proposent des services accessibles par l'intermédiaire d'interfaces.
Ce sont les parties enfichables dans le framework JBI. Ils se divisent en deux sous-familles :
Service Engine (SE) modifier
Les SE fournissent la logique métier et les transformations (XSLT, Drools...). Ils peuvent consommer eux-mêmes d'autres SE.
Binding Component (BC) modifier
Les BC fournissent la connectivité, qu'il s'agisse de protocoles (FTP, HTTP, ...), de piles (SOAP, JMS, ...) ou de services externes au conteneur JBI. Ils permettent l'accès depuis l'extérieur aux services d'une application JBI.
Rôles modifier
Les composants peuvent avoir les rôles suivants :
- Consumer : Le composant utilise un service
- Provider : Le composant fournit un service
Chaque composant peut être à la fois consumer et provider.
EndPoint modifier
Les services proposés par les composants sont accessibles via des endpoints. Un service correspond à un endpoint. Les composants qui consomment des services peuvent spécifier un endpoint de 2 manières :
- Implicitement : Le endpoint est sélectionné en se basant sur le type de service fourni par les composants et celui recherché. C'est une méthode « dynamique » qui permet de trouver un composant fournissant le service recherché s'il en existe au moins un disponible.
- Explicitement : Le endpoint est sélectionné par son nom. Cette méthode fait donc apparaître le endpoint par son nom dans le code. Si ce endpoint est indisponible mais qu'un autre composant propose le même service, il ne pourra pas être utilisé alors que ce serait le cas avec une spécification implicite.
Normalized Message Router (NMR) modifier
Le Normalized Message Router reçoit et envoie des messages de la part de composants. Il est responsable du routage des messages. Les messages sont tous dans un format normalisé.
Message Exchange Pattern (MEP) modifier
Il existe quatre MEPs différents, la différence étant basée sur les types d'invocations One-way et Request-Response. Ils permettent de moduler les types de communications.
- In-Only (One-Way) : Le message est envoyé au destinataire. Aucun moyen n'est mis en œuvre pour s'assurer qu'il est bien arrivé ou non.
- Robust In-Only (One-Way) : Le message est envoyé au destinataire et un message est retransmis à l'expéditeur en cas d'erreur.
- In-Out (Request-Response) : Un message nécessitant une réponse est envoyé au destinataire.
- In Optional-Out (Request-Response) :Un message est envoyé au destinataire et peut parfois nécessiter une réponse.
Normalized Message modifier
Les Normalized Messages sont les messages échangés par une application JBI. Ce sont des documents XML formés :
- Du contexte du message : Il inclut des informations tels que le protocole de communication, des informations spécifiques à d'autres composants ...
- Du contenu du message : Toutes les données.
Delivery Channel modifier
Les composants se « connectent » sur le NMR grâce au delivery channel. C'est une voie de communication bidirectionnelle leur permettant d'envoyer et de recevoir les messages.
Packaging modifier
JBI défini un packaging standard (une archive Zip) et des descripteurs (fichier jbi.xml) pour l'installation et le déploiement des composants afin de permettre leur portabilité sur tous les ESB conforme à sa spécification, sans modification. Le package d'installation contient tout ce qui est nécessaire à l'installation d'un composant (librairies ...) et obligatoirement un descripteur d'installation qui se trouve dans un dossier META-INF à la racine de l'archive. Le packaging de déploiement des services est divisé en 2 parties :
Service Unit (SU) modifier
Chaque service à déployer est défini dans un SU. Celui-ci contient toutes les informations relatives au service (fiche de transformation Xslt... ) et obligatoirement un descripteur qui se trouve dans un dossier META-INF à la racine de l'archive.
Service Assembly (SA) modifier
Les services qui doivent interagir ensemble sont rassemblés dans un SA. Celui-ci contient obligatoirement un descripteur où se trouvent toutes les informations relatives aux SUs à déployer, ainsi que les archives de ces Sus.
Implémentation modifier
Les ESBs fournissent une implémentation de la norme JBI plus ou moins stricte. Les composants utilisables sont fournis avec l'ESB, chacun ayant ses propres composants. Les packages sont pour la plupart le plus possible conformes au standard mais tous sont compatibles avec la norme JBI.
Produits modifier
Il existe un grand nombre d'ESB compatibles JBI, libres ou propriétaires
ESB certifiés JBI :
ESB compatibles JBI :
- Servicemix, fondation Apache
- Sonic ESB, Progress Software
- Mule ESB, Mulesoft
- Talend ESB
- ...
Lexique modifier
- Component: composant
