Freigeben über

Technische Übersicht über COM

Dieses Thema bietet eine Übersicht über das Microsoft Component Object Model (COM):

Einführung in COM

Das Microsoft Component Object Model (COM) definiert einen binären Interoperabilitätsstandard zum Erstellen wiederverwendbarer Softwarebibliotheken, die zur Laufzeit interagieren. Sie können COM-Bibliotheken verwenden, ohne dass sie in Ihre Anwendung kompiliert werden müssen. COM ist die Grundlage für eine Reihe von Microsoft-Produkten und -Technologien, z. B. Windows Medienwiedergabe und Windows Server.

COM definiert einen binären Standard, der für viele Betriebssysteme und Hardwareplattformen gilt. Für das Netzwerkcomputing definiert COM ein Standardverbindungsformat und -protokoll für die Interaktion zwischen Objekten, die auf verschiedenen Hardwareplattformen ausgeführt werden. COM ist unabhängig von der Implementierungssprache, was bedeutet, dass Sie COM-Bibliotheken mit verschiedenen Programmiersprachen wie C++ und denen im .NET Framework erstellen können.

Die COM-Spezifikation enthält alle grundlegenden Konzepte, die die plattformübergreifende Wiederverwendung von Software ermöglichen:

  • Ein binärer Standard für Funktionsaufrufe zwischen Komponenten.
  • Eine Bereitstellung für stark typisierte Gruppierungen von Funktionen in Schnittstellen.
  • Eine Basisschnittstelle, die Polymorphie, Featureermittlung und Objektlebensdauernachverfolgung bietet.
  • Ein Mechanismus, der Komponenten und ihre Schnittstellen eindeutig identifiziert.
  • Ein Komponentenladeprogramm, das Komponenteninstanzen aus einer Bereitstellung erstellt.

COM besteht aus einer Reihe von Komponenten, die zusammenarbeiten, um die Erstellung von Anwendungen zu ermöglichen, die aus wiederverwendbaren Komponenten erstellt werden:

  • Ein Hostsystem , das eine Laufzeitumgebung bereitstellt, die der COM-Spezifikation entspricht.
  • Schnittstellen , die Featureverträge definieren, und Komponenten , die Schnittstellen implementieren.
  • Server , die Komponenten für das System bereitstellen, und Clients , die die von Komponenten bereitgestellten Features verwenden.
  • Eine Registrierung , die nachverfolgt, wo Komponenten auf lokalen und Remotehosts bereitgestellt werden.
  • Ein Dienststeuerungs-Manager , der Komponenten auf lokalen und Remotehosts sucht und Server mit Clients verbindet.
  • Ein strukturiertes Speicherprotokoll , das definiert, wie durch die Inhalte von Dateien im Dateisystem des Hosts navigiert wird.

Die Aktivierung der Wiederverwendung von Code über Hosts und Plattformen hinweg ist für COM von zentraler Bedeutung. Eine wiederverwendbare Schnittstellenimplementierung wird als Komponente, Komponentenobjekt oder COM-Objekt bezeichnet. Eine Komponente implementiert eine oder mehrere COM-Schnittstellen.

Sie definieren eine benutzerdefinierte COM-Bibliothek, indem Sie die Schnittstellen entwerfen, die Ihre Bibliothek implementiert. Consumer Ihrer Bibliothek können die Funktionen ihrer Bibliothek ohne Kenntnis der Bereitstellungs- und Implementierungsdetails Ihrer Bibliothek ermitteln und verwenden.

Objekte und Schnittstellen

Ein COM-Objekt macht seine Features über eine Schnittstelle verfügbar, bei der es sich um eine Sammlung von Memberfunktionen handelt. Eine COM-Schnittstelle definiert das erwartete Verhalten und die Zuständigkeiten einer Komponente und gibt einen stark typisierten Vertrag an, der eine kleine Gruppe verwandter Vorgänge bereitstellt. Die gesamte Kommunikation zwischen COM-Komponenten erfolgt über Schnittstellen, und alle Dienste, die von einer Komponente angeboten werden, werden über ihre Schnittstelle verfügbar gemacht. Ein Aufrufer kann nur auf die Schnittstellenmemberfunktionen zugreifen. Der interne Zustand ist für einen Aufrufer nicht verfügbar, es sei denn, er wird in der Schnittstelle verfügbar gemacht.

Schnittstellen sind stark typisiert. Jede Schnittstelle verfügt über einen eigenen eindeutigen Schnittstellenbezeichner mit dem Namen IID, wodurch Konflikte vermieden werden, die mit für Menschen lesbaren Namen auftreten können. Die IID ist eine GUID (Globally Unique Identifier), die mit der universally Unique ID (UUID) identisch ist, die von der Open Software Foundation (OSF) Distributed Computing Environment (DCE) definiert wird. Wenn Sie eine neue Schnittstelle erstellen, müssen Sie einen neuen Bezeichner für diese Schnittstelle erstellen. Wenn ein Aufrufer eine Schnittstelle verwendet, muss er den eindeutigen Bezeichner verwenden. Diese explizite Identifizierung verbessert die Stabilität, indem Benennungskonflikte beseitigt werden, die zu Laufzeitfehlern führen würden.

Wenn Sie eine neue Schnittstelle definieren, können Sie mithilfe der Schnittstellendefinitionssprache (Interface Definition Language, IDL) eine Schnittstellendefinition erstellen. Aus dieser Schnittstellendefinition generiert der Microsoft IDL-Compiler Headerdateien zur Verwendung durch Anwendungen, die die -Schnittstelle verwenden, sowie Quellcode zum Verarbeiten von Remoteprozeduraufrufen. Die von Microsoft bereitgestellte IDL basiert auf einfachen Erweiterungen von DCE IDL, einem Branchenstandard für remote Procedure Call (RPC)-basierte verteiltes Computing. IDL ist ein Tool für die Benutzerfreundlichkeit des Schnittstellen-Designers und nicht von zentraler Bedeutung für die COM-Interoperabilität. Mit IDL müssen Sie keine Headerdateien für jede Programmierumgebung manuell erstellen. Weitere Informationen finden Sie unter Definieren von COM-Schnittstellen.

Vererbung wird in COM-Schnittstellen sparsam verwendet. COM unterstützt die Schnittstellenvererbung nur, um einen Vertrag wiederzuverwenden, der einer Basisschnittstelle zugeordnet ist. COM unterstützt keine selektive Vererbung. Wenn also eine Schnittstelle von einer anderen erbt, enthält sie alle Funktionen, die die Basisschnittstelle definiert. Darüber hinaus verwenden Schnittstellen nur eine einzelne Vererbung anstelle von mehrfacher Vererbung, um Funktionen von einer Basisschnittstelle abzurufen.

Schnittstellenimplementierung

Sie können keine instance einer COM-Schnittstelle selbst erstellen. Stattdessen erstellen Sie eine instance einer Klasse, die die -Schnittstelle implementiert. In C++ wird eine COM-Schnittstelle als abstrakte Basisklasse modelliert. Dies bedeutet, dass die Schnittstelle eine C++-Klasse ist, die nur reine virtuelle Memberfunktionen enthält. Eine C++-Bibliothek implementiert COM-Objekte, indem sie die Memberfunktionssignaturen von einer oder mehreren Schnittstellen erbt, jede Memberfunktion überschreibt und eine Implementierung für jede Funktion bereitstellt.

Sie können eine beliebige Programmiersprache verwenden, die das Konzept von Funktionszeigern unterstützt, um eine COM-Schnittstelle zu implementieren. In C ist eine Schnittstelle beispielsweise eine Struktur, die einen Zeiger auf eine Tabelle von Funktionszeigern enthält, einen für jede Methode in der Schnittstelle.

Wenn Sie eine Schnittstelle implementieren, muss Ihre Klasse eine Implementierung für jede Funktion in der Schnittstelle bereitstellen. Wenn die -Klasse keine Aufgaben in einer Schnittstellenfunktion hat, kann die Implementierung eine einzelne return-Anweisung sein.

Eine COM-Klasse wird mithilfe einer eindeutigen 128-Bit-Klassen-ID (CLSID) identifiziert, die eine Klasse einer bestimmten Bereitstellung im Dateisystem zuordnet, die für Windows eine DLL oder EXE ist. Eine CLSID ist eine GUID, was bedeutet, dass keine andere Klasse dieselbe CLSID aufweist. Die Verwendung eindeutiger Klassenbezeichner verhindert Namenskonflikte zwischen Klassen. Beispielsweise können zwei verschiedene Anbieter eine Klasse namens CStack schreiben, aber beide Klassen verfügen über eine eindeutige CLSID, sodass jede Möglichkeit einer Kollision vermieden wird.

Sie erhalten eine neue CLSID mithilfe der CoCreateGuid-Funktion oder mithilfe eines COM-Erstellungstools wie Visual Studio, das diese Funktion intern aufruft.

Die IUnknown-Schnittstelle

Alle COM-Schnittstellen erben von der IUnknown-Schnittstelle . Die IUnknown-Schnittstelle enthält die grundlegenden COM-Vorgänge für Polymorphismus und instance Lebensdauerverwaltung. Die IUnknown-Schnittstelle verfügt über drei Memberfunktionen namens QueryInterface, AddRef und Release. Alle COM-Objekte sind erforderlich, um die IUnknown-Schnittstelle zu implementieren.

Die QueryInterface-Memberfunktion bietet Polymorphie für COM. Rufen Sie QueryInterface auf, um zur Laufzeit zu bestimmen, ob ein COM-Objekt eine bestimmte Schnittstelle unterstützt. Das COM-Objekt gibt einen Schnittstellenzeiger im ppvObject Parameter zurück, wenn es die angeforderte Schnittstelle implementiert, andernfalls wird zurückgegeben NULL. Die QueryInterface-Memberfunktion ermöglicht die Navigation zwischen allen Schnittstellen, die ein COM-Objekt unterstützt.

Die Lebensdauer eines COM-Objekts instance wird durch seine Verweisanzahl gesteuert. Die IUnknown-MemberfunktionenAddRef und Release steuern die Anzahl. AddRef erhöht die Anzahl, und Release verringert die Anzahl. Wenn die Verweisanzahl 0 (null) erreicht, kann die Release-Memberfunktion die instance freigeben, da sie von keinem Aufrufer verwendet wird.

Das Client-/Servermodell

Eine COM-Klasse implementiert eine Reihe von COM-Schnittstellen. Die Implementierung besteht aus Binärdateien, die ausgeführt werden, wenn ein Aufrufer mit einer instance der COM-Klasse interagiert. COM ermöglicht die Verwendung einer Klasse in verschiedenen Anwendungen, einschließlich Anwendungen, die ohne Kenntnisse einer bestimmten Klasse geschrieben wurden. Auf einer Windows-Plattform sind Klassen entweder in einer dll (Dynamic-Linked Library) oder in einer anderen Anwendung (EXE) vorhanden.

Com verwaltet auf seinem Hostsystem eine Registrierungsdatenbank aller CLSIDs für die com-Objekte, die auf dem System installiert sind. Die Registrierungsdatenbank ist eine Zuordnung zwischen jeder CLSID und dem Speicherort der DLL oder EXE, die die entsprechende Klasse enthält. COM fragt diese Datenbank ab, wenn ein Aufrufer eine instance einer COM-Klasse erstellen möchte. Der Aufrufer muss nur die CLSID kennen, um eine neue instance der Klasse anzufordern.

Die Interaktion zwischen einem COM-Objekt und seinen Aufrufenden wird als Client/Server-Beziehung modelliert. Der Client ist der Aufrufer, der ein COM-Objekt vom System anfordert, und der Server ist das Modul, das COM-Objekte enthält, die Dienste für Clients bereitstellen.

Ein COM-Client ist jeder Aufrufer, der eine CLSID an das System übergibt, um eine instance eines COM-Objekts anzufordern. Die einfachste Möglichkeit zum Erstellen eines instance besteht darin, die COM-Funktion CoCreateInstance aufzurufen.

Die CoCreateInstance-Funktion erstellt eine instance der angegebenen CLSID und gibt einen Schnittstellenzeiger des vom Client angeforderten Typs zurück. Der Client ist für die Verwaltung der Lebensdauer des instance verantwortlich, indem er seine Release-Funktion aufruft, wenn der Client die Verwendung beendet hat. Um mehrere Objekte basierend auf einer einzelnen CLSID zu erstellen, rufen Sie die CoGetClassObject-Funktion auf. Rufen Sie die GetActiveObject-Funktion auf, um eine Verbindung mit einem Objekt herzustellen, das bereits erstellt und ausgeführt wird.

Ein COM-Server stellt eine COM-Implementierung für das System bereit. Ein Server ordnet eine CLSID einer COM-Klasse zu, beherbergt die Implementierung der -Klasse, implementiert eine Klassenfactory zum Erstellen von Instanzen der -Klasse und ermöglicht das Entladen des Servers.

Hinweis

Ein COM-Server ist nicht identisch mit dem COM-Objekt, das er für das System bereitstellt.

 

Um das Erstellen eines COM-Objekts zu aktivieren, muss ein COM-Server eine Implementierung der IClassFactory-Schnittstelle bereitstellen. Clients können die CreateInstance-Methode aufrufen, um eine neue instance eines COM-Objekts anzufordern, aber in der Regel werden solche Anforderungen in der CoCreateInstance-Funktion gekapselt.

Sie können einen COM-Server entweder als freigegebene Bibliothek bereitstellen, die zur Laufzeit (DLL auf Windows-Plattformen) in den Prozess des Clients geladen wird, oder als ausführbares Modul (EXE auf Windows-Plattformen). Weitere Informationen finden Sie unter Registrieren von COM-Anwendungen.

Dienststeuerungs-Manager

Der Dienststeuerungs-Manager (SCM) verarbeitet die Clientanforderung für eine instance eines COM-Objekts. Die folgende Liste zeigt die Abfolge der Ereignisse:

  • Ein Client fordert einen Schnittstellenzeiger auf ein COM-Objekt von der COM-Bibliothek an, indem er eine Funktion wie CoCreateInstance mit der CLSID des COM-Objekts aufruft.
  • Die COM-Bibliothek fragt den SCM ab, um den Server zu finden, der der angeforderten CLSID entspricht.
  • Der SCM sucht den Server und fordert die Erstellung des COM-Objekts von der vom Server bereitgestellten Klassenfactory an.
  • Bei erfolgreicher Ausführung gibt die COM-Bibliothek einen Schnittstellenzeiger auf den Client zurück.

Nachdem das COM-System ein Serverobjekt mit einem Client verbunden hat, kommunizieren der Client und das Objekt direkt. Es gibt keinen zusätzlichen Mehraufwand beim Aufrufen über eine zwischengeschaltete Laufzeit.

Wenn Sie einen COM-Server beim Hostsystem registrieren, können Sie verschiedene Möglichkeiten für die Aktivierung des Servers angeben. Die folgende Liste zeigt die drei Möglichkeiten, wie der SCM einen COM-Server aktivieren kann:

  • Prozessintern: Der SCM gibt den Dateipfad der DLL zurück, die die Objektserverimplementierung enthält. Die COM-Bibliothek lädt die DLL und fragt sie nach dem Schnittstellenzeiger der Klassenfactory ab.
  • Lokal: Der SCM startet die lokale ausführbare Datei, die beim Start eine Klassenfactory registriert, und deren Schnittstellenzeiger ist für das System und die Clients verfügbar.
  • Remote: Das lokale SCM ruft einen Klassenfactoryschnittstellenzeiger vom SCM ab, der auf einem Remotecomputer ausgeführt wird.

Wenn ein Client ein COM-Objekt anfordert, kontaktiert die COM-Bibliothek den SCM auf dem lokalen Host. Der SCM sucht den entsprechenden COM-Server, der lokal oder remote sein kann, und der Server gibt einen Schnittstellenzeiger auf die Klassenfactory des Servers zurück. Wenn die Klassenfactory verfügbar ist, kann die COM-Bibliothek oder der Client die Klassenfactory verwenden, um das angeforderte Objekt zu erstellen. Weitere Informationen finden Sie unter Implementieren von IClassFactory.

Wiederverwendbarkeit

COM unterstützt die Wiederverwendbarkeit von Blackboxen, was bedeutet, dass die Implementierungsdetails einer wiederverwendbaren Komponente für Clients nicht verfügbar gemacht werden. Um die Wiederverwendbarkeit von Blackboxen zu erreichen, unterstützt COM zwei Mechanismen, durch die ein Objekt ein anderes wiederverwendet. Die beiden Formen der Wiederverwendung sind "Containment" und "Aggregation". Gemäß der Konvention wird das wiederverwendete Objekt als inneres Objekt bezeichnet, und das Objekt, das das innere Objekt verwendet, wird als äußeres Objekt bezeichnet.

In der Eindämmung verhält sich das äußere Objekt wie ein Client des inneren Objekts. Das äußere Objekt ist ein logischer Container für das innere Objekt. Wenn das äußere Objekt die Dienste des inneren Objekts verwendet, delegiert das äußere Objekt die Implementierung an die Schnittstellen des inneren Objekts. Dies bedeutet, dass das äußere Objekt in Bezug auf die Dienste des inneren Objekts implementiert wird. Das äußere Objekt unterstützt möglicherweise nicht dieselben Schnittstellen wie das innere Objekt, und das äußere Objekt kann die Schnittstelle eines inneren Objekts verwenden, um Teile einer anderen Schnittstelle im äußeren Objekt zu implementieren.

In der Aggregation macht das äußere Objekt Schnittstellen aus dem inneren Objekt verfügbar, als ob sie im äußeren Objekt implementiert wären. Dies ist nützlich, wenn das äußere Objekt jeden Aufruf auf einer seiner Schnittstellen immer an dieselbe Schnittstelle des inneren Objekts delegiert. Aggregation ist eine Benutzerfreundlichkeit, die es dem äußeren Objekt ermöglicht, zusätzlichen Implementierungsaufwand zu vermeiden.

Weitere Informationen finden Sie unter Wiederverwenden von Objekten.

Speicher- und Streamobjekte

COM-Objekte speichern den Zustand in einer Datei mithilfe des strukturierten Speichers. Dabei handelt es sich um eine Form des persistenten Speichers, der die Navigation des Inhalts einer Datei mithilfe der Dateisystemsemantik ermöglicht. Wenn Sie den Inhalt einer Datei auf diese Weise behandeln, werden Features wie inkrementeller Zugriff, Transaktionen und freigaben zwischen Prozessen ermöglicht.

Die COM-Spezifikation für beständigen Speicher bietet zwei Arten von Speicherelementen: Speicherobjekte und Streamobjekte. Diese Objekte werden von der COM-Bibliothek implementiert, und Benutzeranwendungen implementieren diese Speicherelemente selten. Speicherobjekte implementieren die IStorage-Schnittstelle , und Streamobjekte implementieren die IStream-Schnittstelle .

Ein Streamobjekt enthält Daten und ähnelt vom Konzept her einer einzelnen Datei in einem Dateisystem. Jeder Stream verfügt über Zugriffsrechte und einen einzelnen Suchzeiger. Über die IStream-Schnittstelle können Sie die zugrunde liegenden Daten des Datenstroms lesen, schreiben, suchen und andere Vorgänge ausführen. Ein Stream wird mithilfe einer Textzeichenfolge benannt. Es kann eine beliebige interne Struktur enthalten, da es sich um einen flachen Bytestrom handelt. Darüber hinaus ähneln die Funktionen in der IStream-Schnittstelle standardmäßigen Dateihandles-basierten Funktionen, z. B. in der ANSI C-Laufzeitbibliothek.

Ein Speicherobjekt ähnelt vom Konzept her einem Verzeichnis in einem Dateisystem. Jeder Speicher kann eine beliebige Anzahl von Unterspeicherobjekten und eine beliebige Anzahl von Streams enthalten. Jeder Speicher verfügt über eigene Zugriffsrechte. Über die IStorage-Schnittstelle können Sie Vorgänge wie Auflisten, Verschieben, Kopieren, Umbenennen, Erstellen und Löschen von Elementen ausführen. Ein Speicherobjekt speichert keine anwendungsdefinierte Daten, aber es speichert implizit die Namen der Elemente (Speicher und Streams), die es enthält.

Speicher- und Streamobjekte können zwischen Prozessen aufgeteilt werden, wenn sie gemäß der COM-Spezifikation auf einer Hostplattform implementiert werden. Dies ermöglicht Objekten, die prozessintern oder out-of-process ausgeführt werden, den gleichen inkrementellen Zugriff auf ihren Dateispeicher. Da COM separat in jeden Prozess geladen wird, werden vom Betriebssystem unterstützte freigegebene Speichermechanismen verwendet, um den Zustand geöffneter Elemente und deren Zugriffsmodi zwischen Prozessen zu kommunizieren.

Jedes Speicher- und Streamobjekt in einer strukturierten Datei hat einen Namen, um es zu identifizieren. Der Name ist eine Zeichenfolge, die einer bestimmten Konvention folgt. Weitere Informationen finden Sie unter Benennungskonventionen für Speicherobjekte. Der Name wird an IStorage-Funktionen übergeben, um anzugeben, welches Element im Speicher ausgeführt werden soll. Namen von Stammspeicherobjekten sind identisch mit Dateinamen im zugrunde liegenden Dateisystem, und diese Namen müssen den Konventionen und Einschränkungen des Dateisystems entsprechen. Zeichenfolgen, die an speicherbezogene Funktionen übergeben werden, deren Namensdateien ohne Interpretation oder Änderungen an das Dateisystem übergeben werden.

Namen von Elementen, die in Speicherobjekten enthalten sind, werden von der Implementierung des jeweiligen Speicherobjekts verwaltet. Alle Implementierungen von Speicherobjekten müssen Elementnamen mit einer Länge von 32 Zeichen unterstützen, und einige Implementierungen unterstützen möglicherweise längere Namen. Namen werden mit beibehaltener Groß-/Kleinschreibung gespeichert, sie werden jedoch ohne Beachtung der Groß-/Kleinschreibung verglichen. Anwendungen, die Speicherelementnamen definieren, müssen Namen auswählen, die in beiden Situationen funktionieren.

Sie greifen auf jedes Element in einer strukturierten Speicherdatei zu, indem Sie Funktionen und Schnittstellen verwenden, die von COM implementiert werden. Dies bedeutet, dass andere Anwendungen die Datei durchsuchen können, indem sie mit den IStorage-Schnittstellenfunktionen navigieren, die verzeichnisähnliche Dienste bereitstellen. Außerdem können andere Anwendungen die Daten der Datei verwenden, ohne die Anwendung ausführen zu müssen, die die Datei geschrieben hat. Wenn eine COM-Anwendung auf die strukturierten Speicherdateien einer anderen Anwendung zugreift, gelten standardmäßige Windows-Zugriffsrechte, und die Anwendung muss über ausreichende Berechtigungen verfügen.

Ein COM-Objekt kann sich selbst lesen und in persistenten Speicher schreiben. Ein Client fragt abhängig vom Kontext des Vorgangs eine der persistenzbezogenen Schnittstellen für das COM-Objekt ab. COM-Objekte können eine beliebige Kombination der folgenden Schnittstellen implementieren:

  • IPersistStorage: Das COM-Objekt liest und schreibt seinen persistenten Zustand in ein Speicherobjekt. Der Client stellt dem -Objekt über diese Schnittstelle einen IStorage-Zeiger bereit. Dies ist die einzige Persistenzschnittstelle, die Semantik für den inkrementellen Zugriff enthält.
  • IPersistStream: Das COM-Objekt liest und schreibt seinen persistenten Zustand in ein Streamobjekt. Der Client stellt das Objekt mit einem IStream-Zeiger über diese Schnittstelle bereit.
  • IPersistFile: Das COM-Objekt liest und schreibt seinen persistenten Zustand direkt in eine Datei auf dem zugrunde liegenden System. Diese Schnittstelle umfasst nicht IStorage oder IStream , es sei denn, auf die zugrunde liegende Datei wird über diese Schnittstellen zugegriffen, aber die IPersistFile-Schnittstelle verfügt über keine Semantik für Speicher und Streams. Der Client stellt dem Objekt einen Dateinamen bereit und ruft die Funktionen Speichern oder Laden auf.

Datenübertragung

Der strukturierte Speicher bildet die Grundlage für den Datenaustausch zwischen COM-Objekten und Prozessen, der als einheitliche Datenübertragung bezeichnet wird. Bevor COM in OLE 2 implementiert wurde, wurde die Datenübertragung unter Windows durch Übertragungsprotokolle wie zwischenablage und Drag-Drop-Protokolle angegeben. Jedes Übertragungsprotokoll verfügte über einen eigenen Satz von Funktionen, die das Protokoll an die Abfrage gebunden haben, und es war spezifischer Code erforderlich, um die einzelnen Protokolle und Austauschprozeduren zu verarbeiten. Die einheitliche Datenübertragung stellt alle Datenübertragungen mithilfe der IDataObject-Schnittstelle dar, die gängige Datenaustauschvorgänge vom Übertragungsprotokoll trennt.

Die IDataObject-Schnittstelle kapselt die standardmäßigen Get- und Set-Vorgänge für Daten, Abfragen und Enumerationen sowie Benachrichtigungen, die erkennen, wenn Sich Daten in einem Objekt ändern. Die einheitliche Datenübertragung ermöglicht umfangreiche Beschreibungen von Datenformaten sowie die Verwendung unterschiedlicher Speichermedien für die Datenübertragung.

Bei der einheitlichen Datenübertragung tauschen alle Protokolle einen Zeiger auf eine IDataObject-Schnittstelle aus. Der Server ist die Quelle der Daten und implementiert ein Datenobjekt, das in jedem Datenaustauschprotokoll verwendet werden kann. Der Client nutzt die Daten und fordert Daten von einem Datenobjekt an, wenn er einen IDataObject-Zeiger von einem beliebigen Protokoll empfängt. Nachdem der Zeigeraustausch erfolgt ist, behandeln beide Seiten den Datenaustausch einheitlich über die IDataObject-Schnittstelle .

COM definiert zwei Datenstrukturen, die eine einheitliche Datenübertragung ermöglichen. Die FORMATETC-Struktur stellt ein generalisiertes Zwischenablageformat dar, und die STGMEDIUM-Struktur stellt das Übertragungsmedium als Speicherhandle dar.

Der Client erstellt eine FORMATETC-Struktur , um den Datentyp anzugeben, den er von einer Datenquelle anfordert, und er wird von der Datenquelle verwendet, um zu beschreiben, welche Formate er bereitstellt. Der Client fragt eine Datenquelle nach den verfügbaren Formaten ab, indem er seine IEnumFORMATETC-Schnittstelle anfordert. Weitere Informationen finden Sie unter Die FORMATETC-Struktur.

Der Client erstellt eine STGMEDIUM-Struktur und übergibt sie an die GetData-Methode , und das Datenobjekt gibt die Daten in der bereitgestellten STGMEDIUM-Struktur zurück.

Die STGMEDIUM-Struktur ermöglicht es sowohl Clients als auch Datenquellen, das effizienteste Austauschmedium auszuwählen. Wenn die auszutauschenden Daten beispielsweise sehr groß sind, kann die Datenquelle anstelle von Standard Arbeitsspeicher ein datenträgerbasiertes Medium als bevorzugtes Format angeben. Diese Flexibilität ermöglicht einen effizienten Datenaustausch, der so schnell wie das Übergeben eines Zeigers auf einen IStorage oder einen IStream erfolgen kann. Weitere Informationen finden Sie unter Die STGMEDIUM-Struktur.

Ein Client einer Datenquelle erfordert möglicherweise eine Benachrichtigung, wenn sich die Daten ändern. COM verarbeitet Datenänderungsbenachrichtigungen mithilfe eines Empfehlungssenkenobjekts , das die IAdviseSink-Schnittstelle implementiert. Das Advise-Senkenobjekt und die IAdviseSink-Schnittstelle werden vom Client implementiert, der einen IAdviseSink-Zeiger an die Datenquelle übergibt. Wenn die Datenquelle eine Änderung der zugrunde liegenden Daten erkennt, ruft sie eine IAdviseSink-Methode auf, um den Client zu benachrichtigen. Weitere Informationen finden Sie unter Datenbenachrichtigung.

Remoting

COM ermöglicht remote und verteilte Berechnungen. Schnittstellenremoting ermöglicht es einer Memberfunktion, einen Schnittstellenzeiger auf ein COM-Objekt zurückzugeben, das sich in einem anderen Prozess oder auf einem anderen Hostcomputer befindet. Die Infrastruktur, die das Schnittstellenremoting ausführt, ist sowohl für den Client als auch für den Objektserver transparent. Weder der Client noch der Server benötigen die Bereitstellungsdetails des anderen, um über eine Remoteschnittstelle zu kommunizieren. Ein Client ruft Memberfunktionen auf derselben Schnittstelle auf, um mit einem COM-Objekt zu kommunizieren, das sich im Prozess befindet, auf dem lokalen Host oder auf einem Remotecomputer out-of-process ist. Lokale und Remoteaufrufe auf derselben Schnittstelle sind für den Client nicht zu unterscheiden.

Um mit einem COM-Objekt zu kommunizieren, ruft ein Client immer eine Prozessimplementierung auf. Wenn sich das COM-Objekt in Einem Prozess befindet, erfolgt der Aufruf direkt. Wenn das COM-Objekt out-of-process oder remote ist, stellt COM eine Proxyimplementierung bereit, die den Aufruf an das -Objekt mithilfe des RPC-Protokolls (Remote Procedure Call) weiterleitet.

Ein COM-Objekt empfängt immer Aufrufe von einem Client über eine Prozessimplementierung. Wenn der Aufrufer in Bearbeitung ist, erfolgt der Aufruf direkt. Wenn der Aufrufer out-of-process oder remote ist, stellt COM eine Stubimplementierung bereit, die den Remoteprozeduraufruf vom Proxy im Clientprozess empfängt.

Marshalling ist das Verfahren zum Verpacken des Aufrufstapels für die Übertragung vom Proxy an den Stub. Das Entmarshaling ist das Entpacken, das am empfangenden Ende erfolgt. Rückgabewerte werden gemarst und vom Stub auf den Proxy getrennt. Diese Art der Kommunikation wird auch als Senden eines Anrufs über das Kabel bezeichnet.

Jeder andere Datentyp verfügt über Regeln für das Marshallen. Schnittstellenzeiger verfügen auch über ein Marshallprotokoll, das in der CoMarshalInterface-Funktion gekapselt ist. In den meisten Fällen ist das vom System bereitgestellte Standardschnittstellenmarining ausreichend, aber ein COM-Objekt kann optional benutzerdefiniertes Schnittstellen marshalling implementieren, um die Erstellung von Remoteobjektproxys für sich selbst zu steuern. Weitere Informationen finden Sie unter Objektübergreifende Kommunikation.

Sicherheit

COM bietet zwei Arten von Anwendungssicherheit. Eine ist die Aktivierungssicherheit, die angibt, wie neue Objekte erstellt werden, wie Clients eine Verbindung mit neuen und vorhandenen Objekten herstellen und wie bestimmte öffentliche Dienste wie die Klassentabelle und die Laufende Objekttabelle geschützt werden. Die andere ist die Aufrufsicherheit, die angibt, wie die Sicherheit in einer eingerichteten Verbindung zwischen einem Client und einem COM-Objekt funktioniert.

Die Aktivierungssicherheit wird automatisch vom Dienststeuerungs-Manager (Service Control Manager, SCM) angewendet. Wenn der SCM eine Anforderung zum Abrufen eines COM-Objekts empfängt, überprüft er die Anforderung anhand von Sicherheitsinformationen, die in der Registrierung gespeichert sind.

SCM-Implementierungen bieten in der Regel eine registrierungsgesteuerte Konfiguration zum Verwalten bereitgestellter Klassen und für bestimmte Benutzerkonten auf dem Host. Weitere Informationen finden Sie unter Aktivierungssicherheit.

Die Aufrufsicherheit wird automatisch angewendet oder von der Anwendung erzwungen. Wenn die Anwendung Setupinformationen bereitstellt, führt COM die erforderlichen Überprüfungen durch, um die Anwendung zu schützen.

Der automatische Mechanismus überprüft die Sicherheit für den Prozess, aber nicht für einzelne Objekte oder Methoden. Wenn eine Anwendung eine differenziertere Sicherheit erfordert, stellt COM Funktionen bereit, die Anwendungen möglicherweise verwenden, um ihre eigene Sicherheitsüberprüfung auszuführen.

Die automatischen und benutzerdefinierten Mechanismen können zusammen verwendet werden, sodass eine Anwendung COM möglicherweise auffordern kann, eine automatische Sicherheitsüberprüfung durchzuführen und dann eine eigene durchzuführen.

COM-Aufrufsicherheitsdienste sind in die folgenden Kategorien unterteilt:

Häufig fragt der Client das COM-Objekt nach der IClientSecurity-Schnittstelle ab, die lokal von der Remotingschicht implementiert wird. Der Client verwendet diese Schnittstelle, um die Sicherheit einzelner Schnittstellenproxys für das COM-Objekt zu steuern, bevor er eine der Schnittstellen aufruft.

Wenn ein Aufruf auf dem Server eingeht, kann der Server die CoGetCallContext-Funktion aufrufen, um eine IServerSecurity-Schnittstelle abzurufen, die es dem Server ermöglicht, die Authentifizierung des Clients zu überprüfen und bei Bedarf die Identität des Clients zu imitieren. Das IServerSecurity-Objekt ist für die Dauer des Aufrufs gültig.

Rufen Sie die CoInitializeSecurity-Funktion auf, um die Sicherheitsebene zu initialisieren und die angegebenen Werte als Sicherheitsstandard festzulegen. Wenn ein Prozess CoInitializeSecurity nicht aufruft, ruft COM ihn automatisch auf, wenn eine Schnittstelle zum ersten Mal gemarst oder aufgehoben wird, wobei die Standardsicherheit des Systems registriert wird. Mit der CoInitializeSecurity-Funktion kann der Client die Standardaufrufsicherheit für den Prozess einrichten, wodurch die Verwendung von IClientSecurity für einzelne Proxys vermieden wird. Die CoInitializeSecurity-Funktion ermöglicht es einem Server, automatische Authentifizierungsdienste für den Prozess zu registrieren. Weitere Informationen finden Sie unter Festlegen Process-Wide Sicherheit mit CoInitializeSecurity.

COM-Clients und -Server

Definieren von COM-Schnittstellen

Registrieren von COM-Anwendungen

Sicherheit in COM

Prozesse, Threads und Apartments