Inter-Object Kommunikation
COM ist so konzipiert, dass Clients transparent mit Objekten kommunizieren können, unabhängig davon, wo diese Objekte ausgeführt werden – im selben Prozess, auf demselben Computer oder auf einem anderen Computer. Dies stellt ein einzelnes Programmiermodell für alle Objekttypen und sowohl für Objektclients als auch für Objektserver bereit.
Aus Der Sicht eines Clients werden über Schnittstellenzeiger auf alle Objekte zugegriffen. Ein Zeiger muss in Bearbeitung sein. Tatsächlich erreicht jeder Aufruf einer Schnittstellenfunktion immer zuerst einen Teil des prozessinternen Codes. Wenn das Objekt im Prozess ist, erreicht der Aufruf es direkt, ohne dazwischen liegenden Systeminfrastrukturcode. Wenn das Objekt außerhalb des Prozesses liegt, erreicht der Aufruf zuerst das von COM oder vom Objekt bereitgestellte "Proxyobjekt" (falls der Implementor wünscht). Die Proxypakete rufen Parameter (einschließlich aller Schnittstellenzeiger) auf und generieren den entsprechenden Remoteprozeduraufruf (oder anderen Kommunikationsmechanismus im Falle von benutzerdefinierten generierten Proxys) für den anderen Prozess oder den anderen Computer, auf dem sich die Objektimplementierung befindet. Dieser Prozess von Verpackungszeigern für die Übertragung über Prozessgrenzen hinweg wird Marshalinggenannt.
Aus Sicht eines Servers werden alle Aufrufe der Schnittstellenfunktionen eines Objekts über einen Zeiger auf diese Schnittstelle vorgenommen. Auch hier weist ein Zeiger nur einen Kontext in einem einzelnen Prozess auf, und der Aufrufer muss immer ein Teil des In-Process-Codes sein. Wenn das Objekt im Prozess 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 im Fall von benutzerdefinierten generierten Proxys) vom "Proxy" im Clientprozess, hebt die Parameter auf und ruft die entsprechende Schnittstelle auf dem Serverobjekt auf. Aus Sicht von Clients und Servern kommunizieren sie immer direkt mit einem anderen In-Process-Code.
COM bietet eine Implementierung von Marshaling, die als Standard marshalingbezeichnet wird. Diese Implementierung funktioniert sehr gut für die meisten Objekte und reduziert die Programmieranforderungen erheblich, wodurch der Marshallingprozess effektiv transparent wird.
Die klare Trennung der Schnittstelle von der Implementierung der Prozesstransparenz von COM kann jedoch in manchen Situationen auf die Art und Weise gehen. Der Entwurf einer Schnittstelle, die sich auf seine Funktion aus der Sicht des Clients konzentriert, kann manchmal zu Entwurfsentscheidungen führen, die mit einer effizienten Implementierung dieser Schnittstelle in einem Netzwerk in Konflikt stehen. In solchen Fällen ist es nicht reine Prozesstransparenz, sondern "Prozesstransparenz, es sei denn, Sie müssen sich kümmern." COM bietet diese Funktion, indem ein Objektimplementierer benutzerdefinierte Marshaling- (auch als IMarshal Marshaling bezeichnet) unterstützt. Standardmarsing ist in der Tat eine Instanz von benutzerdefinierten Marshalling; es ist die Standardimplementierung, die verwendet wird, wenn ein Objekt keine benutzerdefinierte Marshaling erfordert.
Sie können benutzerdefinierte Marshaling implementieren, damit ein Objekt unterschiedliche Aktionen ausführen kann, wenn es von einem Netzwerk aus verwendet wird, als es unter lokalem Zugriff erfolgt und 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 Probleme mit der Netzwerkleistung zu beheben, ohne den etablierten Entwurf zu unterbrechen.
COM gibt nicht an, wie Komponenten strukturiert sind; sie gibt an, wie sie interagieren. COM beunruhigt die interne Struktur einer Komponente in Programmiersprachen und Entwicklungsumgebungen. Umgekehrt haben Programmierumgebungen keine festgelegten Standards für das Arbeiten mit Objekten außerhalb der unmittelbaren Anwendung. Microsoft Visual C++ eignet sich z. B. hervorragend zum Bearbeiten von Objekten innerhalb einer Anwendung, hat jedoch keine Unterstützung für das Arbeiten mit Objekten außerhalb der Anwendung. Im Allgemeinen sind alle anderen Programmiersprachen in dieser Hinsicht identisch. Um daher netzwerkweite Interoperabilität, COM, über sprachunabhängige Schnittstellen bereitzustellen, nimmt an, wo Programmiersprachen ablassen.
Die doppelte Dereferenzierung der vtbl-Struktur bedeutet, dass die Zeiger in der Tabelle der Funktionszeiger nicht direkt auf die tatsächliche Implementierung im realen Objekt verweisen müssen. Dies ist das Herzstück der Prozesstransparenz.
Bei In-Process-Servern, auf denen das Objekt direkt in den Clientprozess geladen wird, verweisen die Funktionszeiger in der Tabelle direkt auf die tatsächliche Implementierung. In diesem Fall überträgt ein Funktionsaufruf vom Client zu einer Schnittstellenmethode direkt die Ausführungskontrolle an die Methode. Dies kann jedoch nicht für lokale Remoteobjekte verwendet werden, da Zeiger auf den Arbeitsspeicher nicht zwischen Prozessen gemeinsam genutzt werden können. Dennoch muss der Client Schnittstellenmethoden aufrufen können, als ob er die tatsächliche Implementierung aufrufe. Daher überträgt der Client die Kontrolle einheitlich an eine Methode in einem Objekt, indem er den Aufruf vornimmt.
Ein Client ruft in einigen Prozessobjekten immer Schnittstellenmethoden auf. Wenn das tatsächliche Objekt lokal oder remote ist, wird der Aufruf eines Proxyobjekts ausgeführt, das dann einen Remoteprozeduraufruf an das tatsächliche Objekt sendet.
Welche Methode wird also tatsächlich ausgeführt? Die Antwort lautet, dass jedes Mal, wenn ein Aufruf einer Out-of-Process-Schnittstelle vorhanden ist, jede Schnittstellenmethode durch ein Proxyobjekt implementiert wird. Das Proxyobjekt ist immer ein Prozessobjekt, das im Auftrag des aufgerufenen Objekts fungiert. Dieses Proxyobjekt weiß, dass das tatsächliche Objekt auf einem lokalen oder Remoteserver ausgeführt wird.
Das Proxyobjekt verpackt die Funktionsparameter in einigen Datenpaketen und generiert einen RPC-Aufruf an das lokale oder Remoteobjekt. Dieses Paket wird von einem Stubobjekt im Prozess des Servers auf dem lokalen oder einem Remotecomputer abgerufen, der die Parameter entpackt und den Aufruf der tatsächlichen Implementierung der Methode vornimmt. Wenn diese Funktion zurückgegeben wird, packt der Stub alle Out-Parameter und den Rückgabewert auf und sendet sie zurück an den Proxy, der sie entpackt und an den ursprünglichen Client zurückgibt.
So sprechen Client und Server immer miteinander, als ob alles in Bearbeitung war. Alle Aufrufe vom Client und alle Aufrufe an den Server sind irgendwann in Bearbeitung. Da die vtbl-Struktur jedoch einem Agent, z. B. COM, das Abfangen aller Funktionsaufrufe und alle Rückgaben von Funktionen zulässt, kann dieser Agent diese Aufrufe nach Bedarf an einen RPC-Aufruf umleiten. Prozessinterne Aufrufe sind zwar schneller als Out-of-Process-Aufrufe, doch sind die Prozessunterschiede für den Client und den Server vollständig transparent.
Weitere Informationen finden Sie in den folgenden Themen:
Verwandte Themen