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.
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.
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 :
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.
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.
L'environnement d'exécution JBI comprend principalement les éléments suivants dans la même JVM:
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
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:
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 :
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 :
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:
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 :
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.
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.
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)
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
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é.
Cela viens dans quelques jours (si vous avez des propositions à base de BPEL, elles sont les bienvenues)