Die Community zu .NET und Classic VB.
Menü

COM als Middleware - Seite 12

 von 

2.7 Microsoft Transaction Server und COM+
Nächste Seite >>
2.5 Proxies und Stub als Stellvertreter
<< Vorherige Seite

2.6 DCOM  

Microsofts DCOM löst die OLE-Remote Automation ab und ist prinzipiell äquivalent zur CORBA-Architektur der OMG. DCOM ermöglicht die für den Entwickler ortstransparente Kommunikation zwischen in einem Netzwerk verteilten Komponenten bei garantierter Zustellung und Einhaltung der Datenreihenfolge. Hierbei stellt DCOM selbst kein Protokoll dar, sondern okkupiert mittels Datenmanipulation das RPC, welches wiederum eine Auswahl verschiedener Protokolltypen wie beispielsweise das verbindungsorientierte TCP/IP nutzt. Die Reihenfolge der zu verwendenden Protokolle während des Verbindungsaufbaus zu einem Remote ist wählbar. Vorzugsweise findet unter NT bei einer unspezifizierten Angabe das nicht verbindungsorientierte UDP/IP Anwendung. UDP benötigt weniger Ressourcen und produziert keinen Overhead für den Verbindungserhalt. Ein von DCOM verwendetes Protokoll lässt sich auf einzelne Ports oder ganze Portbereiche konfigurieren.

Die Größe von RPC-Paketen richtetet sich an der typischen Paketgröße des verwendeten Protokolls aus und liegt meist bei 1024 Byte. Ein entfernter Funktionsaufruf via DCOM benötigt rund 200 Byte zuzüglich der Funktionsparameter. Aus Performancegründen ist dies während der Entwicklung von Komponenten insbesondere bei der Übergabe größerer Datenstrukturen zu berücksichtigen. RPC-Pakete erhalten über einen OXID [Object Exporter Identifier] eine eindeutige Nennung und können daher mittels des auf jedem DCOM-Rechner mitinstallierten OXID-Resolvers in korrekter Reihenfolge wieder lokal zugestellt werden. Weiterhin sendet der Resolverdienst in konstanten Intervallen Pings über einen separaten Kanal an benachbarte Netzteilnehmer und gibt bei Ausfall referenzierter Komponenten über einen verteilten Garbage Collector den betroffenen Speicher wieder frei. Der Resolver optimiert seine Pings, d. h. für die lokale Kontrolle von fünf Referenzen zu Komponenten eines entfernten Rechners erfüllt ein einzelner Ping diese Aufgabe. Nach drei erfolglosen Pings kappt DCOM die Objekt-Verbindung und dekrementiert den Referenzzähler der betroffenen Komponente. Der Client erhält über diesen Vorgang keine Benachrichtigung, sondern lediglich in Folge einen Proxyfehler und muss durch ein erneutes Referenzieren der Komponente die Verbindung abermals aufbauen. Bricht hingegen das Netzwerk zusammen und startet innerhalb eines Timeouts erneut, ist DCOM in der Lage die verlorenen Referenzen zu regenerieren, so dass der Ausfall vom Client unbemerkt bleibt. DCOM optimiert Netzwerkwege, d. h. erfolgt auf Rechner 1, die Instanzierung einer Komponente auf Rechner 3 über Rechner 2 und sind Rechner 1 und Rechner 3 direkt verbunden, so leitet DCOM die Instanzierungsanforderung direkt unter Umgehung von Rechner 2 an Rechner 3.

Eine DCOM-Adaption ist auf Unix-Plattformen und IBM-Server-Produkte realisierbar. Visual Basic lässt das Entwickeln von DCOM-Komponenten nur in der Enterprise-Version zu.

2.6.1 Fehlerbehandlung

Die Methoden einer COM-Komponente sollten nach erfolgtem Aufruf vereinbarungsgemäß einen 32-Bit Fehlercode vom Typ HRESULT an den Client zurückgeben. Dieser Wert gliedert sich durch eine definierte Aufteilung in die drei Bereiche Severity, Facility und Status. Das höchste Bit Severity bezeichnet hierbei lediglich den fehlerfreien oder fehlerbehafteten Verlauf des Vorgangs. Über den 13-Bit breiten Facility-Code lässt sich die Gruppenzugehörigkeit des Fehlers erschließen. Vordefinierte Attribute sind hier Interface- Dispatch- Speicher- oder RPC-Fehler etc.. Die abschließenden 16 Bit repräsentieren den eigentlichen Fehlercode.

Die Rückgabe von Statusmeldungen über Funktionsargumente ist nicht zulässig, sondern darf nur über HRESULT erfolgen. Zudem schreibt COM verpflichtend vor, dass das HRESULT einer Methode einen leicht auszuwertenden Index darstellt und beispielsweise keine komplexen Zeigertechniken beinhaltet. Weiterhin gilt es konzeptionell zu beachten, dass speziell OutProc-Server die Abhandlung einer Ausnahme selbst verarbeiten und nicht etwa an einen autonomen Client durchreichen. Serverseitig auftretende Fehler lassen sich dem Client komfortabel über das Standardinterface IErrorInfo mitteilen. Neben einer Fehlernummer und einer textuellen Beschreibung können auch begleitende Informationen wie der Dateipfad einer Hilfedatei sowie ein Kontextindex zur Auswertung übermittelt werden.

2.6.2 Sicherheit

Im Zuge der Gewährleistung von Datenintegrität und -authentizität bietet DCOM dem Entwickler speziell auf NT-Systemen ein umfangreiches Sicherheitsmodell an. Elementares Bindeglied stellt hier die Verwendung von expliziten Sicherheitspaketen während des prozessübergreifenden Datentransports dar. Beginnend mit NT4 garantierte ursprünglich lediglich NTLM [New Technologie LAN Manager] eine geschützte Zustellung via RPC für einen entfernten Methodenaufruf. Mit Einführung von Windows 2000 erweiterte sich die Auswahl der verfügbaren Sicherheitspakete auf KERBEROS, Snego und SecureChannel.

Die eigentliche Berechtigung zur Erstellung von Objekten, deren Export sowie der Zugriff auf ihre Methoden regelt sich durch Anlegen spezifischer Konten in der Benutzerverwaltung. Entwicklerseitig erfolgt die Festlegung bzw. die Manipulation der Mindestberechtigung anhand des sogenannten Tokens. Die Erstellung eines Token vollzieht das System während der Prozessinitialisierung. Es beschreibt im wesentlichen die Gruppenzugehörigkeiten und die Zugriffsberechtigungen sowie den SID [Security Identification Descriptor] des Anwenders. Fehlen beispielsweise einem Benutzer die notwendigen Startrechte, unterbindet Windows via SCM [Service Control Manager] den Vorgang. Die Kontrolle des Zugriffs auf Objekte und Methoden hingegen regeln die COM-Laufzeitbibliotheken selbst.

Die Serverrechte können bzw. müssen einerseits mittels des Dienstprogrammes DCOMCNFG.EXE geändert oder andererseits zur Laufzeit vom Server selbst arrangiert werden. Clients bleiben für DCOMCNFG.EXE transparent, es sei denn sie stellen selbst eine Komponente also einen Server dar. Eine programmgesteuerte Sicherheit lässt sich durch die Implementierung der Schnittstellen IClientSecurity und IServerSecurity erzielen bzw. alternativ via Aufruf der API-Funktion CoInitializeSecurity erreichen. Jeder Client verfügt über einen Proxy und damit über die Schnittstelle IClientSecurity, respektive jeder Server beinhaltet einen Stub und implementiert somit IServerSecurity. Die explizite Verwendung der softwareseitigen Sicherheit anhand dieser Mechanismen macht die Konfiguration einer Standardsicherheit durch DCOMCNFG.EXE obsolet. Im Zusammenhang mit der Standardsicherheit gilt es zu erwähnen, dass DCOM-Komponenten in der DCOMCNFG.EXE durch die Aktivierung des CIS [COM-Internetdienstes] im Register Standard Eigenschaften und Verwendung des IIS [Internet Information Server] HTTP-fähig werden. CIS bietet für externe Clients auf Port 80 die notwendige TCP-Unterstützung und erspart ein zusätzliches Konfigurieren eines Routers.

2.6.3 Registry

Wichtiges Bindeglied der Komponenteninteraktion ist die zentrale Systemregistratur. Sie beinhaltet die notwendigen Informationen zu einer COM-Klasse und ermöglicht sowohl dem Betriebssystem, als auch dem Anwender spezifische Daten zu erfahren:


Abbildung 14: Komponenten in der Systemregistrierung

Die Instanzierung eines Servers erfolgt wahlweise über seine GUID [H, C] bzw. AppID [A, I] oder seine ProgID [B, O] [s.a. Kapitel 3.3.5]. Mittelpunkt der Komponenteninformation bildet die CLSID [H] des Servers. Hier ist neben der Serverart und Dateipfad [J] auch dessen Remotename [K], seine Netzwerkadresse [N] sowie das verwendete Protokoll für den RPC-Transfer [P] vermerkt. Der Schlüssel InprocServer32 [M] beinhaltet den Dateipfad zu einem InProc-Server [dll] bzw. den Proxy autprx32.dll der veralteten Remoteautomation zu einem OutProc-Server. Der CLSID-Schlüssel [H] ist der Verweis auf eine optional vorhandene Typenbibliothek [Q -> Y] sowie deren Versionsnummer [R -> Z]. Zu dem direkten Dateipfad [1] der Typenbibliothek lässt sich im TypLib-Schlüssel auch der Link auf eine Hilfedatei [2] verankern. In Implemented Categories [L] ist die CatID [s.a. Kapitel 3.3.5] der Komponente abgelegt. Öffentliche Schnittstellen erhalten ihre Registrierung im Schlüssel Interface anhand ihrer IID [S]. Im wesentlichen erfolgt dort identisch zur übergeordneten Komponente die Referenzierung einer Typenbibliothek [V -> Y, X -> Z] und auf die entsprechenden Proxy-Stub-Komponenten. Hier verkörpert durch das Proxy-Stub OLE Automation Interface für ein Typenbibliotheksmarshaling [T & U -> D] [s.a. Kapitel ... ]. Es gilt zwischen der 16- und 32-Bit [E, F] Variante sowie den erlaubten Apartments [G] [s.a. Kapitel 2.5.2] zu unterscheiden.

Unter den beiliegenden Beispielen ist der Quelltext für eine Registry-Klasse sowie der eines Tools zur Komponentenregistrierung enthalten [Samples\Registry\RegistryClass, Samples\Registry\RegBrowser]

Nächste Seite >>
2.7 Microsoft Transaction Server und COM+
<< Vorherige Seite
2.5 Proxies und Stub als Stellvertreter