JBI en theorie et pratique
JBI - Approche standard de SOA en JAVA
Introduction
L'industrie connait un large éventail de solutions concernant l'intégration B2B (Business to Business) et EAI (Entreprise Application Integration). Ces solutions varient entre middleware propriétaires et solutions basées sur des standards tels que JMS et Web Services.
Ce document sert d'introduction au standard JBI (Java Business Integration) qui est basé sur SOA (Service-Oriented Architecture) et l'infrastructure ESB (Enterprise Service Bus), par une approche théorique abstraite et ensuite sur une approche pratique basée sur un exemple de mise en oeuvre.
Architecture orientée services (SOA)
SOA est parmi les derniers développements qui ont marqué l'univers des applications et de la Business intégration. SOA est un ensemble de principes architecturaux bien définis et de bonnes pratiques qui permettent d'avoir une intégration faiblement couplée entre applications.
SOA favorise une intégration faiblement couplée entre les différents composants d'une application basée sur des interfaces bien définies. L'implémentation de chaque service est autonome et ne dépend ni d'un contexte externe ni de l'état des autres services. L'interaction entre services est principalement basée sur l'échange de données structurées défini en utilisant un modèle de message standard. Les services se basent sur la couche transport qui permet la communication entre des fournisseurs (provider) et consommateurs.
Enterprise Service Bus (ESB)
Un ESB fourni l'infrastructure pour réaliser une architecture orientée services (SOA). L'ESB offre un environnement pour le déploiement et d'exécution des services avec des outils permettant l'interaction et l'orchestration des services.
Ci-dessous l'architecture d'un ESB: 
A l'intérieur d'un ESB les services n'interagissent pas directement avec d'autres services, c'est l'ESB qui sert de médiateur entre les services qui sont faiblement couplé entre eux. L'ESB doit implémenter le protocole de binding, la transformation de messages, la gestion des messages, etc.
Les services clés fournis par un ESB sont :
- Fournir la liaison sur la couche transport aux services.
- Fournir un service d'annuaire pour les services déployés.
- Le routage basé sur des rôles et orchestration des messages entres services.
- Services à valeur ajoutée incluant la transformation de documents.
La plupart des fournisseurs d'ESB base leurs produits sur des standard et technologies « open » qui incluent des standards et technologie web service variées. Ils fournissent aussi une variété de liaisons au niveau transport (Binding) pour l'invocation des web services via HTTP, FTP, JMS, etc. La plus part des ESB utilisent WS-BPEL (Business Process Execution Language for Web Services) pour l'orchestration entre les services déployés dans le but de réaliser des business process. Les fournisseurs d'ESB fournissent aussi des fonctionnalités pour assurer la qualité de service (QoS) incluant la tolérance aux pannes, le failover et la répartition de charge etc.
Java Business Integration(JBI)
JBI est un standard JAVA qui s'adresse aux solutions EAI et B2B basées sur les principe d'une architecture orientée service. La norme édictée dans la JSR-208 défini JBI, c'est une approche orientée composants. JBI défini la manière de faire du routage de messages entre les différents composants, les rôles de chaque composant, les canaux de communication et les patterns d'échange entre les différents composants.
Architecture
Environnement JBI
L'environnement d'exécution JBI comprend principalement les éléments suivants dans la même JVM:
- component framework : permet le déploiement des différents types de composants (services) sur l'environnement d'exécution JBI.
- Normalized Message Router: permet un mécanisme standard d'échange de message entre les différents services.
- Management framework: basé sur JMX permet le déploiement, le management et le monitoring sur l'environnement d'exécution JBI.
SE : Service Engine
BC : Binding Component
Architecture JBI
La communication entre le Normalized Message Router et les SE / BC est basées sur un échange de messages par médiation basée sur WSDL (Web Services Description Language) et les 4 pattern d'échange de messages
Notion de médiateur
JBI définit une architecture basée sur un principe de plug-in ou les services sont branchés sur l'environnement d'exécution JBI. JBI fourni des interfaces permettant aux services d'interagir avec sur l'environnement d'exécution JBI. Les services doivent exposer leurs interfaces sur l'environnement d'exécution JBI pour que ce dernier puisse agir comme médiateur pour le routage des messages entre les différents services.
Schéma de mediation JBI entre les services:
Composants JBI
Types de composants
JBI fonctionne avec 4 types de composants :
Normalized Message Router (NMR) -composant qui véhicule les payload (Normalized Message) entre Service Engines et Binding Components.
Service Engines (SE) - composant qui contient la logique métier qui peuvent exposer et/ou consommer des service internes eg : un composant JDBC qui permet d'exécuter des requêtes SQL, un composant de transformation XSLT ou bien un composant BPEL.
Binding Components (BC) - composants capable d'exposer et/ou consommer des services internes et aussi d'envoyer et de recevoir des information a l'extérieur de l'ESB, Eg : un BC peut servir a recevoir des message JMS et déléguer le traitement a un SE ou bien servir a exposer un service BPEL a l'extérieur de l'ESB.
JMX based Administration - un outil permettant de gérer le NMR, déployer les SE et BC et aussi de gérer le cycle de vie de tout les composants.
Rôles des composants:
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.
Les composants : conteneurs de services
Pour qu'un service puisse s'exécuter dans un conteneur JBI il doit ê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 SU sont ensuite déployés dans l'environnement d'exécution JBI qui va installer chaque instance dans le composant (BC ou SE) fournissant le service.
Un SU d'un service exposé contient les parties suivantes :
Jbi.xml deployment descriptor : ce descripteur de déploiement est consommé par le moteur CXF qui est responsable de l'instanciation et l'activation du service.
service implementation : les classes d'implémentation du service incluant le code stub de WSDL.
WSDL contract : la copie serveur du contract qui utilise le format xformat binding et je transport JBI destiné a communiquer avec le NMR.
Les SU 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 ...).
Cycle de vie d'un composant JBI: 
Le Normalized Message Router (NMR)
NMR est un composant qui tient le rôle de bus interne au conteneur JBI qui permet l'interaction entre les différents composants.
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 (eg gestion de message en cache, gestion via file JMS) du NMR dépend de chaque solution d'implémentation de JBI.
Message Exchange Pattern (MEP)
A l'intérieur de l'environnement JBI 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 oeuvre 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.
Autres Fonctionnalités
Ant
Un environnement JBI doit offrir des targets Ant pour gérer le cycle de vie des composants (installation/déploiement, démarrage, arrêt, désinstallation/undeployment)
Shared Library
Ce composant est une sorte de bundle contenant des librairies accessible de tout l'environnement JBI. Il dispose de son propre cycle de vie (installation, désinstallation) et permet, pour simplifier, un mécanisme de chargement/déchargement dynamique de librairie au sein de l'environnement basé sur la norme OSGi
JBI en pratique avec ServiceMix
Pre-requis
Java SDK 1.5 : je suppose que vous l'avez deja et que vous avez bien défini la variable d'environnement JAVA_HOME.
Un répertoire de travail : dossier ou vous allez décompresser des .zip des outils ci-dessous
ServiceMix 3.3.2 : disponible ici qui est une implémentation de JBI par apache
ODE 1.3.5 : disponible ici qui constitue un SE JBI capable d'interpréter du BPEL, il sera le moteur BPEL qui interprètera notre exemple
Maven 3 : disponible ici, c'est un outil pour gérer les différentes étapes de compilation et packaging de notre exemple. Il faut pas oublier de définir M2_HOME autant que variable d'environnement et d'ajouter « %M2_HOME%\bin » a votre PATH. Une fois cela est fait testez la commande « mvn -version » sur votre console.
Eclipse helios : disponible ici qui est l'IDE que nous allons utiliser pour éditer notre exemple. Nous avons besoin de deux plug-in Eclipse pour pouvoir travailler proprement. Le plug-in BPEL et le plug-in soapUI disponibles dans le MarketPlace d'eclipse (outis>MarketPlace) puis utiliser le champ de recherche pour trouver les plug-ins.
Pour démarrer le system et faire un test préliminaire. Il faut ouvrir la console sur le répertoire « apache-servicemix-3.3.2 » et lancer la commande « bin\servicemix.bat ». Cette commande lance ServiceMix et il convient de vérifier qu'il n'y a pas d'erreurs qui s'affichent sur la console. En suite il faut copier le fichier « ode-jbi-1.3.5.zip » depuis de répertoire « apache-ode-jbi-1.3.5 » dans le répertoire apache-servicemix-3.3.2\hotdeploy et s'assurer que l'on affiche sur la console que ODE est bien déployé.
Description de l'exemple
Cela viens dans quelques jours (si vous avez des propositions à base de BPEL, elles sont les bienvenues)
- JBI en theorie et pratique
- Msdb pratique - Forum SQL
- Spring par la pratique pdf ✓ - Forum Java
- Théorie des langages exercices corrigés pdf - Forum Java
- Stock pratique ✓ - Forum VB.NET
- Test pratique excel ✓ - Forum Visual Basic 6