510 likes | 612 Views
Goto COM. Prof. Dr.-Ing. Franz-Josef Behr. Literatur. Loos, Peter: Go to COM. 672 Seiten - Addison-Wesley, 2000 COM/DCOM, Microsofts Standard für Componentware, http://www.informatik.uni-bonn.de/~ur/lectures/ss2002/folien/HJ-de-COM.ppt , 08.01.2005
E N D
Goto COM Prof. Dr.-Ing. Franz-Josef Behr
Literatur • Loos, Peter: Go to COM. 672 Seiten - Addison-Wesley, 2000 • COM/DCOM, Microsofts Standard für Componentware, http://www.informatik.uni-bonn.de/~ur/lectures/ss2002/folien/HJ-de-COM.ppt, 08.01.2005 • Sherif Moustafa, 2001: Verteilte Informationssysteme - DCOM/OLE, http://www.informatik.uni-bonn.de/~tb/Lehre/ws00/sVS/Ausarbeitungen/Moustafa.doc, 08.01.2005
Warum COMponentware? Traditionelle Software (wie unsere bisherige) • unübersichtliche, monolithische Struktur • aufwendig zu erstellen • schwierig zu warten bzw. an Umweltveränderungen anzupassen COMponentware • besteht aus wiederverwendbaren, kombinierbaren Funktionseinheiten (Komponenten) • Komponenten sind sprachenunabhängig • fertige Komponenten stehen in Softwarebibliotheken zur Verfügung -> schnelle, flexible Entwicklung und Aktualisierung von Softwaresystement
Wie läßt sich ein System so erstellen, so dass ausführbare Anwendungen in binärer Form, die von verschiedenen Herstellern zu verschiedenen Zeitpunkten erstellt worden, miteinander kommunizieren können? • Ansätze: • Microsofts Distributed Component Object Model (DCOM) als Nachfolger von COM/OLE, • Common Object Request Broker Architecture (CORBA) der Object Management Group (OMG).
Component Objekt Model (COM) • wurde 1995 mit OLE 2.0 eingeführt und war lange eine von Microsofts Schlüsseltechnologien zur Weiterentwicklung seiner Betriebsysteme und Anwendungssoftware • COM’s Architektur stellt die Grundlage von „higher level“ Software Dienste dar: Grafik (‚DirectX‘), Datenbankzugriff (‚OLE DB‘), Dateisysteme (‚Active Directory Services‘), Anwenderprogramme (Word, Excel, Internet Explorer, …, und natürlich GI-Systeme wie GeoMedia und MapInfo) • ein objektbasiertes Programmiermodell, das in einer Spezifikation beschrieben ist • definiert Mechanismen für die Wiederverwendbarkeit und Interoperabilität von Komponenten • enthält mit der COM-Bibliothek eigenen Code • funktioniert nach dem klassischen Client-Server-Prinzip
Geschichte von COM/DCOM Windows- Zwischenablage 1987 Verteilte Datenverarbeitung 1980er Object Linking and Embedding (OLE 1) 1992 Open Software Foundation Distributed Computing Environment Remote Procedure Calls (OSF DCE RPC) Ende 80er Component Object Model (COM) 1995 Distributed COM (DCOM) 1996
Windows- Zwischenablage 1987 Verteilte Datenverarbeitung 1980er Object Linking and Embedding (OLE 1) 1992 Open Software Foundation Distributed Computing Environment Remote Procedure Calls (OSF DCE RPC) Ende 80er Component Object Model (COM) 1995 Distributed COM (DCOM) 1996 Geschichte COM / DCOM Heute: Ablösung durch .net
Methoden Eigenschaften Eigenschaften ÖffentlicheSchnittstellen Eigenschaften ÖffentlicheSchnittstellen Methoden Methoden Bekannt: Schnittstelle Objekt Eigenschaften: private Setzen und Abfragen nur über get- und set-Methoden
Hinführung • Objektinstanz anlegen:CPoint * pPoint = new CPoint(5.0,9.0); • Geschieht dies im gleichen Programm: "Kein Problem" • Bei Nutzung derselben Klasse in mehreren Programmen: Klasse verfügbar über .h-Datei • "Kein Problem" • Problem jedoch: • Über Programmgrenzen hinweg • bei Nutzung in anderen Programmiersprachen
Idee • System verteilter Objekte • Instanzen können über Programmgrenzen hinweg angelegt werden • Mit verschiedenen Programmiersprachen • Problem: Es existieren möglicherweise viele CPoint-Klassen • Jede Klasse / jedes Objekt benötigt eine eindeutige ID • Objekte werden von "Objektfabriken" (factories) bereitgestellt. • Für alle derzeit und in Zukunft darin vorkommenden Objekte, Schnittstellen, Klassen, Anwendungen und mehr werden sogenannte "Globally Unique IDentifiers" (abgekürzt "GUID"s) erzeugt. • --> Identifikation über eine weltweit eindeutige Nummer
GUID – Globally Unique Identifier • 128 Bit-Zahl, aus einer Menge von Informationen gebildet. • unter anderem wird die MAC-Adresse der Netzwerkkarte bei der Erstellung einer GUID verwendet um sicherzustellen, dass die GUID weltweit eindeutig ist. • Bei der Installation eines Betriebssystems wird auch eine GUID erstellt, die dann eine bestimmte Maschine identifiziert. • 128 Bit, groß genug? • Würde jeder derzeitige Erdenbewohner, das sind etwa 6 Milliarden Menschen (Größenordnung 109), rund um die Uhr 100 Billionen (1014) GUIDs pro Sekunde erzeugen, würde es knapp 20 Millionen Jahre dauern, bis der mögliche Vorrat von 3,4 x 1038 Zahlen ausgeschöpft wäre!(Quelle: Kraig Brockschmidt: Inside OLE, Microsoft Press, nach http://www.aboutvb.de/khw/artikel/khwcreateguid.htm)
GUID – Darstellung • Üblicherweise in hexadezimaler Form in einer bestimmten Formatierung dargestellt, beispielsweise: • {C1D11C25-45D2-11D0-B0E2-444553540000}
CLSID (ClassIDentifier) • ein Name für ein Objekt • spezielle Form eines GUID, also ein weltweit eindeutiger Bezeichner. • 16-byte Wert, der 32 Hexadezimal Ziffern enthält. Diese Ziffern sind in Gruppen angeordnet: 8-4-4-4-12. • CLSIDs werden benutzt, um OLE Objekte eindeutig identifizieren zu können. • Diese Objekte haben Eigenschaften und Methoden. • Methode ist ein Vorgang, der ausgeführt wird, wenn mit diesem Objekt gearbeitet wird, z. B. ein Doppelklick, wenn ein anderes Objekt darauf per Maus "gedropt" wird usw. • Damit ein Objekt, welches durch seine CLSID repräsentiert wird, eine Methode besitzt, muss natürlich ein Programm vorhanden sein, welches diese Methode ausführt. http://www.winfaq.de/faq_html/tip0313.htm
Praxis: Nutzung einer CLSID • Wenn Sie ein Icon zum Aufruf solcher Funktionen anlegen wollen, legen Sie an der gewünschten Stelle (Desktop oder Startmenü) einen neuen Ordner an. Als Namen für den Ordner geben Sie eine Beschreibung, gefolgt von einem Punkt, und dann die CLSID-Nummer [Name.{CLSID-Nummer}] (z. B. Systemsteuerung.{21EC2020-3AEA-1069-A2DD-08002B30309D}) ein.
Praxis: CLSID besorgen #define STRICT #include <objbase.h> #include <stdio.h> #include <assert.h> #include <iostream> using namespace std; Int main (void) { GUID guid; // create guid HRESULT hr = CoCreateGuid (& guid); assert (hr == S_OK); // convert GUID into string OLECHAR szCLSID [256]; int len = StringFromGUID2 (guid, szCLSID, 256); assert (len != 0); printf ("CoCreateGuid: %S\n", szCLSID); cout << "CoCreateGuid: " << szCLSID << endl << endl; return 0; }
Rückgabewerte von COM-Funktionen HRESULT hr = CoCreateGuid (& guid); • HRESULT = "Handle to result" = Verweis auf 32-Bit-Ergebniswert (vgl. WIN-API) -> in Datei winerror.h definiert.
Von der CLSID zur ProgID • ProgID = programmatische ID, Zeichenkette, die einer CLSID eine für uns lesbare Darstellung zuordnet. • ProgID müssen nicht weltweit eindeutig sein. • Namenskonvention: <Hersteller>.<Klasse>.<Version> • Bsp.: Word.Application.8
Registrierungsdatenbank: Zentrale Sammelstelle der ProgIDs • Registrierungsdatenbank = System Registry • Hauptschlüssel: • HKEY_CLASSES_ROOT: Verknüpfungen von Applikation und Dateinamenserweiterungen, Registrierung aller COM-Komponenten • HKEY_CURRENT_USER: Informationen des aktuellen Benutzers • HKEY_LOCAL_MACHINE: rechnerspezifische Informationen, wie z. B. über eingebaute Hardware • HKEY_USERS: Informationen zu allen angemeldteten Benutzern • HKEY_CURRENT_CONFIG: Daten zur aktuellen Konfiguration (angeschlossener Drucker usw.) • HKEY_DYN_DATA: dynamische Statusinformationen (Anzahl der Prozesse usw.) • Zugriffsfunktionen • RegOpenKeyEx: Öffnen eines Haupt- oder Unterschlüssels • RegQueryValueEx: Attributwert lesen • RegCloseKey: Handle für Zugriff auf Registry wieder freigeben
Registrierungsdatenbank: Zentrale Sammelstelle der ProgIDs II • Registrieren von Komponenten manuell oder automatisch von der Komponente selbst. • Ohne einen Eintrag in der Registry kann kein Client die gewünschte Klasse lokalisieren und instantiieren!
COM-Klasse • Konkrete Implementierung einer oder mehrer COM-Schnittstellen; • auch als CoClass bezeichnet; • Name der Klasse: eindeutige CLSID, optional ProgID (besser lesbar)
Das COM-Objekt • bietet seine Funktionen als Methoden für Clients über eine oder mehrere Schnittstellen an • kann von Clients über einen Schnittstellenzeiger angesprochen werden • Clients erhalten nach der Instantiierung eines Objekts automatisch einen Schnittstellenzeiger auf dessen Schnittstelle IUnknown • jede Schnittstelle muß die virtuellen Funktionen von IUnknown erben, jede COM-Klasse muß diese Funktionen implementieren • IUnknown-Methoden können über jede Schnittstelle aufgerufen werden • die Methoden von IUnknown liefern dem Client Zeiger auf weitere Schnittstellen des Objekts und übernehmen eine Referenzzählung zur Speicherverwaltung
Schnittstellenbegriff in COM • Zusammenfassung einer oder mehrerer (semantisch zusammengehöriger) Methoden zu einer logischen Gruppe, die in C++ mit Hilfe einer rein abstrakten Basisklasse definiert werden. • Der Zugriff auf die COM-Schnittstelle sind durch ein binäres Standardformat vorgegeben. • Auf allen Plattformen definiert COM eine Standardmethode, um die sog. virtuellen Funktionstabellen (VTBL) in den Arbeitsspeicher zu laden, sowie eine Standardmethode, um Funktionen mit Hilfe solcher Tabellen aufzurufen. • Virtuelle Tabellen sind eine Menge von Zeigern, die auf verschiedene Funktionen zeigen, d.h. eine beliebige Programmiersprache, welche in der Lage ist, Funktionen durch Zeiger aufzurufen, ist dazu geeignet, Komponenten zu erstellen, die mit anderen Komponenten kommunizieren können.
Ein Zeiger auf eine COM-Schnittstelle ist ein Zeiger auf eine vtbl (virtuelle Funktionszeigertabelle), die der korrespondierenden abstrakten Basisklasse zugeordnet ist.
Schnittstellendefinition • wird vom Entwickler in einer Schnittstellendefinitionsdatei durch eine abstrakte Basisklasse definiert • Werkzeug zum generieren von Schnittstellendefinitionsdateien ist der Microsoft Interface Definition Language (MIDL) - Compiler • die Schnittstellendefinitionsdatei muß als Header-Datei von Client und Komponente benutzt werden • -> es wird ein Binärstandard erreicht • Schnittstellen dürfen nach ihrer Veröffentlichung nicht mehr geändert werden • COM definiert eine Vielzahl von Standardschnittstellen, deren Methoden der Entwickler in der Komponente jedoch selbst implementieren muss.
Schnittstellendefinitionsdatei in IDL MIDL-Compiler Header-Datei mit Schnittstellendefinition Client-Projekt kann Schnittstellenzeiger bilden Server-Projekt vererbt Basisklasse und implementiert deren Member-Funktionen Schnittstellendefinition Quelle: http://www.informatik.uni-bonn.de/~ur/lectures/ss2002/folien/HJ-de-COM.ppt
IUnknown: das grundlegende Interface • Jedes COM- Objekt besitzt dieses Interface. • dient zur Identifizierung eines unbekannten COM Objektes. • Clients erhalten nach Instantiierung eines Objekts automatisch Schnittstellenzeiger auf dessen Schnittstelle IUnknown • IUnknown-Methoden können über jede Schnittstelle aufgerufen werden • Methoden von IUnknown liefern dem Client Zeiger auf weitere Schnittstellen des Objekts und übernehmen eine Referenzzählung zur Speicherverwaltung Interface IUnknown { virtual HRESULT QueryInterface(IID& iid, void ** ppvObj) = 0; virtual ULONG AddRef() = 0; virtual ULONG Release() = 0; }
ActiveX Controls Interfaces http://www.uni-weimar.de/~grolla/docs/com/
IUnknown-Methoden • QueryInterface: Überprüft, nach Angabe dieses bestimmten Interfaces, ob der aktuelle COM-Objekt dieses implementiert, und wenn dem so ist, wird die Referenz auf diesem Interface zurückgeliefert. • AddRef: Ist dafür zuständig, den Referenzzähler zu erhöhen, wenn eine neue Referenz übergeben wird. • Release: Ist dafür zuständig, den Referenzzähler zu erniedrigen, wenn eine Referenz verbraucht wird. Sobald der Wert des Zählers null ist, wird das COM Objekt unerreichbar und somit vernichtet.
Lebensdauer eines COM-Objekts • Der Referenzzähler eines COM-Objekts wird durch die Methoden AddRef nd Release beeinflusst (Quelle: Loos 2001).
Aufbau einer COM-Applikation • Anmelden bei COM • Umwandlung ProID nach CLSID • Erzeugen eines COM-Objekts • Bestimmen Schnittstellenzeigers anfordern • Methode aufrufen • Schnittstellenzeigers wieder freigeben • Aufräumen, Speicherplatzfreigabe • Abmelden von COM Quelle: http://www.informatik.uni-bonn.de/~ur/lectures/ss2002/folien/HJ-de-COM.ppt
Anmelden bei COM • Jedes COM-orientierte Windows-Programm, egal ob Client oder Server, muss sich vor dem ersten Zugriff auf das COM-Laufzeitsystem durch die CoInitialize Funktion bei COM anmelden: ... int main () { ODS0 ("[HelloClient]\tentering main\n"); // initialize COM libraries HRESULT hr = CoInitialize ((LPVOID) 0); ...
Umwandlung ProID nach CLSID // convert ProgID into corresponding CLSID CLSID CLSID_HelloWorldServer; hr = CLSIDFromProgID (L"HandsOnCOM.HelloWorld.1", &CLSID_HelloWorldServer );
Erzeugen eines COM-Objekts • verschiedene Alternativen: • Die am häufigsten vorkommende (und auch am einfachsten zu nutzende) ist die Funktion CoCreateInstance der COM-Bibliothek. Nachdem ein Client die COM-Bibliothek mit dem Aufruf CoInitialize initialisiert hat, kann er diese Funktion aufrufen, um eine Instantiierung einer registrierten Klasse zu veranlassen. • Diese Funktion muss für jedes zu erstellende Objekt aufgerufen werden. // create a HelloWorld object IUnknown * pIUnknown; hr = CoCreateInstance ( CLSID_HelloWorldServer, // CLSID of object (IUnknown *) 0, // object is not part of an aggregate CLSCTX_INPROC_SERVER, // see CLSCTX enumeration IID_IUnknown, // requested interface identifier (void **) & pIUnknown // return value );
1. Parameter: spezifiziert CLSID der gewünschten Klasse. • 2. Parameter: ist nur in Zusammenhang mit Aggregation von Bedeutung und bei uns NULL. • 3. Parameter: wir spezifizieren, dass das Objekt im eigenen Adressraum instantiiert werden soll. Für Nutzung eines OutProcServers würden wir CLSCTX_LOCAL_SERVER, für einen Server auf einem anderen Server CLSCTX_REMOTE_SERVER[1] spezifizieren (siehe wtypes.h). • 4. Parameter: Schnittstelle zu spezifizieren, mit der der Client arbeiten möchte, in unserem Fall eigentlich ISayHello. Der Einfachkeit halber (und aus didaktischen Gründen) fordern wir zunächst den IID_IUnknown-Schnittstellenzeiger an. Von im wissen wir, dass er von dem erzeugten COM-Objekt zur Verfügung gestellt wird. Die Anforderung des Schnittstellenzeigers für ISayHello kann in einem nachfolgenden Implementierungsschritt erfolgen, um an dieser Stelle nicht zwei getrennte Funktionalitäten zu vermischen.
CoCreateInstance • Erzeugt einen Interface Zeiger zu einer nicht initialisierten Instanz einer Objektklasse • CoCreateInstance ruft intern die Funktion CoGetClassObject auf, die sich dann an den Service Control Manager (SCM) wendet, eine Komponente der COM-Bibliothek. • Der SCM sucht in der Registrierung nach der CLSID, erzeugt das Objekt und reicht den empfangenen IUnknown-Schnittstellenzeiger an den Client weiter. Dieser kann dann direkt mit dem Objekt kommunizieren. • Falls die Komponente nicht im Prozessraum des Clients ausgeführt wird, erstellt COM automatisch nach der Objektinstantiierung ein Stub-Objekt für den Server und ein Proxy-Objekt für den Client.
Bestimmten Schnittstellenzeigers anfordern • Die Verhandlungen über einen bestimmten Schnittstellenzeiger (hier ISayHello werden im folgenden Codeabschnitt durchgeführt: // request ISayHello interface ISayHello * pISayHello; hr = pIUnknown -> QueryInterface ( IID_ISayHello, (void **) & pISayHello );
Methode aufrufen • Mit Hilfe des ISayHello- Schnittstellenzeigers können wir nun auf die Methoden dieser Schnittstelle aufrufen: hr = pISayHello->SayHello (szHello); // =============================================================== // interface ISayHello // =============================================================== interface ISayHello : public IUnknown { // ISayHello methods STDMETHOD (SayHello) (BSTR szMessage) PURE; };
Schnittstellenzeigers wieder freigeben // release interface pointer hr = pISayHello -> Release (); hr = pIUnknown -> Release ();
Aufräumen, Speicherplatzfreigabe • Für den Aufruf hr = pISayHello -> SayHello (szHello) musste eine BSTR-Variable mit SysAllocString erzeugt werden, die jetzt wieder freigegeben wird: // free BSTR SysFreeString (szHello);
Abmelden von COM • Sind keine weiteren Zugriffe mehr auf ds COM-System vorgesehen, melden wir uns wieder von COM ab: // release COM libraries CoUninitialize ();
COM-Server, COM-Client • Definition COM-Server:Binärdatei (.exe oder .dll), die die Realisierung einer oder mehrerer COM-Klassen enthält und Objekte für Client (Erzeugung, Zugriff über Schnittstellenzeiger) bereitstellt. • Definition COM-Client:Windows-Programm, das Erzeugung eines (oder mehrerer) COM-Objekte veranlasst und seine Methoden aufruft.
Server / Binärdatei: Zwei Arten • Windows DLL (Dynamic Link Library, .dll), auch In-Process-Server genannt • Eigenständiges Programm (.exe-Datei), auch OutProc-Server genannt • Remote Server (Programme, die in Netzwerken benutzt werden können)
In-Process-Server (InProc-Server) • Dynamic Link Libraries (DLL's) • zur Laufzeit in den Prozess des Client-Programmes geladen • Funktionsaufrufe zwischen Client und Server können direkt erfolgen. • Hieraus resultiert ein sehr günstiges Laufzeitverhalten.
Out of Process-Server (OutProc-Server) • eigenständig ausführbare Programme (.EXE) • separater Prozess • Kommunikation mit dem Client über das sogenannte Marshalling. Hierfür ist ein Proxy/Stub-Modul notwendig, welches Funktionsaufrufe in „Inter Process Calls“ (IPC) übersetzt. Dieses Modul kann relativ einfach als Dynamic Link Library bereitgestellt werden.
Beide Stellvertreter werden in der Regel durch ein Werkzeug automatisch aufgrund einer Schnittstellendefinition generiert, die mittels IDL verfasst wird. compilieren .tld
Transport vom Client zum Server-Prozess • Remote Procedure Call (RPC, seit 1997), http://www.opengroup.org/onlinepubs/009629399/toc.htm • Für das Verpacken der Parameter in ein übertragbares Paket und seine Übertragung über Prozessgrenzen hinweg wurde der Begriff Marshaling gewählt. Das Auspacken und die Wandlung in eine Format, das für den empfangenden Prozess verständlich ist, wird als Unmarshaling bezeichnet. • Hauptvertreter: Typbibliotheks-Marshaling mit vorgefertigter Implementierung