और क्या कोई हैं? मेरे लिए, एमबी ग्राहकों और प्रकाशकों दोनों को जानता है और मध्यस्थ के रूप में कार्य करता है, नए संदेशों पर ग्राहकों को सूचित करता है (प्रभावी रूप से एक "पुश" मॉडल)। दूसरी ओर, एमक्यू एक "पुल" मॉडल से अधिक है, जहां उपभोक्ता संदेशों को एक कतार से खींचते हैं।
क्या मैं यहां पूरी तरह से ट्रैक हूं?
जवाबों:
द्वारा और बड़े, जब यह विक्रेता सॉफ्टवेयर उत्पादों की बात आती है, तो वे परस्पर विनिमय के लिए उपयोग किए जाते हैं, और आपके द्वारा बताए गए अनुसार पुश या पुल के रूप में मजबूत अंतर नहीं होते हैं।
बस बनाम कतार वास्तव में कुछ हद तक एक विरासत अवधारणा है, सबसे हाल ही में आईबीएम MQ और TIBCO मिलन स्थल की तरह सिस्टम से उत्पन्न होता है। एमक्यू मूल रूप से एक 1: 1 सिस्टम था, वास्तव में विभिन्न प्रणालियों को डिकॉप करने के लिए एक कतार।
इसके विपरीत तिब्को मैसेजिंग बैकबोन के रूप में बेचा गया था, जहां आपके पास एक ही विषय पर कई प्रकाशक और ग्राहक हो सकते हैं।
हालाँकि दोनों (और नए प्रतिस्पर्धी उत्पाद) इन दिनों एक-दूसरे के स्थान पर खेल सकते हैं। दोनों को नए संदेशों के लिए मतदान में बाधा डालने के लिए सेट किया जा सकता है। दोनों विभिन्न प्रणालियों के बीच बातचीत में मध्यस्थता करते हैं।
हालाँकि वाक्यांश संदेश-कतार का उपयोग आंतरिक इंट्रा-थ्रेड संदेश पंप और पसंद के लिए भी किया जाता है, और इस संदर्भ में, उपयोग वास्तव में अलग है। यदि आप क्लासिक विंडोज संदेश पंप के बारे में सोचते हैं, तो यह वास्तव में आपके द्वारा वर्णित पुल मॉडल से अधिक है, लेकिन यह वास्तव में इंटर-ऐप या इंटर-बॉक्स की तुलना में अधिक इंट्रा-ऐप है।
संदेश बस
एक संदेश बस एक मैसेजिंग इन्फ्रास्ट्रक्चर है जो विभिन्न प्रणालियों को इंटरफेस ( संदेश बस ) के साझा सेट के माध्यम से संवाद करने की अनुमति देता है ।
स्रोत: ईआईपी
संदेश कतार
एक संदेश कतार का मूल विचार एक सरल है:
दो (या अधिक) प्रक्रियाएं एक सामान्य सिस्टम संदेश कतार तक पहुंच के माध्यम से सूचना का आदान-प्रदान कर सकती हैं ।
भेजने की प्रक्रिया कुछ (OS) संदेश-पासिंग मॉड्यूल के माध्यम से एक कतार में एक संदेश भेजती है जिसे दूसरी प्रक्रिया द्वारा पढ़ा जा सकता है
स्रोत: डेव मार्शल
अंतर
संदेश पंक्ति में FIFO ( प्रथम में प्रथम ) नियम होता है जबकि संदेश बस में नहीं होता है।
निष्कर्ष
दोनों देखो दोनों के बीच संदेशों गुजर - काम का एक ही प्रकार के कर की तरह आवेदन या मॉड्यूल या इंटरफेस या सिस्टम या प्रक्रियाओं का छोटा सा फर्क को छोड़कर, फीफो
इन दो अवधारणाओं के बीच कुछ धुंधलापन आ गया है, क्योंकि कुछ उत्पाद अब ऐसी विशेषताओं का समर्थन करते हैं जो पहले केवल एक या दूसरी श्रेणी से संबंधित थीं (उदाहरण के लिए एज़्योर सर्विस बस दोनों दृष्टिकोणों का समर्थन करती है)।
एक संदेश कतार एक एप्लिकेशन से संदेश प्राप्त करती है और उन्हें पहले-पहले-आउट (FIFO) तरीके से एक या अधिक अन्य अनुप्रयोगों के लिए उपलब्ध कराती है। कई वास्तुशिल्प परिदृश्यों में, यदि एप्लिकेशन ए को बी और सी के लिए अपडेट या कमांड भेजने की आवश्यकता है, तो बी और सी के लिए अलग-अलग संदेश कतारें स्थापित की जा सकती हैं। ए प्रत्येक कतार में अलग-अलग संदेश लिखेंगे, और प्रत्येक आश्रित आवेदन इसके से पढ़ेगा। खुद की कतार (संदेश को हटाए जाने पर हटाया जा रहा है)। अपडेट भेजने के लिए A के लिए न तो B और न ही C उपलब्ध होना चाहिए। प्रत्येक संदेश कतार निरंतर है, इसलिए यदि कोई अनुप्रयोग पुनरारंभ होता है, तो वह ऑनलाइन वापस होते ही अपनी कतार से खींचना शुरू कर देगा। यह निर्भर प्रणालियों के बीच निर्भरता को तोड़ने में मदद करता है और अनुप्रयोगों को अधिक मापनीयता और दोष सहिष्णुता प्रदान कर सकता है।
एक संदेश बस या सेवा बस एक या अधिक अनुप्रयोगों के लिए संदेश भेजने के लिए एक (या अधिक) अनुप्रयोग के लिए एक रास्ता प्रदान करती है। पहले-में-पहले ऑर्डर करने की कोई गारंटी नहीं हो सकती है, और बस के सदस्य संदेश भेजने वालों के ज्ञान के बिना आ सकते हैं और जा सकते हैं। इस प्रकार, एक संदेश बस के माध्यम से आवेदन बी के लिए स्थिति अपडेट को संप्रेषित करने के लिए एक एप्लिकेशन ए लिखा जा सकता है। बाद में, एप्लिकेशन सी लिखा जाता है जो इन अपडेट से भी लाभान्वित हो सकता है। एप्लिकेशन C को संदेश ए को सुनने और इन अपडेट के आधार पर कार्रवाई करने के लिए कॉन्फ़िगर किया जा सकता है, साथ ही आवेदन के लिए कोई भी अपडेट की आवश्यकता नहीं है। क के विपरीत, जहां भेजने वाला एप्लिकेशन स्पष्ट रूप से हर कतार में संदेश जोड़ता है, संदेश बस एक प्रकाशन का उपयोग करता है / सदस्यता मॉडल। संदेश बस में प्रकाशित किए जाते हैं, और उस तरह के संदेश को सदस्यता लेने वाले किसी भी आवेदन को प्राप्त होगा।
मुख्य अंतर जो वास्तव में अन्य उत्तरों में स्पष्ट रूप से उल्लेख नहीं किया गया है, वह यह है कि एक संदेश बस कई ग्राहकों के लिए अनुमति देता है जबकि एक कतार एक-एक करके किसी भी चीज को सुनने के लिए एक-एक आइटम को हटा देगा। यदि आप एक से अधिक श्रोताओं को कतार से बाहर आते देखना चाहते हैं तो आपको खुद को संभालना होगा, एक सर्विस बस आपके लिए यह बॉक्स से बाहर कर देगी।
जिस तरह से मैं देख रहा हूँ कि संदेश कतार संदेश बस बनाता है । ग्राहक (यानी नोड) तब संदेश बस को सुन सकते हैं। यह उस मामले के लिए विशेष रूप से सच है जहां आपके पास यूडीपी के माध्यम से एक एमक्यू प्रसारण संदेश हैं, दूसरे शब्दों में, यह बिना जाने या परवाह किए एक प्रसारण / मल्टीकास्ट पते पर संदेश भेज रहा है जो उन्हें मिलने वाला है। इस परिदृश्य के अधिक गहन विवरण के लिए आप इस लेख को देख सकते हैं ।
सेवा बस एक संदेश कतार की तुलना में अधिक सामान्य शब्द है।
एमक्यू एक सरल एफआईएफओ है, लेकिन सर्विस बस यानी एक इवेंट हब को लागू करने के लिए अधिक परिष्कृत तरीके हैं, जो संदेशों में हेरफेर करने के लिए एक विशाल "केंद्र" है। एमक्यू द्वारा प्रदान की गई कार्यक्षमता के अलावा, यह संदेशों को संग्रहीत करने की अनुमति देता है (और इसलिए कई ग्राहकों का उपयोग करके) आदि
एक संदेश बस वितरण का 1 से कई मॉडल है। इस मॉडल में गंतव्य को आमतौर पर विषय या विषय कहा जाता है। एक ही प्रकाशित संदेश सभी उपभोग्य ग्राहकों द्वारा प्राप्त किया जाता है। आप इसे 'प्रसारण' मॉडल भी कह सकते हैं। आप किसी विषय को वितरित कंप्यूटिंग के लिए ऑब्जर्वर डिजाइन पैटर्न में विषय के बराबर मान सकते हैं। कुछ संदेश बस प्रदाता कुशलतापूर्वक इसे टीसीपी के बजाय यूडीपी के रूप में लागू करना चुनते हैं। विषय के लिए संदेश वितरण 'फायर-एंड-भूल' है - यदि कोई नहीं सुनता है, तो संदेश बस गायब हो जाता है। यदि वह नहीं है जो आप चाहते हैं, तो आप 'टिकाऊ सदस्यता' का उपयोग कर सकते हैं।
एक संदेश कतार संदेशों का 1 से 1 गंतव्य है। यह संदेश केवल एक उपभोग्य रिसीवरों द्वारा प्राप्त किया जाता है (कृपया ध्यान दें: 'विषय ग्राहक के लिए लगातार ग्राहकों का उपयोग करके और कतार ग्राहक के भ्रम के लिए रिसीवर) भ्रम से बचते हैं। किसी कतार में भेजे गए संदेश डिस्क या मेमोरी पर संग्रहीत किए जाते हैं जब तक कि कोई इसे उठाता या समाप्त नहीं करता। इसलिए कतारों (और टिकाऊ सदस्यता) को कुछ सक्रिय भंडारण प्रबंधन की आवश्यकता है, आपको धीमे उपभोक्ताओं के बारे में सोचने की आवश्यकता है।
अधिकांश वातावरण में, मैं तर्क देता हूं, विषय बेहतर विकल्प हैं क्योंकि आप वास्तुकला को बदलने के बिना हमेशा अतिरिक्त घटक जोड़ सकते हैं। जोड़े गए घटक निगरानी, लॉगिंग, एनालिटिक्स आदि हो सकते हैं। आप इस परियोजना की शुरुआत में कभी नहीं जानते कि 1 वर्ष, 5 वर्ष, 10 वर्ष में क्या आवश्यकताएं होंगी। परिवर्तन अपरिहार्य है, इसे गले लगाओ :-)