"संदेश पासिंग" प्रणाली बनाम "इवेंट आधारित" प्रणाली के गुण

Question

मेरा प्रश्न कुछ अशिक्षित दृष्टिकोण से आ रहा है।

एक " संदेश पासिंग " प्रणाली बनाम एक " घटना आधारित " प्रणाली के सापेक्ष गुण क्या हैं ।

कोई एक को दूसरे पर क्यों चुनेगा? उनकी ताकत और कमजोरियां क्या हैं?

मैं न केवल "सिद्धांत रूप में" जानना चाहता हूं, बल्कि "व्यवहार में" भी।

संपादित करें:

विशिष्ट समस्या :

मैं प्लग-सक्षम घटकों की प्रणाली का निर्माण करना चाहता हूं जो छोटे पैमाने की सेवाओं के रूप में व्यवहार करता है (प्रत्येक कुछ छोटे कार्य करने या कुछ जानकारी प्रदान करने के लिए)।

सेवाएं कर सकते हैं:

• स्तरित होना चाहिए ताकि एक सेवा का आउटपुट दूसरे के इनपुट के रूप में कार्य कर सके
• इसमें समालोचना पदानुक्रम होते हैं, ताकि एक विशिष्ट इनपुट-आउटपुट संबंध के बिना एक सेवा को दूसरे द्वारा निहित किया जा सके जैसा कि पिछले वाक्य में उल्लेख किया गया है

सिस्टम का लक्ष्य किसी अन्य सिस्टम में निम्न स्तर की घटनाओं के एकल प्रवाह को उच्च स्तर की जानकारी और कार्यक्षमता में अनुवाद करना है, और इसके अलावा घटनाओं की एक श्रृंखला प्रदान करने वाले अन्य सिस्टम को एक चैनल वापस प्रदान करता है।

यदि यह पर्याप्त नहीं है तो मैं और अधिक विवरण प्रदान कर सकता हूं।

कुछ और आसपास देखने के बाद। यह और यह शायद मेरी स्थिति का बेहतर वर्णन करता है।

ऐसा लगता है कि यह मेरी स्थिति के लिए अच्छा हो सकता है: http://akka.io/

Comments

आपको कुछ संदर्भ प्रदान करने की आवश्यकता होगी। अक्सर घटना आधारित सिस्टम एक संदेश गुजरने वाले मॉडल के माध्यम से आधारित होते हैं, और शैतान विवरण में होते हैं। C # उदाहरण के लिए, एक संदेश पासिंग मॉडल निष्पादन को एक अलग थ्रेड पर मौजूद होने की अनुमति देता है, जहां-जैसे ईवेंट को कॉलिंग थ्रेड पर ट्रिगर किया जाता है।

— तेलस्टिन

मैं विशेष रूप से अपनी परियोजना के विवरण के आधार पर प्रश्न पूछ सकता हूं, हालांकि मैं इसे सामान्य रूप से पर्याप्त बनाना चाहता था ताकि यह मेरे लिए लागू न हो।

— सिल्वानार

जैसा कि @Telastyn ने टिप्पणी की - "संदेश पास करना" और "घटना आधारित" परस्पर अनन्य नहीं हैं।

— ऊद

हालांकि, घटना आधारित के रूप में वर्णित शब्दार्थ के बीच एक प्रवृत्ति है और जिन्हें संदेश पारित होने के रूप में वर्णित किया गया है , उनका व्यवहार किसी भी सिस्टम के लिए विशिष्ट होगा। आपको केवल संदेश पास करने के सिस्टम के अवलोकन में दिए गए विकल्पों की संख्या को देखना होगा ताकि यह देखा जा सके कि साधारण घटनाओं और कुछ संदेशों के बीच बहुत कम अंतर है , लेकिन अन्य संदेशों के शब्दार्थ पूरी तरह से अलग हो सकते हैं। आपको यह बताने की जरूरत है कि आप किस समस्या को हल करने की कोशिश कर रहे हैं ।

— मार्क बूथ

Answer 1

मेरे अनुभव में एकमात्र विशिष्ट अंतर यह है कि अधिकांश संदेश पासिंग सिस्टम में, संदेश भेजने वाले को संदेश का पता (और अक्सर घोषित) होता है कि संदेश प्राप्तकर्ता कौन है।

इसलिए एक घटना को बढ़ाने और जो कोई भी इस घटना के लिए आत्महत्या कर रहा है, प्रेषक प्राप्तकर्ता के कुछ आईडी या तार्किक समूह को परिभाषित करता है और फिर या तो सीधे संदेश भेजता है, या एक संदेश दलाल के माध्यम से जाता है (हालाँकि OS को ईवेंट आधारित सिस्टम में संदेश ब्रोकर के रूप में देखा जा सकता है)।

जाहिर है कि थ्रेडस्टीन के मामले में घटनाओं के कार्यान्वयन के C # के साथ उल्लेख है, लेकिन आप अभी भी अपना खुद का पब / उप मॉडल बना सकते हैं जो विभिन्न थ्रेड्स पर निष्पादित होता है।

Answer 2

यह सेब और संतरे हैं:

ईवेंट ड्रिवेन सिस्टम संदेशों के रूप में पारित होने वाली घटनाओं पर प्रतिक्रिया कर सकता है (इस संदर्भ में संदेश अपरिवर्तनीय गैर-साझा डेटा के रूप में निहित हैं ) जैसे कि घटनाओं को उठाया जाता है। यह विशुद्ध रूप से वास्तुशिल्प डिजाइन है।

एक संदेश पासिंग सिस्टम संदेशों को बनाने और पास करने वाली घटनाओं से प्रेरित हो सकता है । यह विशुद्ध रूप से कार्यान्वयन डिजाइन है।

दो परस्पर अनन्य नहीं हैं।

उदाहरण: आप किसी भी भाषा में एक ईवेंट चालित डिज़ाइन लागू कर सकते हैं जो एर्लांग में एक संदेश गुजरने वाला वातावरण भी हो सकता है ।

Answer 3

"मैसेज पासिंग" और "इवेंट बेस्ड" के बीच की अधिकांश उलझनें वास्तु बनाम कार्यान्वयन विवरण के साथ होती हैं। मैंने इवेंट संचालित (देखा और लिखा हुआ) सिस्टम देखा है जो वास्तव में उनके कार्यान्वयन के लिए ओएस प्रदान किए गए संदेशों का उपयोग करता है। मैं अनुमान लगा रहा हूं कि आप वास्तव में वास्तु विचारों का उल्लेख कर रहे हैं।

जैसा कि कई लोग पहले से ही "संदेश पासिंग" और "घटना आधारित" को इंगित कर चुके हैं, अस्पष्टता से बचने के लिए वास्तव में पर्याप्त शब्द नहीं हैं।

एक "संदेश पासिंग" प्रणाली बनाम एक "घटना आधारित" प्रणाली के सापेक्ष गुण क्या हैं।

संदेश देना

मैं यह अनुमान लगाकर शुरू करने जा रहा हूं कि जब आप "संदेश पासिंग" सिस्टम कहते हैं, तो आप एक ऐसी प्रणाली के बारे में बात कर रहे हैं, जो एक वस्तु किसी अन्य विशिष्ट वस्तु को संदेश देती है। जब मैं इस प्रतिमान के आधार पर एक प्रणाली के बारे में सोचता हूं, तो मैं आमतौर पर एक ऐसी प्रणाली के बारे में सोचता हूं जहां एक वस्तु जो कुछ का पता लगाती है वह जानती है कि किसी चीज के बारे में बताने की आवश्यकता है। (मैं निर्दिष्ट नहीं कर रहा हूँ कि यह कैसे जानता है, बस यह जानता है।)

इस प्रकार की वास्तुकला उन प्रणालियों के लिए बहुत अच्छी है जहां उत्पादकों और उपभोक्ताओं को अच्छी तरह से जाना जाता है। या तो किसी संदेश का निर्माता जानता है कि उसे किसे प्राप्त करना है, या उपभोक्ता को यह पता होना चाहिए कि संदेश किससे प्राप्त करना है।

यदि आप बैंकिंग एप्लिकेशन लिख रहे हैं, तो कोई आपसे यह उम्मीद करेगा कि आप वास्तव में जानना चाहते हैं कि आप किसे अपना लेनदेन भेज रहे हैं और वे किससे आ रहे हैं।

घटना आधारित

दूसरी प्रणाली, मेरा मानना ​​है कि जब आप कहते हैं कि आप "घटना आधारित" प्रणाली के बारे में सोच रहे हैं, तो एक ऐसी वस्तु है जहां कोई वस्तु "घटना" उठाती है, बिना यह जाने कि कौन (यदि कोई है) इसका जवाब देगा।

इस प्रकार की घटना संचालित वास्तुकला उन प्रणालियों के लिए बहुत अच्छी है जहां निर्माता इस बात की परवाह नहीं करता है कि कौन घटना का उपभोग करता है या जहां उपभोक्ता वास्तव में इस बात की परवाह नहीं करता है कि घटना का उत्पादन किसने किया है।

सामान्य तौर पर, ये प्रणालियां महान हैं जहां आप उपभोक्ताओं और उत्पादकों के बीच संबंध नहीं जानते हैं, और जहां आप उम्मीद करते हैं कि संबंध गतिशील होगा।

एक प्रणाली जिसका मैंने इसमें उपयोग किया है, वह एक प्रणाली थी जहां एप्लिकेशन वास्तव में गतिशील रूप से कॉन्फ़िगर किए गए मॉड्यूल (प्लग-इन) से बना था जो कि रन टाइम पर लोड किए गए थे। जब एक मॉड्यूल लोड किया गया था, तो यह उन घटनाओं के लिए पंजीकृत होगा जिनके बारे में परवाह थी। परिणाम एक ऐसी प्रणाली थी जिसमें कार्यक्षमता का विस्तार करना बहुत आसान था।

उदाहरण के लिए, मान लें कि स्थिति A ईए बढ़ा हुआ ईए है जो आमतौर पर प्रतिक्रिया आरए का कारण बनता है। वह वस्तु जिसके कारण प्रतिक्रिया आरए घटना ईए को प्राप्त करने के लिए पंजीकृत होती है और आने पर उस पर कार्रवाई की जाती है। अब, मान लें कि हम EA को एक नई प्रतिक्रिया जोड़ना चाहते हैं, जिसे RA_1 कहा जाता है। ऐसा करने के लिए, हम बस एक नई वस्तु जोड़ते हैं जो ईए के लिए दिखती है और प्रतिक्रिया RA_1 उत्पन्न करती है।

यहां कुछ उदाहरण दिए गए हैं (आपकी शब्दावली का उपयोग करते हुए):

• "मैसेज पासिंग" : आपका बॉस आपको अपनी टाइम शीट भरने के लिए कहता है।
• "ईवेंट संचालित" : विभाग के सचिव ने सभी को एक ईमेल भेजकर याद दिलाया कि आज उनकी समय सारणी होने वाली है।

Comments

यह मुझे याद दिलाता है ... यह महीने का अंत है, इसलिए मैं अपना समय पत्र भरना बेहतर समझता हूं।

— डेव नाय

Answer 4

SOA में आपको कमांड मैसेज और इवेंट मैसेज का कॉन्सेप्ट है । दोनों की जरूरत है।

हालाँकि, कमांड संदेशों में प्राप्तकर्ता समापन बिंदु के लिए एक उच्च व्यवहार युग्मन होता है क्योंकि यह स्पष्ट रूप से समापन बिंदु को कुछ फ़ंक्शन करने के लिए कह रहा है। इसे किसी विशेष समापन बिंदु से बांधा नहीं जाना चाहिए (इसे कॉन्फ़िगर किया जा सकता है या रनटाइम पर निर्धारित किया जा सकता है)।

दूसरी ओर ईवेंट संदेश, प्रेषक / प्राप्तकर्ता के बीच कोई व्यवहारिक युग्मन नहीं है क्योंकि प्रेषक को यह पता नहीं है कि प्राप्तकर्ता संदेश के साथ क्या करने जा रहा है। यह भी नहीं पता है कि किसी को घटना के लिए सदस्यता दी गई है या नहीं।

कुछ और पृष्ठभूमि के लिए आप यहाँ मेरी सेवा बस साइट का उपयोग करने के लिए स्वागत कर रहे हैं: http://www.servicebus.co.za

Answer 5

मेरे अनुभव में, दोनों के बीच सबसे बड़ा अंतर यह है कि एक संदेश-पासिंग सिस्टम में संदेश प्रथम श्रेणी की वस्तुएं हैं, जबकि इवेंट-संचालित सिस्टम में घटनाएं बहुत सरल हैं। संदेश सूचनाओं को ले जाते हैं, और यह जानकारी परिवर्तित, संग्रहीत, पुनर्प्राप्त और पुनः भेजी जा सकती है। घटनाएँ जानकारी के छोटे, अधिक केंद्रित बिट्स को ले जाती हैं जो तुरंत खपत होती हैं और फिर छोड़ दी जाती हैं। वे एक इवेंट स्रोत से सीधे एक या एक से अधिक इवेंट सिंक पर भेजे जाते हैं, जबकि संदेशों को अक्सर कई रिसीवरों के बीच रूट किया जाता है, और रूट के किसी भी बिंदु पर परिवर्तित / अनुवादित / लिपटा या अन्यथा संसाधित किया जा सकता है। वे समान तकनीकों (बसों, कतारों, फ़िल्टरों आदि) का उपयोग करते हैं, लेकिन वे वास्तव में जानवरों को नापसंद करते हैं।

Answer 6

व्यावहारिक दृष्टिकोण से, संदेशों को आमतौर पर मेमोरी के एक ब्लॉक के रूप में कार्यान्वित किया जाता है जो प्रेषक के पते के स्थान से रिसीवर के पते के स्थान पर कॉपी किया जाता है (या अन्यथा एक अपरिवर्तनीय वस्तु के रूप में लागू किया जाता है) ताकि आप तुरंत थ्रेड-सेफ्टी प्राप्त करें।

संदेश के कुछ मामलों में प्रेषक को पास करने के लिए रिसीवर को निर्दिष्ट करना होगा, लेकिन कुछ अन्य मामलों में आप सिर्फ एक संदेश को मेलबॉक्स में पोस्ट कर सकते हैं, और कोई भी उस मेलबॉक्स में संदेशों के लिए सुन सकता है, इसलिए उन्हें कसकर युग्मित करने में कुछ लचीलापन है। बेशक, आपके पास एक मेलबॉक्स हो सकता है जहां अनुबंध "मैं इस घटना के होने पर इस मेलबॉक्स को एक संदेश पोस्ट करूंगा ।"

घटनाओं के मामले में आप घटना के मालिक के साथ एक प्रतिनिधि या कॉलबैक दर्ज कर रहे हैं। ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में इसका मतलब है कि ईवेंट स्वामी उस ऑब्जेक्ट का संदर्भ रखता है जो ईवेंट प्राप्त करने के लिए पंजीकृत है। यह कभी-कभी बहीखाते के बुरे सपने पैदा कर सकता है, यह पता लगाने की कोशिश करता है कि कौन सी वस्तु अपने ईवेंट हैंडलर को अपंजीकृत करना भूल गई। इसका मतलब है कि लक्ष्य को तब तक इकट्ठा नहीं किया जा सकता है जब तक कि इवेंट मालिक कचरा एकत्र नहीं करता है, भले ही लक्ष्य अब उपयोगी कुछ भी नहीं कर रहा हो।

व्यक्तिगत रूप से मैं ईवेंट्स पर संदेश भेजने का चयन करूंगा, सिवाय उन मामलों के जिनमें इवेंट्स को आप पर मजबूर किया जाता है, जैसे कि विंडोज GUI प्रोग्रामिंग, आदि।

Comments

बस फी, मैंने अपने C ++ ईवेंट सिस्टम में चक्र समस्या (आपकी पुस्तक रखने वाली दुःस्वप्न) को हल कर दिया, जब भी घटना को बुलाया गया था तब श्रोताओं के सेट से किसी भी .expired () पॉइंटर्स को साफ़ करके और साफ़ करके। ईवेंट ऑब्जेक्ट प्राप्तकर्ता ऑब्जेक्ट का स्वामी नहीं है और ये पॉइंटर शब्दार्थ इसे स्पष्ट करते हैं।

— रॉबिन्सन