Client/Server Architektur realisieren - Ideen

[Sir Rufo]

Ja, das kommt vom MSMQ, damit es eben keine Überflutungen gibt und die Programmierung des Abfrage-Threads ist sehr simpel (beispielhaft skizziert):

Delphi-Quellcode:

procedure TMSMQThread.Execute;
var
  LNachricht : ...
begin
  while not Terminated do
    if NachrichtInQueue( LNachricht ) then
      Queue( 
        procedure
        begin
          TuWasMitNachricht( LNachricht );
        end );
end;

Wenn Nachrichten da sind feuert der wie ein ganz Großer, ansonsten wartet der die meiste Zeit

[Mikkey]

Da muss ich mich mal einmischen...

Wenn man die COM-Objekte der MSMQ verwendet (IMSMQQueue), kann man beim Empfangsversuch die Wartezeit angeben.

Methode Receive:

Delphi-Quellcode:

Function Receive(vTransaction, vWantDestQueue, vWantBody, vReceiveTimeout, vWantConnectorType): IMSMQMessage;

Dabei ist vReceiveTimeout ein Variant und gibt die Wartedauer in Millisekunden an.

[TheMiller]

Hallo,

ich frage mich gerade, ob die MSMQ-Variante eine gute Lösung ist. Wenn ich hier in der DP oder auf Google nach MSMQ suche ("Delphi msmq tutorial" / sample / code / msmq_tlb.pas / etc.), dann finde ich kaum Ergbenisse.

Das lässt mich vermuten, dass diese Technik wohl selten benutzt wird. Die Hilfe im msdn ist zwar sehr gut, aber Umsetzungsbeispiele etc.pp für Delphi finde ich kaum. Ich würde sie schon gerne benutzen, aber wirklich nur dann, wenn die Technik - naja, wie soll ich sagen - bekannt/verbreitet ist. Zwar scheint es die MQ schon lange zu geben, aber warum findet man so wenig? Macht mich etwas stutzig.

Sehe ich das falsch?

[Mikkey]

Wieviel MSMQ benutzt wird, weiß ich nicht, aber die Verwendung ist recht simpel:

Delphi-Quellcode:

procedure TSample.Execute();
var
  qi: IMSMQQueueInfo3;
  ms: IMSMQMessage3;
  qu: IMSMQQueue3;
  vTransaction, vWantDestQueue: OleVariant;
  vWantBody, vReceiveTimeout, vWantConnectorType: OleVariant;
begin
  CoInitializeEx(nil, COINIT_MULTITHREADED);
  if TryCreateAndOpenQueue(qi, qu) then begin
      while not Terminated do
      try
        vTransaction := OleVariant(MQ_SINGLE_MESSAGE);
        vWantDestQueue := OleVariant(false);
        vWantBody := OleVariant(true);
        vReceiveTimeout := OleVariant(MSMQWAITTIME);
        vWantConnectorType := OleVariant(false);
        ms := qu.Receive(vTransaction, vWantDestQueue, vWantBody, vReceiveTimeout, vWantConnectorType);
        if Assigned(ms) then
          TuIrgendwasmitDerNachricht(ms);
      except on e: Exception do begin
          break;
        end;
      end;
  end;
  if Assigned(qu) then
    qu.Close();
  CoUninitialize();
end;

Dies ist das Empfangen von Nachrichten innerhalb eines TThread-Executes, das Senden ist einiges einfacher

[Dejan Vu]

Und dann ist es eben so: Wenige Leute verwenden Delphi. Nicht so viele Leute verwenden MSMQ => Wenige*Nicht so viele = Viel Weniger.

[humbuck]

LOL

Schöner Thread. :-D

Niemand kann dir die Entscheidung abnehmen, wie du schon selbst festgestellt hast, DJ-SPM.

Eine Betrachtung des Kosten-Nutzen-Faktors spielt dabei sicherlich eine große Rolle. Und wie mir scheint, weißt du noch gar nicht, ob du die MQ nutzen kannst. Als Autodidakt wird es dich sicherlich mehr Zeit kosten, als würdest du mit Seminar-Wissen gesegnet sein.

Deine ursprüngliche Idee, die, wie mir schien, zum Greifen nah war, wurde jetzt erst mal tüchtig vernebelt durch den massiven Input von allen Meinungen und Empfehlungen, wie sie nicht unterschiedlicher sein können.

Eigentlich kann man dir nur empfehlen, das altbewährte einzusetzen, damit du ein Licht am Ende des Tunnels sehen kannst, solange du alleine vor der Umsetzung deines Projektes stehst. Und alternativ solltest du dir vielleicht einen Partner für die Entwicklung mit ins Boot nehmen, bei dem du dann vielleicht ein wenig mit den Augen klauen kannst. Vom Budget des Projekts abhängig.

Ist halt die Frage, ob dein Projekt in naher Zukunft schon Zukunft haben soll, da es von deinen Kunden gefordert wird, oder ob du dir alle Zeit der Welt herausnehmen kannst.

Naja, jedenfalls wenn du kurzfristig ergebnisorientiert handeln musst, musst du halt nur noch abwägen, wie lange es dauert, eine stabile TCP-Lösung zu verwirklichen, die all den Anforderungen vollständig und ohne viel Nachpflege entspricht... Und da wird es wahrscheinlich wieder schnell schwammig...

Gruß vom Jörch

[mjustin]

Zitat:

Zitat von DJ-SPM (Beitrag 1284092)

Zwar scheint es die MQ schon lange zu geben, aber warum findet man so wenig?

Möglicherweise wird Microsoft Message Queuing - ausser im Windows-Bereich - vegleichsweise selten eingesetzt, weil es viele etablierte Alternativen gibt, die auch auf anderen Betriebssystemen laufen. Neben Platzhirschen wie Tibco gibt es Open Source Lösungen, zum Beispiel RabbitMQ oder Apache ActiveMQ bzw. Apollo, die in der Industrie weit verbreitet eingesetzt werden. RabbitMQ zum Beispiel wird von der New York Times eingesetzt.

Es gibt unter anderem auch Open Source Clients für Message Broker, die mit Delphi verwendet werden können. (Ich selber entwickle kommerzielle Clients für ActiveMQ, Apollo, HornetQ, OpenMQ und RabbitMQ.)

Mit Delphi und ActiveMQ Apollo sind kontinuierlich 40.000 Nachrichten-Roundtrips pro Sekunde erreichbar. Das heißt: der Delphi Client sendet in einem Thread jede Sekunde 40.000 Nachrichten an den Apache Apollo Broker, dieser stellt sie in eine Queue, und der Client liest sie in einem anderen Thread aus der Queue. Siehe Screenshot...

[vagtler]

Zitat:

Zitat von mjustin (Beitrag 1284162)

Zitat:

Zitat von DJ-SPM (Beitrag 1284092)

Zwar scheint es die MQ schon lange zu geben, aber warum findet man so wenig?

Möglicherweise wird Microsoft Message Queuing - ausser im Windows-Bereich - vegleichsweise selten eingesetzt, weil es viele etablierte Alternativen gibt, die auch auf anderen Betriebssystemen laufen. [...]

Ja, das war es, was ich in http://www.delphipraxis.net/1283665-post71.html gesagt habe.

[TheMiller]

Moin!

Es tut mir leid, dass ich nie am Wochenende zurückschreibe. Irgendwie sind die so vollgepackt momentan, dass ich stets nicht dazu komme.

Zitat:

Zitat von humbuck (Beitrag 1284144)

Deine ursprüngliche Idee, die, wie mir schien, zum Greifen nah war, wurde jetzt erst mal tüchtig vernebelt durch den massiven Input von allen Meinungen und Empfehlungen, wie sie nicht unterschiedlicher sein können.

Eigentlich kann man dir nur empfehlen, das altbewährte einzusetzen, damit du ein Licht am Ende des Tunnels sehen kannst, solange du alleine vor der Umsetzung deines Projektes stehst. Und alternativ solltest du dir vielleicht einen Partner für die Entwicklung mit ins Boot nehmen, bei dem du dann vielleicht ein wenig mit den Augen klauen kannst. Vom Budget des Projekts abhängig.

Hm, du kennst mich nicht. Nur weil ich mich genau informiere, heißt das nicht, dass das Ziel weit weg ist. Schon am Freitrag lief der Windows-Dienst mit eigenständigem Thread. Auch das Erstellen, Öffnen und Schreiben in die MSMQ hat schon funktioniert (ich werde später eine Klasse erstellen und sie hier veröffentlichen).

Zitat:

Zitat von humbuck (Beitrag 1284144)

Ist halt die Frage, ob dein Projekt in naher Zukunft schon Zukunft haben soll, da es von deinen Kunden gefordert wird, oder ob du dir alle Zeit der Welt herausnehmen kannst.

Von beidem etwas. Die aktuelle Version läuft stabil im produktiven Einsatz. Daher kann ich es mir erlauben, mich genau zu informieren und abzuwägen. Es hilft mir nichts, wenn wir zwei Wochen eher mit dem Programmieren anfagen und dann in 6 Monaten wieder alles umstellen.

Zitat:

Zitat von humbuck (Beitrag 1284144)

Naja, jedenfalls wenn du kurzfristig ergebnisorientiert handeln musst, musst du halt nur noch abwägen, wie lange es dauert, eine stabile TCP-Lösung zu verwirklichen, die all den Anforderungen vollständig und ohne viel Nachpflege entspricht... Und da wird es wahrscheinlich wieder schnell schwammig...

Ich bin schon ein guter Programmierer - auch wenn ich hauptsächlich einen anderen Beruf ausübe. Klar habe ich auch mal ziemlich blöde Fragen und kenne nicht jede Technik. Ich mache das aber daran fest, wie lange und stabil unsere Produkte schon in der Praxis genutzt werden.

Ich denke dennoch, auf eine fertige Lösung zurückzugreifen ist immernoch zeitsparender, performanter und stabiler, als erstmal selbst eine TCP-Lösung zu entwickeln, zu testen, Kinderkrankheiten beseitigen etc.pp.

---

Nun bin ich natürlich wieder am Lesen, ob wir MSMQ verwenden (was schon teilweise läuft) oder doch lieber ActiveMQ o.ä.

Wenn wir nun doch mal einen MAC-Client anbieten wollen, dann ist MSMQ wohl die falsche Wahl. Wir wollen ja ohnehin eine iOS-App und vllt. eine Webseite zu dem Produkt erstellen, also würde es Richtung ActiveMQ tendieren. Richtig? Vielleicht gibt es hier noch ein paar persönliche Erfahrungswerte zu den einzelnen Techniken. Ich lese parallel in Google weiter und poste, wenn ich was Gutes gefunden habe.

Danke

[Sir Rufo]

Generell sollte einer Anwendung egal sein, wie und worüber kommuniziert wird. Konkret wird man immer erst so spät wie möglich.

Ein Interface, dass alle benötigten Aktionen der Anwendung zur Verfügung stellt und dann die konkrete Implementierung mit dem Transportmittel deiner Wahl. Dann brauchst du nur noch die Implementierung tauschen und die Kommunikation läuft über MSMQ, ActiveMQ, eigene TCP Lösung, ...

Oder eben für die Mobile-Devices, die sowieso ganz anders kommunizieren müssen.

Wenn OSX denkbar ist, würde ich allerdings auch eher nicht auf MSMQ setzen, allerdings ist der gut für den Einstieg in das Thema MQ, denn mit ein/zwei Klicks kann man schon schnuppern :)

[TheMiller]

Zitat:

Zitat von Sir Rufo (Beitrag 1284346)

Ein Interface, dass alle benötigten Aktionen der Anwendung zur Verfügung stellt und dann die konkrete Implementierung mit dem Transportmittel deiner Wahl. Dann brauchst du nur noch die Implementierung tauschen und die Kommunikation läuft über MSMQ, ActiveMQ, eigene TCP Lösung, ...

Das ist eine sehr gute Idee - so wird's gemacht. Die MAC-Geschichte ist nämlich bisher nur ein Gedanke, keine Entscheidung. Vllt. lohnt es sich in unserer Branche garnicht.

[TheMiller]

Hi,

ich muss nochmal was grundsätzliches fragen: Mein Programm besteht aus einer Hauptanwendung. Die Plugins waren damals DLLForm und sind nun einfach exe-Anwendungen, die sich nur vom Hauptprogramm starten lassen. Sie werden optisch in Reiter im Hauptprogramm gestartet.

Da es ja eigentlich selbstständige Anwendungen sind, müsste ich nicht dann für jedes Plugin auch eine MessageQueue haben? Also pro Client pro Plugin? (ClientID.Pluginname)

Würde das das System vereinfachen oder verkomplizieren?