Transcript Seminar-Layout

COM (Component Object Model) /
DCOM (Distributed COM)
Evgenij Kuznecov
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–2
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–3
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–4
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–5
Broker-Pattern Struktur
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–6
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
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–7
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–8
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
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–9
Guid
48 Bits = Rechnerspezifisch
60 Bits = Zeitstempel (100Nanosekunden-Intervalle
seit dem 15.10.1582)
Überlauf ca. im Jahr 3400
4 Bits = GUID-Versionsnummer
16 Bits = aus Systemzeit und
Adresse der Netzwerkkarte
berechnet
Universität Bonn, Institut für Informatik III
Typedef struct GUID
{
DWORD Data1;
// 32 Bit
WORD Data2;
// 16 Bit
WORD Data3;
// 16 Bit
Byte Data4[8];
// 64 Bit
}
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–10
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–11
Beispiel
erzeugeST
löscheSt
bearbeiteSt
IStudenten
IProfessoren
erzeugePr
löschePr
bearbeitePr
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–12
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–13
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:
 AddRef:
 Release:
liefert "Handle" auf gewünschtes Interface
explizite Speicherverwaltung
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–14
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–15
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–16
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–17
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–18
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–19
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–20
Ablauf der Kommunikation(2)
Client Process
In Proc
Object
LPC
Local
Object
Local Server
Com
Local Server Process
RPC
Remote
Object
Remote Server
Com
Remote Server Process
Stub
In-Proc-Server
Client
Application
Local
Object
Proxy
Stub
COM
Remote
Object
Proxy
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–21
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–22
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–23
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–24
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
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–25
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–26
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
IUnknown
A
Äußeres Objekt
B
B
B
B
C
C
C
C
Containment/Delegation
Universität Bonn, Institut für Informatik III
Aggregation
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–27
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
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–28
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).
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–29
Aggregation
IUnknown
A
Äußeres Objekt
IUnknown
B
B
C
C
Aggregation
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–30
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
HRESULT
HRESULT
HRESULT
HRESULT
};
IDispatch
{
getTypeInfoCount(/*
getTypeInfo(/*
getIDsOfNames(/*
invoke(/*
:
IUnknown
...
...
...
...
*/);
*/);
*/);
*/);
 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–31
Threads in DCOM
 Apartment Thread
 Free Thread
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–32
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
Ap. Thread
Client
Appl.
bel. Thread
Client
Appl.
Objekt
Stub
Universität Bonn, Institut für Informatik III
Proxy
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–33
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
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–34
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–35
Fragen?
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–36
Vielen Dank
Universität Bonn, Institut für Informatik III
Vorlesung Softwaretechnologie, Wintersemester 2003-2004
1–37