Note : 8 ; Un très grand classique !

Cet ouvrage s’inscrit dans la continuité du « Patterns for Enterprise Applications » de Martin Fowler. Plus exactement, il traite de l’intégration d’application asynchrones par le biais de messages. Cette imposante référence regroupe 65 patterns, décrits au long des 650 pages de cette imposante référence. L’ensemble est découpé en seulement 14 chapitres.

Le premier chapitre est déjà conséquent avec près de 40 pages. Les auteurs y construisent un exemple d’intégration d’application fictif allant jusqu’au monitoring et montrant comment et pourquoi chaque pattern y prend place. Cela me rappelle quelque peu le premier chapitre de l’Enterprise Applications Patterns de Martin Fowler. Par contraste, le second chapitre est bien plus succinct avec ses 17 pages. Il s’agit ici de patterns stratégiques décrivant les différents styles d’intégration : transfert de fichiers, base de données partagée, échanges de messages, appels de procédures distantes, etc.

Le chapitre 3 s’attache à zoomer sur un seul des styles d’intégration décrit précédemment : l’échange de messages. Les patterns figurant ici décrivent les différents composants de cette structure : messages, endpoints, chanel, routeurs, transformateurs, etc. Nouveau coup de zoom au chapitre 4, sur un des composants de l’échange de messages : les canaux. Ce chapitre nous fait découvrir les différents types de canaux de manière exhaustive : point à point, publish and subsribe, bridge, etc. C’est l’occasion de découvrir certains patterns beaucoup moins connus que les grands classiques. Je pense, par exemple au Datatype chanel ou au Dead-letter chanel.

C’est à un autre composant de l’échange de messages qu’est dédié le chapitre 5 : le message lui-même. Il nous emmène à la découverte de 2 aspects principaux. Tout d’abord les différents types de messages, tels que les évènements, les documents, etc. Puis viennent les éléments constitutifs des messages : adresse, adresse de retour, expiration, etc. Tous les aspects du sujet sont bien couverts. Le chapitre 6 nous offre notre premier interlude avec la mise en œuvre de systèmes de messages simples au travers de 2 exemples, en Java et en C#. Ce n’était pas strictement indispensable, mais cela peut aider à avoir « les pieds qui touchent le sol » après ces chapitres fort conceptuels. Mais je suis personnellement à l’aise avec le conceptuel.

Le routage est un peu le cœur des architectures d’intégration. Surtout qu’ici, au chapitre 7, le terme est pris dans un sens assez large, comprenant le « content-based routing » et autres routages dynamiques, mais aussi le filtrage, l’agrégation, le split de messages, etc. Il ne faut guère s’étonner de voir ce chapitre s’étendre sur 100 pages ! Plus court avec moins de 35 pages, le chapitre 8 consacré aux transformations de messages est aussi moins convaincant. Les quelques patterns qui s’y trouvent ont une valeur assez accessoire.

Le chapitre 9 est l’occasion de notre second interlude. Il est particulièrement long avec ses 90 pages regroupant 4 exemples. Mon préféré est le premier et aussi le plus court : il illustre le chapitre 8 sur un cas de figure d’enrichissement progressif de message. Viennent ensuite 3 implémentations, d’abord en mode synchrone et en architecture SOA avec Apache Axis, puis en asynchrone avec MSMQ puis finalement en asynchrone également avec Tibco. Le plus inutile est ce dernier, mais les deux précédents, s’ils ne sont pas dénués d’utilité, sont assez poussifs.

Le chapitre 10 aborde un point important de ces architectures : les endpoints. L’ouvrage lui consacre l’importance qu’il mérite avec 70 pages où sont passés en revue les différents modes de consommation et les différentes manières de transcrire les messages vers les systèmes tiers. Du solide. Dans le chapitre 11 consacré au « system management », les auteurs ont regroupé les patterns nécessaires à la gestion, au contrôle et au test du système. Bref tout ce qui est nécessaire pour s’assurer que le système fonctionne correctement. C’est justement à un exemple de system management qu’est consacré le dernier interlude de l’ouvrage. C’est une bonne idée d’avoir cherché à illustrer cet aspect mais l’exemple n’est que peu moyennement convaincant.

Le chapitre 13 nous approche de la fin en nous montrant comment les patterns des différentes catégories peuvent être sélectionnés pour constituer une solution. On peut en faire soit trop, soit trop peu dans ce type d’exercice. En faire trop nécessiterait des centaines de pages pour couvrir de nombreux cas d’association. Les auteurs ont donc opté pour la seconde solution qui me laisse un peu sur ma faim mais est peut-être le meilleur choix. Le chapitre 14 referme l’ouvrage en s’essayant au difficile exercice des prédictions. Celles-ci s’orientent vers la standardisation de ces patterns au sein du SOA. Autant dire que c’est raté. Mais l’avenir se montrera plus clément avec l’avènement des ESB et surtout des « ESB light » tels que Camel et Spring Integration. Donc je dirais : « job well done ! ».

Aujourd’hui les 65 patterns présentés dans cette imposante référence de 650 pages font autorité : la plupart des outils ESBs du marché revendiquent l’implémentation de ces patterns ! Plus important encore, c’est sur cette base qu’ont été pensés les « ESB light », et leur rapide adoption montre bien que les auteurs ont vu juste. Les exemples du livre ont eux, quelque peu vieilli, avec ces nombreuses références à SOA. Mais ce n’est pas le cas des patterns eux-mêmes dont la pertinence et la clarté restent tout à fait d’actualité !