close

Komponentenobjektmodell

Zur Navigation gehen Zur Suche gehen

Component Object Model (COM) ist eine Microsoft -Plattform für Softwarekomponenten , die 1993 eingeführt wurde . Diese Plattform wird verwendet, um die Kommunikation zwischen Prozessen und die dynamische Erstellung von Objekten in jeder Programmiersprache zu ermöglichen, die diese Technologie unterstützt. Der Begriff COM wird in der Welt der Softwareentwicklung häufig als Überbegriff für OLE-, OLE-Automatisierungs-, ActiveX-, COM+- und DCOM-Technologien verwendet. Obwohl COM 1993 eingeführt wurde, hat Microsoft den COM-Namen erst 1997 hervorgehoben.

Im Wesentlichen ist COM eine Möglichkeit, sprachneutrale Objekte zu implementieren, damit sie in anderen Umgebungen als der, in der sie erstellt wurden, über Maschinengrenzen hinweg verwendet werden können. Bei gut erstellten Komponenten ermöglicht COM die Wiederverwendung von Objekten ohne Kenntnis ihrer internen Implementierung, da es Komponentenimplementierer dazu zwingt, klar definierte Schnittstellen bereitzustellen, die von der Implementierung getrennt sind. Unterschiedliche Speicherzuordnungssemantiken werden berücksichtigt, indem Objekte für ihre eigene Erstellung und Zerstörung über die Referenzzählung verantwortlich gemacht werden. Sie können zwischen verschiedenen Schnittstellen eines Objekts umwandeln, indem Sie die QueryInterface(). Die bevorzugte Vererbungsmethode in COM ist die Erstellung von Unterobjekten, an die Methodenaufrufe delegiert werden (Aggregation genannt).

Obwohl diese Technologien auf vielen Plattformen implementiert wurden, werden sie hauptsächlich mit einem Microsoft Windows -Programm verwendet . Es wird erwartet, dass COM zumindest teilweise durch Microsoft .NET ersetzt wird und Webdienste durch die Windows Communication Foundation (WCF) unterstützt werden. Network DCOM verwendet proprietäre Binärformate, während WCF XML - basierte SOAP -Nachrichten verwendet . COM konkurriert auch als Softwarekomponentensystem mit CORBA und JavaBeans .

Technische Details

COM-Programmierer erstellen Software mit COM-fähigen Softwarekomponenten. Unterschiedliche Arten von Komponenten werden durch Typ-IDs (CLSIDs) identifiziert, bei denen es sich um global eindeutige Bezeichner oder GUIDs handelt. Jede COM-Komponente offenbart ihre Funktionalität über eine oder mehrere Schnittstellen. Die verschiedenen Schnittstellen, die von einer Komponente unterstützt werden, werden durch Schnittstellen-IDs (IIDs), die auch GUIDs sind, voneinander unterschieden.

COM-Schnittstellen haben Implementierungen in verschiedenen Sprachen, wie C, C++, Visual Basic und mehreren der auf der Windows-Plattform implementierten Skriptsprachen. Alle Zugriffe auf die Komponenten erfolgen über die Methoden der Schnittstellen. Dies ermöglicht Techniken wie Inter-Processing, sogar Cross-Computer-Programmierung (letzteres durch DCOM-Unterstützung).

Schnittstellen

Alle COM-Komponenten müssen mindestens die Standard - IUnknown -Schnittstelle implementieren , daher werden alle COM-Schnittstellen von IUnknown abgeleitet . Die IUnknown -Schnittstelle besteht aus drei Methoden: AddRef()und Release(), die das Zählen von Referenzen und die Steuerung des Lebenszyklus der Schnittstelle implementieren; und QueryInterface(), die es einem Aufruf durch Angabe einer IID ermöglicht, Verweise auf die verschiedenen Schnittstellen abzurufen, die die Komponente implementiert. Die Wirkung von QueryInterface()ist ähnlich wie dynamic_cast <>in C++ oder castingin C# und Java.

Die Schnittstellen einer COM-Komponente werden benötigt, um die reflexiven, symmetrischen und transitiven Eigenschaften darzustellen. Die reflektierende Eigenschaft bezieht sich auf die Fähigkeit des Aufrufs von QueryInterface(), bei gegebener Schnittstelle mit der Schnittstellen-ID dieselbe Instanz der Schnittstelle zurückzugeben. Die symmetrische Eigenschaft bezieht sich auf die Tatsache, dass Schnittstelle A auch von Schnittstelle B abgerufen werden kann, wenn Schnittstelle B von Schnittstelle A abgerufen QueryInterface()wird. Die transitive Eigenschaft ähnelt der symmetrischen Eigenschaft, erfordert jedoch, dass, wenn Schnittstelle B von A abgerufen werden kann, und C wiederum von B, dann sollte Schnittstelle C von A verfügbar sein.

Eine Schnittstelle besteht aus einem virtuellen Funktionszeiger, der eine Liste von Zeigern auf die Funktionen enthält, die die in der Schnittstelle deklarierte Funktion in der gleichen Reihenfolge implementiert, in der sie in der Schnittstelle deklariert wurden. Diese Technik zum Übergeben von Strukturfunktionszeigern ist derjenigen sehr ähnlich, die von OLE 1.0 verwendet wird, um mit seinem Bibliothekssystem zu kommunizieren.

COM spezifiziert viele andere Standardschnittstellen, die verwendet werden, um die Kommunikation zwischen Komponenten zu ermöglichen. Einer davon ist beispielsweise IStream , der für Komponenten mit Datenstromsemantik gedacht ist (eine FileStream- Komponente , die zum Lesen und Schreiben von Dateien verwendet wird). Es verfügt über die erwarteten Lese- und Schreibmethoden, um die Stream-Lese- und -Schreibvorgänge auszuführen. Eine weitere Standardschnittstelle ist IOleObject , die für Komponenten vorgesehen ist, die in einen Container gebunden oder eingebettet werden sollen. IOleObject enthält Methoden, die es Stakeholdern ermöglichen, die Größe der Grenzen einer Rechteckkomponente zu bestimmen, wenn die Komponente Operationen wie „Öffnen“ , „Speichern“ usw. unterstützt.

Klassen

Eine Klasse in COM wird als Co -Klasse bezeichnet , was die verkürzte Form der Komponentenobjektklasse ist . Eine Co -Klasse ist die Art von COM, eine Klasse im sprachunabhängigen, objektorientierten Sinne zu definieren. Eine Co -Klasse liefert eine konkrete Implementierung einer oder mehrerer Schnittstellen. In COM können solche konkreten Implementierungen in jeder Programmiersprache geschrieben werden, die die Entwicklung von COM-Komponenten unterstützt, wie C++, Visual Basic usw.

Einer der größten Beiträge von COM zur Windows-Entwicklungswelt ist das Bewusstsein für das Konzept der Trennung von Schnittstelle und Implementierung. Dieses Bewusstsein hat zweifellos die Art und Weise beeinflusst, wie Programmierer die heutigen Systeme bauen. Eine Erweiterung dieses grundlegenden Konzepts ist das Konzept einer Schnittstelle, mehrerer Implementierungen. Dies bedeutet, dass eine Anwendung zur Laufzeit wählen kann, ob sie eine Schnittstelle aus einer von mehreren konkreten Implementierungen instanziieren möchte.

Schnittstellendefinitionssprache und Typbibliotheken

Typbibliotheken enthalten Metadaten , die COM-Typen darstellen. Diese Typen müssen jedoch zunächst mit der Microsoft Interface Definition Language (MIDL) beschrieben werden. Dies ist gängige Praxis bei der Entwicklung einer COM-Komponente, beispielsweise wenn mit der Definition von Typen mit IDL begonnen wird. COM stellt eine IDL-Datei bereit, die es Entwicklern ermöglicht, objektorientierte Klassen, Schnittstellen, Strukturen, Aufzählungen und andere benutzerdefinierte Typen in einer Sprache unabhängig zu definieren. COM IDL ähnelt im Aussehen C- oder C++-Deklarationen mit dem Hinzufügen von Schlüsselwörtern wie "interface" und "library" für die Definition von Schnittstellen bzw. Sammlungen von Klassen. IDL erfordert auch die Verwendung von Attributen in Klammern vor Deklarationen, um zusätzliche Informationen bereitzustellen, wie z. B. die GUID von Schnittstellen und die Beziehung zwischen Zeiger und Längenparametern von Feldern.

Die IDL-Datei wird vom MIDL-Compiler auf verschiedene Weise zur Verwendung in verschiedenen Sprachen kompiliert. Für C/C++ generiert der MIDL-Compiler einen Compiler-unabhängigen Header, der Strukturdefinitionen enthält, die die virtuellen Funktionen mit der Schnittstellendeklaration abgleichen, und eine C-Datei, die Schnittstellendeklarations-GUIDs enthält. Der C++-Quellcode für ein Proxy -Modul kann auch vom MIDL-Compiler generiert werden. Dieser Proxy enthält Stub- Methoden zum Konvertieren von COM-Aufrufen in RPC, dies wird von DCOM zugelassen.

Eine IDL-Datei kann auch vom MIDL-Compiler in eine Typbibliothek (.TLB-Datei) kompiliert werden. Die in der Bibliothek enthaltenen binären Metadaten sollen von den Compilern und Laufzeitumgebungen der Sprache (VB, Delphi, .NET CLR usw.) verarbeitet werden. Das Endergebnis einer solchen TLB-Verarbeitung besteht darin, dass sprachspezifische Konstrukte erzeugt werden, die die in der .TLB-Datei definierte COM-Klasse (und letztendlich die in der IDL-Quelldatei definierte) darstellen.

Referenzzählung

Die wichtigste aller COM-Schnittstellen, d. h. IUnknown (von der alle COM-Schnittstellen abgeleitet sein müssen), unterstützt zwei Hauptkonzepte: das Abfragen von Features (oder Schnittstellen, die ein Objekt implementiert) über die Methode queryInterface()und das Verwalten des Lebenszyklus des Objekts durch Einschließen von AddRef ()und Release (). Die Referenzzähl- und Abfragefunktion gilt für Objekte (nicht für jede Schnittstelle) und muss daher eine zentralisierte Implementierung haben.

Die COM-Spezifikationen erfordern eine Technik namens Referenzzählung, um sicherzustellen, dass die verschiedenen Objekte am Leben sind, solange es Clients gibt, die Zugriff auf eine oder mehrere ihrer Schnittstellen erhalten haben, und umgekehrt, dass dasselbe Objekt ordnungsgemäß verworfen wird, wenn der gesamte Code vorhanden ist vorhanden, der das Objekt benutzt, ist damit fertig und benötigt es nicht mehr. Ein COM-Objekt ist dafür verantwortlich, seinen eigenen Speicher freizugeben, sobald sein Verweiszähler auf Null dekrementiert wurde.

Ein COM-Objekt verwaltet für seine Ausführung im Allgemeinen einen Wert, der als Referenz für die Zählung verwendet wird. Wenn er AddRef ()über eine der Schnittstellen des Objekts aufgerufen wird, wird dieser Wert erhöht. Wenn aufgerufen wird Release(), wird diese Ganzzahl dekrementiert. AddRef ()und Release ()sie sind das einzige Mittel, mit dem ein Client eines COM-Objekts seinen Lebenszyklus beeinflussen kann. Der interne Wert bleibt ein privates Mitglied des COM-Objekts und ist nie direkt zugänglich.

Instanziierung

COM standardisiert den Prozess der Instanziierung (d. h. Erstellung) von COM-Objekten, indem es die Verwendung der Factories -Klasse erfordert . Für jedes erstellte COM-Objekt müssen zwei zugehörige Parameter vorhanden sein:

  • Eine ID -Klasse .
  • Eine Factory -Klasse .

Jeder COM-Klasse oder CoClass muss eine eindeutige Klassen- ID (eine GUID) zugeordnet werden. Es muss auch einer eigenen Factory -Klasse zugeordnet werden (was durch die Verwendung einer zentralisierten Registrierung erreicht wird). Eine Factory -Klasse ist selbst ein COM-Objekt. Es ist ein Objekt, das die Schnittstelle IClassFactory oder IClassFactory2 (letzteres mit den Support-Lizenzen) verfügbar machen muss. Die Verantwortung eines solchen Objekts ist die Erstellung anderer Objekte.

Eine Factory -Klasse ist normalerweise in demselben ausführbaren Code (d. h. dem Codeserver) enthalten wie das COM-Objekt selbst. Wenn eine Factory -Klasse aufgerufen wird, um ein Zielobjekt zu erstellen, ist das Ziel dieses Objekts die Klassen-ID, die bereitgestellt werden muss. Auf diese Weise weiß die Factory -Klasse , welche Objektklasse instanziert werden soll.

Eine einzelne Factory -Objektklasse kann Objekte von mehr als einer Klasse erstellen. Das heißt, zwei Objekte mit unterschiedlichen Klassen- IDs können von derselben Factory -Objektklasse erstellt werden. Dies ist jedoch für das COM-System transparent.

Indem die Verantwortung für die Erstellung eines Objekts an ein separates Objekt delegiert wird, wird ein höheres Abstraktionsniveau erreicht und der Entwickler hat mehr Flexibilität.

Damit Clientanwendungen Factory -Objektklassen erwerben können, müssen COM-Server sie entsprechend verfügbar machen. Eine Factory -Klasse wird je nach Art des Servercodes unterschiedlich verfügbar gemacht. Ein Server, der auf DLLs basiert, muss eine globale Funktion exportieren DllGetClassObject (). Eine Server-EXE-Datei, die auf der Factory -Klasse basiert, registriert sich zur Laufzeit über die Windows-API-Funktion von CoRegisterClassObject ().

Programmierung

COM ist ein binärer Standard und kann in jeder Programmiersprache entwickelt werden, die in der Lage ist, seine definierten binären Datentypen und Schnittstellen zu verstehen und zu implementieren.

Laufzeitbibliotheken (in Extremsituationen Programmierer) sind verantwortlich für das Ein- und Aussteigen aus der COM-Umgebung, Instanziierung und Referenzzählung von COM-Objekten, Objekte zum Abfragen von Versionsinformationen, Codierung zum Nutzen erweiterter Versionen von Objekten.

Anwendungs- und Netzwerktransparenz

COM-Objekte können innerhalb eines Prozesses, über Prozessgrenzen innerhalb eines Computers und über ein Netzwerk mithilfe der DCOM -Technologie instanziiert und referenziert werden . Das Beenden des Prozesses und entfernte Objekte können die Serialisierung verwenden, um Methodenaufrufe zu senden und Werte rückwärts und vorwärts zurückzugeben. Die Serialisierung ist für das Objekt und den Code, der das Objekt verwendet, unsichtbar.

Kritik

Pumpnachricht

Wenn eine STA initialisiert wird, erstellt sie ein verstecktes Fenster, das für das Routing von Nachrichten zwischen Apartments und Prozessen verwendet wird. Die Nachrichtenwarteschlange dieses Fensters sollte regelmäßig gepumpt werden. Diese Konstruktion ist als Nachrichtenbombe bekannt. In früheren Versionen von Windows konnte dies nicht zu systemweiten Abstürzen führen. Dieses Problem ist besonders unangenehm, da einige Windows -APIs COM als Teil ihrer Anwendung initialisieren, wodurch Implementierungsdetails preisgegeben werden.

Referenzzählung

Die Referenzzählung in COM kann Probleme verursachen, wenn auf zwei oder mehr Objekte zirkulär verwiesen wird. Ein Anwendungsdesign muss dies berücksichtigen, damit Objekte nicht verwaisen.

Objekte können die Referenzzählung auch aktiv lassen, wenn der COM-"Senkenfall" das verwendete Modell ist. Da das Objekt, das das Ereignis auslöst, eine Objektreferenz benötigt, um auf das Ereignis zu reagieren, erreicht die Anzahl der Objektreferenzen niemals Null.

DLL-Hölle

Da der Speicherort jeder Komponente an einem systemweiten Speicherort (der Windows-Registrierung) gespeichert ist, ist möglicherweise nur eine Version einer bestimmten Komponente installiert. Daher leidet COM stark unter der DLL-Hölle , bei der zwei oder mehr Anwendungen unterschiedliche Versionen derselben Komponente erfordern.

Windows XP führt einen neuen Modus der COM-Objektregistrierung ein: "COM Free Registration". Dieser Dienst ermöglicht es Anwendungen, die COM-Objekte installieren müssen, alle Registrierungsinformationen, die für die COM-Registrierung benötigt werden, im Anforderungsverzeichnis zu speichern, anstatt in der globalen Registrierung, wo genau genommen nur eine einzige Anforderung verwendet wird. DLL-Hölle, kann durch registrierungsfreies COM vermieden werden, die einzige Einschränkung besteht darin, dass es mindestens Windows XP oder spätere Versionen von Windows erfordert und dass es nicht für EXE, COM oder serverweite Systemkomponenten wie MDAC, MSXML verwendet werden sollte , DirectX oder Internet Explorer.

Referenzen

Siehe auch

Externe Links

Erhalten von « https://es.wikipedia.org/w/index.php?title=Component_Object_Model&oldid=143800526 »