Client/Server Architektur realisieren - Ideen

[Dejan Vu]

Zitat:

Zitat von DJ-SPM (Beitrag 1283011)

Manchmal muss es sein, dass 500+ Einträge aus der DB geladen werden. Jeder Eintrag ist ein Objekt - sagen wir mal, ein Adressen-Objekt. Diese Liste nun in einen json-String zu konvertieren dürfte ziemlich aufwendig / unperformant sein, oder?

Wir leben im Zeitalter von GHZ-Prozessoren mit mehreren Kernen und 39+GB RAM (oder von mir aus auch nur 4 GB).

500.000.000 Objekte sind ein Problem, aber doch keine 500. Das macht mein Telefon sogar schon in <0.1ms (leicht übertrieben ausgedrückt).

Die Überlegungen sind grundsätzlich richtig (Ich hatte ähnliche bei meinem ersten N-Tier Projekt, wo ich dachte, XML würde alle Grenzen sprengen), daher mein Tipp:

Mach einfach Messungen. Prüfe, ab welchem Bereich Du meinst, Performanceprobleme zu bekommen. Versuche dann, diese Probleme zu bewerten: Sind diese im Betrieb derzeit erreichbar? Oder in absehbarer Zeit? Welche Maßnahmen kannst Du ergreifen (z.B. die Objekte zu cachen)? etc.

[Sir Rufo]

Egal ob Chat oder irgendwelche sonstigen Benachrichtigungen, dafür eine extra Service-Anwendung zu bauen und die Komplexität zu erhöhen halte ich für unklug.

Die REST-API weiß, ob eine bestimmte Aktion eine Benachrichtigung erfordert. Wenn, dann trägt diese das in die entsprechenden MessageQueues ein. Diese MessageQueues werden vom Client selber überwacht/abgefragt (Long Polling).

Ob diese Benachrichtigung nun eine Chat-Nachricht oder eine Änderung an dem Datensatz X betrifft spielt doch keine Geige. Das muss der Nachrichteninhalt hergeben.

Was du mit dem Änderungszeitpunkt anfangen möchtest ist mir auch noch nicht klar.

In einem System (speziell einem asynchronen) sollte jede Änderung (Nachricht vom Client an die API) den Zeitpunkt des Auftretens (ocurred) beinhalten. Die API fügt dann noch den Zeitstempel ein, wann das empfangen wurde (received) und trägt die Information ein.

(Muss ich erwähnen, dass die Zeitbasis immer UTC-bezogen sein sollte?)

Jetzt kommen wir zum eigentlichen Kern:

Gibt es in der API schon einen Eintrag, mit einem jüngeren ocurred, dann hat sich der Datensatz nicht verändert - die Historie hat sich sehr wohl verändert - und zieht somit keine weitere Aktionen der anderen Clients nach sich, es sei denn, die schauen sich die Historie an.

[Mavarik]

Zitat:

Zitat von DeddyH (Beitrag 1282946)

Vorsicht vor Optimierungen

OMG..

Zitat:

Zitat von clean-code-developer.de

Optimierungen kosten immer viel Aufwand. Wer Vorsicht walten lässt, spart oft wertvolle Ressourcen für das, was dem Kunden wirklich nützt.

Ich habe schon lange nicht mehr so einen Blödsinn gelesen.

Aber Egal... Lassen wir das Thema - rege ich mich nur auf.

Zum Thema.

Wie hatte ich schon oben geschrieben..."Absender, Kommando, SeekNr, DatenbankID sind bei mir 7 Byte... "
Dann hänge noch die Nutzer Daten daran.. Aber bitte als Byte/Record/Stream, jag das Ganze durch einen Echtzeit Stream-Kompressor ala Telefon/Codec fertig.
Wenn du viele Datensätze hast kann Du auch einen Hardcore Kompressor nehmen. Die schnellere Übertragung macht die Zeit für das komprimieren wieder wett.

5000 Datensätze (Adresserecord) à 1024 Byte dann ggf. komprimieren mit i.d.R. Faktor 3:1 oder kleiner sind rund 1600 KB. Das macht nur Schwupti und ist da.

Ein Update auf diese 5000 Datensätz (z.b. Datum der letzten Rechnung oder was auch immer) - nicht 5000 Datensätz komplett Übertragung sondern:
ID, Feldname, Value... und schon habe ich das Datenvolumen von REST (wahrscheinlich 8k pro Datensatz) auf 30 Byte runtergebrochen...
Und da soll nochmal jemand sagen "Optimierungen kosten immer viel Aufwand." :stupid:

Mavarik

[Dejan Vu]

Optimierung kosten Zeit. Programmierzeit. Wenn Du genügend davon hast, wunderbar. Andere müssen damit rechnen, haushalten etc. Bei professionellen amateurhaften Softwareentwicklern spielt die Resource 'Zeit' nun mal eine Rolle.

Und wenn ich dem Kunden sage: "Dein Tool verschickt nur noch 5kb anstatt vorher 15kb, kostet aber dafür einen Tagessatz mehr", dann schaut dieser mich etwas verdutzt an, knallt mir die Spec ins Gesicht, dreht sich um und sagt: "Das wars dann wohl". Wenn er freundlich ist.

In der professionellen amateurhaften Softwareentwicklung macht man genau das, was der Kunde will. Wer noch eins draufsetzt, macht es gut. Wer noch eins draufsetzt, macht es nachhaltig.

Steht in der Spec: Bitte Bandbreite optimieren, wird das gemacht. Steht es dort nicht, wird es nicht gemacht. Steht dort: Muss bei einer 100kbit-Leitung in 10 Sekunden durchrauschen, wird es gemacht. Steht dort nichts, schaut man sich um, was so usus ist ("allgemeiner Stand der Technik" oder fragt nach) und setzt dann ggf. nach Rücksprache um.

Wo ist da ein OMG, oder 'selten so einen Blödsinn gelesen'?

Edit: Noch ein kleines...

Zitat:

Zitat von Donald E. Knuth, 1974

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1283112)

Optimierung kosten Zeit.

Ich will Dir nicht schon wieder ein OMG schreiben... denn im Prinzip hast Du recht! Mein Standpunkt ist ein anderer.

Ich sage: Optimierung kostet keine Zeit wenn man beim programmieren einfach mal den Kopf zusammen hält.

Ein "Beginupdate, EndUpdate" einer Liste bringt einen enormen Geschwindigkeitszuwachs und kostet keine Zeit.
Und stört auch nicht bei debuggen...
oder stört die Lesbarkeit des Codes...

Mavarik

[mkinzler]

Ich meine mal, das diese Optimierungen hier nicht gemeint sind.

[Dejan Vu]

Zitat:

Zitat von Mavarik (Beitrag 1283200)

Ich sage: Optimierung kostet keine Zeit wenn man beim programmieren einfach mal den Kopf zusammen hält.

Ein sehr schönes Thema für einen eigenen Thread.

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1283205)

Zitat:

Zitat von Mavarik (Beitrag 1283200)

Ich sage: Optimierung kostet keine Zeit wenn man beim programmieren einfach mal den Kopf zusammen hält.

Ein sehr schönes Thema für einen eigenen Thread.

Stimmt.. Hat hier nix zu suchen

[TheMiller]

Guten Morgen!

Nachdem ich den Thread nochmal komplett gelesen und mir über das Wochenende viele Gedanken gemacht habe, möchte ich nochmal zusammenfassen und konkrete Umsetzungsvorschläge anbringen:

* Auf dem Datenbank-Server wird eine REST-API eingerichtet. (Diese habe ich zum Glück schon aus einem anderen Projekt fertig). Die API deshalb, weil wir tatsächlich planen, noch andere Plattformen zu bedienen und die Wartung ist viel einfacher (Queries nur auf einer Plattform aktualisieren/erstellen). Long-Polling kann umgesetzt werden.

* Auf dem Windows-Server wird ein Server-Dienst laufen. Dieser dient auch als Zwischenschicht zwischen Clients und Datenbank-Server. Die Verbindung wird über TCP-Server/TCP-Client von Indy realisiert. Der Server-Dienst nimmt requests entgegen und verarbeitet sie. Diese Requests sind vom Typ TRecord und haben mindestens folgende Felder: Absender, Empfänger, Timestamp, request_id, request_str (json_string). So sollte eine exakte Zuordnung und Verarbeitung der Nachricht möglich sein (genauer ist das noch nicht durchdacht). Je nachdem, was der TRequest dem Server aufträgt, führt er die Aktion durch (Aktion mit anderen Clients oder Anfrage an die DB). Danach sendet er an den ursprünglichen Absender oder einen "Broadcast" TResponse zurück.

* Der Server-Dienst prüft die Erreichbarkeit des Datenbank-Server (vllt. Ping, oder über eine UniDAC-Methode (weiß ich noch nicht)). Ist er mal nicht erreichbar, sendet er einen "Broadcast" (eher eine TCP-Nachricht an alle Clients), dass der Server weg ist. Diese zeigen es dann in der GUI an. Vllt. empfängt der Dienst Datenbank-Anfragen, die er zurückhalt, bis die Verbindung wieder aktiv ist. Weitere Aufgaben der Windows-Dienstes sind zeitgesteuerte kleinere Backups (kein Image o.ä.)/Aufräumarbeiten, Benachrichtigungssysteme etc.

* Benachrichtigungssysteme:
- User A und B haben Modul-1 offen. User B ändert Daten über Modul-1. Nun sendet der Dienst eine TCP-Nachricht an alle User, die Modul-1 offen haben, damit sie aktuelle Daten laden können. Bzw, der Server lädt einmal die aktuellen Daten und sendet sie schon an den User.
- Ein wichtiges Modul ist gerade nicht geöffnet. Es wurden aber von B wichtige Daten für A hinterlegt. So wird User A vom Server benachrichtigt, dass wichtige Daten vorliegen.

* Optimierungen: Da z.T. auch über außenstellen gearbeitet wird, ist VPN sehr wichtig (sensible Daten und einfachere Kommunikation). Die Daten sollen also klein gehalten werden. Ein Zwischending zwischen den hier genannten Vorschlägen wird einzuhalten sein. Wenn man gut plant, mitdenkt und den rest durch ausprobieren ermittelt, dann wird es kein Thema sein.

Soweit bin ich erstmal. Hab nur eine Frage zum Format der TCP-Anfragen. Wie soll ein Kommando an den Server aussehen? Es wird ja vermutlich ein String sein. Soll er wie Parameter in URLs aussehen (module=abc&action=getImportantData&dataId=123), soll er in URL-Form sein (/ABC/getImportantData/123), oder soll es ein Record sein TParams (Modul: abc, Action: xyz...). Was macht da Sinn? Man müsste immer mit Explode etc. arbeiten. Habt ihr dazu noch weitere Vorschläge?

Vielen Dank für die rege Anteilnahme!

[Mavarik]

Zitat:

Zitat von DJ-SPM (Beitrag 1283417)

Wie soll ein Kommando an den Server aussehen?

Immer ein Record nehmen... Da hast Du alle Felder getrennt und musst nicht extra wieder einen String analysieren.

Mavarik

[Sir Rufo]

Wenn die REST-API LongPolling kann wofür in Gottes Namen dieser Windows-Dienst?

Mehr Komplexität?

Und der Service soll auch noch direkt mit dem Datenbank-Server sprechen, also an der REST-API (Zwischenschicht) vorbei?

Respekt, so kann man viele Vorteile der Zwischenschicht auch gleich wieder mit dem Hintern einreissen :thumb:

Ich hätte ja noch verstanden, wenn man, aus welchen Gründen auch immer, den Windows-Service per LongPolling mit der Zwischenschicht verbindet. Aber so ist das ein tolles Beispiel, wie man so etwas nicht machen sollte.

[TheMiller]

Ja sorry, du hast natürlich recht. Da habe ich mich vertran. Der Service soll auch nicht direkt mit der Datenbank sprechen. Die Kommuniaktion geht nur über die API. Aber irgendwie muss ich es realisieren, dass der Service prüft (ping o.ä.), ob die Datenbank erreichbar ist. Mehr soll der Service nicht mit der DB direkt machen. Das könnte man ja auch über einen API-Aufruf prüfen - da fällt der Ping weg, der ohnehin nichts darüber aussagt, ob die DB funktioniert/erreichbar ist.

[Sir Rufo]

Zitat:

Zitat von DJ-SPM (Beitrag 1283441)

Ja sorry, du hast natürlich recht. Da habe ich mich vertran. Der Service soll auch nicht direkt mit der Datenbank sprechen. Die Kommuniaktion geht nur über die API. Aber irgendwie muss ich es realisieren, dass der Service prüft (ping o.ä.), ob die Datenbank erreichbar ist. Mehr soll der Service nicht mit der DB direkt machen. Das könnte man ja auch über einen API-Aufruf prüfen - da fällt der Ping weg, der ohnehin nichts darüber aussagt, ob die DB funktioniert/erreichbar ist.

Hört sich ja schon besser an, allerdings ist das Benachrichtigungs-System wie du das skizzierst hast etwas ... seltsam.

Wenn du die Nachrichten jetzt pro Modul sendest, dann zieht ja jedes neues Modul eine Änderung in der Nachrichten-Struktur mit sich. Da wäre es doch besser, einfach Nachrichten zu schicken, wenn sich die Daten geändert haben. Das Modul selber bekommt dann diese Information mit, und entscheiden ob es damit etwas zu tun hat oder nicht. Hat es, dann lädt es die betroffenen Daten neu, wenn ich, dann eben einfach nicht.

Erweiterst du jetzt die Module, dann brauchst du das in der Benachrichtigung nicht zu berücksichtigen, denn die Module bekommen das schon mitgeteilt.

Zudem würde ich diese Benachrichtigungen sowieso an die Zugriffs-Interfaces verteilen, wo ich dann jeder den es interessiert registrieren kann.

Delphi-Quellcode:

TDataChangedEventArgs = class( TEventArgs )
  property Action : TDataAction read FAction; // Added, Changed, Removed
  property DataId : TDataId read FDataId;
end;

TDataChangeEventHandler = reference to procedure( const Sender : TObject; e : TDataChangedEventArgs );

IMyRepository = interface
  procedure Get( DataId : TDataId; out Data : TData );
  property DataChanged : IEvent<TDataChangedEventArgs>;
end;

An den

Delphi-Quellcode:

DataChanged

Event kann sich jeder dranhängen, der das wissen muss und entsprechend reagieren. Das Repository kümmert sich um den Empfang der Nachricht und verteilt diese. Schon können auch neu erstellte Module einfach so auf diese Nachrichten reagieren.

[Sir Rufo]

Kleine Anmerkung:

Bevor ich mir einen Service schreiben würde, der per TCP mit den Clients kommuniziert, benutze ich lieber die Microsoft MessageQueue und der Drops ist gelutscht. Jeder Client bekommt eine Queue und für Rückmeldungen auch der Service.

Der Service spricht jetzt mit der REST-API und füllt die MessageQueues der Clients. Die Clients holen sich die Informationen aus Ihrer MessageQueue ab.

Das ist schneller implementiert und vor allem robuster als das mit dem TCP-Client/Server.

[Mavarik]

Zitat:

Zitat von Sir Rufo;1283452Bevor ich mir einen Service schreiben würde, der per TCP mit den Clients kommuniziert, benutze ich lieber die [URL="http://technet.microsoft.com/de-de/library/cc771474.aspx"

Microsoft MessageQueue[/URL] und der Drops ist gelutscht.

Ist aber dann - wie ich meine - zu stark an Windows gebunden (ok ein Service auch) aber per TCP kann man auf anderen Plattformen entweder die Routinen dabei linken oder in eine externe App auslagern. Ohne die Kommunikation zu ändern.

Mavarik

[sh17]

Zitat:

Zitat von Sir Rufo (Beitrag 1283452)

Kleine Anmerkung:

Bevor ich mir einen Service schreiben würde, der per TCP mit den Clients kommuniziert, benutze ich lieber die Microsoft MessageQueue und der Drops ist gelutscht. Jeder Client bekommt eine Queue und für Rückmeldungen auch der Service.

Der Service spricht jetzt mit der REST-API und füllt die MessageQueues der Clients. Die Clients holen sich die Informationen aus Ihrer MessageQueue ab.

Das ist schneller implementiert und vor allem robuster als das mit dem TCP-Client/Server.

Vielleicht auch ein Blick Wert: https://www.habarisoft.com/index.html

[Sir Rufo]

Zitat:

Zitat von Mavarik (Beitrag 1283456)

Zitat:

Zitat von Sir Rufo;1283452Bevor ich mir einen Service schreiben würde, der per TCP mit den Clients kommuniziert, benutze ich lieber die [URL="http://technet.microsoft.com/de-de/library/cc771474.aspx"

Microsoft MessageQueue[/URL] und der Drops ist gelutscht.

Ist aber dann - wie ich meine - zu stark an Windows gebunden (ok ein Service auch) aber per TCP kann man auf anderen Plattformen entweder die Routinen dabei linken oder in eine externe App auslagern. Ohne die Kommunikation zu ändern.

Mavarik

Natürlich, weil die Mobile Devices immer eine ganz hervorragende Netzwerkverbindung haben. Sehr stabil und immer verfügbar. Und wir machen uns zusätzlich noch einen Port auf damit die darüber auch mit dem Windows-Service sprechen können. :roll:

Mobile Devices dürfen bei mir nur über HTTP(S) kommunizieren. Z.B. mit der REST-API. Wenn die eine Instant-Benachrichtigung benötigen, dann benutzte ich die Push-Dienste (dafür sind die wohl auch gedacht, gelle) und die werden von der REST-API dann auch gleich benachrichtigt/gefüttert.

Also wofür wird der Windows-Dienst jetzt nochmal benötigt? ;)

[TheMiller]

Zitat:

Zitat von Sir Rufo (Beitrag 1283469)

Also wofür wird der Windows-Dienst jetzt nochmal benötigt? ;)

So wie ich das verstanden habe, stellt doch der Windows-Dienst die Zwischenschicht zwischen Client und Datenbank-Server dar. Der Cleint sendet die Anfrage an die Zwischenschicht, diese leitet sie an den Datenbank-Server weiter.

Darüber hinaus wollte ich doch noch Datensicherung, Chats, Userverwaltung (Online/Offline-User nebst gültiger IP/VPN-IP), Nachrichtengrabber (enorm wichtig für das Projekt), Update-Service, etc.pp. darüber laufen lassen. Oder nicht?

[Sir Rufo]

Und so wie ich das verstanden habe, willst du eine REST-API vor den Datenspeicher setzen.

Oder wo und was macht die da?

Egal ob Update, Chat, was auch immer, es geht im Grunde immer um Daten holen und Daten speichern. Kann so eine REST-API auf jeden Fall.

[TheMiller]

Genau, die REST-API liegt auf dem Apache-Web-Server auf der Linux-Maschine. Dort liegt auch die MySQL-Datenbank. Auf dem Windows-Server - so dachte ich - ist der Windows-Server-Dienst meines Programmes installiert, der für die Clients mit der API kommuniziert und die Anfragen/Antworten hin und her sendet.

[Sir Rufo]

Zitat:

Zitat von DJ-SPM (Beitrag 1283497)

Genau, die REST-API liegt auf dem Apache-Web-Server auf der Linux-Maschine. Dort liegt auch die MySQL-Datenbank. Auf dem Windows-Server - so dachte ich - ist der Windows-Server-Dienst meines Programmes installiert, der für die Clients mit der API kommuniziert und die Anfragen/Antworten hin und her sendet.

Ja, kann man machen, erhöht zwar etwas die Komplexität, aber sei es drum.

Eine MessageQueue für den Service und pro Client eine Queue.

Der Service überwacht die eigene Queue und nimmt die Nachrichten und schickt diese an die API. Das was zurückkommt gibt er wieder in die Queue vom Client. Meldet die API, dass eine Änderung erfolgt ist, dann wird auch eine Nachricht in alle anderen Client-Queues geschrieben.

Der Service kann dadurch niemals durch einen nicht antwortenden Client ausgebremst werden. Die Clients sprechen nur mit den 2 Queues (Service, Eigene). Das ist recht einfach umzusetzen.

Eine Chat-Nachricht geht über die Service-Queue an der Service, der verteilt die Nachricht an die passenden Queues (oder erst zur API und dann erst wieder an die Client-Queues). Auf jeden Fall muss hier nicht das Rad neu erfunden werden und die Kommunikationswege sind inkl. der Protokolle ausgelatschte Trampelpfade und keine labile Hängebrücke über einer Schlucht.

[TheMiller]

Moin!

Zitat:

Zitat von Sir Rufo (Beitrag 1283499)

Das ist recht einfach umzusetzen.

Hm ja mag sein. Für mich noch sehr verwirrend, da ich - wie gesagt - noch nie mit MessageQueues gearbeitet habe. Hört sich aber gut an. Das heißt aber, dass ich ohnehin einen Windows-Service brauche? Nur halt eben nicht mit TCP-Client/Server, richtig?

Das wäre mir auch am liebsten, wenn ich einen solchen Dienst hätte. Aber ich wüsste nicht, wie es ohne gehen sollte. Du hast ja geschrieben, dass man es "zwar so machen kann", es aber die Komplexität erhöht. Also denkst du wohl an eine andere Lösung. Könntest du sie mir nochmal vorschlagen, ich habe sie wohl nicht mehr im Kopf.

[Sir Rufo]

Ja, der Dienst bleibt, allerdings ist die Kommunikation etwas anders.
Statt

Code:

[REST] <-> [SERVICE] <-> [TCP (Protokoll?) ] <-> [CLIENTS]

einfach

Code:

[REST] <-> [SERVICE] <-> [MSMQ] <-> [CLIENTS]

Wobei das zwischen Service und Clients dann so aussieht

Code:

[SERVICE] <-+-- [MSMQ:SERVICE] <-+
            +-> [MSMQ:CLIENT1] --+-> [CLIENT1]
            +-> [MSMQ:CLIENT2] --+-> [CLIENT2]
            :                     :
            +-> [MSMQ:CLIENTn] --+-> [CLIENTn]

[TheMiller]

Ah okay, das hilft schon sehr. Okay, dann werde ich mich mal ein wenig mit der MessageQueue beschäftigen und die Vor-/Nachteile zwischen MessageQueues und dem TCP-Server rausarbeiten.

Ich bedanke mich schonmal recht herzlich!

[Sir Rufo]

Zitat:

Zitat von DJ-SPM (Beitrag 1283577)

Ah okay, das hilft schon sehr. Okay, dann werde ich mich mal ein wenig mit der MessageQueue beschäftigen und die Vor-/Nachteile zwischen MessageQueues und dem TCP-Server rausarbeiten.

Ich bedanke mich schonmal recht herzlich!

Die beiden kann man schlecht vergleichen. Das ist so wie einen Haufen Sand mit einem belebten Bürogebäude zu vergleichen. Natürlich kann man aus einem Haufen Sand auch ein Bürogebäude bauen und dann beleben.

Aber will man sich das wirklich antun? Wäre es da nicht besser, wenn man gleich Einziehen könnte und den Sand in den Sandkasten für die Kinder kippt? ;)

Wenn es jetzt nichts geben würde, oder erst kostspielig angeschafft werden müsste ... ok, ist eine Überlegung wie sich das rechnet, aber MSMQ ist einfach schon da, den muss man nur anhauchen, damit der anfängt zu atmen.

[Mavarik]

Zitat:

Zitat von DJ-SPM (Beitrag 1283577)

Ah okay, das hilft schon sehr. Okay, dann werde ich mich mal ein wenig mit der MessageQueue beschäftigen und die Vor-/Nachteile zwischen MessageQueues und dem TCP-Server rausarbeiten.

Die MessageQueue läuft sowieso - wie "alles" im Netzwerk - über UDP/TCP.

Bei einem "kurzen" Telefonat mit Sir Rufo musste ich wieder mal feststellen:
- Nicht die beste Technik ist das wichtigste
- Nicht die schnellste Technik ist das wichtiges
- und auch nicht immer die aus gereifteste Technik ist immer die beste.

Abgesehen davon, dass wir uns in diesem Thread wahrscheinlich viel zu viel über die Technik dahinter unterhalten.

Nach einem sehr kurzen Einblick in MSMQ musste ich feststellen...

- Nutze die Techniken die Du kennst
- Erstelle ein Interface das alles was die Clientapp braucht unterstützt.
- Kümmere Dich später um "das dahinter"

Klar hat MSMQ sicherlich Vorteile - weil ausgereift... Davon gehe ich mal aus...
Aber für das was ich brauche habe ich fertige Routinen. Mit diese Routinen kann ich sofort umgehen.
Bis ich mich in eine neue Technik eingelesen habe, ist mein POC fertig. Vielleicht nicht so toll wie es MS kann...
Aber für meine belange wird es funktionieren.

Mavarik

PS.: Und ich wette ich habe einen größeren Datendurchsatz... Nur so am Rande...

[sh17]

<HALB OT>
Gibt es für Amazon AWS (SQS,...) irgendwie eine OpenSource SDK/Lib für Delphi? Hab nichts gefunden. Das was in Delphi drin ist, ist denke ich erst ab der Enterprise-Version, oder? Sonst müsste ich ganz bei 0 anfangen.
</HALB OT>

[TheMiller]

Zitat:

Zitat von Mavarik (Beitrag 1283625)

- Nutze die Techniken die Du kennst

...

Bis ich mich in eine neue Technik eingelesen habe, ist mein POC fertig. Vielleicht nicht so toll wie es MS kann...

Danke für den Hinweis. Deswegen bin ich auch hin- und hergerissen! Einerseits lese ich mich gerne in neue Techniken ein (auch wenn es länger dauert), andererseits wurden die MQ als schnell, zuverlässig und bequem zu nutzen angepriesen. Da fehlt mir die persönliche Erfahrung, habe mir noch kein Umsetzungsbeispiel angesehen und weiß daher auch nicht, wie viel Code es sein wird.

Aus diesen Faktoren habe ich gesagt, dass ich mir die Vor und Nachteile von beiden Möglichkeiten nochmal ansehe und dann entscheiden werde. Ich hatte gehofft, dass ich hier im Forum eine deutlichere Empfehlung bekomme, die mir die Entscheidung ganz klar abnimmt ;)

Aber so ist das auch super. Man muss halt jetzt überlegen, die eigenen Szenarien bewerten und dann bewerten. Mein Favorit ist derzeit der TCP-Server, da ich den kenne und den Aufwand abschätzen kann. Und auch, weil mir die MQ derzeit noch nichts sagt. Es kann natürlich sein, dass ich sofort auf die MQ springe, wenn ich mal eine Umsetzung angesehen habe. Ich hoffe, hier gibt es ein Tutorial zu den MQs.

Auch mit Interfaces (Vor- /Nachteile und Umsetzung) habe ich mich leider noch nicht beschäftigt. Da muss ich mir auch noch Infos und Tutorials suchen.

Ich informiere mich halt ganz genau vorher, da es wirklich ein größeres Projekt ist, welches wir umstellen und nicht in 6 Monaten wieder von vorne anfangen wollen, weil der TCP-Server doch keine so gute Idee war.

[Dejan Vu]

Mir hat vor Jahrzehnten ein damals schon sehr erfahrener IT-Guru gesagt: "Wenn Du den Standards nicht folgst, gehst Du unter".

Natürlich würde ich in meiner Produktivzeit, wenn Termine anstehen, kein neues Projekt mit einer neuen Technik angehen. Aber wenn man immer nur das bewährte verwendet (wogegen grundsätzlich nichts einzuwenden ist), dann ist man wirklich irgendwann einmal 'von gestern', weil man bei keiner aktuellen Technik mehr mitreden kann. Problemlos ist es, wenn man in seiner eigenen Realitätsblase lebt (Selbstständige mit festem Kundenstamm tun das meistens). Allerdings wird man dann mal eben -vroooom- von anderen Überholt, weil man beim Anwenden des Altbewährten eben vergessen hat, vorwärts zu kommen.

Ich will niemanden damit in eine Ecke oder Blase stecken, aber ganz so praktisch orientiert wäre ich da nicht.

Ich halte es so, das ich Arbeiten in bewährter Technik abliefere, aber eifrig dazulerne. Erstens macht das Spaß und zweitens spart mir das morgen eine gehörige Portion Arbeit.

Ich kenne diese MSQ nicht, kann mir aber vorstellen, das in ein paar Jahren im Intranet einiger Firmen keine handgebissenen TCP-Server mehr installiert werden dürfen, sondern alles nur über MSQ realisiert werden darf. Ist man vorbreiteit, kann man sein Angebot mit breitem Grinsen unterbreiten. Hat man den MSQ-Zug verschlafen, darf man kleinlaut abziehen.

[sh17]

Zitat:

Zitat von Dejan Vu (Beitrag 1283641)

Mir hat vor Jahrzehnten ein damals schon sehr erfahrener IT-Guru gesagt: "Wenn Du den Standards nicht folgst, gehst Du unter".

Natürlich würde ich in meiner Produktivzeit, wenn Termine anstehen, kein neues Projekt mit einer neuen Technik angehen. Aber wenn man immer nur das bewährte verwendet (wogegen grundsätzlich nichts einzuwenden ist), dann ist man wirklich irgendwann einmal 'von gestern', weil man bei keiner aktuellen Technik mehr mitreden kann. Problemlos ist es, wenn man in seiner eigenen Realitätsblase lebt (Selbstständige mit festem Kundenstamm tun das meistens). Allerdings wird man dann mal eben -vroooom- von anderen Überholt, weil man beim Anwenden des Altbewährten eben vergessen hat, vorwärts zu kommen.....

Jupp. so sieht es aus.

[vagtler]

Zitat:

Zitat von Dejan Vu (Beitrag 1283641)

[...] Ich kenne diese MSQ nicht, kann mir aber vorstellen, das in ein paar Jahren im Intranet einiger Firmen keine handgebissenen TCP-Server mehr installiert werden dürfen, sondern alles nur über MSQ realisiert werden darf.[...]

Ich denke, MSMQ hat mit seinen mittlerweile fast 20 Jahren Existenz schon einen gewissen Reifegrad erreicht - wenn nicht sogar seinen Zenit überschritten. Heutzutage sind moderne Message Queue-Server oder (Enterprise) Service Bus-Implementierungen doch schon Standard und werden von Aktor-basierten eventgetriebenen Systemen wie z.B. Akka flankiert.

[Dejan Vu]

Kannste mal sehen, wie langsam ich inzwischen bin. Ich kenne noch nicht einmal mehr die 20 Jahre alten Techniken. das kommt davon, wenn man selbstständig war.

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1283641)

Ich halte es so, das ich Arbeiten in bewährter Technik abliefere, aber eifrig dazulerne. Erstens macht das Spaß und zweitens spart mir das morgen eine gehörige Portion Arbeit.

Sehe ich auch so... Ich versuche mit jedem neuen Projekt auch mindestens "EINE" neue Technik zu verwenden und somit auch zu erlernen.
Aber besonders, wenn man nicht für andere programmiert, sondern selber etwas benötigt. Ist Zeit noch mehr Geld als sonst...

[OT]
Neue Techniken immer wieder:

Blockwrite -> Stream
Record -> Classen
ISAM -> Nativ MySQL -> FireDac
Classen -> ARC -> Interfaces
Create -> Depentency Injection
RAD -> MVVM
Proceduren -> Anonyme Methoden -> Thread's -> Task -> Future
SOAP -> REST -> SOAP :-)
Perl -> ISAPI.DLL -> ASP.NET
DOS -> Windows -> iOS -> Android
TList -> TList<T>
TCP/IP -> Tethering

Jeden Tag was neues.

[/OT]

Mavarik

[Dejan Vu]

Das wichtigste:
Bier->Wein->Rotwein->Rioja->Bier.

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1283669)

Das wichtigste:
Bier->Wein->Rotwein->Rioja->Bier.

Kaffee -> Sourcecode
oder für die Hacker unter Euch...
Chips & Cola -> Keygenerator

[TheMiller]

Koffeintabletten -> Sourcecode
danach einen Single Malt ;)

Eine Frage habe ich zu den MQs noch: Kann ich damit realisieren, dass andere Clients über Änderungen durch einen Dritten in einem aktiven Plugin automatisch benachrichtigt werden? Ich hatte ja das Szenario beschrieben: 4 Clients haben Plugin A offen, Client 1 ändert Daten und die anderen bekommen mit der Mitteilung, dass sich etwas geändert habe auch automatisch die neuen Daten zur Anzeige mitgeschickt. So wie ich das verstanden habe, funktioniert das. Richtig?
Die MQs schaue ich mir ab heute Abend an.

Und da ohnehin ein Dienst auf der Windows-Kiste läuft, kann ich damit ja auch meine Notfall-Sicherung und Aufräumarbeiten auf Dateiebene erledigen lassen. Oder ist das schädlich für die MessageQueue, weil der Dienst dann mit etwas anderem beschäftigt ist? Ok, Multithreading klar, aber vielleicht sperren sich die Abläufe gegenseitig. Wie gesagt, kenne die MQs noch nicht. Es hört sich aber sehr vernünftig an.

[Sir Rufo]

Also zu den Benachrichtigungen und den Plugins:

Stellen wir uns mal vor, das Modul/Plugin A kann eine Adresse ändern. Es fordert die Adresse mit der ID 42 an, präsentiert diese und der Benutzer kann fleißig ändern. Dann speichert der diese Adresse ab.

Als Nachricht wird nun der gesamte Daten-Satz in Richtung REST-API gesendet, die sich um das tatsächliche Speichern kümmert. Wenn die Daten gespeichert werden konnten, dann wird eine Nachricht in die Runde gesendet, dass sich die Adresse mit der ID 42 geändert hat.

Beispiel (in JSON - das Format ist egal, es geht um die Information)

Code:

{ "context": "address",
  "id": 42,
  "action": "change" }

Jetzt weiß also jeder, dass sich an der Adresse mit der ID 42 etwas geändert hat.

Somit kann auch jeder Client, jedes Modul, jedes Plugin selber entscheiden, ob diese Nachricht relevant ist. Wenn, dann holt man sich diesen Datensatz einfach neu. Den gesamten Datensatz würde ich nicht in die Runde schicken. Wozu auch ... und auch keine speziellen Nachrichten für ein spezielles Plugin/Modul. Wozu?

Jetzt soll irgendwann Modul A nicht nur eine Adresse bearbeiten, sondern auch noch die zugehörigen Rechnungen anzeigen (die werden mit Modul R angezeigt/bearbeitet). Also reagiert das Modul A auch dann, wenn eine Nachricht zu einer Rechnung kommt

Code:

{ "context": "invoice",
  "id": 142421,
  "action": "change" }

Und diese Nachrichten werden einfach per MQ übertragen.

Nachricht in die SERVICE-Queue (der das zur REST-API weiterleitet)

Code:

{ "context": "address",
  "id": 42,
  "firstname": "Peter",
  "lastname": "Lustig" }

und die Nachricht, die der Service an alle CLIENT-Queues sendet, wenn die Aktion erfolgreich war

Code:

{ "context": "address",
  "id": 42,
  "action": "change" }

Man kann die Queues auch fragen, ob die Nachricht xy schon abgeholt wurde. Dadurch kann man verhindern, dass in der Queue für einen Client (nur weil der gerade offline ist) 1000x die Nachricht reinkommt

Code:

{ "context": "address",
  "id": 42,
  "action": "change" }

denn die Nachricht reicht dem einmal. Es ist unerheblich ob ich auf meinem Schreibtisch nach dem Mittag 1000 Zettel oder einen Zettel mit einer Rückrufbitte vorfinde. Die Information ist da und ich will ja auch nicht 1000x zurückrufen, sondern nur einmal. Wenn ich nicht zurückrufen will, dann können da auch 10000000 Zettel liegen, und wenn ich zurückrufen will reicht eben 1 Zettel.

Die MQ laufen völlig unabhängig von den anderen Anwendungen. Die Queue wird abgefragt (wenn die leer ist, dauert die Abfrage 10-20 Sekunden) oder eben mit einer Nachricht gefüttert. MQ kümmert sich darum, dass die Nachrichten bei der Abfrage durch den Consumer in der Reihenfolge ausgeliefert werden, wie die dort eingegangen sind.

Stell dir das einfach wie mit der Email vor. Du schickt die ab und dann kannst du das vergessen (fire-and-forget). Den weiteren Transport erledigen jetzt andere für dich. Und wie im wahren Leben erreicht die Nachricht den Empfänger dann, wenn der in seinen Postkorb schaut (Queue fragt).

[TheMiller]

Wow :shock: - Vielen Dank für die sehr gute Erklärung!

Das hat mir schonmal sehr geholfen! Aber hier hast du dich wohl vertippt, oder?

Zitat:

Zitat von Sir Rufo (Beitrag 1283738)

Die Queue wird abgefragt (wenn die leer ist, dauert die Abfrage 10-20 Sekunden) oder eben mit einer Nachricht gefüttert.

Du meintest bestimmt Millisekungen, oder?

Ich kann es eigentlich garnicht erwarten, dieses System umzusetzen. Bin gerade begeistert und gespannt!

[Sir Rufo]

Zitat:

Zitat von DJ-SPM (Beitrag 1283760)

Wow :shock: - Vielen Dank für die sehr gute Erklärung!

Das hat mir schonmal sehr geholfen! Aber hier hast du dich wohl vertippt, oder?

Zitat:

Zitat von Sir Rufo (Beitrag 1283738)

Die Queue wird abgefragt (wenn die leer ist, dauert die Abfrage 10-20 Sekunden) oder eben mit einer Nachricht gefüttert.

Du meintest bestimmt Millisekungen, oder?

Ich kann es eigentlich garnicht erwarten, dieses System umzusetzen. Bin gerade begeistert und gespannt!

Nein, ich habe diesen Punkt schon mehrfach erwähnt und es ist so wie gesagt 10-20 Sekunden. Das ist ein sogenannter LongPoll. Du kannst die Queue in einem Thread einfach immer fragen. Wenn dort eine Nachricht ist, bekommst du die sofort geliefert und du kannst die verarbeiten und sofort wieder die Queue fragen. Ist keine Nachricht da, dann bremst dich der MSMQ (aber ja nur den Thread), damit du nicht sinnlos Abfragen durchs Netz flutest. Wenn etwas neues da ist, bekommst du das sofort.

[TheMiller]

Ok, dann ist das ja nicht weiter tragisch. Also wird es in der Praxis so gemacht, dass man ständig pollt. Ich gehe jetzt davon aus, dass die Queue 5 Minuten leer bleibt. Das Programm startet einen MQ-Poll-Thread, wird 10 Sekunden gebremst, kehr mit nichts wieder zurück. Das Programm reagiert im Callback, hat nichts zu verarbeiten und pollt daher unverzüglich wieder die MQ. Es ist aber nicht so, dass die eine Anfrage so lange offen bleibt, bis Daten in der MQ liegen? So wäre es ja bei Ajax/PHP. Das Limit von 10/20 Sekunden ist daher fest von MQ-Server vorgegeben?