Portal vs message broker - 2 approches complémentaires

Dans un récent projet impliquant de nombreux partenaires devant s'échanger des données, le débat broker versus portal (ou portail en français) â fait l'objet de nombreuses discussions.

Avec, comme à l'habitude, sur des sujets aussi stratégiques, une tendance malheureuse à polariser les discussions.
Cette polarisation n'a pas lieu d'être : chacune de ces approches a sa part de valeur ajoutée pour le projet.

Je vais m'attacher ici à les expliquer. Rapidement bien entendu - Nous sommes dans le cadre d'un blog.

Mais commençons par rappeler les définitions de broker et portal.

La définition d'un broker est un peu difficile à établir. Pour s'en convaincre il suffit de regarder les discussions sur différents forums qui s'intéressent à ce qui distingue un broker d'un enterprise service bus (ESB).
Faisons simple et considérons le broker comme un moyen de transférer des données via des messages dans le backend (la partie non visible par les utilisateurs).

Dans le cadre qui nous occupe, un portal peut être vu comme un site web destiné à agréger les accès à divers autres sites web sous-jacents. Un point d'accès central en quelque sorte.

Sans le citer nommément, voici maintenant les fondamentaux du projet.

- des acteurs privés, fournisseurs de données, et des acteurs publics, consommateurs de données, avec chacun des besoins propres ;
- les fournisseurs de données sont plusieurs dizaines voire plusieurs centaines ;
- les consommateurs de données sont au nombre de 5 ;
- pour fournir les données, les fournisseurs de données doivent utiliser l'application de tiers (au nombre de 4) - ces tiers sont eux-mêmes fournisseurs d'une partie des données ;
- les consommateurs de données exploitent celles-ci à des fins de contrôle ;
- une obligation de résultats rapide.

La voie initialement choisie a consisté à mettre en place plusieurs bus de données en cascade pour transférer les données des fournisseurs vers les consommateurs.

La première difficulté rencontrée avec cette seule approche est d'arriver à mettre tous les acteurs d'accord sur les différents types de messages à prévoir et sur leur contenu, d'autant plus que les fournisseurs de données vivent le projet comme une obligation (ils doivent se soumettre aux obligations imposées).

Autre difficulté d'importance : les propriétaires des applications doivent chacun compléter leur application avec des écrans de capture pour collecter l'ensemble des données requises par tous les consommateurs. Il faut donc coordonner les efforts de 4 équipes de développement sur des fonctionnalités qui en fait ne constituent pas une valeur ajoutée pour leurs propriétaires (des acteurs du projet finalement gênés dans l’exercice de leur métier par ces obligations).

La difficulté est d'autant plus grande que les 5 consommateurs de données ont des besoins spécifiques. Il s'agit donc de gérer 5 x 4 relations entre partenaires.

Dans un tel contexte, il est évident que les maintenances corrective et évolutive posent de sérieux problèmes, en termes d'obtention des consensus sur les évolutions nécessaires des différentes applications et sur la gestion des plannings de réalisation et de tests. Les disponibilités sont en effet variables selon les acteurs, avec pour corollaire que de manière quasi permanente, au moins un des acteurs est attendu par tout ou partie des autres.

L'addition de toutes ces difficultés a conduit à un allongement considérable du projet.

Après de longs mois de tergiversations multiples, la réflexion suivante s'est imposée : pourquoi ne pas faire en sorte que chacun des partenaires soit responsable de collecter les données dont il a seul l'usage.
Et d'ensuite les partager, via le broker, s'il s'avère que dans le cours du projet, en contradiction avec les analyses de départ, elles peuvent en intéresser d'autres.

Permettre à chacun de développer sa propre application web lui permettant d'obtenir les données qui lui sont propres (comprenez qui n’intéresse aucun des autres consommateurs de données), en complément au broker, a donc finalement été considéré comme une option intéressante.
Sous trois conditions :
- ne pas vouloir obtenir par ce canal une information déjà disponible par un autre canal, ce qui obligerait le fournisseur de la dite information à de l'encodage multiple (respect strict du principe "only once") - donc, si l'information est déjà disponible via le broker, elle doit être récupérée par ce biais;
- mettre à disposition un seul point d'accès aux différentes applications web via la notion de portal ;
- ne pas obliger les fournisseurs de données à des login multiples (principe du "single-sign-on").

Cette approche combinée broker plus portal concilie indépendance des acteurs, gage de leur efficacité individuelle, et partage des données. L'approche permet en effet de réduire considérablement les besoins de concertation sur les développements à réaliser et simplifie également la gestion des plannings.

Comme annoncé en début de ce blog, sur base de ces quelques considérations, il est donc facile de conclure que broker et portal sont bien des approches complémentaires.

Un conseil à ce stade : dès le début du projet, établissez un diagramme de contexte complet, dans lequel vous faites apparaître les flux de données entre partenaires. En complément, établissez des fiches qui donnent le détail de ces flux. Vous prendrez ainsi immédiatement conscience de qui est vraiment intéressé par quelles données.

Voyons maintenant quelques aspects particuliers.

Lors de l'échange de données entre partenaires, une problématique de première importance est incontournable : la gestion des anomalies. Sur ce point, le portal apporte son lot d'avantages, en évitant d'impliquer tous les intermédiaires dans cette gestion souvent complexe. En effet, grâce au portal les retours d'anomalies peuvent être gérés sans dépendances vis-à-vis des tiers qui gèrent le broker. La gestion des anomalies est un vaste sujet qui mériterait à lui seul un blog séparé (et bien plus encore).

L'utilisation du format XML, et la définition d'un format canonique pour les échanges, est aujourd'hui un must pour le succès du broker.

En nous appuyant sur les schémas XSD nous avons pu développer un outil de génération de cas de test qui nous a permis de tester rapidement nos développements, sans attendre que nos partenaires soient déjà à même de nous envoyer des messages. Cette initiative a permis de gagner énormément de temps en s'affranchissant de nombreuses dépendances temporelles dans le projet.

A titre d'information cet outil a été développé en s'inspirant de la philosophie des moteurs de règles (externalisation poussée des logiques d'alimentation des templates de messages sous la forme de règles). Il possède de ce fait un caractère générique non négligeable.

A l'issue de ce projet nous pouvons émettre la recommandation suivante : dans un projet d'intégration impliquant des partenaires multiples, obligés de collaborer mais avec des centres d'intérêts plutôt éloignés, il faut veiller à limiter au maximum les dépendances en matière de développement. C'est la meilleure garantie de rester maîtres des délais de réalisation, de maîtriser dans le temps l’évolution du système global et de garder les coûts de maintenance sous contrôle.

La combinaison broker plus portal aide grandement à satisfaire à cette stratégie.

S'agissant de l'approche portal, pour être complet et ne rien cacher des difficultés rencontrées, il nous faut encore ajouter que la mise en place d'un mécanisme de single-sign-on reste un exercice souvent difficile. La diversité des technologies utilisées par les différents partenaires et les différences de niveau de compétences sur le sujet expliquent cela.