Post on 03-Jan-2016
description
COM (Component Object Model) / DCOM (Distributed COM)
Evgenij Kuznecov
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
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+
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.
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.
Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–6
Broker-Pattern Struktur
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
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)
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
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}
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.
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
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); };
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;
}
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;}
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)
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
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
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
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
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
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
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
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
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
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
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
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
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).
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
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
Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–32
Threads in DCOM
Apartment Thread Free Thread
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
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
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
Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–36
Fragen?
Universität Bonn, Institut für Informatik III Vorlesung Softwaretechnologie, Wintersemester 2003-2004 1–37
Vielen Dank