Java Business Integration

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

Architecture

Concepts

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

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 :

Service Engine (SE)

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

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

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.

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 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)

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)

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

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

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

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)

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

Service Assembly (SA)

Les composants 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

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

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

ESB certifiés JBI :

• Petals ESB, OW2 & Petals Link
• Open ESB, Oracle

ESB compatibles JBI :

• Servicemix, fondation Apache
• Sonic ESB, Progress Software
• Mule ESB, Mulesoft
• ...

Lexique

• Component: composant

Liens internes

• WSDL
• JMX

Liens externes

• JSR 208.
• Présentation de la JSR-208 en français sur 'www.enterpriseservicebus.be'.
• Article sur l'implémentation de SOA avec Java EE 5 SDK.

• Portail de l’informatique