communication Inter-Object
COM est conçu pour permettre aux clients de communiquer en toute transparence avec les objets, quel que soit l’emplacement d’exécution de ces objets, dans le même processus, sur le même ordinateur ou sur un autre ordinateur. Cela fournit un modèle de programmation unique pour tous les types d’objets, ainsi que pour les clients d’objets et les serveurs d’objets.
Du point de vue d’un client, tous les objets sont accessibles via des pointeurs d’interface. Un pointeur doit être in-process. En fait, tout appel à une fonction d’interface atteint toujours une partie du code in-process en premier. Si l’objet est in-process, l’appel l’atteint directement, sans code d’infrastructure système intermédiaire. Si l’objet est hors processus, l’appel atteint d’abord ce qu’on appelle un objet « proxy » fourni par COM ou par l’objet (si l’implémenteur le souhaite). Le proxy package les paramètres d’appel (y compris les pointeurs d’interface) et génère l’appel de procédure distante approprié (ou tout autre mécanisme de communication dans le cas de proxys générés personnalisés) à l’autre processus ou à l’autre ordinateur sur lequel se trouve l’implémentation de l’objet. Ce processus d’empaquetage des pointeurs pour la transmission au-delà des limites de processus est appelé marshaling.
Du point de vue d’un serveur, tous les appels aux fonctions d’interface d’un objet sont effectués via un pointeur vers cette interface. Là encore, un pointeur n’a de contexte que dans un seul processus, et l’appelant doit toujours être un élément de code in-process. Si l’objet est in-process, l’appelant est le client lui-même. Sinon, l’appelant est un objet « stub » fourni par COM ou par l’objet lui-même. Le stub reçoit l’appel de procédure distante (ou tout autre mécanisme de communication dans le cas de proxys générés personnalisés) du « proxy » dans le processus client, annule les paramètres et appelle l’interface appropriée sur l’objet serveur. Du point de vue des clients et des serveurs, ils communiquent toujours directement avec un autre code in-process.
COM fournit une implémentation de marshaling, appelée marshaling standard. Cette implémentation fonctionne très bien pour la plupart des objets et réduit considérablement les exigences de programmation, ce qui rend le processus de marshaling efficacement transparent.
Toutefois, la séparation claire entre l’interface et l’implémentation de la transparence des processus de COM peut se trouver dans certaines situations. La conception d’une interface qui se concentre sur sa fonction du point de vue du client peut parfois conduire à des décisions de conception qui entrent en conflit avec l’implémentation efficace de cette interface sur un réseau. Dans de tels cas, ce qui est nécessaire n’est pas la transparence pure des processus, mais la « transparence du processus, sauf si vous avez besoin de vous soucier ». COM fournit cette fonctionnalité en permettant à un implémenteur d’objets de prendre en charge le marshaling personnalisé (également appelé marshaling IMarshal ). Le marshaling standard est, en fait, un instance de marshaling personnalisé ; il s’agit de l’implémentation par défaut utilisée lorsqu’un objet ne nécessite pas de marshaling personnalisé.
Vous pouvez implémenter le marshaling personnalisé pour permettre à un objet d’effectuer des actions différentes lorsqu’il est utilisé à partir d’un réseau que sous l’accès local et qu’il est complètement transparent pour le client. Cette architecture permet de concevoir des interfaces client/objet sans tenir compte des problèmes de performances réseau, puis de résoudre les problèmes de performances réseau sans perturber la conception établie.
COM ne spécifie pas la façon dont les composants sont structurés ; elle spécifie comment ils interagissent. COM laisse le souci de la structure interne d’un composant aux langages de programmation et aux environnements de développement. À l’inverse, les environnements de programmation n’ont pas de normes définies pour travailler avec des objets en dehors de l’application immédiate. Microsoft Visual C++, par exemple, fonctionne très bien pour manipuler des objets à l’intérieur d’une application, mais ne prend pas en charge l’utilisation d’objets en dehors de l’application. En règle générale, tous les autres langages de programmation sont les mêmes à cet égard. Par conséquent, pour fournir une interopérabilité à l’échelle du réseau, COM, par le biais d’interfaces indépendantes du langage, reprend là où les langages de programmation s’arrêtent.
La double indirection de la structure vtbl signifie que les pointeurs de la table des pointeurs de fonction n’ont pas besoin de pointer directement vers l’implémentation réelle dans l’objet réel. C’est là le cœur de la transparence des processus.
Pour les serveurs in-process, où l’objet est chargé directement dans le processus client, les pointeurs de fonction dans la table pointent directement vers l’implémentation réelle. Dans ce cas, un appel de fonction du client vers une méthode d’interface transfère directement le contrôle d’exécution à la méthode . Toutefois, cela ne peut pas fonctionner pour les objets locaux, et encore moins distants, car les pointeurs vers la mémoire ne peuvent pas être partagés entre les processus. Néanmoins, le client doit être en mesure d’appeler des méthodes d’interface comme s’il appelait l’implémentation réelle. Ainsi, le client transfère uniformément le contrôle à une méthode dans un objet en effectuant l’appel.
Un client appelle toujours des méthodes d’interface dans un objet in-process. Si l’objet réel est local ou distant, l’appel est effectué à un objet proxy, qui effectue ensuite un appel de procédure distante à l’objet réel.
Alors, quelle méthode est réellement exécutée ? La réponse est que chaque fois qu’il y a un appel à une interface hors processus, chaque méthode d’interface est implémentée par un objet proxy. L’objet proxy est toujours un objet in-process qui agit pour le compte de l’objet appelé. Cet objet proxy sait que l’objet réel est en cours d’exécution sur un serveur local ou distant.
L’objet proxy empaquette les paramètres de fonction dans certains paquets de données et génère un appel RPC à l’objet local ou distant. Ce paquet est récupéré par un objet stub dans le processus du serveur sur l’ordinateur local ou distant, qui décompresse les paramètres et effectue l’appel à l’implémentation réelle de la méthode. Lorsque cette fonction est retournée, le stub empaquetage des paramètres sortants et la valeur de retour, puis la renvoie au proxy, qui les décompresse et les retourne au client d’origine.
Ainsi, le client et le serveur se parlent toujours comme si tout était en cours. Tous les appels du client et tous les appels au serveur sont, à un moment donné, in-process. Toutefois, étant donné que la structure vtbl permet à un agent, comme COM, d’intercepter tous les appels de fonction et tous les retours de fonctions, cet agent peut rediriger ces appels vers un appel RPC si nécessaire. Bien que les appels in-process soient plus rapides que les appels hors processus, les différences de processus sont totalement transparentes pour le client et le serveur.
Pour plus d'informations, voir les rubriques suivantes :
Rubriques connexes