dr. welf löwe und markus noga1 i.2.3. dcom distributed component object model

Dr. Welf Löwe und Markus Noga 1

I.2.3. DCOMDistributed Component Object Model


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.


DCOM-Entwicklung

DCE (distributed computing environment)

OLE (object linking and embedding) - ActiveX: OLE-Erweiterung

COM (component object model)

DCOM (distributed COM)

Grenzen fließend!


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.


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)


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


Ursprüngliche Trennung OLE und COM

COM ist Basiskomponentenarchitektur für aufgesetzte Dienste

Basis

OLEapplication

services


Wiederverwendete Technologie

Component Object Model (COM)

Object-Oriented

Model

Client/ServerModel

Dynamic Linking


(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


Komponentenmodell

MyComponent (DLL or EXE)

IUnknown

IViewer(COM Interface)

CoViewer(COM Object)

IUnknown

ISecure CoSecure

IPersist

IUnknown

ILoveComCoPersonality

IHateCom


Grundfunktionalität

Binärstandard für Aufrufe zwischen KomponentenGruppierung (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


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, ...)


Schnittstelle und Implementierung

Komponente kann mehreren Schnittstellen genügen

Komponentenreferenz ist immer Referenz auf eine Schnittstelle

COMCOMObjectObject

ClientClient

IUnknown


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


Beispiel

interface ILookup : public IUnknown{ public: virtual HRESULT __stdcall LookupByName (LPTSTR lpName,TCHAR **lplpNumber) = 0; virtual HRESULT __stdcall LookupByNumber (LPTSTR lpNumber, TCHAR **lplpName) = 0;};

COMCOMObjectObject

IUnknown

ILookup


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)

COMCOMObjectObject

0xc4910d1

0xc4910d2

CLSIDs - GUIDs für COM Klassen

IIDs - GUIDs für Schnittstellen


Identifikatoren

Automatisch generiert– uuidgen.exe Microsoft Programm– CoCreateGuid aus der COM API

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);


Eindeutige Identifikatoren

Wie wird die Evolution von Software unterstützt

Wie wird Interaktion von Komponenten unterstützt

IUnknown: QueryInterface - Abfragen, Aufruf neuer Funktionen ohne Übersetzung

Interfaces unveränderlich- Komponenten unterstützen alte Schnittstellen- Versionierung von Hand

Indirekte Funktionsaufrufe(doppelte Indirektion, vtables)

- Rückwärtskompatibilität

- Performance-Verlust bei Kommunikation mit einem COM Objekt im selben Prozess kann vernachlässigt werden


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


Interface IUnknown

Unterstützt von allen COM Objekten

Basisfunktionalität:

2 AddRef

1 QueryInterface

3 Release

Dynamically discover other interfaces supported by an object

Management of an object´s life cycle


IUnknown in MIDL

interface IUnknown {

virtual HRESULT QueryInterface (IID& iid, void** ppvObj) = 0;

virtual ULONG AddRef() = 0;

virtual ULONG Release() = 0;

}


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


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 implementierenAddRef:

Release:

reference counter = reference counter + 1

reference counter = reference counter - 1

if reference counter == 0: delete component object, release resources


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. }


Ergebnis der Anfrage

HRESULT - 32-bit long Integer

1 bit 2 bits 13 bits 16 bits

SeverityField

For futureuse

Facility Reason

ErfolgFehler

FehlerklasseVordefiniert von COMZentral herausgegeben

Fehlerverursacher

FehlerwertFrei programmierbar

Null


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


Zugriff einer Komponente

CLSID ServerCode

(1) Anfrage mitCLSID

COMBibliothek

ClientApplication

Object

ServerClient(5) Aufruf

(2) Nachschlagen in der Registry

(3) Finde (Objekt-) Implementierung,Lade server code

Registry

(4)Objekt InterfaceZeiger an Klienten

Object Interface


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


Einträge

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)

Pathname of server EXE(local, out-of-process)

Servertyp


Erzeugen des Objekts

(1) CoCreateInstance

SCM

ClientApplication

ServerClient

(7)

(2)

(3)

Registry

IClassFactory (5) Erzeuge Objekt

(4)

(6)

Fabrik

Object


Erzeugen der Fabrik

SCM

ClientApplication

Object

Client

(2)

(1) CoGetClassObject

IClassFactory

(4)

(6)

(5) CreateInstance

Server

(3)

Registry

(5‘) Erzeuge Objekt

Fabrik

Object


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()


Reihenfolge der Suche

Client SCM

COM Cache...

Registry

InprocServerLocalServiceLocalServer

1

245

3


Reihenfolge der Anfragen

1. Zur Aktivierung eines Fabrikprozesses zu einer CLSID

2. Ob im aktuellen Prozess bereits ein entsprechender Fabrikprozess existiert

3. Ob ein anderer Prozess eine entsprechende Fabrik installiert (und registriert) hat

4. Ob ein NT Service die Klasse implementiert

5. An lokale Server, ihre unterstützten Fabriken zu registrieren. Server werden gestartet.


COM nach DCOM

Lokale TransparenzFernaktivierungFernaufrufManagement für NebenläufigkeitManagement für SicherheitAlles bereits im Design von COM vorbereitet

COM DCOM

Standard fürInteroperabität zwischen

Adressräumen aufeinem Rechner

Standard fürInteroperabität zwischen

Rechnern


Transparenz

ClientClient ComponentComponent

ClientClient ComponentComponentCOMCOM

Client ProcessClient Process Server ProcessServer Process

COMCOMDCERPC

ClientClient

Server MachineServer MachineClient MachineClient Machine

COMCOM ComponentComponent

Gleicher Gleicher ProzessProzess

ÜberÜberRechner-Rechner-grenzegrenze

GleicheGleicheMaschineMaschine


DCOM Aufruf

Basiert auf DCE (RPC)

Objektorientierter RPC (ORPC) – RPC + Dispatch

Plattformneutral, integriert in Windows

COMDistributed COM

DCE RPC

Machine A

COMDistributed COM

DCE RPC

Machine B

ORPC

RPC


Distributed Computing Environment (DCE)

Thread Service

Remote Procedure Call

TimeService

DisklessSupport

Distri-butedFileSystem

Cell /Global Directory Service

SecurityService

Distributed Applications

Local OS and Transportation Services


Communikation in DCE

C lie nt S erver

R P C R u n tim e S erv ices

T ran s portS erv ices

R P C R u n tim e S erv ices

T ran s portS erv ices

RPC - Interface

Transport Interface

Runtime Interface

virtual Connection (Application

program)(Application

program)

Remote Call

Return

ClientStub

ServerStub


Kommt bekannt vor...

ID L -F ile

idl

L ink

C lient Server

R P C R untim e

R P C R untim eC lient A ppl. S erver A ppl.

#include

L ink

S erver S tubH eader F ileC lient S tub


Interface Definition

Microsoft Interface Definition Language (MIDL)

Erweiterung von DCE IDL

Erzeugung von nutzerdefinierten Schnittstellen

Nichts neues aber anders!


Transparenz

Client Client ProcessProcess

COMCOM

COMCOMIn-ProcessIn-ProcessServerServer

ClientClientAppApp

LocalLocalObjectObjectProxyProxy

RemoteRemoteObjectObjectProxyProxy

In-In-ProcessProcessObjectObject StubStub

LocalLocalObjectObject

Local Local ServerServer

Local Server ProcessLocal Server Process

COMCOM

StubStubRemoteRemoteObjectObject

Remote Remote ServerServer

Remote Server Remote Server ProcessProcess

Remote Server Remote Server MachineMachine

lightweightRPC

(local)

DLL

EXE

(network)RPC RPC


Fernzugriff in DCOM

Client SCM

COM Cache...

Registry

InprocServerNTServiceLocalServerRemoteServer

1

2456

3

SCM

COM Cache...

Registry

NTServiceLocalServerRemoteServerDLLSurrogate

1

2456

3

7


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 IUnknownJedes 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


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


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


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


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


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


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


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




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 noga1 i.2.3. dcom distributed component object model

Documents