मैसेजिंग, क्यूईएस और ईएसबी - मुझे पता है कि मैं कहां बनना चाहता हूं लेकिन वहां कैसे नहीं जाना है

Question

एक लंबी कहानी को कम करने के लिए, मैं एक ऐसे प्रोजेक्ट पर काम कर रहा हूं जहां हम सभी सामान्य कारणों से एक बड़े वेब एप्लिकेशन को फिर से लिख रहे हैं। पुनर्लेख का मुख्य उद्देश्य इस बड़े एकल एप्लिकेशन को एकल सर्वर पर चलने वाले कई छोटे decoupled अनुप्रयोगों को अलग करना है, जो कई सर्वरों पर चलाया जा सकता है।

यहाँ ठीक है मैं क्या पसंद करेंगे:

मैं HTTP चाहते हैं मुख्य परिवहन व्यवस्था किया जाना है। जब उदाहरण के लिए एक आवेदन सीएमएस अद्यतन किया गया है वह http के माध्यम से दलाल से संपर्क करें और कहते हैं कि "I've changed", तो दलाल वापस भेज देंगे एक 200 OK"thanks I got the message" कहने के लिए होगा।

ब्रोकर फिर अन्य अनुप्रयोगों की सूची देखेगा जो सीएमएस परिवर्तनों के बारे में सुनना चाहते थे और यूआरएल को संदेश भेजते थे कि जब यह ब्रोकर को संदेश के बारे में सुनना था तो आवेदन छोड़ दिया गया था।

अन्य एप्लिकेशन 200 OK लौटाएंगे, जब उन्हें संदेश प्राप्त होता है, यदि ब्रोकर संदेश नहीं रखता है और अगली बार जब कोई उस एप्लिकेशन से संपर्क करने का प्रयास करता है तो उसे कतार में डाल देता है।

समस्या यह है कि मुझे यह भी नहीं पता कि कहां से शुरू करना है या मुझे इसे करने की क्या ज़रूरत है। मैं XMPP, ActiveMQ, RabbitMQ, खच्चर ESB आदि को देख रहा था और मैं खर्च कर सकता है अगले साल इस सामग्री के साथ हलकों में चारों ओर जा रहा देख सकते हैं।

क्या कोई व्यक्तिगत अनुभव से कोई सलाह दे सकता है क्योंकि मैं सीखने के सबक सीखने से बचाना चाहता हूं।

Answer 1

मैंने 2003 के बाद से विभिन्न सॉफ्टवेयर सिस्टम में जेएमएस मैसेजिंग के साथ काम किया है। मेरे पास एक वेब ऐप है जहां ग्राहक प्रभावी रूप से जेएमएस विषय ग्राहक हैं। किसी विषय में एक संदेश प्रकाशित करने के केवल कार्य के द्वारा, संदेश सर्वर के सभी सब्सक्राइब करने वाले वेब क्लाइंटों को विघटित कर देता है।

वेब क्लाइंट फ्लेक्स-आधारित है। हमारे बीच स्तरीय ढेर से मिलकर बनता है:

• जावा 6
• बिलाव 6
• BlazeDS
• वसंत-फ्रेमवर्क
• ActiveMQ (JMS संदेश दलाल)

BlazeDS करने की क्षमता है जेएमएस के लिए एक पुल के रूप में कॉन्फ़िगर किया जाना चाहिए। यह एक टोमकैट सर्वलेट है जो फ्लेक्स क्लाइंट को रीमोटिंग कॉल का जवाब देता है लेकिन जब क्लाइंट को कॉन्फ़िगर किया गया है तो नए संदेश दिखाई देने पर क्लाइंट को संदेश पुश भी कर सकते हैं।

Asynchronous HTTP and Comet architectures An introduction to asynchronous, non-blocking HTTP programming

Farata सिस्टम की घोषणा की है कि वे धूमकेतु पैटर्न को लागू करने के लिए घाट निरंतरता दृष्टिकोण के साथ काम करने के लिए BlazeDS संशोधित किया है:

BlazeDS सर्वर साइड संदेश धक्का करने के लिए धूमकेतु पैटर्न लागू करता है।यह एक भौतिक सर्वर के खिलाफ हजारों धूमकेतु कनेक्शन स्केलिंग को सक्षम बनाता है।

Farata Systems Achieves Performance Breakthrough with Adobe BlazeDS

हम BlazeDS में सर्वलेट 3.0 के समर्थन को लागू करने के लिए खुद को के रूप में मूल रूप से हम काफी कॉम्बो में बिलाव और स्प्रिंग का उपयोग करने के विवाहित रहे हैं के लिए Adobe इंतजार कर रहे हैं।

बड़े पैमाने पर स्केलेबल करने की तकनीक की कुंजी धूमकेतु पैटर्न जावा एनआईओ HTTP श्रोताओं को थ्रेड पूल (जैसे जावा 5 कंसुरेंसी लाइब्रेरी में एक्जिक्यूटिव क्लास) के संयोजन के रूप में उपयोग करना है। सर्वलेट 3.0 सर्वलेट्स के लिए एक एसिंक घटना-संचालित मॉडल है जिसे ऐसे HTTP श्रोता के साथ एक साथ जोड़ा जा सकता है। हजारों (10,000 से 20,000 की संख्या) समवर्ती धूमकेतु कनेक्शन तब एक भौतिक सर्वर के खिलाफ बनाए रखा जा सकता है।

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

अंत में, एडोब और स्प्रिंगसोर्स एक चिकनी, आउट- ऑफ-द-बॉक्स वसंत-फ्रेमवर्क के संयोजन के रूप में BlazeDS के एकीकरण:

सभी की

Adobe Collaborates with SpringSource for Enhanced Integration Between Flash and SpringSource Platforms

Answer 2

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

यदि आपके पास गंतव्य अनुप्रयोगों का एक विविध सेट है जो एक-दूसरे से बात करने की आवश्यकता है - और ऐसा लगता है कि आप ऐसा करते हैं - आप सही हैं कि एक भाषा अज्ञेय प्रोटोकॉल (जैसे एक्सएमपीपी, STOMP या HTTP) पर मैसेजिंग एक साफ है उपाय। इसका मूल रूप से मतलब है कि आपको जेएमएस के पसंदीदा स्वाद में संदेशों का अनुवाद करने के लिए जावा डिमन्स के भार लिखना और चलाने की आवश्यकता नहीं है।

STOMP संदेश दलालों द्वारा विशेष रूप से खुले स्रोत वाले लोगों द्वारा समर्थित है, और कई अलग-अलग क्लाइंट पुस्तकालय हैं। यह एक लाइटवेट प्रोटोकॉल है, विशेष रूप से मैसेजिंग के लिए डिज़ाइन किया गया है ताकि आपको HTTP के साथ बॉक्स की तुलना में अधिक समृद्ध सुविधा मिल सके।

मेरे लिए, XMPP है एक कमजोर विकल्प का एक सा यह इतनी अच्छी तरह से, सर्वर साइड पर समर्थित नहीं है के रूप में हालांकि यह अपने ब्रोकर :)

आप HTTP पर सेट कर रहे हैं IM के लिए सक्षम होने के लिए मजेदार है, OpenMQ बहुत अच्छा है, और मैंने व्यक्तिगत रूप से Universal Message Service का उपयोग किया है - मूल रूप से जेएमएस गंतव्यों के आस-पास एक वेबैप रैपर। यह STOMP प्रदान करता है जैसे क्रियाओं के समान सेट के साथ एक आरईएसटी-पूर्ण इंटरफ़ेस प्रदान करता है।

Answer 3

आप वास्तव में प्रकाशित होने और आश्वासित डिलीवरी के साथ सदस्यता लेने के बारे में बात कर रहे हैं। अधिकांश एमओएम सॉफ़्टवेयर को आसानी से आपके उपयोग के मामले का समर्थन करना चाहिए।

Answer 4

जैसा कि किसी ने पहले ही कहा है, आपका विवरण मूल रूप से प्रकाशक/सदस्यता मॉडल क्या है। यह ईएसबी या एक संदेश कतार का उपयोग करके बहुत आसानी से हासिल किया जाता है।मुझे RabbitMQ के साथ कुछ अनुभव हुआ है। यह बहुत अच्छा है। कुछ भी खो नहीं जाता है और यह प्रकाशित सबस्क्राइब मॉडल से बहुत अच्छी तरह से संबंधित है। मैंने पहले अपने संदेश ब्रोकर को http पर एक bespoke प्रोटोकॉल के साथ विकसित करने के छोटे पैमाने पर सिस्टम पर मार्ग नीचे चला गया है। मैं यह सलाह नहीं दूंगा, कारण यह है कि जब आप इसे विकसित करना शुरू करते हैं तो आप इसे विस्तारित करने के तरीकों के बारे में सोचते रहते हैं।

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

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

http://www.rabbitmq.com/tutorials/tutorial-three-java.html, यह प्रकाशित/सदस्यता मॉडल पर ट्यूटोरियल का एक लिंक है और आप संदेश कतार प्रणाली का उपयोग करके इसे कैसे प्राप्त करेंगे। यह खरगोश एमक्यू के लिए है, लेकिन ईमानदार होने के लिए यह ईएसबी और किसी भी अन्य संदेश कतार प्रणाली के साथ काम करेगा।

Answer 5

ईएसबी (एंटरप्राइज़ सीरियल बस) - इस पर विचार करें जब आपके एप्लिकेशन में दो या दो से अधिक बाहरी/अलग-अलग अनुप्रयोगों के साथ बहुत अधिक बातचीत होती है, जहां इनमें से प्रत्येक एक समान डेटा प्रारूप में संवाद नहीं करेगा। उदाहरण के लिए: को संबोधित करते हुए संदेश सेवा शैलियों, परिवहन प्रोटोकॉल, सेवा संदेश सेवा मॉडल रूटिंग,: कुछ सिस्टम वस्तुओं स्वीकार कर सकते हैं, एक्सएमएल, JSON, एसएमटीपी, टीसीपी/आईपी, HTTP, HTTPS आदि

ESB जैसे कई विशेषताएं है।

उत्पादक - उपभोक्ता अनुप्रयोग एक ही प्रकार के डेटा प्रारूप का पालन करते हैं तो कतार प्रणाली पर विचार करें।

वेब सेवाओं (एसओएपी/आरईएसटी) सर्वोत्तम है यदि किसी एप्लिकेशन को कार्य प्रवाह को पूरा करने के लिए अन्य एप्लिकेशन की आवश्यकता होती है। एप्लिकेशन को एसिंक्रोनस डेटा ट्रांसफर की आवश्यकता होने पर पंक्तियों का उपयोग करें।

Answer 6

जैसा कि पहले से ही कहा गया था, आपके लिए वर्तमान स्थिति के लिए ईएसबी होने से मुझे एक हथौड़ा के साथ एक फ्लाई तोड़ना पसंद है।

ईएसबी सॉफ्टवेयर स्वयं समय लेने वाला होगा और रखरखाव की आवश्यकता होगी। यदि आप ओपन सोर्स सॉल्यूशन पर जाते हैं, तो लाइसेंस प्राप्त समाधान (आईबीएम, ओरेकल, ...) का उपयोग करने में यह अधिक समय ले सकता है।

बेशक एक ईएसबी नौकरी करेगा, और समाधान विकसित करना वास्तव में आसान होगा, लेकिन एक ईएसबी स्थापित करना समाधान को स्वयं करने से कहीं अधिक कठिन होगा।

तो आपकी समस्या को मामले वर्णित तक ही सीमित है, मैं अत्यधिक तुम OpenMQ (या समान) से अधिक एक साधारण वास्तुकला का निर्माण करने का सुझाव देते हैं, और JMS

के माध्यम से इसे का उपयोग