Cet article est un des articles de la suite `Vision des ESBs par un architecte d’entreprise`.
Éditée par le Java Community Process, Java Business Integration1 (JBI) est une spécification d’un conteneur d’intégration d’applications orientée services, autrement dit, c’est une spécification d’un ESB orienté « services ».
Cette spécification définit plusieurs choses :
l’architecture d’un tel conteneur :
les composants, ou moteur d’exécution, peuvent être librement installés dans le conteneur en fonction des besoins, ils seront chacun exécuté de manière isolée des autres. Les composants sont classés en deux catégories :
les « service engines » fournissent la logique métier et les transformations (XSLT, moteur de règles…) et peuvent consommer eux-mêmes d’autres SE,
les « binding components » fournissent la connectivité, qu’il s’agisse de protocoles (FTP, HTTP), de piles (SOAP, JMS) ou de services externes au conteneur JBI. Ils permettent aussi l’accès depuis l’extérieur aux services déployés dans le conteneur JBI.
les « service units » qui sont une configuration à déployer sur les composants pour réaliser fournisseurs et consommateurs de services,
les « service assemblies » permettent le packaging d’application SOA,
le « NMR » (Normalized Message Router) a en charge le transport des messages entre les composants. Chaque composant est relié au « NMR » par le « Delivery Channel ». Tous les messages envoyés par un composant transitent par son propre « Delivery Channel » pour être pris en charge par le « NMR » qui détermine le composant destinataire avant de transmettre le message au « Delivery Channel » de ce dernier.
une API JMX d’administration,
une API entre le NMR et les composants afin d’être indépendant de l’éditeur de l’ESB : il est possible d’installer un composant provenant d’un éditeur dans le conteneur d’un autre, ou de remplacer le conteneur tout en gardant les composants initiaux.
On peut considérer JBI comme un échec. En effet, aujourd’hui il n’existe plus que deux implémentations : Petals ESB et Open ESB. Apache ServiceMix a abandonné JBI dans sa version 4.
Malgré cet échec, certains de ces concepts sont très intéressants et à retenir :
il propose une vraie approche services,
les artefacts « composants », « service units » et « service assemblies » se retrouvent dans les méthodologies d’architecture (IAF2, TOGAF3, …)
JBI n’a pas non plus été aidé par sa volonté de non adhérence à un éditeur. Et ceci d’autant plus que les poids lourds du secteur à l’époque (Oracle, SAP, Seebeyond, Tibco et WebMethods) étaient membres du groupe de spécifications.
Pour ceux qui veulent en savoir plus sur la spécification JBI sans vouloir se plonger dedans, je leur conseille la lecture de l’article « JBI : Qu’est Ce Que C’est ? ».
