هل تنسيق مسؤولية ESB؟

Question

هو حافلة خدمة المؤسسة (أداة تعمل كوسيط ، وسيط رسائل ، وعامل تمكين للخدمات ، ومحسن تحويل المخطط ، ومزود موقع شفاف ، ومجمع الخدمة ، وموازن التحميل ، والمراقبة ، وكل تلك الأشياء) مسؤول عن تنظيم الخدمات?

ماذا عن وضع عملية تجارية تلقائية مع أكثر من ألف خطوة وعشرات من دعوات الخدمة داخل حافلة خدمة المؤسسات الخاصة بك؟

هل ستفعل ذلك ، أم ستستخدم أخصائيًا في التزامن مثل محرك BPEL؟

من فضلك احرز رأيك.

Answer 1

نعم و لا. هناك خط رفيع ، وأحيانًا لا يمكن تمييزه بين التزامن وتجميع/تكبير الخدمة.

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

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

لا يستحق فقدان الكثير من النوم ، رغم ذلك

إخلاء المسئولية: أنا مستشار IBM ESB ، على الرغم من أنني لا أكتب هذا بصفته الرسمية.

Answer 2

لا ، إن مسؤولية ESB ليست هيئة الخدمات (في حد ذاتها). يوفر ESB طبقة من التجريد في "مستوى البنية التحتية للبرامج".

هذا يعني أن ESB هو "منفذ استدعاء منطقي واحد للاتصال" مع أي خدمة يتم نشرها في الحافلة.

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

هذا يعني بعض التنسيق: يوفر ESB تزامن للخدمات المنخفضة المذكورة أعلاه (على سبيل المثال عندما يتم استدعاء الخدمة X عبر IIOP ، قم بترجمة هذا إلى الصابون. ثم قم بتحويل الطلب من أي بيانات متسلسلة إلى حمولة XML).

إن التزامن الذي تتجنبه عادة في ESB هو: من أجل معالجة هذا البيع (التأمين) ، نحتاج أولاً إلى التحقق من المعلومات التي يقدمها المشتري ، ثم نحتاج إلى ضمان مخاطر التأمين ، وأخيراً حساب القسط الذي يحتاج ليتم الدفع مقابل التأمين ، وبعد ذلك نحتاج إلى ... إلخ.

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

إن خدمات الأعمال (مثل التحقق من الصحة ، والضمان ، وحساب الأقساط) التي تشكل عملية تجارية (مثل بيع التأمين) ، وهو ما يشار إليه عادةً باسم التزامن ، هو الأنسب للحدوث في محرك عملية تجارية ومعرفته باستخدام عملية أعمال رسمية لغة النمذجة (مثل BPEL).

قم أيضًا بتخمين العديد من الخطوات في عمليتك: في المثال أعلاه ، فإن التحقق من الصحة هو خدمة (حبيبية للدورة). قواعد التحقق من الصحة نفسها داخلية لتلك الخدمة. بالنسبة لقواعد العمل المعقدة (أي عملية الأعمال) ، قد يكون استخدام محرك قواعد العمل مطلوبًا.

Answer 3

إجابتي السريعة القصيرة هي لا ، هذا ليس مسؤولية.

أود أن أترك ذلك إلى BPEL أو جناح BPM.

MHH لا أعرف ماذا أضيف :) ... حظا سعيدا؟

Answer 4

الآن رؤيتي الخاصة.

فيما يتعلق بجميع العمل الذي يتعين على ESB القيام به ، فإن وضع خدمة الخدمة داخل عنصر البنية التحتية الرئيسية في الخدمية الخاص بك ليس فكرة جيدة.

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

بعد كل شيء، معظم ESBs مثل خدمة Bea Aqualogic دعم محدود للتنسيق بما فيها عدم وجود دولة القدرات ، والأنشطة مثل الانتظار (مؤقت) أو اختيار (انتظر بعض المدخلات للتنقل في العملية) ، وقدرات الانقسام/الانضمام (تمت إضافتها بالفعل على ALSB 3.0) ، وما إلى ذلك.

مستحيل. ما عليك سوى استخدام أدوات مثل محرك BPEL أو أداة مثل تكامل WebLogic.

شكرًا.

Answer 5

كلما كان لديك خدمتان أو أكثر تتفاعل مع استخدام Orchestrator للخدمة ، أي لخدمات التكوين والتحكم في العمليات. إذا كان لديك ESB فضح خدمة التكوين هذه على ESB. الآن إذا كان عليك إنشاء خدمة جديدة تتضمن خدمة التكوين هذه ، فاستخدم Orchestrator و ESB مرة أخرى على ESB. استخدم ESB كآلية تقديم الخدمات ووساعد خدمة الويب والوكالة. في تأليف Orchestrator للخدمة ، ستستخدم ESB للوصول إلى خدمات التفاعل. إذا كانت هذه الخدمات المتفاعلة تستخدم مخططات XML غير المتوافقة ، يمكن لـ ESB تحويلها/رسم خريطة لها إلى مخطط مشترك في طلبات الخدمة والمسار بناءً على المحتوى ، على سبيل المثال مساحة الاسم.

Answer 6

نعم ، التزامن هو مسؤولية ، في معظم الحالات ، من ESB. أو بدلاً من ذلك ، إذا قمت برسم خط بين ESB Infra و Orchestration Infra ، فأنت تفعل ذلك على المستوى المادي لأسباب الأداء ، وليس للإسناد المنطقي للمسؤولية.

لديك خياران - عندما يتلقى نظام الموارد البشرية ، على سبيل المثال ، موظفًا جديدًا - أين تضع منطق العمل الذي يقول "سيحتاج قسم الامتثال إلى الموافقة والتحقق أولاً ، ثم إذا كان ذلك على ما يرام ، فسيحتاج قسم الموارد البشرية لوضع اللمسات الأخيرة على التوظيف ، سيحتاج قسم المحاسبة إلى إدخال جديد ، ثم سيحتاج نظام كشوف المرتبات إلى التحديث ، وإذا فشل ذلك ، فسنحتاج إلى إرسال بريد إلكتروني إلى HR "؟ إذا تم اعتبار جميع العمليات التجارية "مملوكة" من قِبل قسم/التطبيق ، فإن النظام العام الذي هو المؤسسة يصبح معقدًا ، مع أنظمة تزامن متباينة.

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

Answer 7

يجب ألا تكون حافلة خدمة المؤسسات مسؤولة أبدًا عن تنظيم الخدمات.

ينطوي التزامن على الحد الأدنى من "الذكاء" ، وتحديدا القدرة على التعويض عن المعاملات الفاشلة. غالبًا ما تقول أدوات حافلة الخدمة أنها توفر "Try-Catch" أو شيء من هذا القبيل ، لكن القدرة على تشغيل المكونات الناطفية هي علامة على أداة تزامن مناسبة. بالإضافة إلى ذلك ، فإن القدرة على الانتظار ، أو معرفة حالتها الخاصة ، أو الحفاظ على الأمور في حالة تشويق هي مؤشر آخر على أنك تتعامل مع أوركستور وليس حافلة.

التحدث إلى 1000+ خطوة بالإضافة إلى عشرات الخدمات ، فكر في IF-Then في هذه العملية. إذا كانت جميع العبارات IF-Then في خطوة 1000 خطوة تتابع فقط إلى التوجيه دون أي تغيير إلى الحمولات ، فأنت لا تزال في "التوجيه" وبالتالي لا تزال في ESB. ولكن إذا كان هناك واحد متداخل إذا وبدأت في البحث عن أدوات مختلفة. وبصرف النظر عن ذلك ، يمكن أن تؤثر ذلك على أن تكون التوجيهات تؤثر بسرعة كبيرة على منطق العمل. بمجرد أن يبدأ منطق العمل في الظهور ، تكون لغة أفضل مثل BPEL أو BPMN أفضل.

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

على سبيل المثال ، تخيل أن موصلنا الأول يذهب إلى جلب لاعب توبا ، لكنه قال إن لاعب توبا قد قرر القيام بشيء آخر. ستجلب "Orchestrator" البسيط على غرار الكرة والدبابيس قسم Tuba ، مع العلم جيدًا أنه ليس موجودًا ، ثم انتظر حتى يشتكي الجمهور لاحقًا. سيشهد موصل ذكي حقًا أن طوبا قد انتهى ، ويحضر على الفور قرون الباريتون الأعمق للتعويض.