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

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

description

COM ( C omponent O bject M odel) / DCOM ( D istributed COM ). Evgenij Kuznecov. Gliederung. Einführung Entwicklungsziele COM Binäre Interoperabilität COM- Objekte Interfaces / Schnittstellen Klassen Registry. Gliederung (2). DCOM Serverarten Sicherheitsmechanismen - PowerPoint PPT Presentation

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

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

COM (Component Object Model) / DCOM (Distributed COM)

Evgenij Kuznecov

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–2

Gliederung

Einführung Entwicklungsziele

COM Binäre Interoperabilität COM- Objekte Interfaces / Schnittstellen Klassen Registry

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–3

Gliederung (2)

DCOM Serverarten Sicherheitsmechanismen Kommunikationsaufbau Wiederverwendung von Objekten Automation Threads von DCOM

Ausblick auf COM+

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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.

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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.

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–6

Broker-Pattern Struktur

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–7

COM

Zusammenarbeit verschiedener Applikationen Client / Server - Prinzip.

Einem Client zu ermöglichen, auf die Dienste eines Servers zugreifen

binäres Formatwie die auszutauschenden Objekte im Speicher abzulegen sind

Dienste durch Interfaces

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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)

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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ötigtoder von Entwicklern die dieses Objekt in einem Ihrer Projekte

weiterverwenden

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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 BitWORD Data2; // 16 BitWORD Data3; // 16 BitByte Data4[8]; // 64 Bit}

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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.

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–12

Beispiel

erzeugeSTlöscheStbearbeiteSt

erzeugePrlöschePrbearbeitePr

IStudenten

IProfessoren

Das COM - Objekt in der Abbildung besitzt zwei Interfaces:

IStudenten und IProfessoren

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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); };

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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;

}

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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;}

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–16

Klassen

Klassen sind von einer oder mehreren Schnittstellen abgeleitet Aufgaben:

Interfaces implementieren Memberfunktionen implementieren

eindeutige GUID - „Class Identifier" (CLSID)

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–21

Ablauf der Kommunikation(2)

In ProcObject

In-Proc-Server

RemoteObject

Remote Server

Stub

ComRemote Server Process

LocalObject

Local Server

Stub

ComLocal Server Process

RemoteObjectProxy

Client Process

LocalObjectProxy

ClientApplication

COM

RPC

LPC

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

Proxy Stub

Client

Service Control Manager

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

C

B

IUnknown

A

B

C

Containment/Delegation

Äußeres Objekt

C

B

IUnknown

A

B

C

Aggregation

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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ösungEinfü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).

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–30

Aggregation

Äußeres Objekt

C

B

IUnknown

A

B

C

Aggregation

IUnknown

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–32

Threads in DCOM

Apartment Thread Free Thread

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–33

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

ClientAppl.

Objekt

Stub

ClientAppl.

Proxy

Ap. Thread bel. Thread

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–34

Free Threads

Free Threadmulti- 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

ClientAppl.

ClientAppl.

Objekt

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–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

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–36

Fragen?

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

Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–37

Vielen Dank