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

[Der schöne Günther]

Langsam muss ich auch zu einem Ergebnis kommen...

Nachdem für mich für ein RAD Studio Geld in Höhe des Staatsetats von Timbuktu lockergemacht werden musste, will ich nicht gleich noch neue Lösungen wie RealThinClient oder RemObjects kaufen müssen

1. die ich nicht wirklich verstanden habe
2. damit nicht umgehen kann und Zeit verbrate mich groß in etwas einzuarbeiten
3. dass wir in vollem Umfang garantiert nichtmal ansatzweise brauchen

Leichtgewichtige Sachen wie XML-RPC für Delphi sind anscheinend wirklich tot (siehe auch hier im Forum). Ich könnte mich jetzt noch wochenlang durch x-beliebige Middlewares wühlen.

Ich gebe hiermit mehr oder weniger auf: Wahrscheinlich wird es damit enden, sich wieder selbst etwas zusammenzubasteln (wild Pesudo-XML-Zeichenketten über Sockets hin-und herwerfen)um in zwei Jahren zu merken, dass es doch etwas gegeben hätte, was eigentlich genau gepasst hätte (Was ist eigentlich diese DataSnap-Geschichte?) und konform zu irgendeinem tollen Standard gewesen wäre. Ich habe schlichtweg nicht den geringsten Überblick was da draußen alles vor sich hingeistert.

Insgesamt vielleicht etwas traurig - Egal wo ich hinschaue, alles scheint darum zu gehen, eine potentiell riesige Lemming-Horde an Clients versorgen zu können und toll Daten persistieren zu können. Persistente Datenhaltung spielt bei mir nur eine sehr kleine Rolle und Server und Client befinden sich in 95% der Fälle auf einer Maschine.

[sh17]

Also die angesprochene XML-RPC-Sache mit Delphi hatte ich mal im Einsatz, war sehr einfach und stabil, hat eben gemacht was es sollte. Wenn Du das auf dein Delphi gebogen bekommst, sollte alles machbar sein.

[Der schöne Günther]

Es gruselt mich hier nur etwas davor, überall noch Copyright 2003 zu lesen. Die von alphaflight83 freundlicherweise zur Verfügung gestellte Anpassung an Unicode und ähnliches kann ich auf die Schnelle bei mir kompilieren, habe es aber noch nicht wirklich getestet.

Im Endeffekt ist es ja eigentlich ziemlich genau, was mir vorschwebt. Es ist nur so ... alt ... und einsam.

[sh17]

das ist doch das hier? http://sourceforge.net/projects/delphixml-rpc/
da gibts auch nen Branch-Zweig im Quelltext.

Was soll sich an XML-RPC auch ändern, außer die Lauffähigkeit unter Delphi höherer Versionen. Geht ja alles.

[Der schöne Günther]

Ja, ändern muss sich daran eigentlich schon lange nichts mehr.

Nur entweder hat mein Gehirn in den letzten Jahren stark abgebaut, oder SourceForge wird auch nicht übersichtlicher. Ich finde nur irgendeinen "Branch 3.0" aus 2009, der nichts weiter als eine Kopie der 2003er-Version ist.

Die hier im Forum gepostete Aktualisierung auf Unicode bekomme ich wenigstens zum Laufen.


Ich fürchte mich nur davor, dass ich darüber sonst nicht viel finde, außer ein paar noch halb funktionierende Webseiten von vor zehn Jahren. Habe ich so ein exotisches Anwendungsszenario? Was macht die Welt sonst? Riesige Middleware lizensieren und gut ist?

[sh17]

Zitat von Der schöne Günther:

Ich fürchte mich nur davor, dass ich darüber sonst nicht viel finde, außer ein paar noch halb funktionierende Webseiten von vor zehn Jahren. Habe ich so ein exotisches Anwendungsszenario? Was macht die Welt sonst? Riesige Middleware lizensieren und gut ist?

Kann ich verstehen, dann müsstest Du Dich aber auch vor dem selbst programmieren fürchten, weil Du evtl zuviel Zeit benötigst und sich vielleicht Probleme auftun, die Du jetzt noch nicht erkennst.

Wovor hast Du mehr Angst:

1 etwas altes anpassen, das es für dich reicht und funktioniert
2 etwas komplett neues bauen, das es für dich reicht und funktioniert
3 etwas neues für Kohle erwerben, was den neuesten Hype implementiert, eigentlich eine Kanone auf deinen Spatz ist, aber es funktioniert.

wie sagt man: "gehen muss es"

Ich würde 1. nehmen, wenns nicht klappt, 3.

[Der schöne Günther]

Das führt es mir noch einmal richtig deutlich vor Augen, danke dafür!

Meine persönliche Präferenzen sehen (und sahen) nämlich anders aus: 2-3-1. Ich bin bislang eigentlich immer besser damit gefahren, selbst etwas aus dem Boden zu stampfen und keine Zeit über 20 Minuten darauf zu verschwenden, mir überhaupt einen Überblick über das zu verschaffen, was schon geht. So bin ich halt.

Fallen später Erweiterungen an, weiß ich genau, wie mein Kram funktioniert und setze es um. Gerade bei (1) wird mir hier unwohl - Ich kenne den Untergrund nicht wirklich und es gibt keine Community mehr. Bei (3) hat man bei einem modernen Produkt eine Wahrscheinlichkeit, dass das ein gewünschtes Anwendungszenario sowieso schon enthalten oder berücksichtigt ist und man kann sich mit anderen Leuten darüber austauschen.

[mjustin]

Zitat von Der schöne Günther:

Habe ich so ein exotisches Anwendungsszenario? Was macht die Welt sonst? Riesige Middleware lizensieren und gut ist?

Vermutlich wird die Welt für kleinere EInsatzgebiete etwas wie MsgConnect einsetzen:

* MsgConnect is a cross-platform protocol-independent communication framework designed to simplify the task of building peer-to-peer and client-server applications and middleware components. (wenn man sich die Wunschliste unter "Most wanted Features" ansieht fehlen aber einige Features eines modernen Message Brokers).

Ich entwickle zwar auch selbst kommerzielle Messaging Middleware Clients für Delphi, aber die damit einzusetzenden Server benötigen Java oder Erlang als Runtime, was möglicherweise nicht gewünscht wird.

[Der schöne Günther]

Hallo-

Ich habe mich jetzt noch einmal besprochen und es wird in meinem Fall nicht auf ein (großes) Middleware-Framework hinauslaufen - Es ist (und wird wohl auch nie) ein "echtes" verteiltes System werden: Einfache Datenvisualisierung auf irgendeinem anderen PC wäre vielleicht ganz nett, aber nichts was momentan wirklich interessiert. Im Endeffekt bleibt es immer bei einer zentralen Maschine im Schaltschrank die ab und an mal bedient wird und selbstständig Reports und Messwerte weiterschickt oder in Kunden-Datenbanken abspeichert.

Insgesamt werden also deutlich kleinere Brötchen gebacken, es wird wohl eine stinknormale Windows-IPC-Methode (wie Sockets oder Named Pipes) mit einer im Endeffekt beliebigen Formatierung (wenn ich genug Zeit habe, versuche ich irgendeinen Standard wie XML-RPC einzuhalten). Der Grund ist auch, dass man in diesem Umfeld niemanden beeindrucken kann, eine voll serviceorientierte Architektur bereitzuhalten - Hier ist so viel Paranoia im Spiel, da erreicht man damit eher das Gegenteil

Weiterhin werden auf alle Ewigkeit wohl sowohl Kern als auch alle Module von den gleichen Leuten implementiert und betreut werden. Deshalb ist es halb so wild.


Insgesamt ein tolles und für mich ungewohntes Thema, ich habe in den letzten Tagen viel gelernt
und produktiv nichts geschafft