هل دمج ESB (ServiceMix/Mule) يستحق منحنى التعلم؟ [مغلق

Question

أنا أبحث في دمج ESB في منتج قائم على الويب Java/Maven الحالي. على وجه التحديد ، أنا أبحث في Servicemix و Mule. سيتصل المنتج بالعديد من الخدمات المختلفة ، بما في ذلك البريد الإلكتروني والكوارتز وخدمات الويب المريحة عبر HTTP و SMS و IM. لقد ألقيت نظرة سريعة على الوثائق بسرعة ويبدو أن الخيارين ثقيلًا جدًا ومعقدًا إلى حد ما. يبدو أنه مثال على كتاب مدرسي لموعد استخدام ESB ، لكنني لا أريد أن أقضي وقتًا طويلاً فقط في تعلم واحد أو نظام آخر.

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

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

Answer 1

Mule سهل الاستخدام للغاية فيما يتعلق بتوصيل الخدمات مع XML ولديهم الكثير من أمثلة الفيديو التي وجدتها مفيدة حقًا.

من المفترض أن تكون ESBs مستقبلية وكما تقول - يبدو لك مثالًا للكتاب المدرسي على مكان استخدامه.

سأحاول الإجابة على جميع أسئلتك:

هل يستحق محاولة سحب أحد هذه الخيارات؟أعتقد أن هذا سؤال تحتاج إلى طرحه على نفسك - ما الذي تحاول تحقيقه؟ إذا كنت تحاول تسهيل تنفيذها ، فربما يستغرق الأمر نفس الوقت عبر الكود النقي أو ESB ، ما هو مع جميع الإعدادات المدرجة. إذا كنت تفكر في القيام بذلك كتمرين تعليمي ، فقد يكون ذلك جديراً بالاهتمام.

هل هناك طريقة سهلة لدمجها في تطبيق موجود دون إعادة هيكلة بالكامل؟إجابة قصيرة لا. ستحتاج إلى بعض إعادة الهندسة للاندماج مع معظم المكتبات/الأطر من الطرف الثالث.

هل هناك خيارات أخرى أخف وزنا؟البغل بسيط جدا حقا. قد تكون قادرًا على استخدام MQ للقيام بـ HTTP و SMS و IM. ربما ActiveMq أو rabbitmq.

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

Answer 2

قد ترغب أيضًا في إلقاء نظرة على إطار عمل Apache Camel الذي يعد قويًا حقًا لجميع احتياجات التكامل التي ذكرتها دون عقوبات ESB بالكامل.

Answer 3

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

Answer 4

أنصحت بعدم إضاعة وقتك الثمين مع Mule. تجربتي حتى الآن ليست جيدة. لن أستخدمه لأي نظام حرج. إنه بعيد عن كونه منتجًا ناضجًا. بصرف النظر عن تلك الخدمات المريحة تعد بالتأكيد بالكثير من البساطة ولديها حالات استخدام حقيقية.

Answer 5

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

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

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

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