replizieren von Daten zwischen Standorten in einer j2ee-app

Question

wir haben eine J2EE-app, auf dem wir noch arbeiten.Es läuft auf einer Oracle-DB.und der business-Schicht ist codiert mit EJB 2.0 mit einer rich-client-Schnittstelle.

nun, die Anwendung implementiert werden soll auf mehrere Standorte.und jede Seite wird das erstellen neuer Elemente (neue Verträge, etc.).

was wir verwirklichen wollen, ist das duplizieren alle neuen Elemente Hinzugefügt, die die zentrale Lage der DB mit der gleichen DB-schema wie lokal.

was denkst du, ist der effektivste Weg, dies zu erreichen ?

Ich habe mir mal überlegt serialisieren alle neu erstellten Elemente und sendet Sie an den remote-Standort für integration, die durch die Java Message Service-Warteschlange.ist dieser Ansatz gut ?

und es gibt auch einige änderungen repliziert werden, zurück zu den Satelliten.

Answer 1

Ich würde sagen, dass eine synchrone Beziehung mit dem Zentrum führt die Kupplung, die Sie nicht wollen.Damit Ihre asynch Idee scheint ziemlich gut zu mir.Sie vermutlich haben einige location-dependent Kennung der Datensätze so, dass die neuen Verträge Kreationen in den verschiedenen Standorten nicht kollidieren, und Sie akzeptieren einige Wartezeit in der Replikation vom Zentrum entfernt.

So der einfache Fall ist, dass nur die Nutzung von JMS-Nachrichten, die von jedem Ort des Stadtzentrums.

Die nette Sache über dieses Programm ist, dass die Sateliten nicht sogar brauchen, um wissen über die Struktur der Datenbank, in der Mitte, es kann entworfen werden, ganz idepedently.

Die Dinge sind interessanter, wenn Sie auch brauchen, um die änderungen zu replizieren wieder von der Mitte zu den Sateliten.Die große Frage ist, ob wir vielleicht auch Konflikte zwischen den Veränderungen in der Mitte und änderungen an den Satelliten.

Einfacher Fall:Jedes Datenelement hat eine "Heimat".Zum Beispiel der Ursprung Satelliten ist der Ort, wo die änderungen vorgenommen werden.Oder nach der Erstellung der Mitte ist der einzige Ort, den ti änderungen vornehmen.In diesem Fall behandeln wir das Zentrum als "Hub", es fortpflanzen können änderungen außerhalb der Sateliten.Einfache JMS-gerade richtig für die.

Etwas schwieriger Fall:Änderungen können Sie überall, sondern nur an einem Ort zu einer Zeit.Daher können wir uns vorstellen, somne Art, wenn locking scheme.Ich würde dazu neigen, haben das Zentrum als Eigentümer und die Verwendung synchrnous web-Diensten zu sperren und die Daten aktualisieren.Jetzt sind wir verbunden, aber notwendig, wenn wir eine endgültige Inhaber.

Ziemlich komplexen Fall:Jeder kann etwas ändern würde überall ohne Verriegelung.Es ist eine Art "Zuerst Handeln, entschuldige Mich Später" - Ansatz.Wir nehmen den optimistischen Auffassung, dass die änderungen nicht widersprechen.Wir können senden die änderungen zur Genehmigung an das Zentrum und die Mitte kann entweder eine optimistische sperren oder merge nicht in Konflikt stehenden änderungen Ansatz.Ich würde dazu neigen, dies zu tun, indem queueing ändert den Urheber, sondern tatsächlich der Verarbeitung durch synchrone Aufrufe.So Entkopplung der Spezifikation des Wandels von der Verfügbarkeit der Mitte.Einige anspruchsvollere Datenbanken diff/merge-Funktionen, die helfen können, mit dieser.

Große Fragen sind, inwieweit Sie wollen gekoppelt werden, um die Verfügbarkeit der Mitte und die Wahrscheinlichkeit von widersprüchlichen änderungen.Oft list application design können erheblich reduzieren die Wahrscheinlichkeit von Konflikten.