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

[Der schöne Günther]

Ich hatte vom Thema bereits ein paar mal ein paar bestimmte Ecken angeschnitten. Nun das große Ganze:

Es geht um eine grundlegende Neuentwicklung einer Software die bereits seit Anfang des Jahrtausends im Einsatz ist. Die Anwendung könnte man noch als Standardsoftware interpretieren.

Es soll nun eine klare Trennung eines Kerns und einer halbwegs klaren Anzahl von Modulen geben. Diese Module arbeiten an sich sehr autark und sollen als "Plug-In" in den Kern geschraubt werden - Je nach Kunden kommen mal mehr, mal weniger Plug-Ins zum Einsatz, mit unterschiedlicher Konfiguration. Spezialwünsche des Kunden sollen nicht mehr in einzelnen abgeschotteten Entwicklungszweigen münden sondern entweder generell ins Programm einfließen oder als neues Modul realisiert werden. Daher wage ich das ganze Projekt immer noch als Standardsoftware zu sehen. Das nur am Rande.

Ich bin mir mittlerweile sehr sicher darin, jedes Modul als eigenen Prozess realisieren zu wollen. Jetzt stellt sich, ganz allgemein, die Frage welche Art der Interprozesskommunikation die richtige ist. Die wichtigsten Eckdaten hierzu sind:

• Ausschließlich Windows-Systeme
• Gesamte Anwendung läuft generell lokal auf einer Maschine. Allerdings ist nun gewünscht, die Module auch im LAN, evtl. WAN ansprechen zu können. Das wird allerdings sicher nicht oft der Fall sein.
• Es werden keine "großen" Datenmengen zwischen Kern und Plug-In ausgetauscht - Ein großer Datendurchsatz ist also nicht gefordert

Meines Wissens nach bleiben zwei IPC-Methoden mit besonders günstigen Eigenschaften übrig: Es sind Named Pipes und natürlich Sockets.

Auch in der engeren Auswahl - allerdings noch mit Unsicherheit - habe ich DCOM und RPC. Wenn ich DCOM richtig verstanden habe, ist es im Endeffekt RPC, nur mit zusätzlichen Benutzerrechten/Sicherheitsgeschichten obendrauf?


Ich würde gerne einmal zu allen vier hier niederschreiben, was ich davon halte: Wo ich denke, dass es haken könnte und wo es eine gute Wahl ist. Ich möchte den Text hier allerdings nicht noch weiter aufblähen, das liest eh keiner mehr, oder?

Kurzum: Kann mir jemand sagen,

• ob es sich lohnt, sich über DCOM schlau zu machen falls man diese vier Buchstaben erst vor ein paar Tagen zum ersten mal in dieser Reihenfolge gesehen hat?
• ich mit Named Pipes oder Sockets auf dem richtigen Weg bin oder RPC (oder etwas anderes) ein besserer Weg sein könnte?

Vielen Dank im Voraus, ich bin gespannt.

[mjustin]

Sockets wären in Hinblick auf LAN/WAN Unterstützung mein Favorit, und sind lokal ausreichend schnell (bis zu mehreren 100.000 Nachrichten pro Sekunde). RPC ist erst mal nur ein Kommunikationsmodel (Remote Procedure Calls sind Request/Response Kommunikation).

Als Microsoft-spezifische Lösung nenne ich nur mal so MSMQ, Microsoft Message Queuing. Damit können Prozesse Nachrichten austauschen, was sogar "transaktional" geht (d.h. wenn eine Reihe von Nachrichten empfangen wurde und der Empfänger kein "Acknowledge" sendet, sondern abstürzt, erhält er die Nachrichten nach dem Neustart noch einmal). http://msdn.microsoft.com/en-us/library/ms978430.aspx

[BUG]

Zitat von mjustin:

RPC ist erst mal nur ein Kommunikationsmodel (Remote Procedure Calls sind Request/Response Kommunikation).

Streng ausgelegt bedeutet RPC, das sich verteilte Aufrufe wie lokale Prozeduraufrufe verhalten.
Das ist vermutlich auch die Abstraktion, die du für dein Plugin-System anstreben willst.

Woran du denken solltest: Kommunikation über Pipes/Sockets erfordert, dass du dir selbst selbst Gedanken über
Nachrichtenformate, mögliche Verklemmungen, usw. machen musst. Das bekommst du bei DCOM (oder anderen verteilten Objektmodellen) geschenkt.

Ein gutes RPC-System kann man nicht mal so eben aus ein paar Sockets/Pipes basteln.
Ob dich das interessiert, hängt aber auch davon ab, wie kompliziert die kompliziert die Zusammenarbeit deiner Komponenten/Plugins ist.

[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 mjustin:

Als Microsoft-spezifische Lösung nenne ich nur mal so MSMQ, Microsoft Message Queuing. Damit können Prozesse Nachrichten austauschen, was sogar "transaktional" geht (d.h. wenn eine Reihe von Nachrichten empfangen wurde und der Empfänger kein "Acknowledge" sendet, sondern abstürzt, erhält er die Nachrichten nach dem Neustart noch einmal). http://msdn.microsoft.com/en-us/library/ms978430.aspx

Das ist aber mit Vorsicht zu genießen. Messages überleben in der Queue nicht ewig, und wenn sich in der MessageQueue nachrichten Aufstauen, und der Abnehmer sie nicht schnell genug verarbeitet (default liegt bei 10 Sekunden), kann es gut wird es passieren das einzelne Messages austimen und verschwinden.

[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...