के लिए अलग-अलग रिमोट और स्थानीय इंटरफेस की आवश्यकता क्यों है, मुझे आश्चर्य हुआ कि हमें ईजेबी 3.0 सत्र बीन्स के लिए अलग रिमोट और स्थानीय इंटीफेस की आवश्यकता क्यों है। मुझे लगता है कि ज्यादातर समय वे दोनों एक ही अनुबंध को परिभाषित करेंगे। मेरे पास एक आम इंटरफ़ेस क्यों नहीं हो सकता है और मेरे बीन में मुझे बस यह कहने में सक्षम होना चाहिए कि मैं चाहता हूं कि इस बीन को दूरस्थ रूप से और/या स्थानीय रूप से एक्सेस किया जाए।हमें ईजेबी 3.0 सत्र बीन्स
धन्यवाद विकास
मैं सहमत नहीं हूँ कि डिजाइन समय में दूरस्थ और स्थानीय तुच्छता से अंतर-अस्थिर रूप में व्यवहार किया जाना चाहिए।
सबसे पहले, दूरस्थ आमंत्रण में ओवरहेड हैं, इसलिए रिमोट इंटरफेस को डिज़ाइन करते समय आपको ध्यान से विचार करने की आवश्यकता है कि क्या आपको ग्रैन्युलरिटी और पैरामीटर आकार सही हैं। तो एक अनुस्मारक यह तुलनात्मक रूप से महंगा होने वाला है एक डिजाइनर के रूप में सहायक है।
इसके अलावा, यह देखते हुए कि रिमोट इंटरफेस पैरामीटर मान द्वारा पारित किए जाते हैं और स्थानीय इंटरफेस पैरामीटर संदर्भ द्वारा पारित किए जाते हैं, दोनों मामलों के बीच मौलिक अर्थपूर्ण मतभेद हैं इसलिए आप दो इंटरफेस को अलग-अलग डिजाइन करना चुन सकते हैं।
"स्थान पारदर्शिता" की धारणा एक खतरनाक विरोधी-पैटर्न है। आपके डिज़ाइन को पूरी तरह से यह जानने की ज़रूरत है कि क्या यह स्थानीय कॉल या रिमोट कॉल कर रहा है, कई कारणों से (त्रुटि प्रबंधन और प्रदर्शन सबसे स्पष्ट है)।
रिमोट ईजेबी इंटरफेस उनके स्थानीय समकक्षों से अलग हैं क्योंकि अपवाद हस्ताक्षर नेटवर्किंग से संबंधित त्रुटियों को समायोजित करने के लिए अलग होना चाहिए जो केवल रिमोट कॉल पर हो सकते हैं। रिमोट हैंडलिंग बैगेज को स्थानीय इंटरफ़ेस में जोड़ना (जैसा कि ईजेबी 1 में मामला था) कोड को भयानक बनाता है। ईजेबी 2 ने ईजेबी के लिए प्रोग्रामिंग को सरल बनाने के लिए अलग-अलग स्थानीय इंटरफेस पेश किए जो हमेशा स्थानीय थे।
मुझे लगता है कि सवाल यह है कि इंजेक्शन घोषित करते समय मैं इसे क्यों नहीं चुन सकता? –
यह वही है EJB कल्पना का कहना है:
स्थानीय और दूरस्थ प्रोग्रामिंग मॉडल के बीच विकल्प एक डिजाइन निर्णय है कि बीन प्रदाता जब उद्यम सेम विकासशील बनाता है।
हालांकि एक रिमोट क्लाइंट व्यू और एंटरप्राइज़ बीन के लिए स्थानीय क्लाइंट व्यू दोनों प्रदान करना संभव है, अधिक आम तौर पर केवल एक या दूसरा प्रदान किया जाएगा।
तो जब लेखन एक सेम जो ग्राहक है के बारे में सोचते हैं, यह बहुत संभावना नहीं है कि एक स्थानीय ग्राहक एक ही तरीके का या यहां तक कि एक ही सेम कि एक दूरस्थ एक की आवश्यकता होगी है।
एक अच्छा कारण यह है कि आप अपने इंटरफेस के माध्यम से ईजेबी तक पहुंचते हैं। एक दूरस्थ इंटरफ़ेस का उपयोग करते समय और स्थानीय इंटरफ़ेस का उपयोग करते समय संदर्भ द्वारा आप मूल्य से पैरामीटर पास करते हैं। और क्या आप जानते हैं कि यह व्यवहार क्यों? यह समझ में आता है: हो सकता है कि आप एक दूरस्थ एप्लिकेशन को अपने व्यावसायिक ऑब्जेक्ट तक पहुंचना चाहते हैं और क्योंकि संदर्भ द्वारा पास नेटवर्क विलंबता को कम कर देता है। याद रखें: रिमोट एक्सेस में ऑब्जेक्ट को बाइट स्ट्रीम में बदलने की प्रक्रिया शामिल है - मार्शलिंग - और एक ऑब्जेक्ट में बाइट स्ट्रीम को चालू करने की प्रक्रिया - अनारशलिंग। यह अतिरिक्त कदम - मार्शलिंग और unmarshaling - आवेदन के प्रदर्शन को धीमा कर देता है।
'... क्योंकि मूल्य से गुजरने से नेटवर्क विलंबता कम हो जाती है। मुझे लगता है कि आपने इसे थोड़ा तेज़ी से टाइप किया है, क्योंकि यह सिर्फ दूसरा रास्ता है: ** संदर्भ ** द्वारा पारित करें ** नेटवर्क _traffic_ (मामूली विस्तार) को कम करता है :) –
@ ᴠɪɴᴄᴇɴᴛ धन्यवाद! –
मुझे विश्वास है कि जब आपके व्यवसाय की जरूरत है स्थानीय में अपने सभी तरीकों में भी दूरस्थ क्लाइंट के संपर्क में रहने की जरूरत है, तो
इस प्रतिनिधि दृष्टिकोण @Local & @ उसी इंटरफ़ेस को रिमोट करने के लिए चारों ओर एक काम हो सकता है। किसी भी प्रदर्शन ओवरहेड के साथ, आवश्यक होने पर और यदि आवश्यक हो तो दूरस्थ रूप से उसी विधि को एक्सेस किया जा सकता है।
यह मेरा विचार है। किसी को कृपया इसे सत्यापित करने के लिए अपने विचारों को बताएं।
यह एक दिलचस्प विचार है, क्या आपको पता चला कि आपका विचार सही है?यह वास्तव में उपरि उत्पन्न नहीं करेगा। मेरे पास इसके बारे में एक ही सवाल है, http://stackoverflow.com/questions/6361937/application-client-access-ejb-on-glassfish-via-a-remote-interface-can-i-do-it-vi। मैं उम्मीद कर रहा था कि आप यहां कुछ विचार प्रदान कर सकते हैं। tyvm –
ग्राहक बीन के इंटरफेस के माध्यम से एक सत्र या इकाई बीन तक पहुंचते हैं। ईजेबी कंटेनर इस व्यवहार को लागू करने और प्रबंधित करने के लिए इंटरफ़ेस कार्यान्वयन उत्पन्न करता है, जो ग्राहक और बीन के बीच संचार के लिए एक संवहनी के रूप में कार्य करता है। ईजेबी 2.0 विनिर्देश से पहले संस्करणों में, सभी बीन्स को वितरित, दूरस्थ घटकों के रूप में परिभाषित और कार्यान्वित किया गया था। नतीजतन, बीन्स की आवश्यकता वाले दो इंटरफेस को होम इंटरफ़ेस (जो सामान्य रूप से, जीवन चक्र विधियों को परिभाषित करता है) और दूरस्थ इंटरफ़ेस (जो सामान्य रूप से, कार्यात्मक व्यावसायिक तरीकों को परिभाषित करता है) कहा जाता था।
Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides many benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network.
Considerations of performance, practicality, and typical usage in the field resulted in the introduction of local interfaces in the EJB 2.0 specification. As noted, prior terminology referred to the home interface and the remote interface; at this point, depending on which approach is used, local interface and local home interface or remote interface and remote home interface are better terms. Either of the local home or remote home interfaces is referred to as the home interface; either of the local or remote interfaces is referred to as the component interface. This tutorial refers to the interfaces in these terms and uses these conventions for names.
When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both. However, the client must write to a specific (that is, local or remote) interface. There are some issues to keep in mind when using local interfaces:
बीन्स एक ही वीएम में चलने चाहिए - वे सभी के बाद स्थानीय हैं। पैरामीटर्स को प्रतिलिपि बनाने के बजाय संदर्भ द्वारा भेजा जाता है, जैसा रिमोट इंटरफेस और ऑब्जेक्ट्स के मामले में होता है। अप्रत्याशित दुष्प्रभाव का परिणाम हो सकता है यदि आप इस भेद को अनदेखा करते हैं और तदनुसार कोड नहीं करते हैं। आमतौर पर, स्थानीय या दूरस्थ पहुंच का उपयोग करने का निर्णय प्रभावित होता है:
क्लाइंट का प्रकार - जब तक आप हमेशा क्लाइंट को वेब घटक या अन्य बीन होने की अपेक्षा नहीं करते हैं, तो दूरस्थ पहुंच चुनें।
चाहे सेम कसकर या ढीले ढंग से युग्मित हों - यदि सेम एक दूसरे पर निर्भर करते हैं और अक्सर बातचीत करते हैं, तो स्थानीय पहुंच पर विचार करें।
स्केलेबिलिटी - रिमोट एक्सेस स्वाभाविक रूप से स्केलेबल है और इसका उपयोग किया जाना चाहिए यदि स्केलेबिलिटी एक महत्वपूर्ण कारक है। ईजेबी 2.0 विनिर्देशन में स्थानीय इंटरफेस के आगमन के साथ, अधिकांश स्रोतों की सिफारिश है कि इकाई सेम लगभग हमेशा स्थानीय पहुंच पर आधारित होना चाहिए। स्थानीय इंटरफेस के साथ, बहुत बढ़िया डेटा पहुंच के संबंध में अधिकांश प्रदर्शन मुद्दे दूर हो जाते हैं। यदि ग्राहक रिमोट है, तो मानक डिज़ाइन पैटर्न में क्लाइंट एक सत्र बीन तक पहुंचने के लिए रिमोट इंटरफ़ेस का उपयोग करता है, जो तब इकाई बीन के संपर्क के रूप में कार्य करता है। सत्र बीन एक स्थानीय इंटरफ़ेस के माध्यम से इकाई बीन के साथ संचार करता है (पैटर्न दृष्टिकोण से, इस तकनीक को सत्र फ़ैकेड कहा जाता है, और इसका उपयोग वास्तव में दूरस्थ या स्थानीय संदर्भ में किया जा सकता है)।
अच्छा पाठ, सिवाय इसके कि सत्र बीन्स इकाई सेम के साथ संवाद नहीं करते हैं। नाम शायद थोड़ा उलझन में हैं, लेकिन इन दिनों सत्र बीन्स समुदाय एक इकाई प्रबंधक (जेपीए) इकाइयों को प्राप्त करने के लिए समुदाय के साथ। –
मैं मानता हूं कि कई मामलों में मुझे दोनों के लिए अलग-अलग इंटरफेस डिजाइन करना पड़ सकता है, लेकिन जिन मामलों में मेरे पास दो के लिए एक ही इंटरफेस है, मैं इसे स्थानीय और रिमोट दोनों के साथ एनोटेट करने में सक्षम होना चाहिए। इसका लाभ यह है कि मेरे क्लाइंट को यह चिंता करने की ज़रूरत नहीं है कि क्या यह स्थानीय या दूरस्थ आमंत्रण है (सिवाय जब वह jndi नाम निर्दिष्ट कर रहा हो)। यह दोनों मामलों में एक ही इंटरफेस प्राप्त करेगा ताकि यह दोनों समान रूप से इलाज कर सके। –
अच्छा, बेहतर या बदतर के लिए, spec लेखकों ने इस बात से सहमत नहीं था कि ऐसी "स्थानीय/दूरस्थ आजादी" वांछनीय है। निजी तौर पर, मैं इस बारे में विशिष्ट लेखकों से सहमत हूं। – djna