Java Business Integration

Un article de Wikipédia, l'encyclopédie libre.
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant. (Comment ?).

Java Business Integration 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..

Sommaire

[modifier] Architecture

[modifier] Concepts

JBI est une approche orientée composant qui permet de router les messages de composants en composants et reposant sur des concepts suivants.

[modifier] Component

Les composants proposent des services accessibles par l'intermédiaire d'interfaces.
Ce sont les parties enfichables dans le framework JBI. Il se divisent en deux sous-familles:

[modifier] Service Engine (SE)

Les SE fournissent la logique métier et les transformations (XSLT, Drools...). Il peuvent consommer eux-même d'autres SE.

[modifier] Binding Component (BC)

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 de depuis l'extérieur au services d'une application JBI.

[modifier] Rôles

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.

[modifier] EndPoint

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 services fournit 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 utilise un codage en dur du enpoint. Si celui 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.

[modifier] Normalized Message Router (NMR)

Le Normalized Message Router reçoit et envoi des messages de la part de composants. Il est responsable du routage des messages. Les messages sont tous dans un format normalisé.

[modifier] Message Exchange Pattern (MEP)

Il existe 4 MEPs différents basée sur des 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.

[modifier] Normalized Message

Les Normalized Messages sont les messages échangés par une application JBI. Ce sont des documents XML formé  :

  • 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.

[modifier] Delivery Channel

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.

[modifier] Packaging

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 :

[modifier] Service Unit (SU)

Chaque composants à déployer est défini dans un SU. Celui contient toutes les informations relatives au composants (fiche de transformation Xslt... ) et obligatoirement un descripteur qui se trouve dans un dossier META-INF à la racine de l'archive.

[modifier] Service Assembly (SA)

Les composants qui doivent interagir ensemble sont rassemblé 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.

[modifier] Implémentation

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 conforme au standard mais tous sont compatibles avec la norme JBI.

[modifier] Produits

Il existe un grand nombre d'ESB compatibles JBI, libres ou propriétaires

ESB certifiés JBI :

ESB compatibles JBI :

  • Aqualogic Service Bus, BEA
  • WebSphere Application Server, IBM
  • Sonic ESB, Sonic Software
  • Servicemix, fondation Apache
  • Mule, Mulesource
  • ...

[modifier] Références

[modifier] Liens internes

[modifier] Liens externes

[modifier] Lexique

  • Component: composant
Autres langues