Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "COM (Component Object Model) / DCOM (Distributed COM) Evgenij Kuznecov."—  Präsentation transkript:

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

2 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –2 Gliederung Einführung Entwicklungsziele COM Binäre Interoperabilität COM- Objekte Interfaces / Schnittstellen Klassen Registry

3 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –3 Gliederung (2) DCOM Serverarten Sicherheitsmechanismen Kommunikationsaufbau Wiederverwendung von Objekten Automation Threads von DCOM Ausblick auf COM+

4 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –6 Broker-Pattern Struktur

7 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –10 Guid 48 Bits = Rechnerspezifisch 60 Bits = Zeitstempel (100- Nanosekunden-Intervalle seit dem ) Überlauf ca. im Jahr 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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –12 Beispiel erzeugeST löscheSt bearbeiteSt erzeugePr löschePr bearbeitePr IStudenten IProfessoren Das COM - Objekt in der Abbildung besitzt zwei Interfaces: IStudenten und IProfessoren

13 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –13 Beispiel Microsoft Interface Definition Language MIDL [Attributes] Elementname Typename {memberdescriptions} // interface IStudenten [ object, uuid( a2b-3d4e abc), 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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –16 Klassen Klassen sind von einer oder mehreren Schnittstellen abgeleitet Aufgaben: Interfaces implementieren Memberfunktionen implementieren eindeutige GUID - Class Identifier" (CLSID)

17 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –21 Ablauf der Kommunikation(2) In Proc Object In-Proc-Server Remote Object Remote Server Stub Com Remote Server Process Local Object Local Server Stub Com Local Server Process Remote Object Proxy Client Process Local Object Proxy Client Application COM RPC LPC

22 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Server (Objekt) Service Control Manager ProxyStub Client Service Control Manager

26 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –27 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 Äußeres Objekt CB IUnknown A B C Containment/Delegation Äußeres Objekt C B IUnknown A B C Aggregation

28 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –28 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 Containment / Delegation

29 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –30 Aggregation Äußeres Objekt C B IUnknown A B C Aggregation IUnknown

31 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –32 Threads in DCOM Apartment Thread Free Thread

33 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –33 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 Client Appl. Objekt Stub Client Appl. Proxy Ap. Threadbel. Thread

34 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –34 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 Client Appl. Client Appl. Objekt

35 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –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 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –36 Fragen?

37 Universität Bonn, Institut für Informatik IIIVorlesung Softwaretechnologie, Wintersemester –37 Vielen Dank


Herunterladen ppt "COM (Component Object Model) / DCOM (Distributed COM) Evgenij Kuznecov."

Ähnliche Präsentationen


Google-Anzeigen