2009-08-11 13 views
8

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

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

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

कोई सुझाव या विचार? क्या हमें समवर्ती संरचनाओं के रूप में कतार बनाना जारी रखना चाहिए, या उन्हें अलग, संभावित रूप से दूरस्थ वस्तुओं के रूप में व्यवहार करना चाहिए?

उत्तर

6

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

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

1

मेरा एक सहयोगी Mule का उपयोग कर रहा है, जो आपको कतारों को परिभाषित करने की अनुमति देता है जो अंतर-या अंतर-जेवीएम कतार हो सकते हैं।

मैं krosenwald से सहमत: यह स्पष्ट नहीं है कि क्या JMS अपने मामले में जोड़ने की जाएगी, जब तक कि वहाँ एक सामान्य योजना के लिए या तो टेराकोटा से दूर स्थानांतरित (या कम से कम विकल्प है) है।

1

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

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

यदि आपको लगता है कि आपके भविष्य के उपयोग के मामले दृढ़ता आदि के साथ अधिक पब-उप अर्थशास्त्र की आवश्यकता होती है, तो आप जेएमएस के बारे में सोचना शुरू कर सकते हैं। इसके अलावा, चिंताओं को अलग करने पर विचार करें। आप डेटा वितरित करने के लिए टेराकोटा का उपयोग कर रहे हैं (जो इसे करने के लिए डिज़ाइन किया गया है)। क्या आप इसका उपयोग नियंत्रण निर्देशों को वितरित करने के लिए भी करेंगे (जो मैसाइंग सेमेन्टिक्स के साथ बेहतर किया जाता है)?

संबंधित मुद्दे