ما هي أفضل طريقة لمزامنة البيانات بين الأنظمة المنفصلة؟

Question

لنفترض أن هناك نظامين منفصلين بالكامل (لكنهما سيصبحان أكثر في المستقبل):النظام أ والنظام ب

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

لنفترض أنني بحاجة إلى تصدير جزء من المعلومات من النظام أ إلى النظام ب.أريد بعد ذلك تصدير نفس المعلومات من النظام "ب" وإعادة استيرادها إلى النظام "أ" وأحتاج إلى أن أكون قادرًا على التعرف على أنها نفس المعلومة.

ما هي أفضل طريقة للقيام بذلك في تجربة الناس؟

وهذا ما أفكر في القيام به:

1. إعداد ناقل رسائل بين الأنظمة مع قوائم انتظار الرسائل.
2. إعداد نقاط النهاية لكل نظام التي ستراقب التغييرات و إنشاء أوامر ملفوفة في الرسائل التي سيتم ضخها في قوائم الانتظار (على سبيل المثال عندما يكون جزء من المعلومات تم إنشاؤها / حذفها / تحديثها).
3. تعيين رتب لنقاط النهاية بالنسبة إلى إنشاء / حذف / تحديث الأوامر من أجل عدم الاعتماد على أسماء النظام ولكن فقط على عام التسلسل الهرمي - بحيث كل نظام لا يحتاج إلى معرفة المزيد عن الاخرين.
4. تعيين متعدي على تحديث / حذف / إنشاء أمر لكل منها نقطة النهاية بحيث لا الأوامر تلبية متطلبات التعدي سيتم تصفيتها وليس معالجه

لن يحل هذا حقيقة أنني ما زلت بحاجة إلى حمل originalSource+originalSourceID بالرغم من ذلك.

أي مساعدة موضع تقدير.

Answer 1

تمت معالجة هذه المشكلة من قبل بائعي EAI (تكامل التطبيقات المؤسسية) مثل تيبكو و webMethods (الآن جزء من Software AG).لم أستخدم Tibco من قبل مطلقًا، ولكنني استخدمت webMethods لحل هذا النوع من المشكلات، لذا سأركز فقط على webmethods.على سبيل المثال، في إحدى المؤسسات، يمكن أن توجد البيانات المتعلقة بالموظفين في كل من Active Directory وPeopleSoft.يمكن استخدام webMethods لضمان أن التغييرات والإضافات والحذف في نظام واحد (التطبيق) سوف تنعكس في النظام الآخر في الوقت الفعلي.في بعض المؤسسات الأخرى، يمكن أيضًا أن تكون البيانات المتعلقة بالموظفين موجودة في قاعدة بيانات Oracle أو SQL Server.مرة أخرى، ليست مشكلة.يمكن لأدوات EAI مثل webMethods التحدث إلى مجموعة واسعة من الواجهات الخلفية.لا تقتصر webMethods على مصدر واحد وهدف واحد، ولكن نظرًا لاحتوائها على بنية للنشر والاشتراك، يمكن أن تتدفق البيانات من مصدر واحد إلى أهداف مهتمة متعددة تشترك في جزء معين من المعلومات.التسليم مضمون ويمكن العثور على ميزات أخرى في هذه المنتجات.وبالعودة إلى مثال الموظف، في نهاية المطاف، إذا قام الشخص بذلك بشكل صحيح، في أي وقت من الأوقات، يمكن لجميع الأنظمة والتطبيقات في المؤسسة أن تحتوي على نفس المعلومات حول الموظفين دون أي تناقض.

لذا، بدلًا من البرمجة بلغة C# أو Java، ستقوم ببرمجة webMethods والتي تشبه إلى حد كبير لغة 4GL.أسميها برمجة لأنه لا يزال هناك منطق متضمن، حلقة، إذا كان الأمر كذلك، فرع، متغيرات، حزم، وما إلى ذلك ولكنها موجهة نحو الإجراءات، أي.لا يوجد مفهوم OOP على الإطلاق.

تم تصميم أدوات EAI هذه مع وضع أغراض محدودة في الاعتبار وأحد الأغراض هو مزامنة البيانات بين الأنظمة المختلفة في المؤسسة بسهولة.وهم يقومون بعملهم بشكل جيد للغاية.

العيب هو أن هذه الأدوات تكلف الكثير من المال.غالبًا ما يكون لدى الشركات استراتيجية طويلة المدى قبل الاستثمار في هذه الأدوات.

Answer 2

كما كتب أحدهم بالفعل، يبدو هذا وكأنه مشكلة EAI نموذجية.حتى لو كانت أدوات EAI باهظة الثمن، فهناك الآن مجموعة واسعة من الأدوات المجانية مفتوحة المصدر.أدناه قائمة من أحب أكثر

1. أوبنESB
2. بغل
3. أباتشي سيرفيس ميكس
4. اباتشي الجمل

المفضل لدي هو OpenESB، وأنا أعرفه جيدًا، فهو يحتوي على IDE كامل (Netbeans)، ودعم اختياري من بائع كبير و كمية كبيرة من المكونات الإضافية.نظرًا لبساطته وفعاليته، فأنا أحب Apache Camel، ولكن يمكنك تجربة بعض منها وتحديد أي منها يناسبك بشكل أفضل.ثم يمكنك حتى أن تقرر شراء خدمات الدعم لكل هؤلاء.

Answer 3

نحن نقوم تقريبًا بالنوع A -> B -> الشيء الذي تصفه.لقد فكرنا في البداية في محاولة جعل جميع العناصر A وB وC وما إلى ذلك من أقران، لكن ذلك كان صعبًا للغاية، لذلك قمنا الآن بتعيين أحدهم على أنه السيد والآخرون على أنهم العبيد.لا يزال من السهل نقل الأشياء من عبد إلى آخر، ولكن عن طريق السيد.

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

لذا فإن الكود متطابق في كل نظام.العبيد فقط هم الذين يتصلون بالمنزل.

تخبر عمليات التصدير والاستيراد كائنات الأعمال ذات الصلة بتنفيذ جميع عناصر القائمة والحفظ، نظرًا لأنهم يعرفون بالفعل كيفية إنشاء مثيل واستمرار أنفسهم من DataRows.

إنها ليست بنية متعددة عشرات المعاملات في الثانية، ولكنها تعمل ويمكنها تحقيق التزامن في الوقت الفعلي تقريبًا.

بالمناسبة، لم نقم بتحسين تفرد المصدر/المعرف :)

Answer 4

يتم تبسيط هذا إلى حد كبير إذا قمت بتعيين GUID لكل جزء من المعلومات.إذا كنت بحاجة إلى تتبع المصدر والمعرفات الأخرى، فلا بأس بذلك، ولكن يجب أن تنتقل المعلومات دائمًا باستخدام المعرف الفريد العمومي (GUID) المخصص لها.

عندما يرى الجهاز تلك المعلومات مرة أخرى، فإنه سيرى المعرف الفريد العمومي (GUID) ويربطه بالبيانات الموجودة، وبعد ذلك يمكنك أن تقرر ما يجب فعله.لكنك تعلم بالفعل أنها نفس قطعة البيانات - ولكن من الأفضل السفر.

ضع في اعتبارك أنه يتم إنشاء المعرفات الفريدة العمومية (GUIDs) بطريقة تجعل كل جهاز ينشئ جهازًا خاصًا به ولن يتعارض (لجميع الأغراض والأغراض العملية) مع المعرفات الفريدة العمومية (GUIDs) التي تم إنشاؤها على جهاز آخر، أو نفس الجهاز في وقت مختلف.

يعد هذا أحد الأسباب الأكبر وراء إنشاء المعرفات الفريدة العمومية (GUIDs).

-آدم

Answer 5

ما لم يكن هناك بعض القيود المحددة في تصميم النظام التي تمنع ذلك، فإنني أقترح أخذ المعلومات المشتركة/القابلة للمشاركة في الاعتبار في قاعدة بيانات منفصلة يمكن للاثنين الآخرين الرجوع إليها أو تكرارها محليًا.إذن فأنت لا تحتاج إلى المفتاح ثنائي العنصر ولا إلى أي أداة ESB معقدة...