जावा ईई: बनाना और डोमेन मॉडल

Question

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

1. सॉकेट के लिए एक JCA संसाधन एडाप्टर बनाएँ और श्रोताओं के रूप में एमडीबी का उपयोग करें। जिस समस्या में मैं भाग गया था वह यह था कि जब मैं उपयोगकर्ता उन्हें जोड़ता हूं तो अलग-अलग सॉकेट के लिए प्रोग्रामेटिक रूप से एमडीबी को कैसे तैनात किया जाए।

2. बनाएँ @ सिंगलटन/@ सेवा EJB कि सावधान तुल्यकालन के साथ डेमॉन धागे प्रबंधन करता है। सिंगलटन ईजेबी को बिजनेस लेयर में इंजेक्शन दिया जा सकता है ताकि सीआरयूडी ऑपरेशंस और सॉकेट हेरफेर सही वर्कफ़्लो में हो। यहां समस्या यह थी कि माना जाता है कि ईजेबी से धागे बनाने का एक बुरा अभ्यास माना जाता है और यह विशिष्ट अनुपालन नहीं है (भले ही सिंगलटन जीवन चक्र सही तरीके से संभाला जा सके और उचित सिंक्रनाइज़ेशन तंत्र हो?)।

3. (एक और सिंगलटन?) डोमेन मॉडल में धागे रखो और EJBs मॉडल का उपयोग कर सकते है। यह उन सभी में से सबसे खराब था क्योंकि एप्लिकेशन सर्वर में एकाधिक क्लासलोडर होते हैं, सामान्य रूप से कम कंटेनर समर्थन होते हैं, साथ ही यह सबकुछ से पीड़ित होता है 2. इससे पीड़ित होता है।

किसी भी विचार कैसे सही ढंग से जावा ईई में इस स्थिति से निपटने के लिए?

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

Answer 1

आपका विश्लेषण उचित लगता है, और तुम सही हो जब आप कहते हैं कि आप को तैनात नहीं कर सकते एमडीबी गतिशील JCA साथ फिट करने के लिए।

कुछ अधिक डिजाइन विचारों:

• आप एक JCA कनेक्टर कि SocketConnections रिटर्न (JMS की भावना में) लिख सकता है, कि तुम एक सॉकेट से पढ़ने के लिए इस्तेमाल कर सकते हैं। जेएमएस अनुरूपता के साथ जारी रखने के लिए, एमडीबी MessageListener का प्रतिनिधित्व करता है, जबकि आप जो खुलासा करेंगे, वह MessageConsumer है।

• आप एक आवधिक टाइमर का उपयोग एक धागा अनुकरण करने के लिए कर सकता है। थोड़ी देर के लूप के साथ धागे के बजाय, आपके पास एक टाइमर होता है जो स्वयं को पुनर्निर्धारित करता है। मैंने इसका इस्तेमाल एक ऐप के लिए पृष्ठभूमि प्रक्रिया करने के लिए किया था, और यह ठीक काम करता था। ध्यान दें कि मैंने ईजेबी से किसी अन्य ऐप में कुछ समवर्ती गणना करने के लिए धागे को भी बनाया है, और यह भी ठीक काम करता है। लेकिन धागे जहां अल्पकालिक रहते हैं और बीन में व्यापार विधि पूरी तरह से इंतजार कर रही है, इसलिए यह कल्पना का एक बड़ा उल्लंघन नहीं था।

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

मैं # 3 के लिए जाना होगा, अगर विकास समय अनुमति देता है।

संपादित

इस चुनाव वास्तव में आंशिक रूप से डिजाइन पवित्रता का एक सवाल है। हालांकि उपयोगकर्ता द्वारा उत्पन्न धागे के साथ एक समस्या यह है कि आप स्पष्ट रूप से उनके लिए घोषणात्मक लेनदेन का उपयोग नहीं कर सकते हैं। यद्यपि लेनदेन को निर्धारित करने के लिए आप शायद UserTransaction का उपयोग कर सकते हैं। मुझे नहीं पता कि आप इस तरह के धागे में EntityManager का उपयोग कैसे कर सकते हैं। यदि आप अधिकतर डेटा संसाधित करते हैं और मिडलवेयर की अधिक सुविधाओं का उपयोग नहीं करते हैं, तो आप अपने आप को थ्रेड कर सकते हैं। मेरा एक और जवाब देखें: How can an EJB parallelize a long, CPU intensive process?। अन्य चीजें जो मेरे दिमाग में आती हैं (पता नहीं है कि वे समस्याग्रस्त हैं या नहीं): सुरक्षा प्रबंधक थ्रेड (?) बनाने से रोक सकता है, उन्हें deamon threads के रूप में नहीं बना सकता है, जो ऐप को रोक सकता है। सर्वर ठीक से बंद (?) से। ध्यान दें कि मैंने स्टार्टअप पर ServeletContextListener से धागे पैदा किए और यह बहुत अच्छा काम किया। यह एक चाल है जो अक्सर प्रयोग की जाती है भले ही यह spec का उल्लंघन करता है। यह "नव" पेश किए गए सिंगलटन बीन्स के लिए भी सच हो सकता है। इसलिए, यदि आप समय पर कम हैं तो आप निश्चित रूप से सिंगलटन बीन के साथ अपने प्रस्ताव का प्रयास कर सकते हैं और देख सकते हैं कि क्या काम करता है/नहीं।

Answer 2

मुझे यकीन है कि # 2 सबसे अच्छा समाधान है (और यह भी मान्य है)। मैंने नए "सिंगलटन" ejb के लिए spec को नहीं देखा है, लेकिन मेरी धारणा यह है कि इनमें से थ्रेडिंग स्वीकार्य होगी (मान लीजिए कि इन ejbs के अंदर अपना स्वयं का सिंक्रनाइज़ेशन करना स्वीकार्य है)। इन्हें प्रबंधन प्रकार सेवाओं को तैनात करने के लिए आसान (ier) बनाने के लिए डिज़ाइन किया गया था, जिसे आप पहले जेएमएक्स का उपयोग कर सकते थे (हालांकि तैनाती को मानकीकृत नहीं किया गया था)। जेएमएक्स एमबीन के भीतर, यह निश्चित रूप से आपके धागे प्रबंधन, करने के लिए स्वीकार्य होगा, इसलिए मैं इसे सिंगलटन ejbs पर ले जाऊंगा।

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