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

Transkript

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

2 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 Noga 2

3 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 Noga 3

4 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

5 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

6 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

7 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

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

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

10 Komponentenmodell MyComponent (DLL or EXE) IUnknown IUnknown IViewer (COM Interface) CoViewer (COM Object) ILoveCom IHateCom CoPersonality IUnknown ISecure IPersist CoSecure Dr. Welf Löwe und Markus Noga 10

11 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

12 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

13 Schnittstelle und Implementierung Komponente kann mehreren Schnittstellen genügen Komponentenreferenz ist immer Referenz auf eine Schnittstelle IUnknown Client COM Object Dr. Welf Löwe und Markus Noga 13

14 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

15 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

16 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 -GUIDsfür Schnittstellen 0xc4910d2 COM Object 0xc4910d1 CLSIDs - GUIDs für COM Klassen Dr. Welf Löwe und Markus Noga 16

17 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 Noga 17

18 Eindeutige Identifikatoren Wie wird die Evolution von Software unterstützt IUnknown: QueryInterface Interfaces unveränderlich - Abfragen, Aufruf neuer Funktionen ohne Übersetzung - 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

19 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

20 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

21 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

22 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

23 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

24 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

25 Ergebnis der Anfrage HRESULT - 32-bit long Integer 1 bit 2 bits 13 bits 16 bits Severity Field For future use Facility Reason Erfolg Fehler Null Fehlerklasse Vordefiniert von COM Zentral herausgegeben Fehlerwert Frei programmierbar Fehlerverursacher Dr. Welf Löwe und Markus Noga 25

26 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

27 Zugriff einer Komponente Client Client Application (1) Anfrage mit CLSID (5) Aufruf Object Interface (4) Objekt Interface Zeiger an Klienten Server Object (3) Finde (Objekt-) Implementierung, Lade server code COM Bibliothek Registry CLSID Server Code (2) Nachschlagen in der Registry Dr. Welf Löwe und Markus Noga 27

28 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

29 Einträge Servertyp Pathname of server EXE (local, out-of-process) CLSID ABCD ABCDEF00000 Server Code LocalServer32 = C:\MyDir\MyServer.exe ABCD ABCDEF00012 InprocServer32 = C:\object\textrend.dll Pathname of server DLL (in-process) Dr. Welf Löwe und Markus Noga 29

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

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

32 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

33 Reihenfolge der Suche Client 1 3 SCM COM Cache Registry InprocServer LocalService LocalServer Dr. Welf Löwe und Markus Noga 33

34 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 Noga 34

35 COM nach DCOM COM Standard für Interoperabität zwischen Adressräumen auf einem Rechner DCOM 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

36 Transparenz Gleicher Prozess Client Component Gleiche Maschine Client Process Client COM Server Process Component Über Rechner- grenze Client Client Machine COM DCE RPC Server Machine COM Component Dr. Welf Löwe und Markus Noga 36

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

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

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

40 Kommt bekannt vor... IDL-File idl Client Stub Header File Server Stub RPC Runtime Client Appl. #include Server Appl. RPC Runtime Link Link Client Server Dr. Welf Löwe und Markus Noga 40

41 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

42 Transparenz Client Process Client App DLL In- Process Object In-Process Server Local Object Proxy Remote Object Proxy COM lightweight RPC (local) RPC RPC (network) Local Server Process Stub COM Stub COM EXE Local Object Local Server Remote Server Machine Remote Server Process Remote Object Remote Server Dr. Welf Löwe und Markus Noga 42

43 Fernzugriff in DCOM Client 1 SCM 7 1 SCM 3 3 COM Cache Registry InprocServer NTService LocalServer RemoteServer COM Cache Registry NTService LocalServer RemoteServer DLLSurrogate Dr. Welf Löwe und Markus Noga 43

44 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

45 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

46 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

47 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

48 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

49 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

50 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

51 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 Noga 51

52 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