संदेश का संसाधन ठीक एक बार

Question

कृपया परिदृश्य के रूप में संलग्न छवि में दिखाया गया पर विचार करें:

1. पोर्टल (निर्माता) बस के लिए कुछ संदेश भेज देंगे कई द्वारा संसाधित किया जा करने के लिए जो किया है करने के लिए आवेदन पत्र (उपभोक्ता) - PAYROLLAPP, हेल्पडेस्क आदि
2. उपभोक्ता अनुप्रयोगों के कई उदाहरणों चल रहा जा सकता है, भी इन उदाहरणों/ गतिशील रूप से हटाया
जोड़ा जा सकता है
3. अब, यह सुनिश्चित करना महत्वपूर्ण है कि संदेश केवल एक बार संसाधित किया जाता है, प्रति आवेदन i.e यदि पेरोलाप्पी -1 संदेश को संसाधित करता है, तो पेरालाल्प -2 को संसाधित नहीं करना चाहिए; बेशक, आरेख के ऊपर में, HELPDESK - 1 को इसे संसाधित करना होगा। संक्षेप में, कई उदाहरणों के मामले में, वास्तव में संदेश को संसाधित करना होगा, एक बार
4. जब मैंने उत्तर खोजे, तो अधिकांश चीजें 'चुनिंदा उपभोक्ता' बनाने के बारे में थीं - एक उपभोक्ता जो संदेश के आधार पर स्वीकार/अस्वीकार करता है कुछ तर्क - कृपया ध्यान दें कि आरेख में दिखाए गए अनुप्रयोगों के लिए कोई परिवर्तन/जोड़/रैपिंग नहीं किया जा सकता है; तर्क को प्रदाता में कहीं भी रहना है जो बस

का प्रबंधन करता है, कृपया इसके बारे में मार्गदर्शन करें।

पैटर के जवाब के बाद अधिक जानकारी के जोड़ना:

1. बाएं बिंदीदार रेखा के बाईं ओर करने के लिए आइटम 'दृष्टिकोण' कर रहे हैं - शुद्ध JMS, ESB, EAI
2. दाएं-बिंदीदार रेखा के दाईं ओर के आइटम 'कार्यान्वयन'

अब, बड़ा हिस्सा - प्रश्न:

समाधान पर ध्यान दिए बिना
1. (शुद्ध JMS, ESB, ईएआई), भाग क्षैतिज बिंदीदार रेखा (आवेदन विशेष कतारों) नीचे की जरूरत है लागू किया जाना है?
2. कैसे ESB (JBoss ESB आदि) का उपयोग, 'शुद्ध' JMS (सक्रिय MQ आदि), के बजाय मदद करता है/ बाधा? क्या ईएसबी जेएमएस पर कोई लाभ प्रदान करता है जो 'जावा-केवल' (?) है। मैं - 'ईएसबी या जेएमएस' को भ्रमित कर रहा हूं, इनके धागे को संदर्भित करने के बाद भी: JMS and ESB - how they are related?। यह एक जबाब जो कहते हैं, "JMS अच्छी तरह से अनुकूल बाकी सेवाओं, फाइल सिस्टम, एस/एफ़टीपी, ईमेल, हेस्सियन, साबुन आदि जो बेहतर एक ESB कि इन प्रकार के देशी रूप का समर्थन करता है के साथ संभाला हैं के एकीकरण के लिए नहीं है। उदाहरण के लिए, आप एक प्रक्रिया कि आधी रात में 500MB की एक CSV फ़ाइल उदासीनता है, और आप पिक के लिए एक और सिस्टम फ़ाइल, पार्स सीएसवी और एक डेटाबेस में आयात करना चाहते हैं, यह आसानी से एक ESB के द्वारा पूरा किया जा सकता है - जबकि एक सिर्फ जेएमएस के साथ समाधान खराब होगा। इसी तरह, बाकी सेवाओं का एकीकरण, लोड संतुलन के साथ/एकाधिक बैकएंड उदाहरणों को विफलता बेहतर एक ESB के साथ समर्थन HTTP/एस देशी रूप से किया जा सकता। "यह केवल मेरी भ्रम को जोड़ा गया !!!
3. ईएआई फ्रेमवर्क (अपाचे कैमल इत्यादि) का उपयोग शुद्ध जेएमएस या ईएसबी दृष्टिकोण से पूरी तरह से अलग दृष्टिकोण है? यदि हां, पेशेवर और विपक्ष क्या हैं और कैसे हैं?
4. मुझे बताया गया था कि ईएसबी अकेले मदद नहीं करेगा, बीपीएम (या कुछ और?) को परिभाषित करने के लिए उपयोग किया जाना चाहिए और 'रूटिंग' तर्क संग्रहित करें - क्या यह सच है?

Answer 1

मुझे बिंदु दिखाई देता है। यह "शुद्ध" जेएमएस के साथ थोड़ा मुश्किल हो सकता है।

आप जो करना चाहते हैं वह पोर्टल को किसी विषय पर संदेश प्रकाशित करने देना है, लेकिन PAYROLLAPPs उस विषय की सदस्यता लेने दें (क्योंकि उनमें से सभी को संदेश की एक प्रति प्राप्त होगी)। तो आपको जो कुछ चाहिए वह उसमें कुछ तर्क है जो विषय सदस्यता से संदेश को एक कतार प्रति एप्लिकेशन प्रकार में वितरित करता है। उस कतार से, सामान्य भार संतुलित (प्रतिस्पर्धी उपभोक्ता पैटर्न) जेएमएस के साथ लागू किया जा सकता है।

विभिन्न जेएमएस प्रदाताओं के पास विशेष कार्यान्वयन हैं जो इस कार्य को ActiveMQ has its Virtual Destinations, WebSphere MQ has its server side subscriptions that can subscribe from a topic to a queue को कार्यान्वित कर सकते हैं। यदि आपके जेएमएस प्रदाता के पास इसे संभालने का कोई तरीका नहीं है, तो हो सकता है कि आप अपने टोपोलॉजी में कुछ रूटिंग मिडलवेयर जोड़ना चाहें। अपाचे कैमल एक अच्छा, हल्का वजन वाला है, लेकिन ऐसे कई अन्य हैं जो वास्तविक अनुप्रयोगों को प्रभावित किए बिना मध्य में कुछ रूटिंग सेट कर सकते हैं। विस्तृत सवाल

1. रेखा से नीचे कतार के लिए

   अद्यतन यकीन है कि के लिए वहाँ हो (अपने अनुप्रयोगों मैसेजिंग का उपयोग करता है) है। "कुछ distrib तर्क" बॉक्स की जरूरत नहीं है। "कुछ रूटिंग तर्क" बॉक्स एक ईएसबी हो सकता है या इस मामले में, मैसेजिंग सर्वर में कार्यान्वित किया जा सकता है, उदाहरण के लिए वर्चुअल गंतव्यों के साथ ActiveMQ (या वेबस्फेयर एमक्यू या शायद अन्य लोगों के बीच खरगोश एमक्यू)।

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

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

1. पर लाभ उठाने अपनी स्थिति में, मैं बहुत गहरा ESB और EAI सॉफ्टवेयर के बीच शास्रीय/दार्शनिक मतभेद में जाने नहीं होगा। वे आपके लिए बहुत अधिक चीजें करेंगे। इसके बजाय, मूल्य, समर्थन, संसाधन पदचिह्न, निगरानी, ​​तकनीक जैसे कठिन तथ्यों को देखें। विशेषताएं, सीखने वक्र इत्यादि। यह ऊंट/सेवामिक्स, मुले, जेबॉस ईएसबी, माइक्रोसॉफ्ट बिज़टॉक, आईबीएम संदेश ब्रोकर, तिब्को इत्यादि बनें।

2. हां! क्या यह शायद एक विक्रेता था? एक ईएसबी ठीक काम करेगा। एक संदेश सर्वर आपके मामले में भी करेगा, जैसे ActiveMQ जैसा कि पहले से ही इंगित किया गया है। बीपीएम सूट सेमी-ऑटोमैटिक बिजनेस प्रोसेस को ऑर्केस्ट्रेट करने के लिए ठीक हैं या यदि एकीकरण परत में प्रमुख व्यावसायिक तर्क है। अन्यथा, उस जटिल जटिलता से बचें।

Answer 2

1. समाधान का लिहाज किए बिना (शुद्ध JMS, ESB, ईएआई), क्षैतिज बिंदीदार रेखा (आवेदन विशेष कतारों) की जरूरत है नीचे हिस्सा लागू किया जाना है?

उपभोक्ताओं को इस तरह से साथ काम आप समाधान चुना लेकिन आप उपभोक्ता प्रति कतार या वितरण तर्क के निर्माण के बारे में चिंता करने (यह मानते हुए नहीं होना चाहिए में लागू करने की जरूरत है कि उपभोक्ताओं को कर सकते हैं चुने हुए तकनीक से सीधे उपभोग)

1. कैसे ESB (JBoss ESB आदि) का उपयोग, 'शुद्ध' JMS (सक्रिय MQ आदि), के बजाय मदद करता है/बाधा? क्या ईएसबी जेएमएस पर कोई लाभ प्रदान करता है जो 'जावा-केवल' (?) है। मैं नरक उलझन में हूं - 'ईएसबी या जेएमएस', इनके धागे को संदर्भित करने के बाद भी: जेएमएस और ईएसबी - वे कैसे संबंधित हैं? इसमें एक जवाब है जो कहता है "जेएमएस आरईएसटी सेवाओं, फाइल सिस्टम, एस/एफ़टीपी, ईमेल, हेसियन, एसओएपी इत्यादि के एकीकरण के लिए उपयुक्त नहीं है, जो इन प्रकारों को मूल रूप से समर्थन देने वाले ईएसबी के साथ बेहतर तरीके से संभाला जाता है। उदाहरण के लिए, यदि आपके पास ऐसी प्रक्रिया है जो मध्यरात्रि में 500 एमबी की सीएसवी फ़ाइल को डंप करती है, और आप चाहते हैं कि कोई अन्य सिस्टम फ़ाइल को पिकअप करे, सीएसवी पार्स करें और डेटाबेस में आयात करें, यह आसानी से ईएसबी द्वारा पूरा किया जा सकता है - जबकि केवल एक समाधान जेएमएस खराब होगा। इसी तरह, आरईएसटी सेवाओं का एकीकरण, लोड बैलेंसिंग/एकाधिक बैकएंड उदाहरणों में विफलता के साथ एक ईएसबी समर्थन HTTP/S मूल रूप से बेहतर किया जा सकता है। "यह केवल मेरे भ्रम में जोड़ा गया !!!

मेरी राय यह है कि ईएसबी इस समाधान को खत्म कर देगा। यह विभिन्न तकनीकों के साथ एकीकरण में सहायता के लिए (अन्य चीजों के साथ) डिज़ाइन किया गया है, लेकिन सरल समाधान भी ऐसा करते हैं - उदाहरण के लिए - अपाचे कैमल ट्रांसपोर्ट्स (ActiveMQ समेत) का उपयोग करके संचार का एक बहुत ही आसान तरीका प्रदान करता है।

सभी जेएमएस कार्यान्वयन अन्य भाषाओं से कनेक्टिविटी के लिए पूरा नहीं करते हैं, लेकिन ActiveMQ इसका STOMP कनेक्टर का उपयोग करता है।

1. EAI फ्रेमवर्क (अपाचे ऊंट आदि) एक दृष्टिकोण पूरी तरह से शुद्ध JMS या ESB दृष्टिकोण से अलग के उपयोग है? यदि हां, पेशेवर और विपक्ष क्या हैं और कैसे हैं? के रूप में JMS और ESB हैं

अपाचे ऊंट और JMS, पूरक प्रौद्योगिकियों हैं। ऊंट (& वसंत एकीकरण) हल्के, सरल और पोर्टेबल हैं। ईएसबी अधिक हेवीवेट हैं और आमतौर पर ईएसबी/एप्लिकेशन सर्वर के साथ अधिक युग्मन का कारण बनेंगे।

1. मुझे बताया गया था कि अकेले ESB मदद नहीं करेगा, बीपीएम (? या कुछ और) को परिभाषित करने और 'मार्ग' तर्क स्टोर करने के लिए इस्तेमाल किया जा करने की जरूरत है - यह सच है?

यह निर्भर करता है कि आपके 'मार्ग' तर्क है, यह मेरे लिए लगता है कि आप मार्ग तर्क की आवश्यकता नहीं है, तो आप सिर्फ गारंटी वितरण की आवश्यकता होती है उपभोक्ता और 1 हेल्पडेस्क उपभोक्ता 1payroll करने के लिए। बीपीएम अधिक उपयोगी होगा जहां आप चुनिंदा सार्वजनिक डेटा/उस डेटा की कुछ विशेषताओं के आधार पर सेवा का आह्वान करना चाहते हैं।

मैं दृढ़ता से http://activemq.apache.org/virtual-destinations.html पढ़ने का सुझाव, का उपयोग करते हुए इन क्या तुम करोगी:

1. , ActiveMQ दलाल को संदेश भेजें एक VirtualTopic, उदा पर VirtualTopic.X
2. रजिस्टर पेरोल और हेल्पडेस्क उपभोक्ताओं, कतारों कि ActiveMQ गतिशील विषय पर बनाता है पर उपभोक्ताओं के रूप में - जैसे Consumer.Payroll.VirtualTopic.X। पेरोल उपभोक्ताओं दोनों को एक ही स्ट्रिंग के साथ पंजीकृत किया जाना चाहिए।
3. ActiveMQ स्वचालित रूप से एक मार्कर लगायें जिसको उपभोक्ताओं के प्रत्येक सेट का सेवन नहीं किया है बनी रहेगी। इसका मतलब है कि 100% संदेशों को पेरोल उपभोक्ता द्वारा संसाधित किया जाएगा लेकिन एक संदेश कभी भी 1 पेरोल उपभोक्ता को नहीं भेजा जाएगा।
4. जोड़ें/होगा पर उपभोक्ताओं को हटा दें।

N.B.I का मानना ​​है कि अन्य उत्पादों, जैसे अपाचे Qpid इसी तरह की सुविधा प्रदान करते हैं - मैं तो बस सबसे ActiveMQ के बारे में पता कर रहा हूँ, और इस दृष्टिकोण