Modèles d’architecture logicielle : le modèle de courtier

Les modèles sont une abstraction importante dans le développement de logiciels modernes et l’architecture logicielle. Ils offrent une terminologie bien définie, une documentation propre et l’apprentissage des meilleurs. Le Broker Pattern structure les systèmes logiciels distribués qui interagissent avec les appels de service à distance. Il est responsable de la coordination des communications, de leurs résultats et des exceptions.

Le Broker Pattern du livre “Architecture logicielle orientée modèle, volume 1” aide à résoudre de nombreux défis des systèmes distribués. Il peut s’agir, par exemple, de trouver le bon fournisseur de services, de communiquer avec eux en toute sécurité, d’utiliser le bon langage de programmation ou de gérer les erreurs. Je n’entrerai pas dans les détails dans cet article. destiné uniquement à donner un aperçu approximatif du modèle de courtier. Plus d’informations peuvent être trouvées dans le livre “Architecture logicielle orientée modèle, volume 1“.

Courtier

But

• Un système logiciel complexe doit être conçu comme une série de sous-systèmes découplés et interactifs.
• Le service utilisé doit être transparent pour le client.
• Cela a les conséquences suivantes :
• Tous les sous-systèmes doivent communiquer entre eux via un protocole de communication interprocessus (IPC).
• Un sous-système doit trouver son service approprié.
• Les services doivent être gérés.

Solution

• Vous introduisez un courtier qui réunit le fournisseur de services et l’utilisateur de services.
• Le fournisseur de services s’inscrit auprès du courtier.
• Le client fait une demande au courtier, qui le connecte ensuite au fournisseur de services.
• Le courtier fournit l’infrastructure pour communiquer, trouver et configurer les sous-systèmes via une simple API.

Structure

Le courtier se compose de cinq composants :

Client

• Implémente les fonctionnalités de l’application et
• envoie des requêtes au serveur via le clientseitig Proxy.

clientseitig Proxy

• Encapsule les fonctions spécifiques au système,
• parle la langue du client et
• sert d’intermédiaire entre le client et le courtier.

Server

• Met en œuvre des services et
• s’inscrit auprès du courtier.

serverseitig Proxy

• Services du serveur d’appels,
• parle la langue du serveur
• encapsule des fonctions spécifiques au système et
• sert d’intermédiaire entre le serveur et le courtier.

Broker

• Enregistre les serveurs et les désenregistre,
• transmet des messages et des erreurs et
• trouve des serveurs.

Il existe d’autres aspects intéressants de l’architecture du courtier.

Langage de définition d’interface

Typiquement, les services offerts par le serveur sont définis dans un langage de définition d’interface (IDL). C’est la base du proxy côté client et du proxy côté serveur. Voici les deux étapes typiques :

1. Utilisation de l’IDL indépendant du langage de programmation pour créer le stub et le squelette d’un langage de programmation spécifique. Ceci est souvent possible pour différents langages de programmation.
2. Implémentation du proxy côté client et du proxy côté serveur en fonction du stub et du squelette.

L’IDL peut également être enregistré dans le courtier afin que le courtier puisse trouver le proxy côté serveur approprié lorsque le côté client le lui demande.

L’avantage de l’architecture de courtier est que les clients et les serveurs peuvent communiquer entre eux même s’ils parlent des langages de programmation différents, par exemple.

Jusqu’à présent, j’ai décrit la structure statique du modèle Broker. Je vais maintenant examiner l’interaction entre le client et le serveur.

Le client a une demande

Si un client veut utiliser un service, il le demande au courtier. Ce dernier renvoie le proxy côté client qui implémente l’interface du service. Le proxy côté client gère la mise en cache des données, la communication interprocessus ou la préparation des données (Triage/Sérialisation). Il se connecte au proxy côté serveur, qui appelle le serveur. Le proxy côté serveur a une tâche similaire à celle du proxy côté client : il prépare les données et parle la langue du serveur. Lorsque le serveur renvoie le résultat de l’appel de fonction, il invoque son proxy côté serveur, qui communique avec le côté client.

Le serveur se connecte

Lors de l’initialisation du système, le courtier démarre lui-même et entre dans sa boucle d’événements. Le serveur s’initialise et s’enregistre auprès du courtier. Le serveur reçoit la confirmation d’inscription du courtier et entre dans sa boucle d’événements.

Courtiers supplémentaires

Parfois, il y a plus d’un courtier. Un courtier peut donc déléguer la demande de service à un autre courtier. Dans cette architecture avancée, chaque courtier doit prendre en charge deux protocoles. Un protocole interne pour son proxy côté client et son proxy côté serveur, et un protocole externe pour l’autre courtier.

Il existe de nombreux exemples d’architectures de courtier.

exemples

SunRPC:

Le programme rpcgen génère des stubs, des squelettes et un fichier XDR pour la conversion de données à partir d’une description d’interface. rpcgen propose une API pour les appels de fonction à distance en C.

Invocation de méthode à distance (RMI):

Le rmic-Compiler génère les stubs et les squelettes à partir d’une interface serveur en Java. Contrairement aux références de fonction dans SunRPC, ce sont des références d’objet. Depuis Java 5, les stubs et les squelettes sont générés implicitement par la machine virtuelle Java.

Architecture CORBA (Common Object Request Broker):

CORBA utilise l’IDL pour la description de l’interface. La syntaxe de l’IDL est orientée C++. CORBA utilise des objets similaires à RMI. Implémentations standardisées de IDL2Language Des compilateurs sont disponibles pour Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I et Python.

Protocole d’accès aux objets simples (SOAP):

En tant que langage de description d’interface Langage de définition de service Web (WSDL) utilisé. WSDL est un protocole basé sur du texte (XML). Ce protocole n’est pas seulement déclaratif, mais spécifie également le type de transmission de données et un service.

UN wsdl2Compiler Le générateur de code est disponible en Java, C++, Python, Perl, …

• Implémentation C++ : gSAVON

Avantages et inconvénients

Avantages

• Indépendance géographique du client et du serveur par l’intermédiaire.
• Le client est indépendant des changements d’implémentation du serveur.
• Les modifications apportées à l’IDL peuvent être facilement mises en œuvre, de sorte que seuls des ajustements mineurs sont nécessaires sur le client et le serveur.
• Il est facile de porter le courtier vers un autre système car le client et le serveur n’utilisent pas les fonctionnalités natives.
• L’ajout de clients ou de serveurs qui parlent d’autres langages de programmation est assez facile si un IDL est disponible pour le compilateur de langage de programmation.
• De nouveaux services peuvent être ajoutés facilement car ils peuvent tirer parti de l’architecture de courtier existante.
• SOAP est un protocole basé sur du texte ; cela facilite l’analyse des communications avec les outils de ligne de commande basés sur UNIX ou la mise en œuvre d’un programme simple qui envoie du texte.

Désavantages

• Du fait des nombreuses indirections (client -> représentant côté client -> broker -> représentant côté serveur -> serveur), la mise à disposition des données et la communication entre les processus, les performances sont souvent insuffisantes ; après la communication initiale entre le proxy côté client et le proxy côté serveur, les deux composants se parlent souvent directement, sans le courtier intermédiaire.
• La communication des parties dépend de nombreux composants et est donc difficile à déboguer en cas d’erreur ; contrairement à SOAP, les autres protocoles sont binaires

Et après?

Le Model View Controller (MVC) est l’un des modèles architecturaux classiques. Il divise la logique de programme d’une interface utilisateur en un modèle, une vue et un contrôleur de composants individuels. Le modèle gère les données et les règles de l’application. La vue restitue les données et le contrôleur interagit avec l’utilisateur. Je présenterai MVC dans mon prochain article.

(rme)