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? :stupid:

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:

Zitat von mjustin (Beitrag 1214387)

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:

Zitat von BUG (Beitrag 1214398)

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:

Zitat von mjustin (Beitrag 1214387)

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:

Zitat von Der schöne Günther (Beitrag 1214468)

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:

Zitat von Der schöne Günther (Beitrag 1214486)

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.

[Der schöne Günther]

RemObjects sieht jetzt auf den ersten Blick wirklich mächtig und gleichzeitig elegant aus. Gleichzeitig habe ich aber weiterhin das Gefühl, dass es ein ziemlicher Overkill ist.

Nach bisheriger Planung muss ein Plug-In nicht mehr leisten als

• Von einem anderen Prozess (dem Kern) seine Konfiguration empfangen (bsp. als XML)
• Einen Befehl "Fange an, zu arbeiten" entgegennehmen, ebenso "Fahre dich herunter"
• seine Oberfläche (bsp. VCL-Form) anzeigen, ebenso verstecken (bzw. Form zerstören)
• seine (durch den Benutzer über die Oberfläche veränderte) Config wieder zurückgeben

Bislang geregelt habe ich das über DLLs die in den Prozess (als separater Thread) eingeklinkt werden. Auf die Nachteile wenn hier etwas abstürzt (und ich bsp. serielle Ports nicht mehr freibekomme) müssen wir sicher nicht mehr reden. Deshalb war der Ansatz, es in gesonderte Prozesse zu packen.

Bislang möchte ich im Kern noch nicht einmal wissen, was in den Plug-Ins vor sich geht und wie sie funktionieren. Mit so einem simplen Weltbild bleibt allerdings eine brauchbare Visualisierung auf anderen Maschinen außen vor, oder?

Insgesamt stehe ich irgendwie vor dem Dilemma, mich im Kern nicht damit befassen zu wollen, was in einem Plug-In vor sich geht und was es kann, aber trotzdem die Möglichkeit behalten möchte, das Plug-In (oder die gesamte Anwendung) später einmal über einen Webbrowser oder eine native Anwendung auf einem anderen System zu steuern. Und das führt auch mittlerweile schon wieder etwas weg vom eigentlichen Thema, ob nun Sockets, Pipes oder Mega-Lösung wie RealThinClient, RemObjects oder sonstwas. :pale:

[Morphie]

Naja, eigentlich ist das doch der klassische Anwendungsfall von Pluginframeworks...

Du schreibst, dass du es vorher mit DLLs gemacht hast... Ich bin der Meinung, dass genau das der richtige Weg für dein Vorhaben ist.
Ein einheitliches Interface für die DLLs definieren und gut ist.
Wo genau sind denn deine Probleme hierbei?

Ich sehe das immer wieder, dass einige Softwarehersteller für jede kleine Funktion / Fenster eine eigene Anwendung (*.exe) schreiben und diese dann aus der Hauptanwendung aufrufen... Da kratze ich mir immer den Kopf... Oft heißt es dann, dass das historisch bedingt so entstanden ist...
Für eine Neuentwicklung halte ich das aber für den falschen weg.

[Der schöne Günther]

Zitat:

Zitat von Morphie (Beitrag 1214504)

Ich bin der Meinung, dass genau das der richtige Weg für dein Vorhaben ist.
Ein einheitliches Interface für die DLLs definieren und gut ist.

:-D

Genau so habe ich es jetzt auch in meinen ersten Delphi-Wochen bislang hingebogen. Die DLLs führen eigentlich auch nur genau die genannten Funktionen nach außen. Für Notfallzwecke gibt es weiterhin noch ein

Delphi-Quellcode:

get/setValue(propertyName:Str):Str

welches dann über RTTI in den von der DLL erstellten Objekten wühlt.

Toll, dass jemand das genauso sieht, dann bin ich wohl doch kein hoffnungsloser Fall :-)

Der gravierende Schwachpunkt ist allerdings, dass Windows Dinge wie Verbindungshandles und geöffnete Dateien pro Prozess verwaltet. In meinem Anwendungsfall ist die Anwendung dazu da, Hardware zu steuern. Hat sich ein Programmteil aufgehangen oder ist abgestürzt, kann ich den Speicher zwar wieder brauchbar freiräumen, bekomme aber meine Handles nicht wieder - Ich komme an die Ports nicht mehr dran. Der Kunde kann nicht wegen so etwas den gesamten Betrieb lahmlegen und das ganze Programm herunter- und wieder hochfahren. Daher der Wille zur Multi-Prozess-Architektur. Auch der Internet Explorer und Google Chrome halten das seit Neustem mit ihren Plug-Ins und Tabs ähnlich.


Nun gut, dann halt die Module als eigene Prozesse statt Libraries im selben Prozess. Unterhalte ich mich mit denen halt per x-beliebiger Methode. Eigentlich kein wirklicher Unterschied bis hierhin. 8-)

Nun wäre es allerdings auch zeitgemäß, auch auf anderen Geräten zu sehen (und steuern), was auf der eigentlichen Maschine vor sicht geht - Ohne Eselsbrücken wie TeamViewer ;-)

Jetzt habe ich doch schon mehrere Prozesse - Jetzt sollte ich auch dafür sorgen, dass die Prozesse sich gut fernsteuern lassen! Entweder spuckt mir das Modul nun einen Block (XML) an Dingen aus, die sich bei ihm einstellen lassen, ich bereite das anderswo auf wie ich lustig bin auf und schicke ihm einen XML-Block zurück (den es entweder annimmt, nur teilweise oder komplett zurückweist), oder das Modul bietet nur die interne Logik an ("stellt einen Service bereit"?) den ich dann mittels einer GUI auf der gleichen Maschine oder anderswo direkt darstellen kann (Präsentationsschicht).

Zusammenfassend scheinen fertig zu kaufende Lösungen wie eben RemObjects oder RealThinClient mir (in meinem konkreten Fall) die Arbeit abzunehmen, wie ich jetzt meine Präsentationsschicht mit der Anwendungsschicht verknüpfe?

Der einzige Grund warum ich damit vielleicht noch hadere, war dass ich bislang nur an reine VCL-Anwendungen auf einem Windows-System gedacht hatte, die Plug-Ins sich auch selbst um ihre VCL-Oberfläche gekümmert haben, und gut war. Wenn ich die Darstellung nun aus den Plug-Ins rausziehe, brauche ich für den lokalen Betrieb (95% der Fälle) nun den Kern, seine n Module und noch einmal n Präsentationsanwendungen. Und irgendwie wird mir das dann langsam etwas zu viel...


Vielen Dank für die Antworten bislang! :thumb: Ich versuche die Sache nicht zu sehr auszuschmücken um nicht zu viel Zeit zu stehlen.

[QuickAndDirty]

Ich weiß jetzt nicht ganz genau was die Anwendung leisten soll.
Wenn diese "Plug-Ins" jetzt nicht Steuereinheiten für Maschienen sind oder
Spezialisierte Simulatoren oder
andere leistungshungrigen "Echtzeit" Funktionen bieten,
dann würde ich zu einer SOA Struktur auf Basis von Webservies tendieren.
Da hast du alles was du brauchst. Lizensierung , verteilte Ausführung, Konfigurierbarkeit, Erweiterbarkeit ist alles schon abgedeckt.
Manche Administratoren wissen was das ist und wie man das am laufen hält.
Aber auch hier ist das drumherum für dich vermutlich zu viel?

Edit:...hab überlesen das du hardware steuern willst...also einfach ignorieren...

[Der schöne Günther]

Aber warum meinst du, dass es sich für den Hardware-Steuerfall nicht eignet?

Nichts hiervon ist auf einem modernen Computersystem wirklich rechenintensiv und sonderlich zeitkritisch ist eigentlich auch nichts.

[mjustin]

Zitat:

Zitat von Phoenix (Beitrag 1214469)

Zitat:

Zitat von mjustin (Beitrag 1214387)

Als Microsoft-spezifische Lösung nenne ich nur mal so MSMQ, Microsoft Message Queuing. ...

Messages überleben in der Queue nicht ewig

Das Timeout kann man nach Bedarf hochsetzen, solange ausreichend RAM vorhanden ist. Microsoft MSMQ ist vermutlich dann aus dem Rennen, wenn man den Server öfter mal neu booten muss, und keine Möglichkeit hat, die noch nicht zugestellten Messages zu persistieren - so wie es andere (RabbitMQ, WebSphere) können.

[Morphie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214510)

Der gravierende Schwachpunkt ist allerdings, dass Windows Dinge wie Verbindungshandles und geöffnete Dateien pro Prozess verwaltet. In meinem Anwendungsfall ist die Anwendung dazu da, Hardware zu steuern. Hat sich ein Programmteil aufgehangen oder ist abgestürzt, kann ich den Speicher zwar wieder brauchbar freiräumen, bekomme aber meine Handles nicht wieder - Ich komme an die Ports nicht mehr dran.

Aber ist das dann nicht ein allgemeines Problem der Ressourcenverwaltung / des Error-Handlings?

Wenn ich eine bestimmte Hardware per COM-Anschluss ansteuere und mein Programm dabei ein Fehler produziert, muss ich doch sicherstellen, dass der COM-Anschluss auch wieder freigegeben wird.

[Der schöne Günther]

Zitat:

Zitat von mjustin (Beitrag 1214520)

Microsoft MSMQ ist vermutlich dann aus dem Rennen, wenn man den Server öfter mal neu booten muss, und keine Möglichkeit hat, die noch nicht zugestellten Messages zu persistieren

. Der Kunde stellt die lustigsten Dinge mit den Maschinen an, einfach Strom ziehen ist nichts ungewöhnliches. Daher... :lol:

Zitat:

Zitat von Morphie (Beitrag 1214521)

Aber ist das dann nicht ein allgemeines Problem der Ressourcenverwaltung / des Error-Handlings?

Wenn ich eine bestimmte Hardware per COM-Anschluss ansteuere und mein Programm dabei ein Fehler produziert, muss ich doch sicherstellen, dass der COM-Anschluss auch wieder freigegeben wird.

In der Theorie, ja. Allerdings muss (und möchte) ich auch davon ausgehen, dass es immer irgendwo eine Fehlermöglichkeit gibt, die das ganze Teil aufhängt oder komplett abstürzen lässt. Die Aufteilung in eigene Prozesse hilft da ungemein da Windows hier alles wieder freigibt.

[mjustin]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214510)

Zusammenfassend scheinen fertig zu kaufende Lösungen wie eben RemObjects oder RealThinClient mir (in meinem konkreten Fall) die Arbeit abzunehmen, wie ich jetzt meine Präsentationsschicht mit der Anwendungsschicht verknüpfe?

Die fertig zu kaufenden Lösungen sind aber nicht für alle Architekturen optimal geeignet. RO und RTC sind eher Serveranwendugen, an die sich dann Clients (auch sehr viele Clients) wenden, wenn sie ein Anliegen haben - Request / Response und RPC Kommunikation.

Wenn aber alle Plugins als Clients implementiert werden, die sich an einen zentralen Server andocken sollen, wird dem Serverprozess die gesamte Koordination der Anfragen und das Weitergeben an andere Plugins übertragen. Dazu müssten auch Callbacks implementiert werden, so dass der Server aufgrund der Anfrage eines Plugins aktiv einem anderen Plugin Nachrichten senden kann.

Ich stelle mir als Lösung eher einen sehr schlanken Message Bus vor - eine einheitliche Infrastruktur die allen Plugins gleichberechtigt zur Verfügung steht. Dazu würde ich ein sehr kompaktes Protokoll wie MQTT einsetzen, das gerade für kleine Nachrichten und langsame Netze (schwache Hardware wie Arduino) ausgelegt ist. (http://mqtt.org/ und http://mqtt.org/faq)

Jedes Plugin benötigt dann nur eine sehr kompakte und komplett im Prozess integrierte Clientbibliothek, unabhängig von DLLs oder Services wie DCOM ist. Nur TCP wird benötigt, zum Beispiel über Synapse das auch sehr schlank ist.

Anwendungen, die die Daten der Plugins visualisieren wollen, lauschen dann entweder auf dem Message Bus und verarbeiten Daten die momentan darüber gesendet werden, oder senden Befehle über den Message Bus an ein Plugin, das daraufhin zum Beispiel Statusdaten an den Sender zurückschickt.

Auch eine Weboberfläche liesse sich damit problemlos anbinden, selbst wenn sie in einer anderen Sprache geschrieben ist, wenn für das Protokoll (z.B. MQTT) bereits entsprechende Clients existieren.

Der wesentliche Unterschied ist, dass es keine Server- und Clientprozesse gibt sondern jedes Plugin aktiv senden und passiv empfangen kann. Das kann man auch nutzen um eine Benutzeroberfläche fernzusteuern, zum Beispiel abhängig vom Status eines Plugins einen Menüpunkt zu aktivieren - das Plugin sendet eine Nachricht wie "Ich bin jetzt aktiviert!" über den Bus. Das GUI Programm lauscht auf entsprechende Statusnachrichten und schaltet die Menupunkte ein.

[sh17]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214527)

Der Kunde stellt die lustigsten Dinge mit den Maschinen an, einfach Strom ziehen ist nichts ungewöhnliches. Daher...

...ist das Handle wenigstens freigegeben.

[sh17]

und die Instanz vom Message Bus kann im Kern der Anwendung liegen? Oder lieber separat?

[mjustin]

Zitat:

Zitat von sh17 (Beitrag 1214535)

und die Instanz vom Message Bus kann im Kern der Anwendung liegen? Oder lieber separat?

Der Message Bus wird von einem eigenen Prozess bereitgestellt, damit ist er selbst in dem (allerdings unwahrscheinlichen Fall) erreichbar, dass der Anwendungskern komplett abgestürzt ist - und nur noch die Plugin-Prozesse laufen ;) und man kann ihn bei Bedarf auch auf eine eigene (virtuelle) Maschine legen, an der nicht herumgefummelt wird.

[Der schöne Günther]

Faszinierendes Kochrezept.

Für meinen Zweck hatte hätte ich bislang eigentlich bewusst eine Punkt-zu-Punkt-Verbindung zwischen Kern und den Modulen angestrebt. Und zwar da

1. die Module in ihrer Natür sehr autark sind. Was ein einem passiert beinflusst i.d.R. die Tätigkeiten des anderen in keinster Weise, oder nur sehr indirekt
2. ich bewusst verhindern möchte, dass man sich in einem Modul mit Aufgabenbereichen eines eigentlich anderen befasst.

Der Grund für den zweiten Punkt ist folgender: Baut der Kunde an seiner Installation etwas um, möchte ich ihm nur eine neue Konfiguration des Moduls (oder ein anderes) liefern. Wenn ich jetzt noch andere Module habe, die in gewisser Weise von anderen Plug-Ins "abhängig" sind, komme ich in Teufels Küche...


Ich bin begeistert, wie lange sich so ein komplexes Thema hält. :thumb:

[sh17]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214541)

Ich bin begeistert, wie lange sich so ein komplexes Thema hält. :thumb:

Na nur die machen doch Spaß, zumindest interessiert es mich auch.

[QuickAndDirty]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214516)

Aber warum meinst du, dass es sich für den Hardware-Steuerfall nicht eignet?

Nichts hiervon ist auf einem modernen Computersystem wirklich rechenintensiv und sonderlich zeitkritisch ist eigentlich auch nichts.

Einfach so intuitiv würde ich nichts zeitkritisches mit SOA machen.

So wie ich die letzten Posts verstehe würde dir ein gemeinsames Postfach zur Kommunikation reichen.

Vielleicht mit einem Broadcast das ein frühzeitiges Pollen auslöst.

ich glaube nicht das es sowas als middleware gibt...

[mjustin]

Zitat:

Zitat von QuickAndDirty (Beitrag 1214547)

ich glaube nicht das es sowas als middleware gibt...

Zumindest für MQTT sieht es gar nicht so schlecht aus. Die MQTT Home Page listet unter http://mqtt.org/software auch eine kostenlose und sehr kompakte IBM Implementierung namens "Really Small Message Broker" des aktuellen MQTT 3.1 Standards (der kürzlich zu einem offziellen OASIS Standard wurde), aber auch einige andere freie Implementierungen. Einen open source Delphi Client für MQTT habe ich bereits im Netz gesehen, er ist etwas älter und unterstützt die Basisfunktionen des Protokolls.

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

Zitat von Der schöne Günther (Beitrag 1214697)

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. :smile2:

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.

[sh17]

um zwischen 1,2 und 3 zu unterscheiden, würde ich auf jeden Fall den finanziellen/zeitlichen Anteil in Betracht ziehen. (Zumindest bei solch komplexen Sachen, jeden kleinen Mist kauf ich nicht zu, da tendiere ich auf jeden Fall zu selbst machen)

- Wie lange brauche ich, um es selbst zu implementieren - Zeit - Geld? Beispielsweise 2-3 Wochen?
- Was kostet das entsprechende Gegenstück und der gedachte Einarbeitungsaufwand? Beispielsweise um die 500 EUR Lizenz + 1 Woche.

Im Beispiel wäre ich jetzt schon für die kommerzielle Lösung, wenn ich pro Std von 100 EUR ausgehe.

Wenn das noch nicht reicht als Überzeugung:

- Kann ich die zugekaufte Lösung im Extremfall dann doch durch eine eigene Lösung relativ einfach ersetzen? D.h. drückt mit die kommerzielle Lösung kein Schema auf.

[Der schöne Günther]

Ja, ich werde mich in dieser Woche darüber besprechen. Im Endeffekt bin ich nicht derjenige, der über Zeit und Geld entscheidet. Zeitdruck herrscht (wie immer) auch, zumindest für eine grobe funktionierende Vorabversion.

Mittlerweile kann ich zum Thema überhaupt etwas sagen, ich bin sehr gespannt, wohin die Reise letztendlich gehen wird. Das Thema hat mir wirklich großartig weitergeholfen, noch einmal vielen Dank an alle!


PS: Gargano hier im Forum war vor ein paar Jahren wohl in genau der gleichen Situation wie ich...

[mjustin]

Zitat:

Zitat von Der schöne Günther (Beitrag 1214697)

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 :-D

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