Component Object Model

Das Component Object Model [kəmˈpoʊnənt ˈɒbdʒɪkt ˈmɒdl] (Abk. COM) ist eine von Microsoft entwickelte Plattformtechnik, um unter dem Betriebssystem Windows Interprozesskommunikation und dynamische Objekterzeugung zu ermöglichen. COM-fähige Objekte sind sprachunabhängig und können sowohl DLLs als auch ausführbare Programme sein. Jede COM-Komponente bietet ein Interface an, welches nach erfolgreicher Instanziierung dazu verwendet werden kann, die angebotenen Funktionen der COM-Komponente einzusetzen. Somit soll COM eine leichte Wiederverwendung von bereits geschriebenem Programmcode, auch über (Windows-)Betriebssystemgrenzen hinweg, möglich machen.

Architektur

COM basiert auf dem Client/Server-Prinzip. Ein COM-Client instanziiert eine COM-Komponente in einem COM-Server und nutzt die Funktionalität des Objektes über COM-Interfaces. Der Zugriff auf Objekte wird innerhalb eines Prozesses durch COM-Apartments synchronisiert.

COM-Server

Unter einem COM-Server versteht man eine DLL (Dynamic Link Library) oder ein Executable, welches in einer COM-fähigen Programmiersprache erstellt wurde und COM-Komponenten anbietet und erstellen kann. Es gibt drei Typen von COM-Servern:

In-process-Server

Im Falle des In-process-Servers ist die COM-Komponente in einer DLL implementiert (sie tragen unter Windows oft die Dateiendung OCX). Diese DLLs müssen die Funktionen DllGetClassObject(), DllCanUnloadNow(), DllRegisterServer() und DllUnregisterServer() exportieren. Wird eine COM-Komponente eines In-process-Servers instanziiert, so wird der zugehörige Server (ein Server kann mehrere COM-Komponenten anbieten) in den Prozess des Clients geladen. In-process-Server sind besonders schnell, da der Zugriff auf die Funktionen der COM-Komponenten keine Umwege nötig macht. Jedoch muss jeder Prozess, der eine COM-Komponente nutzen möchte, die in einem In-process-Server implementiert ist, diese für sich in den Speicher laden, was nicht besonders speicherschonend ist.

Local Server

Local Server sind unter Windows ausführbare Programme, die COM-Komponenten implementieren. Bei Instanziierung einer COM-Komponente wird dieses Programm gestartet (sofern es nicht schon läuft) – dies bedeutet, dass ein Executable vorliegen muss, eine DLL kann hier nicht aufgerufen werden. Zur Kommunikation zwischen Client und Server wird ein abgespecktes RPC-Protokoll (Remote Procedure Call) benutzt. Local Server haben den Vorteil, dass sie nur einmal gestartet werden müssen und dann viele Clients bedienen können, was speicherschonend ist. Zudem lassen sich so recht leicht Datenzugriffe auf einen gemeinsamen Datenbestand synchronisiert von mehreren laufenden Clients durchführen (wie zum Beispiel in Microsoft Outlook). Die Zugriffe über RPC sind allerdings langsamer.

Remote Server

Befindet sich zwischen Server und Client ein Netzwerk, so kommt DCOM (Distributed COM) zum Einsatz. Der Einsatz von DCOM macht es theoretisch möglich, dass Server und Client auf unterschiedlichen Betriebssystemen laufen.

DCOM benutzt im Gegensatz zum Local Server ein vollständig implementiertes RPC, was die Aufrufe jedoch (auch bei sehr geringer Netzwerkauslastung) deutlich verlangsamt. Die Implementierung vom DCOM unterscheidet sich von der von COM mit Local Server zusätzlich noch durch den vorgeschalteten Protokollstack.

Durch eine Sicherheitslücke in der RPC-Implementation von DCOM wurde die Angriffsweise des bekannten Wurms W32.Blaster möglich.

COM-Interface

Das COM-Interface dient der Kommunikation vom Client zum Server. Eine COM-Komponente kann dazu über allgemein definierte und vorgegebene Schnittstellen (zum Beispiel IUnknown, IDispatch) sowie über spezielle Schnittstellen angesprochen werden.

Jedes Interface hat eine weltweit eindeutige Identifikationsnummer, die GUID (Globally Unique Identifier). Dadurch können auch mehrere Interfaces mit demselben Namen existieren (aber nicht mit derselben GUID).

Damit gewährleistet wird, dass die Client/Server-Kommunikation programmiersprachenübergreifend möglich ist, findet am Interface das so genannte Marshalling statt, welches die auszutauschenden Daten in eine vordefinierte Binärrepräsentation wandelt.

Ein Interface erfüllt die Funktion einer abstrakten Klasse, die lediglich virtuelle Memberfunktionen enthält, die (wegen der Trennung von Deklaration und Implementierung) alle samt auf 0 (Eintrag in der VTable) gesetzt werden. Die C-Version eines Interfaces ist entsprechend eine Struktur, die Methodenzeiger enthält. Die instanziierten COM-Objekte nutzt man dabei über Zeiger auf deren Interfaces.

Wenn ein COM-Objekt ein Interface implementiert, muss es alle Methoden des Interfaces überschreiben, also die VTable füllen. Dabei sind mindestens die drei Methoden von IUnknown zu implementieren, welche für das Lebenszyklusmanagement zuständig sind und eventuell vorhandene, weitere implementierte Schnittstellen offenlegen.

Ein Interface sieht in der für COM-Komponente nutzbaren IDL (Interface Definition Language) wie folgt aus (als Beispiel dient das Interface IUnknown):

 // Standardschnittstelle aller COM-Komponenten
 [
   object,
   uuid(00000000-0000-0000-C000-000000000046)
 ]
 interface IUnknown {
      [restricted]
      HRESULT _stdcall QueryInterface([in] GUID* rrid,
                                      [out] void** ppvObj);
      [restricted]
      unsigned long _stdcall AddRef();
      [restricted]
      unsigned long _stdcall Release();
 }

Jedes Interface muss über eine Interface-Vererbung die Funktionen des hier gezeigten Interfaces IUnknown definieren, da dieses die grundlegenden Funktionen für COM implementiert. Eine weitere Vererbung der Interfacedefinitionen ist möglich.

Da Programmiersprachen wie Visual Basic Script keine Typen kennen, hat Microsoft eine weitere Möglichkeit entwickelt, Funktionen aus COM-Interfaces aufzurufen. Für diese Möglichkeit muss das Interface die Funktionen des Interfaces IDispatch definieren. Dies erlaubt es dann dem Programmierer, eine COM-Komponente über IDispatch.Invoke() anzusprechen, ohne dass der COM-Client die Typbibliothek des Servers kennen muss. Da der Zugriff über das Dispatch-Interface sehr viel langsamer als der Zugriff über ein typisiertes Interface ist, wird oft beides implementiert (Dual Interface), so dass sich der Programmierer bei Programmiersprachen, die Pointer beherrschen, den Weg des Zugriffs auf die COM-Komponente aussuchen kann.

COM-Komponente

Eine COM-Komponente bietet die aufrufbaren Funktionen über ein oder mehrere COM-Interfaces an. Die Instanziierung des Objektes erfolgt durch die Implementierung von IClassFactory.CreateInstance() im COM-Server.

Die Lebensdauer eines Objektes wird mittels Referenzzählung gesteuert. Eine COM-Komponente lebt nur so lange, wie die Differenz der Aufrufe von AddRef() (Instanziierung einer Komponente) und Release() (Freigabe einer Instanz) nicht null ergibt.

Es ist möglich, dass eine COM-Komponente mehrere Interfaces anbietet. Dies ist in bestimmten Situationen auch notwendig, um ein Programm erweitern zu können, ohne andere Programme neu kompilieren zu müssen, denn der Compiler kodiert die aus der VTable gelesenen Einsprungadressen der vom Client aufgerufenen Funktionen unter bestimmten Umständen fest. Wird das Interface einer Komponente später geändert, kann sich die Einsprungadresse ändern, was die Funktionstüchtigkeit des Clients beeinträchtigen würde. Zur Erweiterung der Serverfunktionalität wird also stattdessen ein weiteres Interface implementiert.

Eine Vererbung von COM-Komponenten (Aggregation) ist durch die Anforderungen der Binärkompatibilität nur in wenigen Programmiersprachen möglich. Dazu wird die zu vererbende Komponente über explizite Durchleitung der Schnittstellen über die erbende Komponente veröffentlicht^[1].

COM-Client

Der Client ist das Programm, welches

• möglicherweise ein Objekt einer COM-Komponente über einen COM-Server erzeugt und
• die von der COM-Komponente angebotenen Funktionen benutzt.

Der Client kennt die Funktionen, die von der COM-Komponente angeboten werden, da diese in den entsprechenden COM-Interfaces deklariert sind. Die Veröffentlichung von Interfaces erfolgt entweder über Typbibliotheken oder Beschreibungen in der IDL (Interface Definition Language).

Apartments

COM-Objekte werden bei Instanziierung immer einem so genannten Apartment zugeordnet. Dabei handelt es sich um transparente Rahmen, welche zur Synchronisierung von Methodenaufrufen mehrerer Objekte dienen, die mit unterschiedlichen Anforderungen an die Threadsicherheit arbeiten. Wird COM nicht mitgeteilt, dass eine entsprechende Komponente threadsicher ist, wird COM nur einen Aufruf gleichzeitig an ein Objekt erlauben. Threadsichere Komponenten können auf jedem Objekt beliebig viele Aufrufe gleichzeitig ausführen.

Geschieht ein Aufruf im gleichen Apartment zwischen verschiedenen Objekten, ist kein Marshalling erforderlich. Wird jedoch ein Interface über Apartmentgrenzen hinweg benutzt, muss ein Marshalling erfolgen.

Jeder Thread, welcher COM verwenden möchte, muss sich vor der ersten Verwendung einer COM-Funktionalität einem Apartment zuordnen (MTA) oder ein neues Apartment erstellen (STA). Dies geschieht über die Funktion CoInitialize(). Programmiersprachen mit integrierter COM-Unterstützung (zum Beispiel VB6 und die meisten .NET-Sprachen) führen diese Zuordnung oft automatisch durch.

Jede COM-Komponente wird bei Erzeugung einem Apartment zugeordnet. Falls die Apartment-Anforderungen der erzeugten Komponente zum Apartment des erzeugenden Threads passen, wird das Objekt dem gleichen Apartment zugeordnet. Bei Aufrufen über Prozessgrenzen hinweg liegen die beiden Objekte immer in verschiedenen Apartments. Die Zuordnung zu einem Apartment kann während der Lebensdauer des Objektes nicht geändert werden.

Es gibt drei Arten von Apartments ^[2]:

• Single Threaded Apartments (STA) besitzen genau einen Thread und beliebig viele Objekte. Es können beliebig viele STAs in einem Prozess existieren. Es erfolgt nur ein Aufruf gleichzeitig an das aufzurufende Objekt. Die restlichen Aufrufe warten in einer Warteschlange auf die Freigabe des Apartment-Threads. Dies impliziert, dass zwei Objekte in demselben STA auch von zwei verschiedenen Clients nicht parallel aufgerufen werden können. Als Besonderheit wird das erste in einem Prozess initialisierte STA automatisch zum Main-STA. Pro Prozess gibt es nur genau ein Main-STA, alle Objekte die keine explizite Anforderung an das Apartment stellen, werden in diesem erzeugt.
• Multi Threaded Apartments (MTA) besitzen beliebig viele Threads. Es gibt in einem Prozess allerdings maximal ein MTA. Dadurch können von mehreren Clients gleichzeitig Aufrufe an das gleiche oder auch verschiedene Objekte erfolgen. Die Anforderungen an die Implementierung der Komponenten sind wegen der notwendigen Threadsicherheit und Reentranz sehr hoch.
• Neutral Threaded Apartments (NTA) haben keine Threadaffinität. Es gibt in einem Prozess allerdings maximal ein NTA. Jedes Objekt in einem NTA kann von einem STA/MTA Apartment ohne Threadübergang aufgerufen werden. Der Thread wird also kurzzeitig in das NTA ausgeliehen, um damit aus Performancegründen das Marshalling zu überspringen. Neutral Threaded Apartments wurde mit Windows 2000 eingeführt um die Vorzüge von MTA (meist kein Marshalling notwendig) mit den Vorzügen von STA (keine threadsichere Implementierung notwendig) zu vereinen.

Funktionalität

Durch den Einsatz von COM erhält ein Programmierer die Möglichkeiten

• sprachunabhängig,
• versionsunabhängig,
• plattformunabhängig,
• objektorientiert,
• ortsunabhängig,
• automatisierend

zu programmieren. Viele der Funktionen des „Windows Platform SDKs“ sind über COM zugänglich. COM ist die Basis, auf der OLE-Automation und ActiveX realisiert sind. Mit der Einführung des .NET-Frameworks verfolgt Microsoft allerdings die Strategie, COM unter Windows durch dieses Framework abzulösen. Im Folgenden werden die einzelnen Punkte der Aufzählung genauer erläutert.

Sprachunabhängigkeit

Das wichtigste Argument für COM ist sicherlich die Sprachunabhängigkeit. COM unterstützt den so genannten Binärstandard. Die erzeugte Binärdatei stellt einerseits die implementierten Funktionen zur Verfügung und andererseits ein Interface, welches diese Funktionen aufzeigt. Mit Hilfe des Interfaces ist es möglich, von anderen Programmen aus die Funktionen zu verwenden. Dabei wird mit Konzepten aus dem Bereich Verteilte Systeme gearbeitet.

Versionsunabhängigkeit

Ein weiterer wichtiger Vorteil beim Einsatz von COM ist es, dass man die Verwaltung von neuen Softwarefeatures einfach in eine bestehende Anwendung integrieren kann. Oftmals kann es Probleme geben, wenn man herstellerneutrale oder herstellerübergreifende Softwarekomponenten mit weiteren Funktionen ausstattet. Dadurch kann zwar die eigene Software erweitert werden, jedoch besteht die Gefahr, dass andere Software, welche ebenfalls die herstellerübergreifenden Komponenten verwendet, nicht mehr funktionsfähig bleibt.

COM bietet eine robuste Möglichkeit an, um eine Softwarekomponente mit neuen Funktionen zu erweitern. Dies wird dadurch ermöglicht, dass mehrere Interfaces in einer Header-Datei zusammengefasst werden können. Der folgende C++-Programmcode verdeutlicht dies:

  //
  // Interface mathematik.h
  //
  class IStandardMathFunctions  :  public IUnknown
  {
  public: 
     STDMETHOD(Addieren)(long, long, long*)
     STDMETHOD(Subtrahieren)(long, long, long*)
  };
  
  class IAdvancedMathFunctions  :  public IUnknown
  {
  public: 
     STDMETHOD(Fibonacci)(short, long*)
  }

Dieser Header namens mathematik.h enthält zwei Interfaces. Das erste Interface könnte beispielsweise die herstellerübergreifenden Funktionen anbieten, die von verschiedenen Programmen verwendet werden. Durch das zweite Interface IAdvancedMathFunctions wird diese Softwarekomponente erweitert. Weitere Interfaces können jederzeit hinzugefügt werden. Die alten Interfaces und darin enthaltenen Funktionen gehen dabei nicht verloren. Das Hinzufügen neuer Interfaces statt des Veränderns derselben ist so die von Microsoft gedachte Form, Softwarekomponenten zu erweitern, da so keine Inkonsistenzen entstehen.

Plattformunabhängigkeit

x64-Applikationen können dank Marshalling auf 32bittige COM-Server zugreifen (und umgekehrt). Der COM-Server muss dann in einem eigenen Prozess laufen und seine Objekte können demnach nicht als In-process-Server instanziiert werden. COM-Applikationen sind jedoch immer auf die Windows-Betriebssystemfamilie und von dieser unterstützte Hardware angewiesen, von einer wirklichen Plattformunabhängigkeit kann daher nicht gesprochen werden.

Objektorientierung

Beim Einsatz von COM wird objektorientiert gearbeitet. Trotzdem können COM-Komponenten auch zum Beispiel in C erstellt und genutzt werden, da die Interfaces tatsächlich eine Sammlung von Methodenzeigern sind (abstrakte Klasse in C++, struct in C).

Ortsunabhängigkeit

COM ist ortsunabhängig, d. h. dass die einzelnen COM-Komponenten an einer zentralen Stelle (Registry) angemeldet werden und so der Zugriff auf die Komponenten unabhängig von ihrem eigentlichen Ort erfolgen kann.

Siehe auch: Ortstransparenz

Automatisierung

Das Steuern von Anwendungen über COM-Interfaces wird als Automatisierung bezeichnet. Von dieser Anwendungsmöglichkeit wird häufig im Rahmen von OLE (Object Linking and Embedding) Gebrauch gemacht.

Siehe auch

• Object Linking and Embedding
• .NET-Framework
• Objektorientierte Programmierung
• Verteilte Systeme
• Komponente (Software)

Quellen

1. ↑ Com_Interface_Entry Macros (Atl)
2. ↑ CodeGuru: Understanding COM Apartments, Part I

Literatur

• Peter Loos: Go to COM. Das Objektmodell im Detail betrachtet, Addison-Wesley, 1. Aufl. 15. November 2000, ISBN 978-3827316783
• Olaf Zwintzscher: Software-Komponenten im Überblick. Einführung, Klassifizierung & Vergleich von JavaBeans, EJB, COM+, .Net, CORBA, UML 2. W3L, Herdecke 2005, ISBN 3-937137-60-2

Weblinks

• Microsoft® Component Object Model (COM)