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.

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 | modifier le code]

Concepts[modifier | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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 | modifier le code]

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.