DCOM: DLL lokal registrieren Warum?

[Kunig]

Hallo zusammen,

ich möchte eine Komponente auf einem anderen Rechner nutzen. Das ganze soll über DCOM realisiert werden.
Ich importiere also die benötigte DLL über "Typbibliothek importieren" in Delphi und lasse mir eine Wrapper-Unit erstellen. In dieser Unit sind alle Guid und sonstigen Informationen für die Arbeit mit der betreffenden Komponente hinterlegt.
Der fehlende Teil, auf welchem Rechner diese Komponente zu finden ist, wird über die Methode CreateRemote angegeben.

Warum muss diese Dll trotzdem lokal registriert werden, wobei alle Informationen doch in der Wrapper-Unit enthalten sind und die CoClass nicht einmal instantiert werden muss?

Geht dabei nicht der Sinn von DCOM verloren, nämlich diese leidige Aktualisierung unendlich vieler Anwendungen auf unendlich vielen Rechnern zu vermeiden?

Gruß
Paul

[Ralf Jansen]

Die entscheidende Info steht in der Registry und die musst du zum Client bringen. Dafür brauchst du aber nicht zwingend die Dll die Typbibliothek reicht zum registrieren vollkommen aus.
Die Details wie man die tlb registriert bringe ich leider nicht mehr zusammen. Beides (Delphi und DCOM) habe ich vor über einem Jahrzehnt als Tod definiert und seitdem nicht mehr benutzt. Die genannte Info stammt also nur aus der Erinnerung.
Ich weiß noch das man die tlb direkt aus einer Resource registrieren konnte. Ich habe also damals die tlb als Resource in meine Anwendung aufgenommen und direkt diese Anwendung zusammen mit der Nummer der Resource registriert.

[Kunig]

Hallo Ralf,

danke erst einmal, dass du dich meiner Frage angenommen hast. Insoweit hast du recht. Wenn es sich um InprocServer und Localserver handelt verstehe ich das Nachschauen in der Registry. Wenn ich aber auf einen Rechner remote zugreife fehlt mir die Logik. Warum sollte ich in der Registry den Standort eines RemoteServers festlegen? Dieser kann doch jederzeit umziehen. Von daher ist es doch besser, wenn ich durch eine Abfrage den Standort des Servers in mein Programm einfließen lasse. Zudem sind doch alle Informationen wie Konstanten, Schnittstellen, Eigenschaften und so weiter in der Wrapper-Unit enthalten. Somit bündele ich die Informationen nach dem Bauplan der Wrapper-Unit und schicke diese über CreateRemoteObject zum RemoteServer. Dort angekommen können die Informationen ausgewertet und das Ergebnis an den Client zurück gesendet werden. Eine Registrierung der Typbibliothek lokal auf dem Client ergibt für mich keinen Sinn. Auch sehe ich keinen Grund dafür, dass DCOM in der lokalen Registry eine Information sucht, die auf einem fremden Rechner liegt.

Warum sucht also DCOM beim Aufruf der Methode CreateRemoteObject nach Informationen auf dem Client?

Gruß
Paul

[Ralf Jansen]

Warum sollte ich in der Registry den Standort eines RemoteServers festlegen?

Das ist eine Option kein Zwang beim erzeugen des clientseitigen Stubs kannst du ja einen anderen Rechnernamen mitgeben wenn du die passenden Rechte hasst.
Ich spekuliere mal das es ursprünglich auch ein Rechte Ding war. Ein Admin legt in der Registry fest wohin sich ein normaler User hin verbinden darf. Das ist was anderes als wenn der User bzw. die Software frei entscheidet wohin er sich verbindet. Der Nutzer sollte vermutlich nicht mal wissen wohin er sich verbindet und ob das remote, lokal, inproc oder was auch immer ist. That's Admin Business.

Auch sehe ich keinen Grund dafür, dass DCOM in der lokalen Registry eine Information sucht, die auf einem fremden Rechner liegt.

In der Registry steht die Oberflächenbeschreibung der nutzbaren Schnittstelle. Die brauche ich lokal um zu wissen was man denn auf dem anderen Rechner über diese Schnittstelle machen kann. Es hilft nicht diese Info erst von diesem anderen Rechner irgendwie beziehen zu müssen. Möglicherweise fehlt mir dafür die Rechte und ich darf nur aufrufen was ich lokal kenne(Eine Untermenge der tatsächlichen Schnittstelle). Bedenke DCOM ist eine sprachneutrale uralte Schnittstelle. Es war bestimmt mal gedacht das sich die verwende Sprache direkt an die Registry wendet um irgendeinen Call auszuführen. Das Delphi so freundlich ist einen Wrapper zu erzeugen von dem man annehmen könnte das der doch selbstbeschreibend ist kann ich nachvollziehen. Sollte ich heute selbst einen RPC Mechanismus implementieren würde ich das sicher auch nicht so machen wie COM/DCOM aber damals war es halt so. Die Wurzeln von dem Zeug liegen in der Mitte der 90er. Vorbilder waren Sachen wie CORBA etc. und ein Teil der Nutzersprachen nicht objektorientiert. Vom damaligen Blickwinkel war es höchstwahrscheinlich sinnvoll es so zu machen wie es ist.

Böse ausgedrückt wenn ich mich mit historischen Techniken Beschäftige sollte ich auch den historischen Kontext berücksichtigen. Die IT Welt zu dem Zeitpunkt als die Technik entstand. Das jetzt ist da eher nicht hilfreich. Die meisten Dinge die ich in der Vergangenheit programmiert habe sehen aus heutiger Perspektive sinnlos aus da es heute passenderes gibt. Wäre ja auch traurig wenn sich die Dinge nicht weiterentwickeln würden.

[Kunig]

Hallo Ralf,

danke für deine Antwort. Ich gehe mal davon aus, dass du .Net nutzt. Gibt es noch andere Möglichkeiten für den Zugriff auf Ressourcen eines entfernten Rechners, außer DCOM und .Net?

Gruß
Paul

[Christian Marquardt]

Per Java und RMI

https://de.wikipedia.org/wiki/Remote_Method_Invocation

Sprachunabhängig -> Webservices

[Kunig]

Danke für die Info.

Gruß
Paul