Client/Server Architektur realisieren - Ideen

[Mavarik]

Zitat von DJ-SPM:

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 von Mavarik:

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

Jupp. so sieht es aus.

[vagtler]

Zitat von Dejan Vu:

[...] 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 von Dejan Vu:

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 von Dejan Vu:

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

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