ما المقصود بناقل خدمة المؤسسة (ESB)؟

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

عادةً ما يتم تنفيذ نمط ناقل خدمة المؤسسة (ESB) باستخدام وقت تشغيل تكامل ومجموعة أدوات مصممة خصيصًا (أي ESB) تضمن أفضل إنتاجية ممكنة.

يُعَد ESB مكونًا أساسيًا في البنية المعتمدة على الخدمات (اختصارًا SOA)، وهي بنية برمجية ظهرت في أواخر التسعينيات.تحدِّد SOA طريقة لجعل عناصر البرمجيات قابلة لإعادة الاستخدام عبر واجهات الخدمة. وعادةً ما تستخدم هذه الخدمات واجهات قياسية (أي، خدمات الويب) بطريقة يمكن دمجها بسرعة في التطبيقات الجديدة دون الحاجة إلى تكرار الوظائف التي تؤديها الخدمة في التطبيقات الجديدة.

تجسد كل خدمة في SOA التعليمات البرمجية والبيانات المطلوبة لتنفيذ وظيفة عمل كاملة ومنفصلة (على سبيل المثال: التحقق من رصيد العميل، أو حساب الدفعة الشهرية للقرض، أو معالجة طلب الرهن العقاري). توفِّر واجهات الخدمة اقترانًا فضفاضًا، ما يعني أنه يمكن استدعاؤها دون معرفة تُذكَر أو دون معرفة تمامًا بكيفية تنفيذ الخدمة تحتها، ما يقلل من التبعيات بين التطبيقات. يمكن كتابة التطبيقات الموجودة خلف واجهة الخدمة بلغة Java أو Microsoft .Net أو Cobol أو أي لغة برمجة أخرى. يمكن أن تتوفر كتطبيقات مؤسسة مجمعة من قِبَل المورد (مثل SAP) أو كتطبيقات SaaS (مثل Salesforce CRM) أو يمكن الحصول عليها كتطبيقات مفتوحة المصدر.

يتم تعريف واجهات الخدمة بشكل متكرر باستخدام لغة تعريف خدمة الويب (WSDL) التي تعتمد على xml (لغة ترميز قابلة للتوسيع) وهي بنية علامات قياسية. يتم عرض الخدمات باستخدام بروتوكولات الشبكة القياسية - مثل SOAP (بروتوكول الوصول إلى الكائنات البسيطة) / HTTP أو JSON / HTTP - لإرسال طلبات لقراءة البيانات أو تغييرها. تتحكم عناصر التحكم في حوكمة الخدمات في دورة حياة التطوير، وفي المرحلة المناسبة يتم نشر الخدمات في سجل والذي يمكِّن المطورين من العثور عليها بسرعة وإعادة استخدامها لتجميع تطبيقات أو عمليات أعمال جديدة.

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

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

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

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

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

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

للتعمق أكثر في صعود وهبوط ناقل خدمة المؤسسة (ESB)، اقرأ "The fate of the ESB".

تُتيح بنية البرمجيات المصغّرة تقسيم مكونات التطبيق الواحد إلى وحدات صغيرة يمكن تغييرها وتوسيع نطاقها وإدارتها بشكل مستقل. برزت البرمجيات المصغرة واكتسبت زخمًا مع صعود كل من المحاكاة الافتراضية، والحوسبة السحابية، وممارسات التطوير المرن (Agile)، وعمليات التطوير (DevOps). في هذه السياقات، تقدِّم الخدمات المصغرة ما يلي:

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

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