Problem wie man mit WCF einen verteilten, skalierbaren und katastrophenresistenten Pub / Sub-Service bereitstellt.

Einzelheiten

Beachten Sie, dass dieser Ansatz zusätzlich zu Messaging- / Middleware-Lösungen wie Tibco EMS in Betracht gezogen wird.

Ich habe mich mit WCF befasst, insbesondere, wie es verwendet werden kann, um Pub / Sub anzubieten. Zu diesem Thema ist dieser Artikel sehr gut:WCF pub-sub.

In dem Artikel versucht der Autor, das Problem mit mehreren Publishern anzugehen (wie dies bei einem Service-Layer der Fall wäre, der über mehrere Boxen hinweg skaliert ist). Das Problem besteht darin, dass, wenn sich Client A bei Publisher A registriert, Publisher B jedoch ein Ereignis veröffentlichen möchte, Publisher B nicht über Client A informiert wird. Das heißt, niemand hat Publisher B mitgeteilt, dass Client A über Ereignisse benachrichtigt werden möchte. Der Autor schlägt einen Pub / Sub-Service als Lösung vor. Der Pub / Sub-Service speichert Abonnements zentral. Wenn ich jedoch den Pub / Sub-Service durch einen sekundären / dualen Pub / Sub-Service unempfindlich machen wollte, habe ich das gleiche ursprüngliche Problem.

Also, ich denke, es gibt ein paar Lösungen für das Problem:

Speichern Sie Abonnentendetails in einem verteilten Cache (siehe Fragen: q1 und q2).Speichern Sie Abonnentendetails in einem Datenbank- / zentralen Dateisystem.

Kann jemand an eine andere Lösung denken (d. H. Ich habe einige fantastische magische Funktionen von WCF nicht verpasst?) Kommentare erwünscht.