Bien adapter le couplage des composants au middleware

Il est peu probable de voir des développeurs bâtir des applications distribuées sans middleware et il est encore plus improbable qu’un consensus émerge sur l’architecture et le middleware en question. Dans cet article, l’expert Tom Nolle passe en revue les difficultés du couplage de composants et comment le Cloud y injecte ses propres spécificités comme les microservices.

Un architecte qui s’occupe d’applications distribuées doit conserver le contrôle simultané du couplage de composants et du middleware. Cela comprend l’identification des modèles premiers de couplage, adopter une vision Cloud de ces modèles, recenser les implications des modèles sur le développement et associer le couplage à une architecture middleware.

Faire passer les tâches entre composants est la base en matière de développement distribué, et la base de la réutilisation de composants. Le Cloud a relié cette mise en composants, et le couplage, à l’efficacité des ressources et à l’agilité, ce qui a des implications profondes sur la façon de coupler les composants et de développer des applications distribuées. Il est important de comprendre les approches autour du middleware.

La question la plus fondamentale est de savoir si les processus appelés et appelants sont synchronisés en temps réel. Cela signifie qu’un message qui nécessite un service peut être dispatché seulement s’il peut être reçu. Aujourd’hui, les interfaces qui passent les messages supportent le couplage en temps réel et les middlewares proposent des systèmes de queuing qui permettent d’interroger des composants porteurs de messages – si de nombreuses requêtes sont réalisées et le composant de destination n’est pas capable de les recevoir.

La seconde question à se poser sur les middlewares est de savoir si le requêtage de services est « blocking » (bloquant) ou « non-blocking » (non bloquant). Si un message est envoyé, l’envoyeur peut, en théorie, soit attendre une réponse (« blocking ») ou continuer à faire autre chose (« non-blocking »).  Cela est identique côté receveur. Bloquer les appels vers un autre composant stoppe le processus appelant jusqu’à ce que le service soit finalisé et le résultat retourné – cela est facile à développer. Lorsque le « non-blocking » est utilisé, les applications doivent reconnaître le retour des réponses aux messages envoyés pour traitement, et cela nécessite une implémentation plus sophistiquée. Ce modèle est souvent appelé gestionnaire d’événements « Event Handler » car cela implique que les composants travaillent de façon asynchrone.

Passons au développement Cloud. Le Cloud a vulgarisé le modèle RESTful, par lequel les messages transitent vers des composants sans état pour traitement. Dans un modèle sans état, chaque message est traité comme entité et c’est la responsabilité de l’appelant d’un composant RESTful de conserver le contexte ou état dans une série de tâches.

L’approche RESTful en matière de gestion de workflows entre composants contraste avec le modèle RPC (Remote Procedure Call), plus traditionnel, qui est généralement utilisé avec CORBA et la SOA. Avec RPC, un composant applicatif transmet à un composant distant en l’appelant comme s’il était en local. L’état du composant appelant est ainsi étroitement couplé à celui du composant appelé.

Les modèles RPC supportent les modes synchrone et asynchrone, avec le bon design. Les interfaces RESTful, conçues largement pour les applications Web qui nécessitent de nombreux événements concurrents, sont plus asynschrones.  Une bonne conception de composants Cloud tend vers un design pattern liée à un gestionnaire d’événements et non bloquant.

Le dernier point est celui de la directionalité. Dans l’architecture middleware traditionnelle, les développeurs ont la possibilité de bâtir des flux duplex (requête/réponse) ou simplex (unidirectionnels), où les requêtes et les réponses sont des événements distincts. Les interfaces de gestion des messages sont plus souvent utilisés pour des flux duplex, alors que les middlewares orientés messages des flux simplex.

Côté middleware, les problèmes de couplage sont mieux contrôlés en considérant les applications, non pas comme une série de composants mais comme des threads de processus. Les threads d’une application Web sont multiples côté client et convergent vers le serveur. Dans la plupart des cas, les clients sont intrinsèquement un thread unique et bloquant.

Un thread transactionnel dans un processus vraiment distribué est une chaîne d’événements. Il est commun d’avoir recours à un bus de services ou de messages pour faire la médiation de ce couplage. Traduire cela sur le Cloud créerait davantage de couplage rigide. La gestion des états au sein des messages, associée à un middleware orienté-message et aux interfaces RESTful, peut créer un framework prêt pour le Cloud.

Les trois attributs principaux du middleware peuvent être adaptés aux pratiques du Cloud, comme les microservices, mais le modèle MOM (Message Oriented middleware) est plus facile à harmoniser. Toutefois, les composants peuvent être collectés au sein d’agrégations qui reposent sur un mécanisme de couplage différent.

Le point important est que le couplage de composants doit être optimisé en fonction de la nature de l’application, d’abord, puis au middleware et interfaces qui le supportent, ensuite. Pour faire cela, utilisez l’architecture middleware la moins complexe avec l’implémentation la plus ouverte.