باستخدام JMS أو ThreadPool لإرسال رسائل البريد الإلكتروني

Question

أود أن أعرف:

لدي سيناريو. إذا أضاف المستخدم منتجًا إلى النظام (أنا أتطور) ، فهناك مستمع يرسل إشعارًا إلى قاعدة عملاء المستخدم لإخطار منتج جديد أضافه المستخدم.

لقد قرأت هذا مسلك و (رؤية أنني لم أستخدم أبدًا JMS ولا ThreadPool من قبل) كنت أتساءل عما إذا كان ينبغي علي استخدام JMS أو ThreadPooling.

أنا أستخدم Tomcat 5.5 و أعلى و JBoss 5 وأعلى (اعتمادًا على الشركة الأخيرة) لنشر تطبيق الويب الخاص بي.

إذا استخدمت JMS ، فهل أستخدمها Apache ActiveMq أو مراسلة jboss؟ هل كلاهما متوافقان مع تشغيل كلا المنصتين (Tomcat و JBoss)؟

شكرا لك مقدما.

Answer 1

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

ActiveMQ هو وسيط رسائل يستخدم على نطاق واسع يوفر واجهات برمجة التطبيقات العميل لـ Java و C/C ++ و C#و Perl و Php و Python و Ruby والمزيد. هذا يسمح باستخدام JMS مع التطبيقات المكتوبة في Java ولغات أخرى.

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

لمعرفة مدى سهولة إرسال الرسائل باستخدام Spring JMS ، تحقق من منشور مدونة كتبته مؤخرًا بعنوان باستخدام الربيع jmstemplate لإرسال رسائل JMS. أنا أعمل أيضًا على منشور مدونة حول تلقي الرسائل باستخدام SPRING JMS.

لو كانت لديك اي اسئلة اضافية فاخبرني.

بروس

Answer 2

كان لدي متطلبات مماثلة مرة واحدة ، واستخدمنا JMS. ثم كانت المشكلة الرئيسية هي كيفية التعامل مع الأخطاء لأن SMTP ليست في الواقع معاملات:

1. هل هو موافق إذا فقدت بعض البريد الإلكتروني؟
2. هل هو موافق إذا تم إرسال بعض البريد الإلكتروني مرتين؟

قررنا أنه من الأفضل إرسال الرسالة مرتين ، وهنا أكثر أو أقل من التصميم الذي كان لدينا:

1. اعتمدنا على المعاملة المدارة للحاويات ، وإذا لم يكن من الممكن إرسال البريد الإلكتروني لسبب ما ، فقد قررنا التراجع عن معاملة JMS ؛ سيتم إعادة توجيه الرسالة لاحقًا بواسطة JMS وتم إجراء محاولة جديدة لإرسال الرسالة.

2. إذا فشلت معاملة تسليم رسالة JMS بعد إرسال البريد الإلكتروني (على سبيل المثال بسبب مشكلة في JMS) ، سيتم إعادة المعاملة تلقائيًا وتم إعادة توجيه الرسالة لاحقًا. في هذه الحالة ، تم إرسال البريد الإلكتروني مرتين لأن STMP ليس معاملات.

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

لكننا كنا بالفعل نستخدم JMS. لن أقدم JMS فقط لتلك بالنظر إلى أن الحجة الرئيسية هي أن JMS هي المعاملات ، لكن SMTP ليست على أي حال.

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

Answer 3

أعلم أن هذا الرد متأخر جدًا على هذا التغلب ، لكنني آمل أن يظل ذلك ذا قيمة للأشخاص الذين يبحثون عن معلومات حول دمج ActiveMQ و Tomcat.

لقد طلبت مني الكثير من الناس المساعدة في القضايا التي قاموا بدمجها ActiveMQ و Tomcat ، لذلك قررت كتابة بعض المقالات حول هذا الموضوع. ليس هذا الموضوع مغطى فقط ActiveMq في العمل (انظر الفصل 8) ، لكنني نشرت أيضًا سلسلة من المقالات على عنوان ActiveMq و Tomcat: شركاء مثاليان. نأمل أن يجد الناس هذا مفيدًا.

Answer 4

سأذهب للحصول على JMS المستمر (لقد استخدمت فقط WLS JMS و WebSphere MQ ، لذلك لا يمكنني مقارنة AQ vs JBOSS ، أيهما يوفر ضمانًا أفضل للتسليم). أيضًا ، سأفكر بجدية في جعل محرك البريد الإلكتروني تطبيقًا منفصلًا تمامًا ، اعتمادًا على المبلغ الذي تتوقع أن تنمو فيه حركة المرور.