Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Fonctionnalités avancées

Fonctionnalités avancées

Code générique et JNDI

Comme nous l’avons souligné, le principe d’une spécification telle que JMS est que l’on peut écrire un programme s’interfaçant à un provider JMS, c'est-à-dire à un MOM, sans être dépendant d’une implémentation particulière, d’un MOM en particulier.

Pour cela, le programme « JMS Client », ne doit pas instancier directement les classes du MOM, et la bonne pratique est de les obtenir à partir d’un fournisseur JNDI.

De même que JDBC est une interface permettant d’accéder à une base de données, de même JNDI ou « Java Naming and Directory Interface » est l’interface qui permet l’accès à des services de nommage et de répertoire de façon standard. L’utilisation la plus commune de l’interface JNDI concerne l’accès à un annuaire LDAP. Mais au-delà de la fonctionnalité usuelle de gestion d’une base de personnes, d’utilisateurs, on peut utiliser l’API JNDI simplement pour accéder à des objets désignés par des noms. Ainsi, dans le contexte des MOMs, JNDI sert à stocker des objets génériques du MOM, afin de transmettre leur implémentation spécifique de JMS au programme.

Le premier objet que le programme obtient est une connectionFactory, une usine à connexions. Puis la connectionFactory permettra de créer un objet Connection, à partir duquel on créera un objet Session, qui lui-même pourra instancier des objets Message, MessageProducer et MessageConsumer.

Ce que l’on peut représenter comme suit :

code_generique_JNDI

Entreprise Intégration Patterns

Le livre de Gregor Hohpe et Bobby Woolf intitulé « Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions », est un ouvrage de référence en matière de middleware. Il recense en particulier toutes les formes d’interactions par middleware, et tous les types de traitements que peut réaliser un middleware. Par exemple un traitement de routage d’une queue vers une autre, selon différentes règles. Ou encore des traitements de fusion ou de fission des messages : le moteur de traitement peut éclater un message en plusieurs, ou à l’inverse réunir différents messages en un seul.

EIP se ne limite pas à cela. Il décrit toutes les manières à disposition pour intégrer des logiciels entre eux. Catégorisant ces patterns selon leur objet, c’est un peu la bible des architectes et urbanistes.

Voici la liste des catégories référencées par EIP ainsi que quelques exemples :

  • Styles d’intégration : Liste les supports de communications comme le transfert de fichier, le partage de donnée, l’invocation de procédure et la communication par message. On retrouve ici les type de middleware évoqués en introduction
    • Les systèmes de messagerie : Cette catégorie de pattern regroupe les composants des systèmes basés sur une communication par messages comme un message, un traducteur de message, un routeur de message, …
    • Les cas d’utilisation d’une communication par messages : Cette catégorie décrit le concept de queue, de topic, de bridge de message et autres
    • Méthode de construction des messages : message de commande, message de document, message d’événement, …
    • Le routage des messages : routage basé sur le contenu, agrégation de message, …
    • Transformation de message : envelopper un message, enrichir le contenu, …
    • Réception de message : Cette catégorie décrit les différentes manières de recevoir un message comme la consommation à callback, abonnement durable, sélection de message, …
    • Administration de la plateforme : Cette catégorie décrit les différentes manières de gérer la plateforme : persistance, détournement de message, écoute passive, …

Interopérabilité entre MOMs

Les protocoles filaires des MOMs (par exemple entre une application et un broker ou entre un broker et un autre) sont parfois sans spécification et sans documentation. Parmi les MOMs de notre sélection, aucun n’offre nativement une passerelle vers d’autres MOMs.

Pour résumer, la partie haute de la figure ci-dessous, c'est-à-dire l'interconnexion des MOMs au niveau du protocole interne, n'est pas possible. Il faudrait que les deux MOMs utilisent le même protocole interne, ce qui n’est en général pas le cas.

Il ne suffit pas d’assurer la transmission des messages, il faut gérer la propagation de tout l’annuaire des domaines.

interoperabilite_moms

À des fins d’interopérabilité, certains MOMs ont mis en place un système dit de « Bridge » (Passerelle). C'est une application à deux faces qui est, d'un côté connectée à un MOM et de l'autre connectée à un autre. Lorsqu’elle reçoit un message d’un côté, elle le transmet de l’autre.

Cette solution peut rencontrer des limites en termes de performance, flexibilité et de sécurité. Hormis le temps et la complexité de mise en place, la passerelle risque d’être un goulot d'étranglement, et un point de fragilité. Au sein d’un même système d’information, on vise à l’évidence, un MOM unique. Mais bien sûr, les cas possibles d’hétérogénéité sont nombreux : rachat et intégration d’entreprise, relations avec des partenaires, etc.

Passerelle à base d'ESB

Le travail d'intégration est laissé aux solutions du type EAI ou ESB (Enterprise Service Bus). À l’aide de l’ESB Mule, par exemple, il est assez simple de mettre en place une passerelle entre deux domaines de deux MOMs - Pas besoin d’application supplémentaire pour jouer le rôle de passerelle ni même de toucher à une ligne de code Java. Regardons comment configurer Mule pour cette tache. Pour ce faire, il faut créer deux connecteurs : un vers chacun des MOMs. Puis il faut créer un service par domaine qui aura la mission de transmettre les messages. Voici une partie du fichier de configuration.

 

La tâche n’est pas d’une grande complexité, mais elle peut être fastidieuse, et donc coûteuse, puisqu’il faut relier des domaines entre eux un par un, sans en oublier aucun. Et bien sûr, cette configuration devra être l’objet d’une maintenance, en fonction des variations de configuration intervenant de part et d’autre.

Passerelle_ESB

Dans notre exemple, la passerelle met en correspondance :

  • La queue Q2 du MOM A à la queue Q47 du MOM B
  • La queue Q1 du MOM A à la queue Q12 du MOM B
  • Le topic T1 du MOM A à la queue T52 du MOM B

Dans la pratique, cette passerelle est généralement réalisée en Java et utilise le JMS. On parle de « JMS Bridge » ou de passerelle JMS.

La mise en place d'une passerelle rend caduque certaines fonctionnalités incluant plusieurs brokers. Des fonctionnalités comme le partage de média de stockage ou le clustering ne marcheront plus de manière naturelle. Deux MOMs différents impliquent deux politiques différentes de persistance, de réplication, de topologie.

Ceci étant, il est possible de multiplier les passerelles à des buts de répartition de charge ou de robustesse uniquement dans les cas de liaison de queue. D'autres solutions sont envisageables, mais cela reste des développements spécifiques relatifs à des problématiques d'intégration. Un exemple simple serait de buffériser les transactions. Il est en effet bien plus performant de regrouper la réception ou l’envoi de plusieurs messages dans une seule et même transaction.

Gestion de la sécurité

Étant donné le rôle souvent central d’un MOM dans un système d’information, les questions de sécurité sont évidemment cruciales. Si n’importe quelle application peut se connecter au MOM et se mettre en lecture sur une queue, on voit qu’il sera facile de pirater le système et d’accéder à des données critiques, ou d’injecter des messages.

Un MOM interagit avec des applications, lesquelles interagissent avec d’autres applications, ou avec des utilisateurs. La question de la sécurité dans le contexte des MOMs est semblable à ce qu’elle est dans le contexte des bases de données. Les brokers doivent authentifier les applications qui s’y connectent, mais ils doivent aussi contrôler les droits spécifiques de chaque application vis-à-vis de chaque opération sur chaque queue ou topic. Et les brokers doivent aussi authentifier les autres brokers avec lesquels ils échangent.

Il est essentiel de mettre en place toute la politique de sécurisation du MOM dès son premier déploiement, quelle que soit la nature des informations échangées, ou la configuration réseau, car une fois le MOM institué comme standard d’échange, il est à craindre qu’on ne se reposera pas la question de la sécurité pour chaque nouvelle application qui en aura l’usage.

Les MOMs que nous étudions offrent la possibilité de spécifier les règles d’authentification et d’habilitations au moyen d’un provider de sécurité, utilisant le cadre de JAAS, Java Authentication and Authorization Service. Le MOM propose son propre plugin JAAS, dont le comportement est configuré par un fichier Xml, ce qui convient le plus souvent, mais il est envisageable également de mettre en place un plugin JAAS spécifique.

Administration et monitoring

Les MOMs offrent différentes possibilités d’administration et de monitoring :

API spécifique

Configuration et déploiement

Les MOMs peuvent fournir plusieurs modes de configuration : fichiers de configuration, messages adressés aux brokers, à travers différentes syntaxes (Ini, Spring, DSL, …), plus ou moins compliquées. On remarque une tendance à intégrer le MOM au sein d'environnements comme Spring. L’intérêt d’intégrer la configuration à Spring est par exemple la possibilité de lancer un broker à partir d’un outil le supportant. Ci-après un exemple issu de Mule.

 

Dans certains cas, le MOM est intimement intégré à un serveur d'application - c’est le cas de JBoss - et ainsi utilise ses fichiers de configuration. Cette intégration est plutôt une gêne qu’autre chose.

Les MOMs peuvent aussi permettre de modifier leur configuration à chaud. Par exemple, il est utile d'avoir la possibilité d'ajouter des brokers à la volée sans avoir à redémarrer la plateforme, qui impliquerait une interruption. Les messages non persistants doivent être sauvegardés et remis en mémoire lors du démarrage, ce qui ne se fait pas automatiquement d’ailleurs.

Les MOMs étudiés sont tous réalisés en Java. Ils sont tous utilisables sur les plateformes supportant le Java 5 (Linux, Windows, Mac OS, Solaris, HP UX, AIX …).

Répartition de charge applicative

On parle parfois des queues comme mettant en œuvre un échange « de 1 vers 1 ». C'est exact pour un message donné, mais ce n'est pas nécessairement le cas pour l'ensemble du flux de messages. On a vu en effet que plusieurs applications clientes pouvaient être en lecture sur une même queue. Dans ce cas, le MOM délivre chaque message à une et une seule des applications. Les règles de choix de l'application ne sont pas spécifiées, mais le plus souvent il s'agit d'un simple round robin, c'est-à-dire une attribution cyclique, « à tour de rôle ».

Ainsi, un MOM peut offrir un moyen très simple et robuste de mettre en œuvre une répartition de charge applicative.

Considérons que chaque message représente une demande de traitement, un par exemple un traitement d'OCR (reconnaissance de caractères) qui consomme beaucoup de CPU. Une application principale est en charge de définir chaque traitement unitaire, dont elle écrit les caractéristiques dans un message, qu'elle adresse sur une queue du MOM. Le traitement est réparti sur une dizaine de serveurs physiques, sur lesquels tourne la même application, dont chaque exemplaire, chaque « instance », boucle sur le traitement:

  • Recevoir un message
  • Effectuer le traitement
  • Acquitter le message.

Le flux de travaux est donc réparti de manière équilibrée entre les différents serveurs. Et notons que même si l'affectation est bêtement cyclique, l'équilibrage est satisfaisant puisque chaque serveur reçoit des travaux selon sa capacité à traiter.

queue_1_n

Et l’on peut même spécialiser les consumers, si besoin, en leur faisant sélectionner dans la queue, les tâches qu’ils savent faire.

Topologie et réseau de brockers

Un MOM peut être constitué d’un unique broker, ou bien de différents brokers échangeant en réseau.

Selon quels critères peut-on définir ces questions de topologie ?

Les questions essentielles porteront sur :

  • Les performances et la tenue en charge
  • La tolérance aux pannes matérielles
  • La tolérance aux pannes réseau

En général, sur une même plateforme, c'est-à-dire un ensemble de serveurs relevant d’un même datacenters et connectés à très haut débit, un unique broker peut suffire, pour autant que sa haute disponibilité soit assurée, et qu’il ait la capacité à traiter la volumétrie requise.

Nous verrons plus loin comment traiter la haute disponibilité. Concernant la capacité, comme nous le verrons dans les benchmarks, les MOM sont des outils construits pour de hautes performances, et un unique broker pourra acheminer plus de 1000 messages par seconde en mode persistance, et plus de 5000 sans persistance. Dans beaucoup de cas, cela peut suffire. D’autant qu’il s’agit là de débits de traitement et d’acheminement, il est toujours possible de confier les messages au MOM à un débit plus élevé en présence de pics.

Du point de vue réseau, on peut représenter cette configuration à un seul broker, dans un seul datacenter, simplement comme ceci :

toplogie_img1

D’un point de vue logique, on peut le visualiser comme ceci, une configuration « hub and spoke », noyau et rayons :

topologie_datacenter1

C’est principalement lorsque les applications sont réparties sur plusieurs datacenters que l’on doit envisager des configurations à plusieurs brokers.

Rappelons que la disponibilité du MOM n’est pas juste une bonne chose, elle est absolument fondamentale pour les applications. Lorsqu’un utilisateur veut se connecter au site web de sa banque, on préfère bien sûr que ce site soit disponible. S’il ne l’est pas, l’utilisateur est mécontent, mais il peut ré-essayer un peu plus tard.

Pour une application s’adressant à un MOM, la question de disponibilité s’analyse différemment :

  • Si le concepteur de l’application peut être certain que le MOM est toujours disponible, il ne traite pas le cas d’indisponibilité, ou plus exactement, il considère ce cas comme une erreur fatale, ou en d’autres termes : « pas de MOM, pas d’appli ». C’est souvent la politique d’une application vis-à-vis de sa base de données.
  • Si au contraire l’indisponibilité du MOM est possible, le concepteur de l’application doit gérer ce cas, ce qui peut changer radicalement la logique de son application, et amener une grande complexité. L’application est-elle supposée « mettre de côté » le message en attendant le retour du MOM ? Non, certainement pas, ce serait une erreur de s’engager dans cette voie. Le MOM lui-même est déjà le moyen de « mettre de côté » le message, en cas d’indisponibilité de l’application destinataire.

Ainsi, nous considérons qu’une application qui utilise un MOM est, le plus souvent, dans un mode où l’indisponibilité du MOM est une erreur fatale.

Et pour l’application, le MOM est indisponible lorsque le broker est indisponible ou bien n’est pas joignable.

C’est pourquoi, lorsqu’un système d’information est réparti sur plusieurs datacenters, connectés en WAN, on préconise de disposer d’un broker dans chaque datacenters. Ainsi, même lorsque la connectivité est perdue entre les datacenters, toutes les applications peuvent continuer à échanger avec le MOM, via un broker local.

Ce qui donne, d’un point de vue réseau, le modèle suivant :

topologie_img2

Et bien sûr, d’un point de vue logique :

topologie_img3

En présence de multiples brokers, le MOM fonctionne toujours sur un principe de « store and forward », c'est-à-dire que chaque broker conserve les messages jusqu’à ce qu’il ait pu les transmettre à un autre broker, ceci bien sûr dans une logique transactionnelle. Les brokers échangent entre eux afin d’identifier les besoins de routage des messages. C'est-à-dire que lorsqu’une application « D » indique à son broker local qu’elle est en lecture sur telle queue ou tel topic, le broker local échange avec les autres brokers pour les informer de cette attente, et obtenir les messages de cette queue.

Notons qu’il n’y a pas de notion de « broker affecté à la gestion d’une queue », ni de « queue affectée à un broker », la gestion de toutes les queues est véritablement distribuée entre les brokers.

Tolérance aux pannes

Nous avons abordé plus haut, en évoquant la topologie, la question de la tolérance aux pannes réseau, aux pertes de connectivité.

Voyons maintenant la tolérance aux pannes au niveau d’un broker particulier.

Les techniques mises en œuvre sont en fait les mêmes que pour n’importe quel serveur d’application : redondance du serveur et partage des données.

Réplication maître-esclave

Lorsqu’on met en place une réplication d’un broker maître vers un broker esclave, chaque broker possède son propre stockage, le broker maître adresse chaque message reçu à l’esclave, et le message n’est acquitté à l’application que lorsqu’il a été sécurisé sur le maître et sur l’esclave, c'est-à-dire que la réplication est synchrone.

On peut représenter cette configuration comme suit :

broker_maitre_vers_un_broker_esclave

Lorsque le broker maître devient indisponible, le broker esclave reprend la fonction et toutes les applications clientes s’adressent à lui, de manière transparente.

broker_esclave_fonctionne

Partage du stockage

Une autre configuration possible assurer la haute disponibilité du broker est le partage du système de persistance, qu’il s’agisse d’une base de données ou bien du système de fichiers.

Dans cette configuration, il n’y a qu’un stockage, partagé entre le maître et l’esclave. Le maître détient un verrou sur une table ou un fichier, et l’esclave est en attente sur ce verrou. De sorte que lorsque le maître est arrêté, l’esclave obtient le verrou et reprend la fonction de broker principal, en accédant à tous les messages et les informations d’état qui se trouvent dans le dispositif de stockage.

On peut représenter cette configuration ainsi :

partage_stockage

Et le dispositif peut s’étendre assez facilement à de multiples brokers esclaves.

Auto-découverte

Ces clusters de brokers sont configurables et peuvent profiter des fonctionnalités d'auto-découverte. Par exemple, lors de la mise en ligne d'un broker supplémentaire (configuré correctement), les brokers en cours d'exécution le reconnaitront tout de suite comme faisant partie de la plateforme.

Tous les mécanismes de découverte automatique reposent sur le broadcast ou le multicast. Ces dernières permettent l'envoi de paquets d'information à un ensemble de machines sur un réseau sans pour autant les avoir identifiées unitairement.

L’auto-découverte par broadcast et multicast ne fonctionne pas sur l’Internet. Dans ces cas, certains MOMs autorisent l'auto-découverte à l’aide d’un serveur d’annuaire comme LDAP. Un soin particulier doit être apporté à la sécurité de la plateforme distribuée.