Wie erfolgt die Nachrichtenübertragung von Pull- / Polling von einem Webserver gewährleisten

StackOverflow https://stackoverflow.com/questions/4030433

Frage

Dies baut auf Wie Nachrichten zwischen Unternehmen zu senden. Wenn ich diese Firma S (upplier) entscheiden, sollen Aufträge von Unternehmen abfragen (B) in einigen einfachen HTTP-basierten Weg, was die beste Umsetzung ist.

  • Ich gehe davon aus dem Unternehmen B hat einen Webserver läuft und die Back-End-Datenbank dieses Webserver ist langlebig. Wir sollten so wenige möglichen Annahmen über die Lagerprozesse bei S machen, und wenn sie in der Lage, Zustand zu halten (zum Beispiel einer Liste der bereits übertragenen GUIDs)
  • Die Internet-Verbindung zwischen B und S ist unzuverlässig.
  • Wir müssen erreichen Eventual Consistency alle Aufträge zwischen B an einem Punkt in der Zeit bedeutet, und S übertragen werden sollen.

Was ist die beste Praxis, ein solches System zu implementieren?

War es hilfreich?

Lösung

Ein Ansatz für diese Art von Problem ist eine Art von Warteschlangen Produkt, als IBM Person zu verwenden, ich MQ sofort betrachten. Doch als ich mich nicht wirklich MQ Person bin, wie ich Sie wahrscheinlich mit Service basierten Ansatz glücklich sein würde, die Sie einnehmen.

Es gibt zwei mögliche Ansätze, die in den Sinn kommen. Eine davon ist die Verwendung der WS Reliable Messaging , was die Zuverlässigkeit Problem nach unten in den Web-Service schiebt Infrastruktur. Die andere ist, zu Handkurbel Ihr eigenes zuverlässiges Protokoll, das auf der einfachen, aber unzuverlässig, Dienstleistungen.

Ich habe nicht bekam ernsthafte praktische Erfahrung in der ein System mit WS Reliable Messaging Implementierung, ich glaube, dass es an die Arbeit gemacht werden kann, aber es hat ein gewisses Maß an Kontrolle über die Teilnehmer erfordern - wie es eine verhältnismäßig neue Standard, den wir ist kann nicht garantieren, dass eine bestimmte IT eine Implementierung zu Hand haben kaufen, und die Interoperabilität zwischen Anbietern kann ein Problem sein. Je mehr Kontrolle ich über die SW-Stacks an jedem Ende haben die mehr geneigt ich nutzen würde WS Reliable Messaging. [I sollte auch WS Atomic Transaktion erwähnen, die auch realiable Dienste bauen verwendet werden können, die gleichen inter op Bedenken gelten.]

Was ist also mit Roll-your-own? Der Schlüssel hier ist, um alle Dienste Idempotent zu machen. Wie wir, dass die beiden Systeme umspannen nicht transaktionale Garantien müssen wir davon ausgehen, dass ein bestimmte Service-Aufruf mit unbekanntem Ausgang fehlschlagen.

Ich gehe davon aus, dass B will eine Bestätigung hat, dass S einen Auftrag angenommen hat, deshalb müssen wir Update-Informationen sowohl auf B und S, wenn ein Auftrag übertragen wird.

B müssen Dienste wie diese bieten: 

 Give me the next order(s)

 I have stored {orders ...}

So wie definieren wir „weiter“. Der einfachste Fall funktioniert gut, wenn die Volumina wir beschäftigen uns einen einzigen „Faden“ der Übertragung haben lassen. Dann Abhaken B wird die gesendete Aufträge einen nach dem anderen, und die Aufträge haben eine monoton steigende ID. Wir können dann vereinfachen zu: 

 I have stored order <65,004> please give me the next

Beachten Sie, dass dies ein idempotent Anfrage: es kann sicher viele Male wiederholt werden. Beachten Sie auch, dass S die Möglichkeit, sich in der gleichen Reihenfolge zweimal antizipieren müssen, und prüfen Sie nach Duplikaten.

Andere Tipps

Was Sie wahrscheinlich suchen ist zweiphasige Festschreibung. Es ist im Internet, zum Beispiel hier beschrieben:

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

Der Kern von ihm:

Die Commit-Prozess geht wie folgt vor: 

* Phase 1
      o Each participating resource manager coordinates local 
        operations and forces all log records out:
      o If successful, respond "OK"
      o If unsuccessful, either allow a time-out or respond "OOPS" 
* Phase 2
      o If all participants respond "OK":
            * Coordinator instructs participating resource managers to "COMMIT"
            * Participants complete operation writing the log record
              for the commit 
      o Otherwise:
            * Coordinator instructs participating resource managers to "ROLLBACK"
            * Participants complete their respective local undos

Should Arbeit für jede Art von Daten.

Okay, zunächst einmal kann man nicht Garantie etwas über einen unzuverlässigen Link. Die Drei-Wege-Handschlag dies für beide deterministische und nichtdeterministische Protokolle beweist. Alles, was Sie tun können, ist die Unzuverlässigkeit auf ein akzeptables Maß zu verringern.

Die einfachste Methode ist, in Ihrem Fall, wenn der Server eine Abfrageanforderung empfängt, sendet er x Anzahl an Antworten, die alle mit der gleichen GUID. Zum Beispiel. 

S: B, anything new?
S: B, anything new?
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need some shoes (order #124).
...

S kann mit dem Befehl bekommen spammed, aber da die # mit jeder Anfrage gesendet wird, es ist keine große Sache. Wenn wir es vor verpasst haben, sind wir nun bekommen. Wenn wir haben es nicht vor erhalten, Woohoo! Wir haben es jetzt. Das System funktioniert! Sie werden bemerken, dass B sendet Nachrichten mal in meinem Beispiel 5. In einem realistischen Szenario würden Sie wahrscheinlich eine Nachricht hunderte oder tausende Male senden, bis Sie die gewünschte Zuverlässigkeit haben.

Nun ist die obige Lösung verarbeitet und Bandbreite intensiv, aber es funktioniert. Eine clevere Methode ist zu tun, was TCP hat. Hat einen Drei-Wege-Handshake 

S: Hello B. Are you there? -> SYN
B: Hello S, yep I'm here. What's up? -> SYN+ACK
S: Oh good, you're there. -> ACK
S: B, anything new?
B: Yes, S, I need a jacket (order #123).

Aber .. HTTP tut dies bereits. Also, wenn etwas nicht irgendwo bekommt, wissen Sie. Connection timed out, Verbindung brach, etc.

Nun, Sie könnten diese Szenarien innerhalb der Anwendungsebene neu schreiben (geben Sie WS-Reliable Messaging), aber wirklich TCP ist bereits zuverlässig. Einige Kritiker dieser SOAP (ish) Frameworks und faux-Protokolle (sie arbeiten auf HTTP in der Regel) beschuldigen sie im Wesentlichen das Rad neu zu erfinden - und das Rad Probleme -. Auf einer höheren Abstraktionsebene

Das Endergebnis ist, dass jedes System fehlschlagen kann, einschließlich zuverlässigen Messaging-Systeme.

Was Eventual Consistency angeht, ich glaube, Sie verwechseln kann. Eventual Consistency gilt nur für verteilte Speichersysteme, bei denen nach einer Write(), können Sie nicht in der Lage sein, um es deterministisch für einige Zeit mit einem Read() abrufen. Dies gilt nicht, wie Ihr Problem überhaupt zu sein scheint. Ich meine, ich sehe, was Sie sagen, aber in einem eventually consistent-System, eine zuverlässige (genug) Verbindung zwischen den Knoten angenommen. Sie haben nicht diese Annahme machen (auch wenn ich denke, Sie sollten .. TCP ist verflixt zuverlässig).

Aufbauend auf, dina erwähnt. Webservices wäre eine perfekte Lösung für das obige Problem sein. Einige Protokoll kann vereinbart werden, die die Anzahl der Datensätze definieren würde. 

S ---> D ( Call a service which would list record keys)
D----> S ( provide xml of keys)
S----> D ( Request each of the records)
D----> S ( Submit record)

Im Falle eines neuen Aufzeichnungseintrag nach dem Synch gemacht wird, kann Destination einen Dienst an der Quelle eingesetzt aufrufen, die einen neuen Datensatz behandeln würde.

Da die Kommunikation abgewickelt wird eine Web-Service-Motor kaufen, müssen Sie sich keine Sorgen über die Nachrichtenparameter. SSL kann für die Sicherheit hinzugefügt werden.

Cheers!

Ich glaube, Sie versuchen, zu sagen, dass das Unternehmen B ein passiver Teilnehmer ist. S (Lieferant) muss nur die Möglichkeit, alle Aufträge, dass B-Stellen (Eventual Consistency) zu erhalten. Aber B braucht nicht oder kümmern uns um welche Aufträge S hat bereits (keine Notwendigkeit für commit).

Wenn Unternehmen B ein halb genaue Uhr hat, Sie Datum als monoton steigende GUID, je nach Auflösung von Ereignissen verwenden können - Sie werden nicht zu Umfrage möchten, wenn Sie sowieso Millisekundenauflösung benötigen. Sie nur B-Uhr verwenden, so dass Sie sich Sorgen zu machen über die Synchronisierung nicht haben. Wenn B alle Aufträge veröffentlicht, kann S nur abholen die Aufträge aus dem sie zuletzt aufgehört haben.

Ich bin mir nicht sicher, ob Sie Best Practices oder beste Kompromisse für ein einfach zu implementieren System gemeint. Je nach Volumen und Reaktionszeit, gibt es keine Notwendigkeit, sie ein dynamisches System zu machen, wenn Sie Polling ohnehin sind. Dump Aufträge als Textdateien (mit Zeitstempel genannt) in ein Verzeichnis nach dem Datum benannt und ziehen sie alle nach unten (oder selektiv). Sie können speichern sie auch in den Verzeichnissen von Stunde zu Stunde oder was auch immer Sinn macht. HTTP GET ist idempotent.

Das könnte hässlich sein, aber es klingt wie Sie nicht viel Komplexität von Unternehmen B. SSL verwenden und Auth erwarten und es ist gesperrt und verschlüsselt.

Wenn Sie nicht brauchen Leistung es ist nichts falsch mit einfach. Was gewinnen Sie wirklich von einem komplizierten Protokoll?

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top