WARs सत्र जानकारी साझा क्यों नहीं कर सकते?

Question

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

मैंने जो कुछ भी खोजा है, उसमें कंटेनर के आधार पर कुछ विशिष्ट समाधान हैं, लेकिन यह किसी तरह ' विनिर्देश के विपरीत ' है। मैंने जावा ईई विनिर्देश के माध्यम से उत्तर खोजने पर बिना किसी भाग्य के देखा है।

कुछ डेवलपर्स वेब अनुप्रयोगों के बीच युग्मन के बारे में बात करते हैं, लेकिन मैं असहमत हूं। क्या कारण है कि कपलिंग नहीं होने पर उसी EAR के अंदर WAR को रखा जाएगा? उदाहरण के लिए, EJBs को स्थानीय रूप से एक्सेस किया जा सकता है (भले ही उसी EAR के भीतर एक और EJB JAR के अंदर)।

अधिक विशेष रूप से, मेरे WARs में से एक प्रमाणीकरण और प्राधिकरण को संभालता है, और मैं इस जानकारी को अन्य WAR (उसी EAR में) के साथ साझा करना चाहूंगा। मैं पहले भी इसी तरह की समस्याओं पर काम कर चुका हूं, जैसे WARs को JAR की पैकेजिंग करके और उन्हें एक विलार WAR प्रोजेक्ट (WEB-INF / lib) में डालकर। फिर भी मुझे यह समाधान पसंद नहीं है (इसे सर्वलेट नामकरण और इतने पर एक बड़े प्रयास की आवश्यकता है)।

और किसी भी समाधान ने पहले (और सबसे महत्वपूर्ण) प्रश्न का उत्तर नहीं दिया है: WARs सत्र की जानकारी साझा क्यों नहीं कर सकते?

Comments

यह सुनिश्चित नहीं किया गया कि इसे डाउनवोट क्यों किया गया था, इसके अलावा यह एसओ के लिए बेहतर फिट हो सकता है।

— 21

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

(बेहतर, वर्तमान लिंक HttpSession के लिए )

@ मिचेल्ट, धन्यवाद। लेकिन यह अभी भी क्यों जवाब नहीं देता है।

— 23

@ नैटडॉट्स भले ही प्रश्न विशिष्ट प्रौद्योगिकियों से संबंधित हो, मेरा मानना ​​था कि यह एक वैचारिक प्रश्न होने की अधिक संभावना थी। फिर, मैंने प्रोग्रामर्स के लिए फैसला किया।

— rvcoutinho

Answer 1

एक ईएआर का इलाज एक छद्म आभासी मशीन की तरह करें

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

उसी तरह जिस तरह एक आभासी मशीन पर एक प्रक्रिया दूसरे को प्रभावित नहीं कर सकती है, वही एक ईएआर के लिए सही है। सभी WAR को उनकी आंतरिक स्थिति की सुरक्षा के लिए पृथक किया जाता है।

स्केलिंग प्रमाणीकरण

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

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

प्रासंगिक जानकारी तक त्वरित कैश्ड पहुंच पर ध्यान केंद्रित करने से कुछ जटिल, नाजुक सत्र साझाकरण समाधान की तुलना में अधिक मापनीय परिणाम मिलेंगे।

Comments

धन्यवाद, @GaryRowe यह वह उत्तर है जिसकी मुझे तलाश थी। वैसे भी, यह तय करने के लिए डेवलपर के लिए नहीं हो सकता है?

— rvcoutinho

एक और सवाल: क्या आपको लगता है कि JBoss कैश एक अच्छा समाधान हो सकता है? क्या आपने अपाचे शेरो (और इसके सत्र क्लस्टरिंग) के बारे में सुना है? इसके बारे में क्या है?

— rvcoutinho

@rvcoutinho क्या एप्लिकेशन डेवलपर तय करता है कि लिनक्स कर्नेल में प्रक्रियाओं का प्रबंधन कैसे किया जाता है? यह एक प्रश्न के समान है - हाँ, आप इसे कर सकते हैं लेकिन यह बहुत कठिन होने जा रहा है और शायद आपको वैकल्पिक पथ लेने की तुलना में अधिक दर्द हो सकता है।

— गैरी रोवे

@rvcoutinho मैंने अपाचे शिरो (उर्फ अपाचे सिक्योरिटी) का उपयोग नहीं किया है, लेकिन मुझे लगता है कि यह साझा सुरक्षा मुद्दे का एक अच्छा समाधान होगा। निश्चित रूप से एक ही चीज़ को प्राप्त करने के लिए अपने स्वयं के प्रोटोकॉल को रोल करने के बजाय OpenID और OAuth2 के साथ एकीकृत करने पर विचार करें। JBoss Cache को उनके खुद के प्रवेश द्वारा एक मृत अंत में Infinispan के साथ प्रतिस्थापित किया जा रहा है जो जटिल दिखता है। आप एक सरल और अधिक स्केलेबल समाधान की एक झलक के लिए बारह फैक्टर ऐप साइट पर एक नज़र रखना चाहते हैं।

— गैरी रोवे

Answer 2

यह ऐसा कुछ है जो मुझे लगता है कि जेईई ईएआर विनिर्देश से कार्यक्षमता गायब है - एक ईएआर के भीतर बंधे कई वेब अभिलेखागार में वेब सत्र साझा करने की क्षमता।

इस तरह की कार्यक्षमता के लिए वेबलॉजिक जैसे ऐप सर्वर में गैर एसटीडी कार्यान्वयन हैं।

Comments

अब तक मेरी यही राय थी। मैं यह समझने की कोशिश कर रहा था कि उल्लिखित विकल्प क्यों बनाया गया था।

— rvcoutinho

Answer 3

खैर, AFAIKS, कोई वास्तविक कारण नहीं है कि आप ऐसा क्यों करना चाहते हैं। एक WAR एक स्व-निहित वेब अनुप्रयोग है, यह स्वयं (वेब ​​अनुप्रयोग विशिष्ट) स्कोप्स (जैसे सत्र गुंजाइश) है। यदि आपको कार्यक्षमता (जावा कोड, जेएसपी पेज, सीएसएस फ़ाइलें) साझा करने की आवश्यकता है, तो कई WARs के बीच आपके पास JAR फ़ाइलों के रूप में उन्हें पैकेजिंग करने और उन्हें अपने एप्लिकेशन सर्वर में तैनात करने का अधिक समझदार विकल्प है। एक WAR पैकेज एक अधिक जटिल पैकेजिंग समाधान है, और एक सरल "सामान्य कोड / कार्यक्षमता" की तुलना में कुछ अलग करने के लिए डिज़ाइन किया गया है। JAR एक सरल प्रारूप है और पैकेजिंग और साझाकरण कोड और कार्यक्षमता के लिए डिज़ाइन किया गया है। आप कुछ साझा करने के लिए एक और अधिक जटिल और विशिष्ट-विशिष्ट-डिज़ाइन किए गए-पैकेजिंग का उपयोग क्यों करना चाहते हैं, जब आपके पास पहले से उपलब्ध एक सरल और अधिक-अनुकूल-से-पैकेज का प्रारूप है।

Comments

मैं आपसे सहमत हुँ। लेकिन केवल जब यह सामान्य संसाधनों के लिए आता है। लेकिन, एकल साइन-ऑन एप्लिकेशन के लिए, मुझे सत्र विशिष्ट जानकारी (लॉग किए गए उपयोगकर्ता के बारे में) को साझा करने की आवश्यकता होगी। और मुझे कोई कारण नहीं दिखता कि यह कल्पना के खिलाफ क्यों होगा।

— 23

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

— शिवन ड्रैगन ०

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

— rvcoutinho

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

— rvcoutinho

@rvcoutinho अच्छी तरह से, इस मामले पर मेरी राय है, क्षमा करें यह आपके लिए अधिक उपयोगी नहीं था।

— शिवन ड्रैगन

Answer 4

मुझे लगता है कि यह उद्देश्य पर किया गया था, विभिन्न वेब ऐप्स से गलती से एक-दूसरे सत्र की जानकारी को अधिलेखित करने से बचने के लिए। यह आपके मामले में काम आ सकता है, लेकिन सामान्य तौर पर, आप नहीं चाहते हैं कि उपयोगकर्ता ऐप को क्रैश करें या अपने विशेषाधिकारों को केवल इसलिए बढ़ा दें क्योंकि वे एक ही समय में दो वेब ऐप का उपयोग करते हैं। वेब एप्लिकेशन के बीच जानकारी साझा करना बिल्कुल मुश्किल नहीं है; स्थिर HashMap के साथ एक वर्ग बनाएं, GUID को कुंजियों के रूप में उपयोग करें और उन्हें URL या HTTP पैरामीटर के भाग के रूप में स्थानांतरित करें।

Comments

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

— rvcoutinho