Transcript Software aus Komponenten

I.2.3. DCOM
Distributed Component Object Model
Dr. Welf Löwe und Markus Noga
1
Literatur
Es scheint keine guten COM Bücher zu geben.
Don Box. Essential COM. Addison-Wesley. 1998. Viel zu
detailliert, zu wenig abstrakte Konzepte. Eher ein Hacker
Buch.
Plasil, F, Stal, M. An architectural view of distributed objects
and components in CORBA, Java RMI, and COM/DCOM.
Software - Concepts and Tools, 19: 14-28. Technischer
Überblick. Recht knapp und gut. Empfohlen zur
Prüfungsvorbereitung.
Dr. Welf Löwe und Markus Noga
2
DCOM-Entwicklung
DCE (distributed computing environment)
OLE (object linking and embedding) - ActiveX: OLEErweiterung
COM (component object model)
DCOM (distributed COM)
Grenzen fließend!
Dr. Welf Löwe und Markus Noga
3
DCE
OSF (open software foundation) ähnlich Corba OMG
Nicht Microsoft standard
Verteiltes Betriebssystem
Plattformunabhängig
Basiskommunikation RPC
Konzept von IDL, mit generierten Client-Server-Stubs etc.
Dr. Welf Löwe und Markus Noga
4
OLE -ActiveX
OLE (object linking and embedding)
Ende der 80er für Microsoft Office.
Ermöglicht Verbunddokumente (Spreadsheets und
Graphiken in Texten, von den jeweiligen Werkzeugen
bearbeitet),
Entspricht also OpenDoc (Apple)
Dr. Welf Löwe und Markus Noga
5
COM
COM (component object model)
Komponentenarchitektur für Microsoft Windows 1993
Schnittstellenbeschreibungen mit MIDL (Microsoft IDL),
– aus DCE (distributed computing environment) abgeleitet
– ähnlich CORBA IDL
Dr. Welf Löwe und Markus Noga
6
Ursprüngliche Trennung OLE und COM
OLE
application
services
Basis
COM ist Basiskomponentenarchitektur für aufgesetzte Dienste
Dr. Welf Löwe und Markus Noga
7
Wiederverwendete Technologie
ObjectOriented
Model
Client/Server
Model
Dynamic
Linking
Component Object Model (COM)
Dr. Welf Löwe und Markus Noga
8
(D)COM
Binärstandard Interoperabilität zwischen Komponenten
– Sprachunabhängig
– Über Prozessgrenzen
– Über Rechnergrenzen
Reflexion und Dynamisches Nachladen von Komponenten
Versionierung von Komponenten und Schnittstellen
Dr. Welf Löwe und Markus Noga
9
Komponentenmodell
MyComponent (DLL or EXE)
IUnknown
IUnknown
ILoveCom
IViewer
(COM Interface)
CoViewer
(COM Object)
CoPersonality
IHateCom
IUnknown
ISecure
CoSecure
IPersist
Dr. Welf Löwe und Markus Noga
10
Grundfunktionalität
Binärstandard für Aufrufe zwischen Komponenten
Gruppierung (schwach) typisierter Funktionen zu
Schnittstellen (interfaces)
Basisschnittstelle (IUnknown)
– Reflektion über Interfaces anderer Komponenten
– Reference counting zur Verwaltung von Lebenszyklen
Eindeutige Identifikation von Komponenten und
Schnittstellen (GUID)
Komponentenfabrik transparent über
– Sprache
– Prozess
– Rechner
Dr. Welf Löwe und Markus Noga
11
Binärer Aufrufstandard
Entsprechend C Standard:
– Layout von virtuellen Funktionstabellen (vtables)
– Aufruf der Funktionen über vtables
Klient kennt vtable
Aufruf möglich in allen Sprachen, die Funktionen über
Zeiger aufrufen können (C, C++, SmallTalk, Ada, Basic, ...)
Dr. Welf Löwe und Markus Noga
12
Schnittstelle und Implementierung
Komponente kann mehreren Schnittstellen genügen
Komponentenreferenz ist immer Referenz auf eine
Schnittstelle
IUnknown
COM
Object
Client
Dr. Welf Löwe und Markus Noga
13
Schnittstelle
Sammlung von Funktionen, die eine Komponente anbietet
Signatur ist Vertrag
– Schwach typisiert bzgl. Werten und Schnittstellen
Eindeutige Namen
– Weltweit eindeutig
– Unveränderlich – Vertrag für die Ewigkeit
Vererbung auf Schnittstellen
– Mehrfach
– Jedes Interface muss (transitiv) von IUnknown erben
Konventionen für die Benennung der Methoden zur Dokumentation
Unterschiedlich zu
– Klassen (Implementierung von Schnittstellen)
– Komponenten
Dr. Welf Löwe und Markus Noga
14
Beispiel
IUnknown
ILookup
COM
Object
interface ILookup : public IUnknown
{
public:
virtual HRESULT __stdcall LookupByName
(LPTSTR lpName,TCHAR **lplpNumber) = 0;
virtual HRESULT __stdcall LookupByNumber
(LPTSTR lpNumber, TCHAR **lplpName) = 0;
};
Dr. Welf Löwe und Markus Noga
15
Identifikation (GUID)
Global und zeitlos eindeutig (general unique id)
128-bit Name (enthält Zeit und Boardid)
Automatische Versionierung
Verhindert Namenskonflikte
Lesbare Namen müssen explizit zugeordnet werden
– nur für Dokumentation und Bequemlichkeit
– Lokaler Gültigkeitsbereich
Alias für DCE RPC Universal Unique ID (UUID)
IIDs - GUIDs für
Schnittstellen
COM
Object
CLSIDs - GUIDs für
COM Klassen
0xc4910d1
0xc4910d2
Dr. Welf Löwe und Markus Noga
16
Identifikatoren
Automatisch generiert
Microsoft Programm
CoCreateGuid aus der COM API
– uuidgen.exe
–
Im Binärcode enthalten und dynamisch getestet
Referiert über lokale Namen
DEFINE_GUID(CLSID_PHONEBOOK,
0xc4910d70, 0xba7d, 0x11cd, 0x94, 0xe8,
0x08, 0x00, 0x17, 0x01, 0xa8, 0xa3);
DEFINE_GUID(IID_ILOOKUP,
0xc4910d71, 0xba7d, 0x11cd, 0x94, 0xe8,
0x08, 0x00, 0x17, 0x01, 0xa8, 0xa3);
Dr. Welf Löwe und Markus Noga
17
Eindeutige Identifikatoren
Wie wird die Evolution von Software unterstützt
IUnknown: QueryInterface
- Abfragen, Aufruf neuer Funktionen ohne Übersetzung
Interfaces unveränderlich
- Rückwärtskompatibilität
- Komponenten unterstützen alte Schnittstellen
- Versionierung von Hand
Wie wird Interaktion von Komponenten unterstützt
Indirekte Funktionsaufrufe
(doppelte Indirektion, vtables)
- Performance-Verlust bei Kommunikation mit einem
COM Objekt im selben Prozess kann vernachlässigt
werden
Dr. Welf Löwe und Markus Noga
18
Vorteile-Nachteile der GUIDs
Vorteile
– Wiederverwendung, Wiedererkennung
– Schnittstellen Vererbung eindeutig
– Transprarenz
• In-process, cross-process, remote
• Programmiersprache
Nachteile
– Viele ähnliche Interfaces
– Keine Möglichkeit, Entwicklungen zusammenzuführen
Dr. Welf Löwe und Markus Noga
19
Interface IUnknown
Unterstützt von allen COM Objekten
Basisfunktionalität:
1 QueryInterface
Dynamically discover other
interfaces supported by an object
2 AddRef
3 Release
Management of an object´s life cycle
Dr. Welf Löwe und Markus Noga
20
IUnknown in MIDL
interface IUnknown {
virtual HRESULT QueryInterface
(IID& iid, void** ppvObj) = 0;
virtual ULONG
AddRef() = 0;
virtual ULONG
Release() = 0;
}
Dr. Welf Löwe und Markus Noga
21
Abfrageschnittstelle
Laufzeittest, ob eine Schnittstelle unterstützt wird
Mechanismus, um tatsächlich einen Zeiger auf ein
Schnittstellenobjekt zu bekommen
– Client: Anfrage auf das Schnittstellenobjekt, das eine Funktion
unterstützt
– Server:
• kennt er die entsprechende Schnittstelle, wird der Zeiger
zurückgegeben und Erfolg gemeldet
• Kennt er sie nicht, Fehlermeldung
Dadurch schwache Typisierung
Dr. Welf Löwe und Markus Noga
22
Lebenszyklus
Referenzzähler
– AddRef: Aufgerufen bei Referenzierung oder Kopieren der Referenz
– Release: Aufgerufen, wenn Referenz nicht mehr benötigt
– Löschen des Objektes, wenn keine Referenz vorhanden
Extrem Fehlerträchtig aber
Sehr einfach zu implementieren
AddRef:
reference counter = reference counter + 1
Release:
reference counter = reference counter - 1
if reference counter == 0:
delete component object, release resources
Dr. Welf Löwe und Markus Noga
23
Beispiel
LPLOOKUP *pLookup;
TCHAR szNumber[64];
HRESULT hRes;
// Call QueryInterface on the component object
// PhoneBook, asking for a pointer to the ILookup
// interface identified by a unique interface ID.
hRes = pPhoneBook->QueryInterface(IID_ILOOKUP, &pLookup);
if( SUCCEEDED( hRes ) ) {
// use Ilookup interface pointer
pLookup->LookupByName("Daffy Duck", &szNumber);
// finished using the IPhoneBook interface pointer
pLookup->Release();
}
else {
// Failed to acquire Ilookup interface pointer.
}
Dr. Welf Löwe und Markus Noga
24
Ergebnis der Anfrage
HRESULT - 32-bit long Integer
1 bit
Severity
Field
Erfolg
Fehler
2 bits
For future
use
Null
13 bits
16 bits
Facility
Reason
Fehlerklasse
Vordefiniert von COM
Zentral herausgegeben
Fehlerwert
Frei programmierbar
Fehlerverursacher
Dr. Welf Löwe und Markus Noga
25
COM Bibliothek
Implementierung der Standard API Funktionen für
Kommunikation
Selbst eine (System-)Komponente
– Laufzeitunterstützung von COM
– Dynamische Bibliotheken
– COMPOBJ.DLL, OLE32.DLL
Verantwortlich
– Objekterzeugung
– Verbindungen zwischen Objekten herzustellen und zu koordinieren
Dr. Welf Löwe und Markus Noga
26
Zugriff einer Komponente
Object
Interface
Client
Server
(5) Aufruf
Object
Client
Application
(4)
Objekt Interface
Zeiger an Klienten
(3) Finde (Objekt-)
Implementierung,
Lade server code
(1) Anfrage mit
CLSID
CLSID
COM
Bibliothek
Registry
Server
Code
(2) Nachschlagen
in der Registry
Dr. Welf Löwe und Markus Noga
27
Registrierdatenbank (registry)
Übernommen aus COM
Verwaltet Schnittstellen, Implementierungen von Klassen
– registry in NT 4.0: hierarchisch, auf Verzeichnisse im Dateisystem
abgebildet
– entsprechen den CORBA interface/implementation repositories
– Schlüssel: CLSID
Service Control Manager (SCM) kapselt registry
–
–
–
–
findet Klassen und ihren Code in der Registrierdatenbank
aktiviert ihn in einem Fabrikprozess
erzeugen Objekte bereits aktiver Fabrikprozesse
dazu: Klassen müssen registriert werden
Dr. Welf Löwe und Markus Noga
28
Einträge
Pathname of server EXE
(local, out-of-process)
Servertyp
CLSID
Server Code
12345678-ABCD-1234-5678-9ABCDEF00000
LocalServer32 = C:\MyDir\MyServer.exe
12345678-ABCD-1234-5678-9ABCDEF00012
InprocServer32 = C:\object\textrend.dll
Pathname of server DLL
(in-process)
Dr. Welf Löwe und Markus Noga
29
Erzeugen des Objekts
Client
Server
(7)
Object
Client
Application
(6)
IClassFactory
Fabrik
(1) CoCreateInstance
(4)
SCM
(2)
(3)
Registry
Dr. Welf Löwe und Markus Noga
30
Erzeugen der Fabrik
Client
Server
Object
Object
Client
Application
IClassFactory
(5) CreateInstance
(1) CoGetClassObject
Fabrik
(6)
(4)
SCM
(3)
Registry
(2)
Dr. Welf Löwe und Markus Noga
31
Finden der Komponente
Server ist ein ausführbares Programm
–
–
–
–
COM ruft Programm auf
Implementiert eine Klassenfabrik um Instanzen zu erzeugen
Server registriert diese Fabrik CoRegisterClassFactory()
COM wartet darauf, um Erzeugung von Objekte auszuführen
Server ist eine Dynamische Bibliothek (DLL)
– COM lädt DLL
– Aufruf DLLGetClassFactory()
Dr. Welf Löwe und Markus Noga
32
Reihenfolge der Suche
Client
1
SCM
3
COM Cache
...
Registry
2 InprocServer
4 LocalService
5 LocalServer
Dr. Welf Löwe und Markus Noga
33
Reihenfolge der Anfragen
1.
2.
3.
4.
5.
Zur Aktivierung eines Fabrikprozesses zu einer CLSID
Ob im aktuellen Prozess bereits ein entsprechender
Fabrikprozess existiert
Ob ein anderer Prozess eine entsprechende Fabrik
installiert (und registriert) hat
Ob ein NT Service die Klasse implementiert
An lokale Server, ihre unterstützten Fabriken zu
registrieren. Server werden gestartet.
Dr. Welf Löwe und Markus Noga
34
COM nach DCOM
COM
DCOM
Standard für
Interoperabität zwischen
Adressräumen auf
einem Rechner
Standard für
Interoperabität zwischen
Rechnern
Lokale Transparenz
Fernaktivierung
Fernaufruf
Management für Nebenläufigkeit
Management für Sicherheit
Alles bereits im Design von COM vorbereitet
Dr. Welf Löwe und Markus Noga
35
Transparenz
Gleicher
Prozess
Gleiche
Maschine
Über
Rechnergrenze
Client
Component
Client Process
Client
Component
COM
Client Machine
Client
Server Process
COM
Server Machine
DCE
COM
RPC
Component
Dr. Welf Löwe und Markus Noga
36
DCOM Aufruf
Basiert auf DCE (RPC)
Objektorientierter RPC (ORPC)
– RPC + Dispatch
Plattformneutral, integriert in Windows
Machine A
Machine B
ORPC
Distributed COM
Distributed COM
COM
COM
DCE RPC
RPC
DCE RPC
Dr. Welf Löwe und Markus Noga
37
Distributed Computing Environment (DCE)
Distributed Applications
Time
Service
Cell /
Global
Directory
Service
Security
Service
Distributed
File
System
Diskless
Support
Remote Procedure Call
T hread Service
Local OS and Transportation Services
Dr. Welf Löwe und Markus Noga
38
Communikation in DCE
C lie nt
(Application
program)
virtual
Connection
S e rv e r
(Application
program)
RPC - Interface
Client
Stub
Runtime
Interface
Transport
Interface
Server
Stub
R P C R u n tim e
S e rv ic e s
R P C R u n tim e
S e rv ic e s
Remote Call
T ra n s p o rt
S e rv ic e s
Return
T ra n s p o rt
S e rv ic e s
Dr. Welf Löwe und Markus Noga
39
Kommt bekannt vor...
IDL-File
idl
Client Stub
Header File
Server Stub
#include
RPC
Runtime
Client Appl.
Link
Client
RPC
Runtime
Server Appl.
Link
Server
Dr. Welf Löwe und Markus Noga
40
Interface Definition
Microsoft Interface Definition Language (MIDL)
Erweiterung von DCE IDL
Erzeugung von nutzerdefinierten Schnittstellen
Nichts neues aber anders!
Dr. Welf Löwe und Markus Noga
41
Transparenz
Client
Process
Local Server Process
DLL
InProcess
Object
In-Process
Server
Client
App
EXE
Stub
lightweight
RPC
(local)
COM
Local
Server
Remote Server
Machine
Remote Server
Process
Local
Object
Proxy
Remote
Object
Proxy
COM
Local
Object
Stub
RPC RPC
(network)
COM
Remote
Object
Remote
Server
Dr. Welf Löwe und Markus Noga
42
Fernzugriff in DCOM
Client
1
SCM
7
1
SCM
3
3
COM Cache
...
Registry
2
4
5
6
InprocServer
NTService
LocalServer
RemoteServer
COM Cache
...
Registry
2
4
5
6
NTService
LocalServer
RemoteServer
DLLSurrogate
Dr. Welf Löwe und Markus Noga
43
Wie CORBA
Marshalling
– automatische Übermittlung von Daten in verteilten Systemen
– generiert aus IDL-Spezifikationen
Statischer und dynamischer, vermittelter Aufruf möglich
Objekte auf dem Server können sequentiell oder gefädelt realisiert sein
– ein Faden im Adressraum (Apartment, apartment model)
– vielfädiger Adressraum (free threading model)
Jedes Objekt unterstützt die Schnittstelle zur Reflektion IUnknown
Jedes Objekt trägt eindeutigen Identifikator OBJREF mit:
– OXID (Object Exporter Identifier), Bezeicher für Adressraum (Apartment)
– OID (Object Identifier), Objekt global im Netzwerk
– IPID (Interface Pointer Identifier), Interface in einem Adressraum
Persistenzdienste
Dr. Welf Löwe und Markus Noga
44
Persistente Objekte
Moniker (dt. Spitzname) kapseln Persistenz von Objekten
entsprechen CORBA-Objektadaptern (BOAs) auf
Serverseite
Wie Stellvertreterobjekte
– Einer pro Objekt
– Nicht einer pro Servicekomponente
Namensraum beliebig (meist URL)
können hierarchisch strukturiert sein
Dr. Welf Löwe und Markus Noga
45
Speziell in DCOM
GUID (Global Unique Identifier)
–
–
–
–
Eindeutiger Name für Klassen (CLSID) und Schnittstellen (IID)
vererbt aus DCEs UUIDs (universally unique identifiers)
BDA4A270-A1BA-11d0-8C2C-0080C73925BA
Durch IDL-Spezifkation der Komponente zur Schnittstelle bzw.
Klasse assoziiert
– CoCreateGuid() global eindeutige Name
Keinen zentralen Broker (ORB) sondern Proxies
Fassadenkomponenten
Komponentenkategorie
Dr. Welf Löwe und Markus Noga
46
Vermitteln in DCOM (broking)
Broker nicht explizit ansprechbar (kein ORB-Konzept)
– Statt dessen werden Stellvertreterobjekte, die das entfernte Objekt in der
eigenen Komponente vertreten (proxy-Objekte), angesprochen.
Standardfall: dynamischer Aufruf flüchtiger, nicht-persistenter Objekte
– Klasse finden und aktivieren, dann Objekte erzeugt
– Allokation von Objekten mit abstrakter Fabrik auf Server, die die Verteilung
verbirgt (Schnittstelle IClassFactory ist Objektfabrik)
– Stellvertreter in der eigenen Komponente vertreten (proxy-Muster).
– CORBA fasst der ORB alle Stellvertreterobjekte zusammen
– Ansprache der entfernten Objekte per OBJREF oder per Stellvertreter
– Entferntes, dynamisch aufgerufenes Objekt muss IDispatch erfüllen
(indirekte Aufrufschnittstelle invoke(method,args))
Statischer Aufruf möglich, wenn Stellvertreter und Objekt identisch
Dr. Welf Löwe und Markus Noga
47
Fassadenkomponenten
Zusammengesetzte Komponenten, die Fassadenobjekte
enthalten
– Mehrere Schnittstellen pro Komponente werden auf verschiedene
interne Objekte mithilfe eines Fassadenobjektes delegiert
– Mächtiger aber langsamer als Mehrfachvererbung, denn
• Mehrfachvererbung ersetzt Delegation durch zusammenhängendes
Speicherlayout eines Objektes
• Delegation und Aggregation: Indirektion aber keine Layout und
Namenskonflikte
Menge der unterstützten Schnittstellen ab Allokation fest
– Hängt von der Zusammensetzung der Komponente ab und muss
nicht statisch sichtbar sein, da ein Objekt rekursive angelegt wird.
– Fassadenkomponenten kann man nicht dynamisch um neue
Dienste erweitern
Dr. Welf Löwe und Markus Noga
48
Komponentenkategorien
Ersatz für Vererbung von Eigenschaftsschnittstellen
Eine Kategorie kann Eigenschaften / Merkmale ausdrücken
Klassen, die die gleiche Menge von Schnittstellen erfüllen
gehören zu einer Kategorie (Schlüssel CATID)
Verwaltet durch den Kategorie Manager
CLSID_StdComponentCategoriesMgr
Registrierung und Abmeldung von Kategorien in der
Registrierdatenbank
Dr. Welf Löwe und Markus Noga
49
Dienste in DCOM
Vorhandene Dienste: (services)
– Alle Microsoft-Werkzeuge sind als Dienste verfügbar (Spreadsheet,
Powerpoint, Datenbank, ODBC Datenbankverbindung, …), aber nicht
standardisiert!
– Referenzzählende Abfallsammlung
– Microsoft Transaction Server (MTS) ermöglicht flache und geschachtelte
Transaktionen
– Ereignisdienst (publisher/subscriber pattern):
•
•
•
•
•
Schnittstelle registrieren,
Bei Auslösung des Ereignisses wird sie aufgerufen (outgoing interface).
Schnittstelle durch connection point Objekt (IConnectionPoint) repräsentiert.
Publisher erfüllen IconnectionPointContainer und haben ein IconnectionPoint
Keine eigentständigen Ereignisobjekte.
Fehlende Dienste
– Makler
– Lizensierung
Dr. Welf Löwe und Markus Noga
50
Diskussion
Kein offizieller, kein offener, sondern proprietärer Standard
– Änderungen jederzeit möglich und schon öfters durchgeführt
Keine standardisierten Dienste, nur proprietäre
– DCOM ist ein hauptsächlich ein proprietärer Verdrahtungsstandard
Eingeschränkte Platformabhängikeit
– DCOM war stark auf C++ orientiert, obwohl es jetzt andere Brücken für
andere Sprachen gibt (VisualBasic, Microsoft Java). Man muss aber das
binäre Aufrufformat des Microsoft C++-Übersetzers erzeugen!
– DCOM war PC-gebunden,
– Software AG stellt DCOM-Portierungen auf Unix her - EntireX
http://www.softwareag.com/corporat/solutions/entirex/entirex.htm
Probleme mit der Sicherheit
– DCOM ist binärer Standard - Binärcodes (Viren)
– I love you virus: ein VDB script wird ausgeführt und wirft die
Mailerkomponente an, die lawinenartig Mails verschickt
Dr. Welf Löwe und Markus Noga
51
Wie die Zukunft aussehen wird
DCOM ist wegen der Marktdominanz von Microsoft nicht mehr aus dem
Komponentenmarkt wegzudenken.
Es gibt Brücken
–
–
–
–
von Corba nach DCOM,
von Java nach DCOM,
von Java nach Corba,
Nebeneinander der Ansätze möglich.
Java (EJB) - härtester DCOM-Konkurrent.
Prognose der Gartner Group (Information week 10/99):
– 75% aller Großunternehmen setzen bereits heute Java ein
– Microsoft wird es nicht gelingen, Java an den Rand zu drängen.
– Im Jahr 2002 wird Java die wichtigste Technologie für
Netzwerkapplikationen sein (bei mehr als 60% der Unternehmen)
– Geschwindigkeit von Java spielt in 95% aller Anwendungen keine Rolle
– JINI, die Java Technik für Netzdienste, wird 2003 de-facto Standard sein
Dr. Welf Löwe und Markus Noga
52