Modularer (evtl. verteilter) Programmaufbau - Welche Art von IPC ist die richtige?

[Der schöne Günther]

Zitat von BUG:

Das ist vermutlich auch die Abstraktion, die du für dein Plugin-System anstreben willst.

Eigentlich schon. Sockets und Pipes sind im Endeffekt ja zunächst Datenaustauschverfahren zwischen Prozessen. Im Endeffekt will ich ja nicht wirklich Daten austauschen, ich möchte Methoden aufrufen. Vom Konzept her wäre RPC schon deutlich näher an dem, was ich eigentlich will.

Ich wühle mich weiterhin durch die wilde Welt der verschiedenen RPC-Modelle. Ehrlich gesagt ohne wirkliches Ziel.

Ich bin weiterhin unschlüssig: Kann man allgemein sagen, wie sehr man sich auf die ganze RPC-Geschichte überhaupt noch verlassen kann, wenn der Rechner mal beispielsweise einmal hart abstürzt und auf den letzten Wiederherstellungspuntk gesetzt wird? Oder der Kunde selbst (bzw. durch einen Drittanbieter) zusätzliche Software und Dienste auf der Maschine laufen lassen will (ohne das abzusprechen)?

[Phoenix]

Zitat von Der schöne Günther:

Ich bin weiterhin unschlüssig: Kann man allgemein sagen, wie sehr man sich auf die ganze RPC-Geschichte überhaupt noch verlassen kann, wenn der Rechner mal beispielsweise einmal hart abstürzt und auf den letzten Wiederherstellungspuntk gesetzt wird? Oder der Kunde selbst (bzw. durch einen Drittanbieter) zusätzliche Software und Dienste auf der Maschine laufen lassen will (ohne das abzusprechen)?

Der erste Fall ist in der Regel eher unproblematisch.
Der zweite kann zu einem Problem werden, wenn z.B ein vom Kunden installierter Dienst einen Port verwendet, der vom eigenen System verwendet werden soll, und dann auch noch früher hochfährt. Oder wenn die 'fremde' Software sehr Speicherintensiv ist und das System in Memory Pressure bringt, so daß die eigenen Dienste permanent geswapped werden. Oder oder oder...

[sh17]

Schau Dir mal RemObjects SDK an, falls Du nicht alles selbst machen möchtest. Da kannst Du zwischen den verschiedenen Transportschichten wechseln, falls es doch mal die Rechnergrenze verlässt. Quasi schon ein besseres RPC. Ich prinzip bin auch gerade an der gleichen Aufgabe wie Du. Eingebettete Prozesse und Kommunikation zwischen ihnen.

[Der schöne Günther]

Ja, das gab es auch schon: Kommunikation über Named Pipes, auf der Kundenmaschine lief allerdings noch Kontakt mit einem SQL Server, ebenfalls über Pipes. Windows hat dann die ältesten Pipes immer rausgekickt und nichts ging mehr

Bei RPC allgemein habe ich noch die Furcht, dass hier zu viel schiefgehen kann, wenn jemand am Rechner herumspielt - Einfach hinfahren und wieder gradebiegen ist keine Option

RemObjects sehe ich mir mal an - Hier im Forum schon hundert mal gehört, keine Ahnung, was es eigentlich ist...

[taveuni]

Zitat von Der schöne Günther:

RemObjects sehe ich mir mal an - Hier im Forum schon hundert mal gehört, keine Ahnung, was es eigentlich ist...

Dann wird es Zeit. Sehr komfortable Möglichkeit Methoden mit Strukturen via IPC zu benutzen. Und dies lokal, LAN, sowie Programmiersprachenübergreifend (und somit auch Plattformübergreifend).

[Der schöne Günther]

Ich kann leider nicht mehr tun, als mich durch Webseitenbeschreibungen und eventuell vorhandene Demo-Versionen zu wühlen. Gibt es so etwas wie ein Buch zu der ganzen RemObjects-Geschichte? Spontan hätte ich nämlich gesagt, dass es anscheinend eher um Services geht, die parallel von mehreren Clients angesprochen werden, das will ich ja nicht wirklich.

Außerdem binde ich mich damit dann auf ewig an RemObjects, oder? Würde ich nur mit Sockets/Pipes ein paar Daten hin- und herschaufeln, muss ich mir keine Sorgen machen, sollte ein Drittanbieter über Nacht dichtmachen...

[taveuni]

Ein "Service" ist mehr oder weniger ein Interface.
Da drin können Strukturen, Methoden usw. definiert werden.
Dan gibt es Channels welche als Client und Server benutzt werden können.
Diese wiederum gibt es als Named Pipes, Socket, Http und viele mehr.

Natürlich bindest Du Dich an Remobjects. Wir sind schon seit 7 Jahren dabei.
Die Sourcen sind dabei. Das wichtigste: Du implementierst die Programmlogik.
Das Framework kümmert sich um den Transport.

[sh17]

Ne, ein Buch gibt es nicht, auch Doku ist rar. Kann ich nur auf das Forum verweisen, oder auch hier in die DP.

Aber die Zeit, die Du sparst, ist enorm. Und wenn es doch mal nicht mehr klappt, weil RemObjects pleite geht (wobei da es ein Fallback gibt), Delphi in die falsche Richtung wandert oder die Erde untergeht, kannst Du es immer noch selbst programmieren. Der Schnittpunkt ist recht klein gehalten und damit einfacher austauschbar.

Und für IPC ist es geeignet.