Dr. Welf Löwe und Markus Noga1 I.2.3. DCOM Distributed Component Object Model

Dr. Welf Löwe und Markus Noga2 Literatur Es scheint keine guten COM Bücher zu geben. Don Box. Essential COM. Addison-Wesley 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: Technischer Überblick. Recht knapp und gut. Empfohlen zur Prüfungsvorbereitung.

Dr. Welf Löwe und Markus Noga3 DCOM-Entwicklung DCE (distributed computing environment) OLE (object linking and embedding) - ActiveX: OLE- Erweiterung COM (component object model) DCOM (distributed COM) Grenzen fließend!

Dr. Welf Löwe und Markus Noga4 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 Noga5 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 Noga6 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 Noga7 Ursprüngliche Trennung OLE und COM COM ist Basiskomponentenarchitektur für aufgesetzte Dienste Basis OLE application services

Dr. Welf Löwe und Markus Noga8 Wiederverwendete Technologie Component Object Model (COM) Object- Oriented Model Client/Server Model Dynamic Linking

Dr. Welf Löwe und Markus Noga9 (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 Noga10 Komponentenmodell MyComponent (DLL or EXE) IUnknown IViewer (COM Interface) CoViewer (COM Object) IUnknown ISecure CoSecure IPersist IUnknown ILoveCom CoPersonality IHateCom

Dr. Welf Löwe und Markus Noga11 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 Noga12 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 Noga13 Schnittstelle und Implementierung Komponente kann mehreren Schnittstellen genügen Komponentenreferenz ist immer Referenz auf eine Schnittstelle COMObject Client IUnknown

Dr. Welf Löwe und Markus Noga14 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 Noga15 Beispiel interface ILookup : public IUnknown { public: virtual HRESULT __stdcall LookupByName (LPTSTR lpName,TCHAR **lplpNumber) = 0; virtual HRESULT __stdcall LookupByNumber (LPTSTR lpNumber, TCHAR **lplpName) = 0; }; COMObject IUnknown ILookup

Dr. Welf Löwe und Markus Noga16 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) COMObject 0xc4910d1 0xc4910d2 CLSIDs - GUIDs für COM Klassen IIDs - GUIDs für Schnittstellen

Dr. Welf Löwe und Markus Noga17 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);

Dr. Welf Löwe und Markus Noga18 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

Dr. Welf Löwe und Markus Noga19 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 Noga20 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

Dr. Welf Löwe und Markus Noga21 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 Noga22 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 Noga23 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: Release: reference counter = reference counter + 1 reference counter = reference counter - 1 if reference counter == 0: delete component object, release resources

Dr. Welf Löwe und Markus Noga24 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 Noga25 Ergebnis der Anfrage HRESULT - 32-bit long Integer 1 bit2 bits 13 bits16 bits Severity Field For future use FacilityReason Erfolg Fehler Fehlerklasse Vordefiniert von COM Zentral herausgegeben Fehlerverursacher Fehlerwert Frei programmierbar Null

Dr. Welf Löwe und Markus Noga26 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 Noga27 Zugriff einer Komponente CLSIDServer Code (1) Anfrage mit CLSID COM Bibliothek Client Application Object ServerClient (5)Aufruf (2) Nachschlagen in der Registry (3)Finde (Objekt-) Implementierung, Lade server code Registry (4) Objekt Interface Zeiger an Klienten Object Interface

Dr. Welf Löwe und Markus Noga28 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 Noga29 Einträge CLSID Server Code ABCD ABCDEF00000 LocalServer32 = C:\MyDir\MyServer.exe ABCD ABCDEF00012 InprocServer32 = C:\object\textrend.dll Pathname of server DLL (in-process) Pathname of server EXE (local, out-of-process) Servertyp

Dr. Welf Löwe und Markus Noga30 Erzeugen des Objekts (1) CoCreateInstance SCM Client Application ServerClient (7) (2) (3) Registry IClassFactory (5) Erzeuge Objekt (4) (6) Fabrik Object

Dr. Welf Löwe und Markus Noga31 Erzeugen der Fabrik SCM Client Application Object Client (2) (1) CoGetClassObject IClassFactory (4) (6) (5) CreateInstance Server (3) Registry (5) Erzeuge Objekt Fabrik Object

Dr. Welf Löwe und Markus Noga32 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 Noga33 Reihenfolge der Suche ClientSCM COM Cache... Registry InprocServer LocalService LocalServer

Dr. Welf Löwe und Markus Noga34 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.

Dr. Welf Löwe und Markus Noga35 COM nach DCOM Lokale Transparenz Fernaktivierung Fernaufruf Management für Nebenläufigkeit Management für Sicherheit Alles bereits im Design von COM vorbereitet COMDCOM Standard für Interoperabität zwischen Adressräumen auf einem Rechner Standard für Interoperabität zwischen Rechnern

Dr. Welf Löwe und Markus Noga36 TransparenzClient Component Client Component COM Client Process Server Process COM DCE RPC Client Server Machine Client Machine COM Component GleicherProzess ÜberRechner-grenze GleicheMaschine

Dr. Welf Löwe und Markus Noga37 DCOM Aufruf Basiert auf DCE (RPC) Objektorientierter RPC (ORPC) –RPC + Dispatch Plattformneutral, integriert in Windows COM Distributed COM DCE RPC Machine A COM Distributed COM DCE RPC Machine B ORPC RPC

Dr. Welf Löwe und Markus Noga38 Distributed Computing Environment (DCE) Thread Service Remote Procedure Call Time Service Diskless Support Distri- buted File System Cell / Global Directory Service Security Service Distributed Applications Local OS and Transportation Services

Dr. Welf Löwe und Markus Noga39 Communikation in DCE ClientServer RPC Runtime Services Transport Services RPC Runtime Services Transport Services RPC - Interface Transport Interface Runtime Interface virtual Connection (Application program) (Application program) Remote Call Return Client Stub Server Stub

Dr. Welf Löwe und Markus Noga40 Kommt bekannt vor...

Dr. Welf Löwe und Markus Noga41 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 Noga42 TransparenzClientProcess COM COM In-ProcessServer ClientApp LocalObjectProxy RemoteObjectProxy In-ProcessObject Stub LocalObject LocalServer Local Server Process COM Stub RemoteObject RemoteServer Remote Server Process Remote Server Machine lightweight RPC (local) DLL EXE (network) RPC

Dr. Welf Löwe und Markus Noga43 Fernzugriff in DCOM ClientSCM COM Cache... Registry InprocServer NTService LocalServer RemoteServer SCM COM Cache... Registry NTService LocalServer RemoteServer DLLSurrogate

Dr. Welf Löwe und Markus Noga44 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 Noga45 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 Noga46 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 Noga47 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 Noga48 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 Noga49 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 Noga50 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 Noga51 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 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 Noga52 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