Ich muss ein System erstellen, das aus zwei Komponenten besteht:
Ein einzelner Server, der Daten verarbeitet und speichert. Es sendet auch regelmäßig Aktualisierungen an die Agenten
Mehrere Agenten, die auf Remote-Endpunkten installiert sind. Diese sammeln Daten in (oft, aber nicht immer) lang andauernden Operationen, 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 arbeiten könnte, da wir in Zukunft wahrscheinlich auch Java-Agenten verwenden). Gibt es Alternativen zu Webdiensten? Was sind meine Optionen?
So wie ich es sehe, habe ich 3 Optionen, die Webdienste verwenden, und habe folgende Beobachtungen gemacht:
Der "Hybrid" (wo Agenten sowohl Client als -Server sind, scheint die offensichtliche Wahl zu sein), aber diese Anwendung wird normalerweise in Unternehmens- und Regierungsumgebungen installiert, und ich bin besorgt, dass sie ein Problem haben könnten mit dem Öffnen eines Hafens beim Agenten, halte ich zu viel davon?
Gibt es irgendwelche anderen Vor- und Nachteile, die ich verpasst habe?
Unsere Freunde bei Ссылка schwören auf Pull-basierte Mechanismen: Ссылка
Ein wichtiger Grund, warum sie Client-Pull-Server-Push bevorzugen, ist, dass Clients möglicherweise nicht verfügbar sind und Clients (im Allgemeinen) alle von Servern ausgelösten 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 Artikels zu lesen, um selbst zu bestimmen.
Ich würde sagen, dass Sie heutzutage nur noch an Pull-Technologien denken können. Das Problem mit Push ist, dass Clients oft hinter NAT-Geräten (Network Address Traversal Devices) wie drahtlosen Routern, Breitbandmodems oder Unternehmensfirewalls versteckt sind und oft vom Server nicht erreichbar sind.
Ausgehende Verbindungen ('phone-home'), speziell an bekannten Ports wie HTTP / HTTPS, können grundsätzlich auch in den meisten eingeschränkten Netzwerken als 'möglich' vorausgesetzt werden.
Wenn Sie eine Art Messaging-Server verwenden (JMS für Java, nicht sicher für C #), dann ist Ihr Nachrichtenserver der einzige Server, der einen Port öffnen muss und Sie können eine Zweiweg-Kommunikation von Ihrem Agenten zum Messaging-Server und vom Server zum Nachrichtenserver. Dadurch können Sie das Hybridmodell ausführen, ohne einen Port auf dem Agentenserver öffnen zu müssen.
IMHO, ich finde Ihre beste Option ist die Pull-Option .., die Ihre wichtigsten Systemanforderungen wie folgt erfüllen kann:
Der erste Teil: Daten müssen zum Server gelangen, das kann natürlich durch Aufruf einer Web-Methode geschehen, die diese Daten als Parameter sendet
2. Teil: (Der Server sendet regelmäßig Updates an die Agenten): Sie können immer noch so tun, dass der Client (regulär) nach einer Art von Web-Service-Methode sucht, die seit dem letzten Pull nach den Updates fragt (einige Art von Zeitstempel, um die Updates zu erhalten, die es verpasst hat)
Die hybride Methode scheint mir etwas seltsam zu sein, da ich einen Agenten als einen Teil des Systems betrachte, der wahrscheinlich oft "offline" gehen könnte, was wird der Server tun, wenn das fehlschlug? es ist normalerweise eine schwierige Frage / Entscheidung, vor allem, wenn Sie nicht sicher sind, ob dies beabsichtigt "offline gehen" oder ein System / Netzwerk-Fehler .. etc
Tags und Links .net c# architecture networking