ServiceMix 3.2.x – Introduction à JBI

Pour bien comprendre le fonctionnement de l’ESB ServiceMix, il faut tout d’abord se plonger dans la spécification de Java Business Integration (JBI).

Java Business Integration est une norme édictée dans la JSR-208 : basée sur une approche orientée composant, JBI définit la manière de router les messages entre composants. Elle définit les composants et leur rôle, les messages qui circulent dans le bus, les canaux de communication entre les composants ainsi que les patterns d’échange.

ServiceMix est une implémentation de la norme JBI.

Architecture de JBI

Le schéma ci-dessous présente l’architecture générale de JBI.

L’ensemble des éléments de ce schéma sera décrit dans la suite de cet article.

Notion de composants

Catégories de composants

JBI définit deux types de composants : Les Binding Components (BC) et les Service Engines (SE).

• Les Binding Components (BC)
  Les Binding Components permettent l’accès depuis l’extérieur au bus JBI. Ils peuvent à la fois exposer des services ou consommer des services disponibles sur des applications hors de l’ESB.
• Les Service Engines (SE)
  Les Services Engines exposent et consomment des services disponibles uniquement à l’intérieur du bus JBI. Ils ne peuvent accéder au monde extérieur.

Les rôles des composants JBI

Un composant JBI peut proposer des services suivant deux types de rôles :

• Rôle  » Provider  » :
       – Ce rôle est endossable par les Binding Components ou les Service Engines.
       – Un service de type provider fournit des services exposés en interne du bus JBI.
       – Exemples :
            – Un composant de transformation va offrir des services de transformations sur le bus JBI.
            – Un composant Web Service va permettre d’invoquer un Web Service extérieur à partir du bus JBI.
• Rôle  » Consumer  » :
       – Ce rôle n’est endossable que par les Binding Components.
       – Un service de type  » consumer  » écoute les messages provenant de l’extérieur et initie les échanges JBI à partir des messages qu’il reçoit.
       – Exemples :
            – Un composant va exposer un Web Service vers l’extérieur et envoyer chaque message qu’il reçoit dans le bus JBI.
            – Un composant va attendre des messages sur une file JMS et envoyer chaque message qu’il reçoit dans le bus JBI.

Un composant peut fournir à la fois des services consumer et provider.

Les composants : conteneurs de services

Les composants (BC & SE) une fois installés dans le bus JBI proposent des services. Les composants proposent différents services en fonction de leur technologie.

Exemple : Le composant de type SE servicemix-saxon offre des services de transformation XSL et XQuery, le composant de type BC permet d’exposer et d’invoquer des services externes au bus JBI, etc.

Ces services doivent être en quelque sorte configurés et instanciés pour s’exécuter. Les composants agissent ainsi comme des conteneurs pour des instances de service.

Les instances des services sont packagées sous la forme de Service Unit (SU). Ces services units sont ensuite déployés dans le bus JBI qui va installer chaque instance dans le composant (BC ou SE) fournissant le service.

Les services units doivent être packagés sous la forme de Service Assembly (SA) pour être « déployable ».

JBI définit 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 conformes à sa spécification, sans modification. Le package d’installation contient tout ce qui est nécessaire à l’installation d’un composant (librairies …).

Interaction entre les composants ServiceMix

Le Normalized Message Router (NMR)

JBI définit un concept de bus interne permettant la communication entre les composants : c’est le Normalized Message Router (NMR).

Les éléments qui composent ce NMR sont :

• NormalizedMessage : Cette interface de la spécification définit la structure standard d’un message. Ce format est utilisé pour représenter un message en entrée ou en sortie ainsi qu’un message d’erreur. Les messages transitent forcément sous la forme de message XML (implémentant l’interface javax.xml.transform.Source). Un message peut aussi contenir des propriétés et des attachements (binaires ou non).
• MessageExchange : Cette classe représente un appel transitant à l’intérieur du bus JBI. L’échange contient le message d’entrée, l’éventuel message de sortie ou d’erreur (sous la forme de NormalizedMessage) et véhicule aussi les informations de l’appel (ex : destinataire) et le statut (actif, fini, en erreur). Il existe plusieurs types de MessageExchange, chacun suivant un pattern d’échange défini dans JBI.
• DeliveryChannel (DC) : JBI fournit à chaque composant (BC ou SE) un channel d’échange avec le NMR. Les composants utilisent ce channel pour échanger des messages au travers du NMR.

L’implémentation des mécanismes de routage du NMR dépend de chaque solution d’implémentation de JBI. ServiceMix fournit une implémentation d’un NMR sous la forme de flow. Il existe trois types de flow dans ServiceMix : Le SedaFlow (défaut), le JMSFlow et la JCAFlow.

Le SedaFlow stocke les messages en mémoire, le JMSFlow utilise des queues JMS comme implémentation des DeliveryChannel et le JCAFlow se base sur un connecteur JCA pour stocker les messages.

Message Exchange Pattern (MEP)

JBI définit aussi des patterns d’échanges de message. Chaque composant supporte selon la technologie qu’il représente tout ou partie de ces patterns d’échanges.

Chaque MEP définit l’enchaînement, le sens et le nombre de messages échangés ainsi que l’évolution du statut de l’échange de manière précise.

Au travers du DeliveryChannel, les composants interagissent avec le NMR de deux façons :

• En acceptant des échanges (MessageExchange) : le composant reçoit un échange émis par un composant.
• En envoyant des échanges (MessageExchange) : le composant initie ou poursuit un échange après avoir traité les messages de l’échange.

Un Binding Component de type consumer initie un échange en créant une instance d’un objet MessageExchange et en le mettant à disposition des autres composants au travers du NMR. Un autre composant va accepter l’échange, effectuer un traitement puis envoyer l’échange (éventuellement mis à jour) vers le NMR, etc.

L’échange se termine quand l’un des composants positionne l’échange au statut ‘Done’ ou ‘Error’.

Les échanges entre les composants sont décrits au travers des patterns suivants. Il existe 4 MEPs différents basés sur les types d’invocations One-way et Request-Response. Ils permettent de moduler les types de communications entre les composants :

• 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 (de type acknowledge) 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.

En exemple voici, un échange de type InOut décrit par des diagrammes de séquence UML, le premier finissant normalement, le second finissant en erreur.

Schéma d’un échange In Out se terminant normalement

 

Schéma d’un échange In Out se terminant en erreur

Cette présentation de JBI se termine ici, prochainement nous étudierons quelques exemples de mise en œuvre avec ServiceMix.