Apache Camel : Réalisez facilement vos applications orientées messages

Lorsque le nombre d'applications interagissant sur un même ESB augmente, le travail de son développeur devient de plus en plus complexe, d’une part parce que les technologies utilisées peuvent devenir de plus en plus hétérogènes et d’autre part parce que le nombre de contraintes métier va croissant.

Le framework Apache Camel apporte une réponse complète et efficace à cette problématique, sous forme d’une puissante toolbox qui peut considérablement réduire le travail d’intégration de vos applications sur le bus d’entreprise.

SOA is dead long live Microservices

A n’en pas douter, les architectures microservice sont la tendance hype du moment. Une nouvelle vague de patterns d’architecture vient donc en écraser une autre. Et bien pas si sûr ! Martin Fowler, auteur bien connu, a publié un article intitulé « Microservices ». Dans cet article nous pouvons lire « the microservice style is very similar to what some advocates of SOA have been in favor of ». Cette phrase prend tout son sens pour certains architectes. Parmi ceux-ci, il y a Anne Thomas Manes qui dans un post fameux du 5 janvier 2009, « SOA is dead ; Long Live Services », écrivait : « the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever… If you want spectacular gains, then you need to make a spectacular commitment to change ». Il semblerait que l’architecture à base de microservices vise à atteindre cet objectif !

Bus d’entreprise – Architecture de production

Un bus d’entreprise est maintenant un élément commun des systèmes d'information. Il permet de véhiculer les messages, les données et les commandes d'un système moderne. La conception et la réalisation de tels outils ne sont pas anodines et leurs indisponibilités ont un coût qu'il convient d'anticiper. Cet article liste les éléments clés à prendre en compte pour une exploitation sereine et maitrisée.

TIBCO ActiveMatrix BusinessWorks

A travers ce billet, vous découvrirez TIBCO ActiveMatrix BusinessWorks qui est l’une des solutions d’orchestration et d’intégration de services réputées les plus performantes du marché.

Introduction

Les architectures orientées service (SOA) vont continuer à s'imposer au cours des prochaines années. Elles renforceront particulièrement leur place dans les contextes d’applications d’entreprise, imposant parfois une refonte majeure des architectures déjà en place.

Mule ESB & Elasticsearch, main dans la main

Poursuivons notre apprentissage de Mule ESB à travers un autre exemple simple faisant également intervenir le moteur de recherche Elasticsearch

Cas d'utilisation

Soit le SI d'une entreprise possédant X applications communiquant entre elles via Mule ESB. A un instant T, le génial DSI décide qu'un certain nombre de données générées par les différents composants du SI doivent désormais être indexées dans un cluster Elasticsearch, données qui seront ensuite utilisées par le nouvel intranet.

Voilà ce que souhaite obtenir notre directeur du SI à terme :

Chaque application doit donc publier sur le bus, des données qui doivent être indexées par le cluster Elasticsearch.

Choix de l'équipe technique :

Les responsabilités que nous pouvons confier à notre ESB sont multiples. Dans notre cas, il a basiquement la responsabilité de collecter les données publiées par les différentes applications et aussi de les envoyer vers notre cluster qui n'a qu'une seule chose à faire : les indexer.

Pour ce faire, notre équipe a choisi d'enrichir notre ESB et de lui accorder la capacité de contacter directement Elasticsearch et de lui demander d'indexer du contenu. Elle va donc créer un composant Java qui va faire office de client vers Elasticsearch tout en lui demandant d'indexer les données obtenues.

Heureusement , tout ce que souhaite faire notre équipe est déjà disponible sous la forme du module elastic-mule disponible sur Github.

Présentation d'Elastic-Mule

Comme vu sur Github, pour utiliser elastic-mule, il suffit d'ajouter le jar associé dans les librairies du projet Mule que nous sommes en train de construire.

Pour indexer un document avec elastic-mule, il faut déclarer la classe ElasticSearchConnector dans son flow. Il s'agit d'un composant Java implémentant l'interface Callable de l'api Mule qui va permettre à notre ESB de savoir qu'il doit l'appeler via sa méthode onCall pour effectuer un traitement.

Cette méthode pour le moment ne supporte que les String et des objets de type JsonData, fourni nativement dans l'api mule (Représentation Java d'un document JSon).

Si on souhaite indexer un document dans notre flow, on peut adopter la syntaxe suivante :

<component doc:name="Elastic Search Connector">
<singleton-object >
<property key="clusterPort" value="${mule.cluster.port}"/>
<property key="clusterHost" value="${mule.cluster.host}"/>
<property key="indexName" value="${mule.indexName.value}"/>
<property key="indexType" value="${mule.indexType.value}"/>
</singleton-object>
</component>

Les différentes propriétés mule.cluster.port, mule.cluster.host, mule.indexName.value, mule.indexType.value sont disponibles dans le fichier de propriétés de l'application. Etant donné qu'on utilise un TransportClient pour contacter le cluster Elasticsearch, il faut préciser le port TCP utilisé (9300-9399 par défaut). A ce stade, pour les opérations d'indexation, elastic-mule ne permet pas encore de créer à la volée un nouvel index; cela viendra plus tard (les pull requests sont toujours les bienvenus 😉 ).
Il faut donc en attendant, au démarrage de l'application, préciser où seront stockés les nouveaux documents.

Cas 1 : Application publiant des fichiers Json

Soit l'application SAP du SI qui publie un fichier txt contenant du json. La modélisation du processus sera la suivante :

Flow avec un fichier contenant du JSon

En xml, cette modélisation correspond au bloc suivant :

<flow name="ElasticSearchCloudConnectorFlow3" doc:name="ElasticSearchCloudConnectorFlow3">
<file:inbound-endpoint path="D:folders_reposelasticSearchConnectorInData_JSON_String" responseTimeout="10000" doc:name="File"/>
<file:file-to-string-transformer doc:name="File to String"/>
<component doc:name="Elastic Search Connector">
<singleton-object  >
<property key="clusterPort" value="${mule.cluster.port}"/>
<property key="clusterHost" value="${mule.cluster.host}"/>
<property key="indexName" value="${mule.indexName.value}"/>
<property key="indexType" value="${mule.indexType.value}"/>
</singleton-object>
</component>
</flow>

Ce flow traduit que le point d'entrée est un le répertoire spécifié.

  • Chaque fois qu'un fichier arrive dans ce dossier, à intervalle régulier , Mule le lit.
  • On applique un transformer "file-to-string" sur le fichier : ce transformer manipule le contenu du fichier et en fait un string.
  • Le String obtenu est envoyé vers le composant Elastic Search Connector qui va l'envoyer ensuite vers le cluster elastic search.

Cas 2 : Application publiant du JSon via JMS

Dans ce cas, le flow peut être modélisé de la façon suivante :

Flow par une JMS

L'ajout de cette liaison se traduit en xml par

<jms:activemq-connector name="Active_MQ" brokerURL="tcp://localhost:61616" validateConnections="true" doc:name="Active MQ"/>

<flow name="ElasticSearchCloudConnectorFlow2" doc:name="ElasticSearchCloudConnectorFlow2">
<jms:inbound-endpoint queue="JsonMessageQueue" connector-ref="Active_MQ" doc:name="JMS">
<jms:transaction action="NONE"/>
</jms:inbound-endpoint>
<json:json-to-object-transformer doc:name="JSON to Object"/>
<component doc:name="Elastic Search Connector">
<singleton-object  >
<property key="clusterPort" value="${mule.cluster.port}"/>
<property key="clusterHost" value="${mule.cluster.host}"/>
<property key="indexName" value="${mule.indexName.value}"/>
<property key="indexType" value="${mule.indexType.value}"/>
</singleton-object>
</component>

Nous avons déclaré un composant pour nous permettre d'écouter une queue sur un Apache Active MQ. Pour ce test, nous avons utilisé la version 5.7.0 d'Apache Active non supportée nativement dans la version community de Mule 3.3.0.

  • Ici, au lancement de l'application, Mule se met en écoute sur la queue JsonMessageQueue
  • A chaque nouveau message publié dessus, Mule le récupère
  • Applique un transformer pour passer de l'objet reçu qui doit être un message JSON à un objet java représentant le json en question
  • Le transmet à Elasticsearch Connector qui va l'envoyer vers le cluster pour indexation.

Cas 3 : Application stockant du JSon dans sa BDD

Cet exemple va nous permettre d'illustrer la capacité de Mule à lire directement une base de données disponible dans le SI (Est-ce une bonne idée de l'autoriser à le faire ? Je pense que non mais ce n'est pas l'objet de l'article).

On va supposer l'existence d'une base de données contenant une table JSONDOCS à 2 entrées : ID et JSONDOC; cette table est alimentée en écriture uniquement par l'application à laquelle elle est liée.

L'opération peut être modélisée par le graphique suivant :

Database Flow

Database Flow

En terme de configuration xml, cela peut se traduire par :

<flow name="ElasticSearchCloudConnectorFlow5" doc:name="ElasticSearchCloudConnectorFlow5" >
<poll frequency="50000">
<jdbc:outbound-endpoint exchange-pattern="request-response" queryTimeout="-1" connector-ref="JDBCConnector" doc:name="Database" queryKey="alldocs">
<jdbc:query key="alldocs" value="select * from jsondocs"/>
</jdbc:outbound-endpoint>
</poll>
<collection-splitter xmlns:jdbc="http://www.mulesoft.org/schema/mule/jdbc" doc:name="For each entry from DB"/>
<expression-transformer expression="#[map-payload:JSONDOC]" doc:name="Expression"/>
<component xmlns:jdbc="http://www.mulesoft.org/schema/mule/jdbc" doc:name="Elastic Search Connector">
<singleton-object class="org.mule.elasticsearch.ElasticSearchConnector" >
<property key="clusterPort" value="${mule.cluster.port}"/>
<property key="clusterHost" value="${mule.cluster.host}"/>
<property key="indexName" value="${mule.indexName.value}"/>
<property key="indexType" value="${mule.indexType.value}"/>
</singleton-object/>
</component/>
</flow>

  • Ici nous avons configuré un polling de Mule sur la table en question. L' ESB en lit le contenu à intervalle régulier et envoie vers le cluster elastic search tout ce qu'il y trouve. Il effectue donc une requête "select * from JSONDOCS".
  • En sortie de cette opération, Mule renvoie une liste correspondant à chaque ligne de la table JSONDOC. Chaque objet contient lui-même une map avec en clé les noms des colonnes et en valeur les valeurs réelles des différents champs. Comme Elasticsearch Connector ne supporte pas les collections dans son traitement, nous allons affiner le traitement mule en rajoutant un composant splitter juste en sortie de la DB pour indiquer qu'il doit ensuite effectuer un traitement pour chacune des lignes de la table, donc envoyer la map représentant une ligne de la table
  • Etant donné que l'Elastic Search ne traite pas non plus les map, nous rajoutons un traitement pour extraire de la map la valeur de la clé "jsondoc". Pour ce faire, nous rajouter un expression evaluator pour trouver dans la payload en cours la valeur cherchée. L'instruction #[map-payload:JSONDOC] va indiquer à Mule qu'en ce moment nous manipulons une map qui contient une clé nommée jsondoc et dont nous voulons la valeur.
  • C'est l'évaluation de cette dernière expression qui est envoyée à Elasticsearch Connector et transmise vers le cluster Elasticsearch.

Conclusions

Au terme de cet article nous aurons vu comment intégrer notre elastic-mule à travers quelques cas d'utilisation assez simples. Des évolutions sont à prévoir pour lui permettre de supporter encore plus de chose, notamment pouvoir effectuer des recherches ou pouvoir effectuer des indexations en masse.

Vous trouverez ci-dessous les éléments vous permettant de reproduire les exemples de cet article :

Les ESB, exemple particulier de Mule ESB

A la fin de l'article qui va suivre, vous aurez joué avec la sympathique api spellcheck de google sans avoir écrit la moindre ligne de code  (savoir dézipper des archives et créer des dossiers dans l'explorateur de votre OS restent cependant indispensables). Mais avant d'en arriver là, je vous parlerai un peu des fondamentaux de la SOA et de l'utilisation des bus d'entreprise dans ce contexte.

Rappels sur la SOA

Un besoin récurrent des DSI est de parvenir à faire communiquer entre elles des applications qui au départ n'avaient pas vocation à le faire, de pouvoir réutiliser des composants déjà développés ou encore de réduire les couplages pouvant exister entre différents modules du système d'information. La SOA ( Architecture Orientée Services ) est un ensemble de principes et de méthodologies pour la conception, le développement et l'intégration de solutions logicielles qui tente de répondre à ces attentes. Ce point est important ! La SOA n'est pas une technologie, c'est une façon de penser son SI !

La notion de Service est centrale en SOA. Dans ce contexte, un service est un composant à forte valeur ajoutée métier et il remplit les conditions suivantes :

  • Il définit un contrat connu des autres systèmes;
  • Il est unique;
  • Il est invocable à distance par n'importe quel programme;
  • Il est possible de le localiser (à terme via un annuaire).

Chaque service doit se conformer au contrat qu'il a publié et le reste du système n'est pas tenu de connaître son implémentation ou ses évolutions.

Enterprise Service BUS (ESB)

Un Enterprise Service Bus (au sens architecture du terme) est devenue l'implémentation commune de la SOA. Il s'agit d'un ensemble de règles et de principes qui vont permettre d'intégrer plusieurs applications du SI qui pourront communiquer entre elles en s'adressant uniquement à un bus. Les ESB (au sens outils middleware disponibles sur le marché tels que Mule ESB, Apache ESB, Sonic ESB) vont donc nous permettre d'implémenter une telle architecture.

Schéma de fonctionnement d'un ESB

De fait, les principales promesses d'un ESB sont les suivantes :

  • Connectivité vers des technologies diverses (doit s'adapter à tous les protocoles et formats de données présents dans le SI et doit donc supporter le plus de standards de l'interopérabilité possible (web services, xml, jms, fichiers plats, etc.) mais aussi le cas échéant proposer des connecteurs spécifiques en cas de formats propriétaires dans le SI;
  • Routage (c'est l'ESB qui déduit le destinataire d'un message à partir du contenu de celui-ci car on souhaite découpler l'ensemble consommateur/producteur);
  • Transformation (capacité de l'ESB de transformer les messages circulant sur le bus par exemple d'un format vers un autre avant envoi vers un service cible);
  • Monitoring (garantie que les messages seront lus et livrés; sécurisation des services, garder traces des échanges...);

A ces promesses essentiellement techniques, peuvent venir s'ajouter :

  • le Business Activity Monitoring (BAM) qui permet de suivre l'activité d'un processus métier.
  • le Business Process Management (BPM) qui va gérer l'orchestration des processus métier.

Dans la suite de cet article, nous allons nous atteler à exposer plus en détails les capacités des ESB au travers de quelques d'utilisations concrets basés sur Mule ESB.

MULE ESB

Installation

Il s'agit d'un ESB développé par Mulesoft et dont la version communautaire est téléchargeable sur http://www.mulesoft.org/download-mule-esb-community-edition.
Il existe également une version entreprise payante (après essai de 30 jours).
Mule ESB est actuellement disponible en 2 versions; une embarquant un éditeur reposant sur eclipse et permettant de créer ses projets à travers une interface graphique
plutôt sympathique d'ailleurs et une autre en standalone. Dans cette version, il faudra prévoir plus de configuration xml pour modéliser le processus.

Ici pour déployer Mule, nous avons utilisé la version mule-standalone-3.3.0 pour permettre de mieux comprendre le fonctionnement de l'application.

Configuration

Après avoir téléchargé et dézippé dans un répertoire donné la distribution, il faut créer une variable d'environnement MULE_HOME pointant vers le répertoire d'installation de Mule. Rajouter ensuite au PATH le chemin MULE_HOMEbin est également souhaitable. Il suffit alors de lancer "mule" en ligne de commande et ça y est, ça fonctionne !

Architecture de Mule ESB

Comme dit précédemment, le travail premier de Mule est de connecter des applications, donc de recevoir des messages et d'en envoyer. Un traitement qu'effectue Mule sur un message est modélisé dans l'application par un FLOW. Techniquement, ce FLOW est représenté au sein de notre application par un fichier xml.

Dans un flow, nous allons définir en ensemble de ENDPOINTS, dans un ordre déterminé qui peuvent représenter chacune des étapes de notre traitement.  Un ENDPOINT représente le moyen par lequel Mule va communiquer avec un système extérieur. Ils sont divisés en 2 types : les inbounds et les outbounds. Dans un flow, le point d'entrée du processus sera un inbound, tous les autres seront des outbounds. Pour chaque endpoint, en fonction de son type (JMS, file, web services, ...), il existe un certain nombre de paramètres (obligatoires ou non) qui vont nous permettre de préciser le mode de connexion et certains comportements supplémentaires que nous souhaitons pour notre endpoint.

Dans un flow, nous pouvons également définir des transformers, traitements qui, comme leur nom l'indique, vont permettre à Mule de passer d'un type de données à un autre. Mule par défaut supporte déjà un grand nombre de transformation (File to String, JMSMessage to Object, Object to byte array, ...). Bien sûr, il est possible de créer ses propres transformers.

Il est également possible d'enrichir son flow, d'expressions conditionnelles, de créer des boucles, de créer des filtres sur les messages entrant/sortant, paramétrer la gestion des erreurs au sein de l'ESB, définir des connexions directement vers des bases de données, même de publier directement sur Twitter. L'ESB est très riche de base, y compris dans sa version libre, et permet de gérer un très grand nombre de cas concrets, que ce soit pour de grandes entreprises ou des PMEs.

Déploiement d'une première application

Veuillez récupérer le zip : Spellchecker sur GitHub.

Dézipper son contenu dans le répertoire MULE_HOME/apps. C'est dans ce répertoire que Mule détecte les applications qu'il doit faire tourner. Nous devons avoir en résultat dans MULE_HOME/apps/Spellchecker/ un lot de fichiers.

Mule devrait détecter automatiquement le changement et déployer directement la nouvelle application.

Spellchecker

But de cette application : à partir d'une requête stockée dans un fichier xml et contenant une phrase quelconque, on va chercher dans une api de google l'ensemble des propositions possibles pour chacun des mots de la phrase et stocker l'ensemble des propositions dans un fichier xml de sortie.

Pour tester, l'application, un peu de paramétrage sera nécessaire :

Dans le fichier mule-config.xml

<flow name="Spell_CheckerFlow1" doc:name="Spell_CheckerFlow1">
<file:inbound-endpoint path=" D:toolsMulestudioMuleStudioexamplesSpellCheckerInXML" responseTimeout="10000" doc:name="Incoming Data File"/>
<echo-component doc:name="Log Info"/>
<http:outbound-endpoint exchange-pattern="request-response" host="www.google.com/tbproxy/spell?lang=en" port="80" doc:name="GOOGLE - SPELL CHECK SERVICE" doc:description="GOOGLE - SPELL CHECK SERVICE"/>
<file:outbound-endpoint path=" D:toolsMulestudioMuleStudioexamplesSpellCheckerOutXML" outputPattern="#[function:datestamp:dd-MM-yy]_#[function:systime].xml" responseTimeout="10000" doc:name="File out" doc:description="File out"/>
</flow>

Créez 2 dossiers dans votre environnement. Le dossier défini dans inbound, sera celui sur lequel notre ESB va lire les fichiers entrants, et celui défini dans outbound contiendra les résultats après traitement par l'api spellcheck de google.

Puis redémarrez l'application Mule.

Posez dans le dossier inbound, le fichier suivant : spellcheck.xml .

Le fichier disparaît quelques secondes après et dans le dossier outbound, se trouve un fichier avec toutes les propositions de google.

A travers le diagramme suivant, on peut visualiser l'enchaînement des traitements effectués par Mule.

  • Mule écoute dans un dossier donné
  • Mule trace le fichier reçu
  • Mule appelle le service de google via l'url  www.google.com/tbproxy/spell?lang=en avec en paramètre la requête contenue dans le fichier entrant
  • Mule récupère la réponse de google et la sauvegarde dans un fichier qu'il archive dans le dossier Outbound

Conclusion

A travers cet article, nous avons fait un premier pas vers les ESB et à travers un exemple particulier, nous sommes parvenus à déployer une première application très simple qui effectue un traitement léger. Bien sur, nous n'avons fait qu'avoir un aperçu de la puissance des ESB.  Plus tard, à travers des exemples plus poussés, nous pourrons voir jusqu'où peuvent aller les ESB.

Les exemples pour l'application Spellcheck sont également disponibles sur github (Explications sur l'utilisation de Git ici : Gestion des versions avec Git )

Red Hat va aquérir FuseSource

Logo Red HatUne récente publication de Progress Software Corporation annonçait une nouvelle stratégie de la société visant à augmenter sa croissance et sa rentabilité. Cette stratégie consiste notamment à recentrer la société sur son coeur métier (plateforme de développement et de déploiement) mais surtout à se séparer de plusieurs gammes de produit jugées hors-stratégie : Actional, Artix, DataXtend, FuseSource, ObjectStore, Orbacus, Orbix, Savvion, Shadow and Sonic. Dans cette liste, on trouve la société FuseSource, filiale du groupe, qui offre du support et des outils complémentaires pour les solutions Apache ServiceMix, Apache ActiveMQ et Apache Camel.

SOA Suite 11g PS5

Roulement de tambours ! Le PS5 de SOASuite est sorti.

Oracle apporte quelques retouches (tests plus complets, nouveau composant d'agrégation, amélioration des performances, etc) à son couteau suisse SOA avant l'arrivée de la 12c. Les previews ODI et USM dessinent déjà les contextes de cette prochaine version.

Quand urbanisation rime avec méthode…

 

Le concept d'urbanisation de SI est très porteur depuis quelques années. Grands groupes comme PME sont concernés pour avoir souvent construit leur SI de manière empirique suivant les aléas de la stratégie d'entreprise (rachat, fusion, repositionnement métier...).

Une étude d'urbanisation vise à identifier des axes d'amélioration du SI pour le réconcilier avec l'activité humaine de l'entreprise, pour qu'il retrouve son rôle de facilitateur du métier, et surtout pour qu'il retrouve sa capacité à évoluer.

L'urbanisation ne se résume pas à un empilement de bonnes idées apportées par un auditeur externe, car il ne faut pas perdre de vue que derrière les aspects techniques, la réussite d'un tel chantier repose avant tout sur la méthode !