Le pattern « Choregraphy » peut être considéré comme l’alter ego du pattern « Orchestrator ». En effet, ce dernier s’appuie sur un point de contrôle central qui s’assure de la bonne exécution d’un flux. Au contraire, le pattern « Choregraphy » a pour objectif de décentraliser le processus décisionnel afin que chaque microservice soit en mesure de traiter l’opération sans orchestrateur central. Le service n’a besoin que de savoir effectuer l’opération pour lequel il est programmé et non de connaître l’entièreté du flux global.
Figure 6 – Implémentation d’un pattern « Choregraphy » à l’aide d’un message broker
Dans le cadre du développement d’une gateway supportant le protocole Interop’Fibre, nous avons eu à mettre en place ce pattern. Afin de garantir une haute disponibilité en évitant au maximum la création de point de de défaillance, nous avons fait le choix d’utiliser le mécanisme de chorégraphie. Nous avons utilisé un message broker RabbitMQ utilisant le protocole AMQP afin de mettre en place des files de messages de type FIFO (first-in first out). L’idée étant d’être capable d’absorber des quantités de messages conséquentes dans un intervalle de temps réduit. Les messages sont traités en conservant l’ordre d’arrivée, ce qui est indispensable dans la mesure où les messages concernent des créations, mise à jour et avancement de commandes qui doivent respecter une machine à état correspondant à une logique métier. Chaque microservice consomme les messages d’une file pour ensuite publier dans la file du microservice suivant. Les messages comportent non seulement les champs logiques qui permettent les traitements, mais aussi la machine à état des traitements à effectuer ainsi que l’état courant. Il est ainsi possible pour le microservice d’effectuer son traitement, de déduire son successeur à partir de l’état courant et de logique métier et de passer la main au microservice suivant : la décentralisation est donc complète.