Server-Push vs. Client-Pull für Agent-Server-Topologie

Question

Ich muss ein System erstellen, das aus 2 Komponenten besteht:

• Ein einziger Server, der Daten verarbeitet und speichert. Außerdem sendet er in regelmäßigen Abständen Aktualisierungen an die Agenten.

• Mehrere Agenten, die an entfernten Endpunkten installiert sind. Diese sammeln Daten in (oft, aber nicht immer) langwierigen Vorgängen, und diese Daten müssen zum Server gelangen

Ich verwende C# .NET, und idealerweise möchte ich eine standardkonforme Kommunikationsmethode verwenden (d.h. eine, die theoretisch auch mit Java funktionieren könnte, da wir in Zukunft auch Java-Agenten verwenden könnten). Gibt es Alternativen zu Webservices? Was sind meine Optionen?

So wie ich es sehe, habe ich 3 Möglichkeiten, Webdienste zu nutzen, und habe folgende Beobachtungen gemacht:

• Kunde ziehen
  • Kein offener Port beim Agenten erforderlich, da er sich wie ein Client verhält
  • Müsste den Server nach Updates abfragen
• Server-Push
  • Öffnen Sie den Port des Agenten, da er sich wie ein Server verhält.
  • Server muss Agenten für Ergebnisse abfragen
• Hybride
  • Öffnen Sie den Port beim Agenten, da er sich wie beide ein Client und ein Server
  • Kein Polling; Server sendet Aktualisierungen bei Bedarf, Client sendet Ergebnisse, wenn sie verfügbar sind

Die "hybride" Variante (bei der Agenten sowohl Kunden als auch y Server scheint die offensichtliche Wahl zu sein - aber diese Anwendung wird typischerweise in Unternehmens- und Regierungsumgebungen installiert, und ich befürchte, dass sie ein Problem mit dem Öffnen eines Ports beim Agenten haben könnten. Mache ich mir zu viele Gedanken darüber?

Gibt es noch andere Vor- und Nachteile, die ich übersehen habe?

Answer 1

Unsere Freunde von http://www.infrastructures.org durch pull-basierte Mechanismen zu schwören: http://www.infrastructures.org/papers/bootstrap/bootstrap.html

Ein wichtiger Grund, warum sie Client-Pull gegenüber Server-Push bevorzugen, ist, dass Clients ausfallen können und Clients (im Allgemeinen) alle von Servern gepushten Operationen anwenden müssen. Wenn dieses Kriterium in Ihrem Fall nicht wichtig ist, wird ihre Schlussfolgerung vielleicht nicht Ihre Schlussfolgerung sein, aber ich denke, es lohnt sich, den Abschnitt "Push vs. Pull" ihres Papiers zu lesen, um selbst zu entscheiden.

Answer 2

Ich würde sagen, dass man in der heutigen Zeit nur noch Pull-Technologien ernsthaft in Betracht ziehen kann. Das Problem bei Push ist, dass die Clients oft hinter Network Address Trav versteckt sind.

M

Answer 3

Wenn Sie eine Art Messaging-Server verwenden (JMS für Java, nicht sicher für C#), dann ist Ihr Messaging-Server der einzige Server, der einen Port öffnen muss, und Sie können eine Zwei-Wege-Kommunikation von Ihrem Agenten zum Messaging-Server und vom Server zum Messaging-Server haben. Auf diese Weise können Sie das Hybridmodell verwirklichen, ohne einen Port auf dem Agentenserver öffnen zu müssen.

Answer 4

IMHO finde ich, dass Ihre beste Option die Pull-Option ist die Ihre wichtigsten Systemanforderungen wie folgt erfüllen kann:

Der erste Teil: Die Daten müssen zum Server gelangen, was natürlich durch den Aufruf einer Webmethode geschehen kann, die die Daten als Parameter sendet.

2. Teil: (Server sendet regelmäßig Updates an die Agenten): Das kann man immer noch durch (regelmäßige) Abrufe des Clients über eine Art Webservice-Methode erreichen, die nach den Aktualisierungen seit dem letzten Abruf "fragt" (eine Art Zeitstempel, um die verpassten Aktualisierungen zu erhalten)

Die hybride Methode erscheint mir etwas seltsam, da ich einen Agenten als einen Teil des Systems betrachte, der wahrscheinlich oft "offline" geht. Was wird der Server dann tun, wenn er ausfällt? das ist normalerweise eine schwierige Frage/Entscheidung, besonders wenn man nicht sicher ist, ob es sich um ein beabsichtigtes "Offlinegehen" oder einen System-/Netzwerkausfall handelt.