communication Inter-Object
COM est conçu pour permettre aux clients de communiquer de manière transparente avec des objets, quel que soit l’endroit où ces objets sont en cours d’exécution, 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 et 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 un élément de 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’il appelle un objet « proxy » fourni par COM ou par l’objet (si l’implémenteur le souhaite). Les paramètres d’appel de proxy (y compris les pointeurs d’interface) et génèrent l’appel de procédure distante approprié (ou un autre mécanisme de communication dans le cas de proxys générés personnalisés) vers l’autre processus ou l’autre ordinateur où se trouve l’implémentation de l’objet. Ce processus d’empaquetage de pointeurs pour la transmission entre les 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 a un contexte uniquement 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 un autre mécanisme de communication dans le cas de proxys générés personnalisés) à partir 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 de 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 de l’interface par rapport à l’implémentation de la transparence du processus COM peut, toutefois, se trouver dans certaines situations. La conception d’une interface qui se concentre sur sa fonction du point de vue du client peut parfois entraîner des décisions de conception qui entrent en conflit avec une implémentation efficace de cette interface sur un réseau. Dans les cas comme celui-ci, ce qui est nécessaire n’est pas la transparence pure du 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 de marshaling personnalisé (également appelé marshaling IMarshal). Le marshaling standard est, en fait, une 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 différentes actions lorsqu’il est utilisé à partir d’un réseau par opposition à celui utilisé 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 plus tard pour résoudre les problèmes de performances réseau sans perturber la conception établie.
COM ne spécifie pas comment les composants sont structurés ; il spécifie la façon dont 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 l’utilisation d’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, via des interfaces indépendantes du langage, récupère l’emplacement où les langages de programmation quittent.
L’indirection double 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 le cœur de la transparence du 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, même 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é vers 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 existe 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 au nom de l’objet appelé. Cet objet proxy sait que l’objet réel est en cours d’exécution dans un serveur local ou distant.
L’objet proxy regroupe 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 regroupe les paramètres sortants et la valeur de retour et les renvoie au proxy, ce qui les décompresse et les retourne au client d’origine.
Ainsi, le client et le serveur communiquent toujours entre eux comme si tout était in-process. 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 complètement transparentes pour le client et le serveur.
Pour plus d’informations, consultez les rubriques suivantes :
Rubriques connexes