Marshallingdetails
Wenn Sie das Standardmäßige Marshalling verwenden, verarbeitet COM alle hier beschriebenen Details für Sie. Es gibt jedoch die wenigen Programmierer, die diese Details benötigen, und für diejenigen, die an den zugrunde liegenden Informationen interessiert sind. Marshalling ist der Prozess des Verpackens und Entpackens von Parametern, damit ein Remoteprozeduraufruf erfolgen kann.
Verschiedene Parametertypen werden auf unterschiedliche Weise gemarshallt. Das Marshallen eines ganzzahligen Parameters umfasst beispielsweise das einfache Kopieren des Werts in den Nachrichtenpuffer. (Obwohl es auch in diesem einfachen Fall Probleme wie die Bytereihenfolge gibt, die bei computerübergreifenden Aufrufen behandelt werden müssen.) Das Marshallen eines Arrays ist jedoch ein komplexerer Prozess. Arraymember werden in einer bestimmten Reihenfolge kopiert, damit die andere Seite das Array genau rekonstruieren kann. Wenn ein Zeiger gemarshallt wird, werden die Daten, auf die der Zeiger verweist, gemäß den Regeln und Konventionen für den Umgang mit geschachtelten Zeigern in Strukturen kopiert. Es sind eindeutige Funktionen vorhanden, um das Marshallen jedes Parametertyps zu verarbeiten.
Beim Standardmäßigen Marshalling sind die Proxys und Stubs systemweite Ressourcen für die Schnittstelle und interagieren mit dem Kanal über ein Standardprotokoll. Das Standardmäßige Marshalling kann sowohl von COM-definierten Standardschnittstellen als auch von benutzerdefinierten Schnittstellen wie folgt verwendet werden:
- Im Fall der meisten COM-Schnittstellen sind die Proxys und Stubs für das Standardmarshalling prozessinterne Komponentenobjekte, die aus einer systemweiten DLL geladen werden, die von COM in Ole32.dll bereitgestellt wird.
- Bei benutzerdefinierten Schnittstellen werden die Proxys und Stubs für das Standardmarshalling vom Schnittstellen-Designer generiert, in der Regel mit MIDL. Diese Proxys und Stubs werden statisch in der Registrierung konfiguriert, sodass jeder potenzielle Client die benutzerdefinierte Schnittstelle über Prozessgrenzen hinweg verwenden kann. Diese Proxys und Stubs werden aus einer DLL geladen, die sich über die Systemregistrierung befindet, wobei die Schnittstellen-ID (IID) für die benutzerdefinierte Schnittstelle verwendet wird, die sie marshallen.
- Als Alternative zur Verwendung von MIDL zum Generieren von Proxys und Stubs für benutzerdefinierte Schnittstellen kann stattdessen eine Typbibliothek generiert werden, und die vom System bereitgestellte, typbibliotheksgesteuerte Marshalling-Engine marshallt die Schnittstelle.
Als Alternative zum Standardmäßigen Marshalling kann eine Schnittstelle (Standard oder benutzerdefinierte Schnittstelle) benutzerdefiniertes Marshalling verwenden. Beim benutzerdefinierten Marshalling implementiert ein Objekt dynamisch die Proxys zur Laufzeit für jede schnittstelle, die es unterstützt. Für eine beliebige Schnittstelle kann das Objekt von COM bereitgestelltes Standardmarsaling oder benutzerdefiniertes Marshalling auswählen. Diese Auswahl wird vom -Objekt auf Schnittstellenbasis getroffen. Nachdem die Auswahl für eine bestimmte Schnittstelle getroffen wurde, bleibt sie während der Lebensdauer des Objekts wirksam. Eine Schnittstelle in einem Objekt kann jedoch benutzerdefiniertes Marshalling verwenden, während eine andere das Standardmäßige Marshalling verwendet.
Benutzerdefiniertes Marshalling ist von Natur aus für das Objekt eindeutig, das es implementiert. Es verwendet Proxys, die vom -Objekt implementiert und dem System zur Laufzeit auf Anforderung zur Verfügung gestellt werden. Objekte, die benutzerdefiniertes Marshalling implementieren, müssen die IMarshal-Schnittstelle implementieren, während Objekte, die das Standardmäßige Marshalling unterstützen, dies nicht tun.
Wenn Sie sich entscheiden, eine benutzerdefinierte Schnittstelle zu schreiben, müssen Sie Marshallingunterstützung dafür bereitstellen. In der Regel stellen Sie eine Standardmäßige Marshalling-DLL für die von Ihnen entworfene Schnittstelle bereit. Sie können den Proxy-/Stubcode und die Proxy-/Stub-DLL erstellen, oder Sie können eine Typbibliothek erstellen, die COM zum datengesteuerten Marshalling verwendet (unter Verwendung der Daten in der Typbibliothek).
Damit ein Client eine Schnittstellenmethode in einem Objekt in einem anderen Prozess aufruft, ist die Zusammenarbeit mehrerer Komponenten erforderlich. Der Standardproxy ist ein schnittstellenspezifischer Code, der sich im Prozessbereich des Clients befindet und die Schnittstellenparameter für die Übertragung vorbereitet. Sie packt oder marshallt sie so, dass sie im Empfangensprozess neu erstellt und verstanden werden können. Der Standard-Stub, auch schnittstellenspezifischer Code, befindet sich im Prozessbereich des Servers und kehrt die Arbeit des Proxys um. Der Stub entpackt oder entmarshaliert die gesendeten Parameter und leitet sie an die Objektanwendung weiter. Außerdem werden Antwortinformationen zum Zurücksenden an den Client bereitgestellt.
Hinweis
Leser, die mit RPC besser vertraut sind als COM, können verwendet werden, um die Begriffe Client-Stub und Server-Stub zu sehen. Diese Begriffe sind analog zu Proxy und Stub.
Komponenten der prozessübergreifenden Kommunikation
Das folgende Diagramm zeigt den Kommunikationsfluss zwischen den beteiligten Komponenten. Auf der Clientseite der Prozessgrenze durchläuft der Methodenaufruf des Clients den Proxy und dann den Kanal, der Teil der COM-Bibliothek ist. Der Kanal sendet den Puffer, der die gemarshallten Parameter enthält, an die RPC-Laufzeitbibliothek, die ihn über die Prozessgrenze hinweg überträgt. Die RPC-Laufzeit und die COM-Bibliotheken sind auf beiden Seiten des Prozesses vorhanden. Die Unterscheidung zwischen dem Kanal und der RPC-Laufzeit ist ein Merkmal dieser Implementierung und ist nicht Teil des Programmiermodells oder des konzeptionellen Modells für COM-Client/Server-Objekte. COM-Server sehen nur den Proxy oder Stub und indirekt den Kanal. Zukünftige Implementierungen können verschiedene Ebenen unterhalb des Kanals oder keine Ebenen verwenden.
Zugehörige Themen