تكرار البيانات بين المواقع في j2ee التطبيق

Question

لدينا J2EE التطبيق الذي نحن لا تزال تعمل.أنه يعمل على Oracle DB.و الطبقة التجارية يتم ترميز مع EJB 2.0 مع العميل الغنية واجهة.

الآن التطبيق سوف يتم نشرها على مواقع متعددة.و كل موقع سيتم إنشاء عناصر جديدة (جديد العقود ، إلخ.).

ما نريد أن ندرك أن تكرار جميع عناصر جديدة تضاف إلى موقع مركزي DB باستخدام نفس DB schema المحلية منها.

ما رأيك هو الطريقة الأكثر فعالية لتحقيق هذا الهدف ؟

لقد فكرت التسلسلية كل العناصر الجديدة التي تم إنشاؤها وإرسالها إلى موقع بعيد عن التكامل من خلال جافا رسالة قائمة انتظار الخدمة.هل هذا نهج جيد ؟

و هناك أيضا بعض التغييرات النسخ المتماثل مرة أخرى إلى الأقمار الصناعية.

Answer 1

أود أن أقول أن متزامن العلاقة مع المركز يقدم اقتران ان كنت لا تريد.ومن ثم الخاص بك asynch الفكرة تبدو جيدة جدا بالنسبة لي.كنت من المفترض أن بعض المواقع التي تعتمد على معرف في السجلات بحيث عقود جديدة الإبداعات في مواقع مختلفة لا صراع و تقبل بعض الكمون في النسخ المتماثل إلى المركز.

وبالتالي فإن هذه القضية البسيطة هي أن مجرد استخدام الدائرة رسائل من كل مكان إلى المركز.

الشيء الجميل في هذا appraoch هو أن satelites حتى لا تحتاج إلى معرفته حول هيكل قاعدة البيانات في المركز ، يمكن أن تكون مصممة تماما idepedently.

الحصول على أشياء أكثر إثارة للاهتمام إذا كنت في حاجة أيضا إلى التغييرات نسخا متماثلا من مركز إلى satelites.السؤال الكبير هو ما إذا كنا قد تحصل صراعات بين التغيرات في المركز التغييرات على قمر اصطناعي.

حالة بسيطة:أي عنصر بيانات واحد "الوطن".على سبيل المثال الأصلي قمر اصطناعي هو المكان حيث يتم إجراء تغييرات.أو بعد إنشاء المركز هو المكان الوحيد ti إجراء تغييرات.في هذه الحالة يمكننا علاج مركز باسم "المحور" ، فإنه يمكن نشر التغييرات إلى satelites.بسيطة الدائرة سوف تفعل ما يرام لذلك.

قليلا أكثر صعوبة الحالة:يمكن إجراء تغييرات في أي مكان, ولكن في مكان واحد فقط في كل مرة.ومن هنا يمكننا إدخال somne النوع إذا قفل المخطط.أنا أميل إلى أن يكون المركز مثل مالك و استخدام synchrnous ويب الخدمات قفل و تحديث البيانات.الآن نحن إلى جانب ، ولكن هذا ضروري إذا أردنا أن يكون نهائي مالك.

معقدة جدا الحالة:أي شخص يمكن أن يغير أي شيء في أي مكان من دون تأمين.انها نوع من "فعل أولا اعتذر في وقت لاحق" النهج.نأخذ متفائل النهج أن التغييرات لن اشتباك.يمكننا إرسال التغييرات للحصول على موافقة ومركز يمكن استخدام إما متفائل تأمين أو دمج غير متضاربة تغييرات النهج.أنا أميل إلى القيام بذلك من خلال الطوابير يغير المنشئ ، ولكن في الواقع معالجتها من خلال المكالمات المتزامنة.لذلك فصل مواصفات تغيير من توافر المركز.بعض أكثر تطورا قواعد البيانات مهرجان دبي السينمائي الدولي/دمج القدرات التي قد تساعد في هذا.

الأسئلة الكبيرة هي إلى أي مدى كنت تريد أن تكون إلى جانب توافر مركز احتمال تغييرات متعارضة.في كثير من الأحيان الماكرة تصميم التطبيق يمكن أن تقلل بشكل كبير من احتمال نشوب الصراعات.