Inter-Object Kommunikation

COM ist so konzipiert, dass Clients transparent mit Objekten kommunizieren können, unabhängig davon, wo diese Objekte im selben Prozess, auf demselben Computer oder auf einem anderen Computer ausgeführt werden. Dies bietet ein einzelnes Programmiermodell für alle Objekttypen und sowohl für Objektclients als auch für Objektserver.

Aus Sicht eines Clients erfolgt der Zugriff auf alle Objekte über Schnittstellenzeiger. Ein Zeiger muss in Bearbeitung sein. Tatsächlich erreicht jeder Aufruf einer Schnittstellenfunktion immer zuerst einen Teil des In-Process-Codes. Wenn das Objekt in Bearbeitung ist, erreicht der Aufruf es direkt, ohne dazwischen liegenden Systeminfrastrukturcode. Wenn das Objekt prozessexverwendet ist, erreicht der Aufruf zunächst ein sogenanntes "Proxy"-Objekt, das entweder von COM oder vom -Objekt bereitgestellt wird (wenn der Implementierer möchte). Die Proxypakete rufen Parameter (einschließlich aller Schnittstellenzeiger) auf und generieren den entsprechenden Remoteprozeduraufruf (oder einen anderen Kommunikationsmechanismus bei benutzerdefinierten generierten Proxys) für den anderen Prozess oder den anderen Computer, auf dem sich die Objektimplementierung befindet. Dieser Prozess der Paketierung von Zeigern für die Übertragung über Prozessgrenzen hinweg wird als Marshalling bezeichnet.

Aus Sicht eines Servers werden alle Aufrufe der Schnittstellenfunktionen eines Objekts über einen Zeiger auf diese Schnittstelle ausgeführt. Auch hier hat ein Zeiger nur in einem einzigen Prozess Kontext, und der Aufrufer muss immer ein Teil des prozessbezogenen Codes sein. Wenn das Objekt in Bearbeitung ist, ist der Aufrufer der Client selbst. Andernfalls ist der Aufrufer ein stub-Objekt, das entweder von COM oder vom -Objekt selbst bereitgestellt wird. Der Stub empfängt den Remoteprozeduraufruf (oder einen anderen Kommunikationsmechanismus bei benutzerdefinierten generierten Proxys) vom "Proxy" im Clientprozess, entmarshalt die Parameter und ruft die entsprechende Schnittstelle für das Serverobjekt auf. Aus Der Sicht von Clients und Servern kommunizieren sie immer direkt mit einem anderen in-Process-Code.

COM stellt eine Implementierung des Marshallings bereit, die als Standard-Marshalling bezeichnet wird. Diese Implementierung funktioniert für die meisten Objekte sehr gut und reduziert die Programmieranforderungen erheblich, sodass der Marshallingprozess effektiv transparent wird.

Die klare Trennung der Schnittstelle von der Implementierung der Prozesstransparenz von COM kann jedoch in einigen Situationen in den Weg kommen. Der Entwurf einer Schnittstelle, die sich aus Sicht des Clients auf seine Funktion konzentriert, kann manchmal zu Entwurfsentscheidungen führen, die mit der effizienten Implementierung dieser Schnittstelle in einem Netzwerk in Konflikt stehen. In solchen Fällen ist nicht reine Prozesstransparenz erforderlich, sondern "Prozesstransparenz, es sei denn, Sie müssen sich darum kümmern". COM bietet diese Funktion, indem es einem Objekt implementor ermöglicht wird, benutzerdefiniertes Marshalling (auch als IMarshal-Marshalling bezeichnet) zu unterstützen. Standard-Marshalling ist tatsächlich eine Instanz des benutzerdefinierten Marshallings. es ist die Standardimplementierung, die verwendet wird, wenn ein Objekt kein benutzerdefiniertes Marshalling erfordert.

Sie können benutzerdefiniertes Marshalling implementieren, damit ein Objekt andere Aktionen ausführen kann, wenn es über ein Netzwerk verwendet wird, als es unter lokalem Zugriff verwendet wird, und es für den Client vollständig transparent ist. Diese Architektur ermöglicht es, Client-/Objektschnittstellen ohne Berücksichtigung von Netzwerkleistungsproblemen zu entwerfen und später Netzwerkleistungsprobleme zu beheben, ohne den eingerichteten Entwurf zu unterbrechen.

COM gibt nicht an, wie Komponenten strukturiert sind. gibt an, wie sie interagieren. COM überlässt die Bedenken hinsichtlich der internen Struktur einer Komponente den Programmiersprachen und Entwicklungsumgebungen. Umgekehrt gibt es in Programmierumgebungen keine festgelegten Standards für die Arbeit mit Objekten außerhalb der unmittelbaren Anwendung. Microsoft Visual C++ funktioniert beispielsweise sehr gut zum Bearbeiten von Objekten innerhalb einer Anwendung, bietet aber keine Unterstützung für die Arbeit mit Objekten außerhalb der Anwendung. Im Allgemeinen sind alle anderen Programmiersprachen in dieser Hinsicht identisch. Um netzwerkweite Interoperabilität zu gewährleisten, wird COM daher über sprachunabhängige Schnittstellen an den Stellen verwendet, an denen Programmiersprachen nicht mehr vorhanden sind.

Die doppelte Dekonstruktion der vtbl-Struktur bedeutet, dass die Zeiger in der Tabelle der Funktionszeiger nicht direkt auf die tatsächliche Implementierung im echten Objekt verweisen müssen. Dies ist der Kern der Prozesstransparenz.

Bei Prozessservern, bei denen das Objekt direkt in den Clientprozess geladen wird, zeigen die Funktionszeiger in der Tabelle direkt auf die tatsächliche Implementierung. In diesem Fall überträgt ein Funktionsaufruf vom Client an eine Schnittstellenmethode die Ausführungssteuerung direkt an die -Methode. Dies funktioniert jedoch nicht für lokale Objekte, geschweige denn für Remoteobjekte, da Zeiger auf den Arbeitsspeicher nicht von Prozessen gemeinsam genutzt werden können. Trotzdem muss der Client Schnittstellenmethoden so aufrufen können, als würde er die tatsächliche Implementierung aufrufen. Daher überträgt der Client die Steuerung gleichmäßig an eine Methode in einem Objekt, indem er den Aufruf vornimmt.

Ein Client ruft immer Schnittstellenmethoden in einem In-Process-Objekt auf. Wenn das tatsächliche Objekt lokal oder remote ist, erfolgt der Aufruf an ein Proxyobjekt, das dann einen Remoteprozeduraufruf an das tatsächliche Objekt vornimmt.

Welche Methode wird also tatsächlich ausgeführt? Die Antwort ist, dass bei jedem Aufruf einer Out-of-Process-Schnittstelle jede Schnittstellenmethode von einem Proxyobjekt implementiert wird. Das Proxyobjekt ist immer ein Prozessobjekt, das im Namen des aufgerufenen Objekts fungiert. Dieses Proxyobjekt weiß, dass das eigentliche Objekt auf einem lokalen oder Remoteserver ausgeführt wird.

Das Proxyobjekt packt die Funktionsparameter in einigen Datenpaketen zusammen und generiert einen RPC-Aufruf an das lokale oder Remoteobjekt. Dieses Paket wird von einem Stubobjekt im Serverprozess auf dem lokalen computer oder einem Remotecomputer übernommen, das die Parameter entpackt und die tatsächliche Implementierung der Methode aufruft. Wenn diese Funktion zurückgegeben wird, packt der Stub alle Outparameter und den Rückgabewert und sendet sie zurück an den Proxy, der sie entpackt und an den ursprünglichen Client zurückgibt.

Daher kommunizieren Client und Server immer miteinander, als ob alles in Bearbeitung wäre. Alle Aufrufe vom Client und alle Aufrufe an den Server werden zu einem bestimmten Zeitpunkt verarbeitet. Da die vtbl-Struktur es einem Agent wie COM jedoch ermöglicht, alle Funktionsaufrufe und alle Rückgaben von Funktionen abzufangen, kann dieser Agent diese Aufrufe bei Bedarf an einen RPC-Aufruf umleiten. Obwohl In-Process-Aufrufe schneller sind als Out-of-Process-Aufrufe, sind die Prozessunterschiede für Client und Server vollständig transparent.

Weitere Informationen finden Sie unter den folgenden Themen:

COM-Clients und -Server

Marshallen von Schnittstellen