COM ( C omponent O bject M odel) / DCOM ( D istributed COM )

1. COM (Component Object Model) / DCOM (Distributed COM) Evgenij Kuznecov

2. Gliederung • Einführung • Entwicklungsziele • COM • Binäre Interoperabilität • COM- Objekte • Interfaces / Schnittstellen • Klassen • Registry

3. Gliederung (2) • DCOM • Serverarten • Sicherheitsmechanismen • Kommunikationsaufbau • Wiederverwendung von Objekten • Automation • Threads von DCOM • Ausblick auf COM+

4. Einführung • komponentenbasierte Softwareentwicklung in Windows-Umgebungen • Basistechnologie für verteilte Systeme • ActiveX, DNA(Dynamic InterNet Applications ) oder OLE(Object Linking & Embedding) basieren letztendlich auf COM • 1996 ein verteiltes Komponenten-Modell entwickelt. Um dies auszudrücken wurde COM um den Buchstaben D für distributed erweitert und hieß damit DCOM.

5. Entwicklungsziele • Interoperabilität • Zusammenarbeit zwischen Applikationen in verschienenen Programmiersprachen • Skalierbarkeit • Keine Beschränkung hinsichtlich der Zahl von Kommunikationspartnern oder ihrer Größe • Sprachenunabhängigkeit • Unterstützung beliebiger Programmiersprachen • Verteilungstransparenz • Für einen Client bleibt verborgen, wo die verwendete Komponente liegt • Robustheit gegenüber Weiterentwicklung • Änderung von Komponenten soll keine Auswirkung auf existierende Clients haben • COM verwendet als architekturelles Prinzip das Broker-Pattern.

6. Broker-Pattern Struktur

7. COM • Zusammenarbeit verschiedener Applikationen • Client / Server - Prinzip. • Einem Client zu ermöglichen, auf die Dienste eines Servers zugreifen • binäres Format • wie die auszutauschenden Objekte im Speicher abzulegen sind • Dienste durch Interfaces

8. Binäre Interoperabilität • Motivation • unabhängige binäre Anwendungen • Lösung • virtuelle Tabellen (VTBL) • einheitliche Position von Methoden aus Interface in jeder VTable (Handle)

9. COM - Objekte • Bei COM - Objekten handelt es sich um die Instanzen zuvor definierter Klassen • eindeutiger Identifikator (Class Identifier CLSID) • Vermeindung der Namenskonflikte • Festlegung noch vor der Entwicklung einer Klasse • Binärer Format • API mit der Bezeichnung "CoCreateGuid„ • GUIDGEN.EXE oder UUIDGEN.EXE • erstellten CLSID's werden in den Headerdateien abgelegt • Werden nur von Entwickler des jeweiligen COM- Objektes benötigt • oder von Entwicklern die dieses Objekt in einem Ihrer Projekte weiterverwenden

10. Guid 48 Bits = Rechnerspezifisch 60 Bits = Zeitstempel (100- Nanosekunden-Intervalle seit dem 15.10.1582) Überlauf ca. im Jahr 3400 4 Bits = GUID-Versionsnummer 16 Bits = aus Systemzeit und Adresse der Netzwerkkarte berechnet Typedef struct GUID { DWORD Data1; // 32 Bit WORD Data2; // 16 Bit WORD Data3; // 16 Bit Byte Data4[8]; // 64 Bit }

11. Interfaces • Zugriff auf die Funktionalität von Komponenten • Mehrere Interfaces sind erlaubt • semantisch zusammengehörige Gruppe von Methoden • Facette eines Objekts • Erzeugen: Interface Definition Language (IDL) • [Attributes] Elementname Typename {memberdescriptions} • Kontrakt zwischen dem Anbieter und dem Nutzer zum Beispiel Methoden wie save() zum Datensichern und nicht etwa zum Löschen zu verwenden.

12. Beispiel erzeugeST löscheSt bearbeiteSt IStudenten IProfessoren erzeugePr löschePr bearbeitePr Das COM - Objekt in der Abbildung besitzt zwei Interfaces: IStudenten und IProfessoren

13. Beispiel • Microsoft Interface Definition Language MIDL • [Attributes] Elementname Typename {memberdescriptions} // interface IStudenten[ object, uuid(12345678-1a2b-3d4e-1111-123456789abc), helpstring(“Studenten") ] interface IStudenten : IUnknown { HRESULT erzeugeST([in] LPSTR eStudent); HRESULT löscheST([in] LPSTR lStudent); HRESULT bearbeiteST( [in] LPSTR bStudentAlt, [in] LPSTR bStudentNeu); };

14. Interfaces (2) • Der Zugriff über Schnittstellenzeiger (Handles) • Der Wechsel des Zugriffes von einem Interface auf ein anderes wird als "interface navigation" bezeichnet • Interface Iunknown • QueryInterface: liefert "Handle" auf gewünschtes Interface • AddRef: explizite Speicherverwaltung • Release: explizite Speicherverwaltung • interface Iunknown { virtual HRESULT QueryInterface(IID& iid, void **ppv) = 0; virtual ULONG AddRef() = 0; virtual ULONG Release() = 0; }

15. Beispiel • Addref wird automatisch bei der Erzeugung eines Objektes aufgerufen • Release wird automatisch bei der Löschung eines Objektes aufgerufen • class CBeispielObjekt : Iunknown • { private: ULONG cRef;} • CBeispielObjekt::AddRef(void){  //AddRefULONG • return ++cRef; • } • CBeispielObjekt::Release(void){ //ReleaseULONG • cRef--; if (cRef == 0) • { delete this; } • return cRef; • }

16. Klassen • Klassen sind von einer oder mehreren Schnittstellen abgeleitet • Aufgaben: • Interfaces implementieren • Memberfunktionen implementieren • eindeutige GUID - „Class Identifier" (CLSID)

17. Registry • alle wichtigen Informationen zu den COM- Klassen • friendly name, in diesem Fall “Tail Rotor Simulator” • Servertype, hier InprocServer32 • Ort des Servers: „C:\Helicopter\TailRotor.dll“ • Welche Threads unterstützt werden, hier „Apartment Threads“ • ProgID: ist nicht eindeutig ist • TypeLib: Die TypeLibraries enthalten Typinformationen über die Komponente, ihre Interfaces, ihre Methoden. Sie liegen als Binärfile vor

18. DCOM • Erweiterung des COMs • Bearbeitung der Objekte,die sich auf verschiedenen Rechnern befinden • Aufsetzt auf RPC(Remote Procedure Call) – Verfahren • unterstützt TCP : Transmission Control Protocol UDP : User Data Protocol IPX : Internetwork Packet Exchange

19. Serverarten • Klasse jedes COM – Objektes liegt in binärer Form (entweder EXE oder DLL) vor und wird als COM-Server bezeichnet • in-process-server • Server die als DLL ( Dynamic-Linked-Library ) vorliegen • werden direkt in den Adressraum des Clients geladen • hohe Geschwindigkeit • out-process-server(.EXE : Programm) • ein eigener Adressraum • Die reservierten Ressourcen werden zwischen den die Dienste des Servers in Anspruch nehmenden Clients aufgeteilt

20. Ablauf de Kommunikation • Proxy • exakt dieselben Schnittstellen wie das ihm zugeordnete COM- Objekt • Clients verweisen auf die Schnittstellenimplementierung des Proxy • Einrichtung eines Kommunikationskanals • Konvertierung der Parameter (Marshaling) • Weiterleitung der Anfrage • Rückmeldung der Ergebnisse • Stub • Verbindungsaufbau mit dem Client • Empfang von Aufrufen • Entpacken von Parametern (Demarshaling) • Aufruf des COM- Objekts (Dispatching). • LPCs (Local Procedure Calls)- Kommunikation von Proxies und Stubs auf derselben Maschine • RPCs (Remote Procedure Calls ) - Kommunikation über Maschinengrenzen

21. Local Server Local Object Ablauf der Kommunikation(2) Client Process Local Server Process In-Proc-Server In Proc Object Com Stub LPC Client Application COM Local Object Proxy Remote Server Process Remote Server Com Stub Remote Object Remote Object Proxy RPC

22. Imoniker • Es gibt keine Möglichkeit eine unterbrochene Verbindung wieder herzustellen • Zuweisung eines symbolischen Name • Eine eindeutige Objektidentifikation • Speichern und Laden eines Zustands eines Objekts • ein neues Objekt erzeugen • Vorgang der Erzeugung muss explizit durch den Client erfolgen

23. Sicherheitsmechanismen • activation security legt fest (und überwacht) wer beispielsweise COM Server starten darf • call security dient der Regulierung des Zugriffs auf die Funktionen des Interfaces eines COM – Objektes • Um überhaut Zugriff auf die benötigten Dienste zu bekommen muss sich der Benutzer erst authentifizieren • 6 Authentifizierungsebenen z.B. RPC_C_AUTHN_LEVEL_NONE Keine Authentifizierung nötig • Festlegung der Zugriffsrechte auf Schnittstellen • Festlegung der Zugriffsrechte auf Ressourcen

24. Kommunikationsaufbau • Informationen über einen "entfernten" COM - Server • Struktur COSERVERINFO • typedef struct _COSERVERINFO • { • DWORD dwReserved1; • LPWSTR pwszName; • COAUTHINFO *pAuthInfo;  Authentication - Einstellungen • DWORD dwReserved2; • } COSERVERINFO; • pwszName    : zeigt auf den Namen des zu benutzenden Computers pAuthInfo    : Zeiger auf eine COAUTHINFO - Struktur, legt activation security fest

25. Kommunikation • Erzeugen der Objekte • CoGetClassObject – finden des Objektes • CoCreateInstance - erzeugen des Objektes • Aktivierung des Objektes durch Service Control Manager.  • CoCreateInstanceEx mehrere Schnittstellenzeiger auf dasselbe Objekt • Server, der Objekte nach außen zur Verfügung stellt, bezeichnet DCOM als Objektexporteur Client Server (Objekt) Proxy Stub Service Control Manager Service Control Manager

26. Kommunikation (2) • 1 CoCreateInstance() aufrufen • 2 in Registry nachschauen (lokal) • 3 in Registry nachschauen und Objekt aktivieren (entfernter Rechner) • 4 Schnittstellenzeiger zurückliefern • 5 Schnittstellenzeiger benutzen

27. IUnknown Äußeres Objekt A C B B B C C Aggregation Wiederverwendung von Objekten • keine Implementationsvererbung sondern Interfacevererbung • zwei Arten von Wiederverwendung in DCOM • Containment/Delegation • Aggregation • Es gibt jeweils ein inneres und ein äußeres Objekt • Gemeinsam ist beiden, Sprachunabhängigkeit, da die wiederverwendeten Objekte als Binärcode vorliegen können IUnknown Äußeres Objekt A B C Containment/Delegation

28. Containment / Delegation • die Interfaces des inneren Objektes werden vom äußeren Objekt neu implementiert • Innerhalb dieser Neuimplementierung werden dann die Interfaces des inneren Objektes aufgerufen • Somit greift der Client nicht direkt auf das wiederverwendete Interface zu • die Möglichkeit neue Funktionalität dem Interface hinzuzufügen • Das Verhältnis entspricht einem Client-Server-Verhältnis

29. Aggregation • Direkter Zugriff auf die Interfaces des inneren Objekts • Problem: • Memberfunktion Queryinterface des inneren Objektes kennt die Interfaces des äußeren Objektes nicht • Lösung • Einführung Zweier IUnknown Interfaces • Delegating Iunknown • IUnkown- Interface des inneren Objektes • eine Referenz auf das IUnknown- Interface des äußeren Objektes • Nondelegating Iunknown • Das Nondelegating IUnknown wird benötigt, wenn nicht über ein äußeres Objekt auf das innere Objekt zugegriffen wird. In diesem Fall werden Anfragen von dem inneren Objekt selbst bearbeitet. • ein Objekt muss schon bei der Implementierung auf Aggregation ausgelegt werden (Implementierung von Delegating und Nondelegating IUnknown).

30. IUnknown Äußeres Objekt A C B B C Aggregation Aggregation IUnknown

31. Automation • dynamische Methodenaufrufe • es wird erst zur Laufzeit bestimmt, welche Methode aufgerufen wird • Interface IDispatch • für Interpretative Umgebungen und Scriptsprachen • Schnittstelle zu mehreren eigentlichen DCOM- Interfaces • interface IDispatch : IUnknown { HRESULT getTypeInfoCount(/* ... */); HRESULT getTypeInfo(/* ... */); HRESULT getIDsOfNames(/* ... */); HRESULT invoke(/* ... */); }; • getTypeInfo() textuelle Darstellung der Methoden • Mit invoke() teilt der Client mit, welche Methode er mit welchen Parametern aufrufen möchte • getIDsOfNames Abbildung von Strings auf Zahlenwerte • Möglichkeit, Interfaces als ein Dual Interface zu implementieren

32. Threads in DCOM • Apartment Thread • Free Thread

33. Ap. Thread bel. Thread Client Appl. Client Appl. Objekt Stub Proxy Apartment Thread • Apartment Thread • single- threaded • ein Objekt gehört im Prinzip dem erzeugenden Thread • alle Zugriffe auf das Objekt müssen über den erzeugenden Thread erfolgen • DCOM- Klassen müssen nicht thread- safe implementiert werden

34. Client Appl. Client Appl. Objekt Free Threads • Free Thread • multi- threaded • erzeugten Objekte gehören nicht mehr nur dem erzeugenden Prozess • alle Prozesse können beliebig auf das Objekt zugreifen • Klassen müssen thread- safe implementiert weden • Implementierung von Marshalling und Unmarshalling

35. Ausblick auf COM+ • Weiterentwicklung von DCOM • Wegfallen des Programmier-Overheades (z.B. Referenzzähler, Implementierung von IUnknown usw.) • GUIDs - interne Verwendung • Konstruktoren und Destruktoren (Objekte initialisieren) • Kontrolle des Lebensdauers von Objekten • Implementationsvererbung • jede maschinenspezifische Datenbank statt Registry

36. Fragen?

37. Vielen Dank