Détails du marshaling

Si vous utilisez le marshaling standard, COM gère tous les détails décrits ici pour vous. Toutefois, il y a quelques programmeurs qui ont besoin de ces détails et pour ceux qui s’intéressent aux informations sous-jacentes. Le marshaling est le processus d’empaquetage et de déballage des paramètres afin qu’un appel de procédure distante puisse avoir lieu.

Différents types de paramètres sont marshalés de différentes manières. Par exemple, le marshaling d’un paramètre entier implique simplement de copier la valeur dans la mémoire tampon de messages. (Même dans ce cas simple, il existe des problèmes tels que l’ordre des octets à traiter dans les appels entre ordinateurs.) Toutefois, le marshaling d’un tableau est un processus plus complexe. Les membres du tableau sont copiés dans un ordre spécifique afin que l’autre côté puisse reconstruire le tableau exactement. Lorsqu’un pointeur est marshalé, les données vers laquelle pointe le pointeur sont copiées en suivant les règles et conventions pour traiter les pointeurs imbriqués dans les structures. Des fonctions uniques existent pour gérer le marshaling de chaque type de paramètre.

Avec le marshaling standard, les proxys et les stubs sont des ressources à l’échelle du système pour l’interface et interagissent avec le canal via un protocole standard. Le marshaling standard peut être utilisé à la fois par des interfaces définies par COM standard et par des interfaces personnalisées, comme suit :

• Dans le cas de la plupart des interfaces COM, les proxys et les stubs pour le marshaling standard sont des objets composant in-process qui sont chargés à partir d’une DLL à l’échelle du système fournie par COM dans Ole32.dll.
• Dans le cas d’interfaces personnalisées, les proxys et les stubs pour le marshaling standard sont générés par le concepteur d’interface, généralement avec MIDL. Ces proxys et stubs sont configurés de manière statique dans le Registre, de sorte que tout client potentiel peut utiliser l’interface personnalisée au-delà des limites de processus. Ces proxys et stubs sont chargés à partir d’une DLL qui se trouve via le registre système, à l’aide de l’ID d’interface (IID) pour l’interface personnalisée qu’ils marshalent.
• Alternative à l’utilisation de MIDL pour générer des proxys et des stubs pour des interfaces personnalisées, une bibliothèque de types peut être générée à la place et le moteur de marshaling piloté par la bibliothèque de type fourni par le système marshale l’interface.

En guise d’alternative au marshaling standard, une interface (standard ou personnalisée) peut utiliser le marshaling personnalisé. Avec le marshaling personnalisé, un objet implémente dynamiquement les proxys au moment de l’exécution pour chaque interface qu’il prend en charge. Pour une interface donnée, l’objet peut sélectionner le marshaling standard fourni par COM ou le marshaling personnalisé. Ce choix est effectué par l’objet sur une base interface par interface. Une fois que le choix est fait pour une interface donnée, il reste en vigueur pendant la durée de vie de l’objet. Toutefois, une interface sur un objet peut utiliser le marshaling personnalisé tandis qu’une autre utilise le marshaling standard.

Le marshaling personnalisé est intrinsèquement propre à l’objet qui l’implémente. Il utilise des proxys implémentés par l’objet et fournis au système à la demande au moment de l’exécution. Les objets qui implémentent le marshaling personnalisé doivent implémenter l’interface IMarshal , contrairement aux objets qui prennent en charge le marshaling standard.

Si vous décidez d’écrire une interface personnalisée, vous devez fournir une prise en charge du marshaling pour celle-ci. En règle générale, vous fournissez une DLL de marshaling standard pour l’interface que vous concevez. Vous pouvez créer le code proxy/stub et la DLL proxy/stub, ou créer une bibliothèque de types que COM utilisera pour effectuer un marshaling piloté par les données (à l’aide des données de la bibliothèque de types).

Pour qu’un client effectue un appel à une méthode d’interface dans un objet dans un autre processus, cela implique la coopération de plusieurs composants. Le proxy standard est un élément de code spécifique à l’interface qui réside dans l’espace de processus du client et prépare les paramètres d’interface pour la transmission. Il les empaquetage, ou marshale, de telle sorte qu’ils puissent être recréés et compris dans le processus de réception. Le stub standard, qui est également un élément de code spécifique à l’interface, réside dans l’espace de processus du serveur et inverse le travail du proxy. Le stub déballe ou démarshale les paramètres envoyés et les transfère à l’application objet. Il empaquette également les informations de réponse à renvoyer au client.

Notes

Les lecteurs plus familiarisés avec RPC que COM peuvent être utilisés pour voir les termes stub client et stub serveur. Ces termes sont analogues à proxy et stub.

 

Composants des communications interprocessus

Le diagramme suivant montre le flux de communication entre les composants impliqués. Du côté client de la limite de processus, l’appel de méthode du client passe par le proxy, puis sur le canal, qui fait partie de la bibliothèque COM. Le canal envoie la mémoire tampon contenant les paramètres marshalés à la bibliothèque d’exécution RPC, qui la transmet au-delà de la limite de processus. L’heure d’exécution RPC et les bibliothèques COM existent des deux côtés du processus. La distinction entre le canal et l’exécution RPC est une caractéristique de cette implémentation et ne fait pas partie du modèle de programmation ou du modèle conceptuel pour les objets client/serveur COM. Les serveurs COM voient uniquement le proxy ou le stub et, indirectement, le canal. Les implémentations futures peuvent utiliser différentes couches sous le canal ou aucune couche.

Rubriques connexes

Channel

Communication inter-objets

Microsoft RPC

Proxy

Stub