2011-10-11 10 views
71

मैं समझने की कोशिश कर रहा हूं कि उद्देश्य क्या है और हमें ईजेबी में विभिन्न ग्राहक विचारों की आवश्यकता क्यों है। क्या कोई समझाने की कोशिश कर सकता है?ईजेबी में स्थानीय/दूरस्थ और नो-इंटरफेस दृश्य क्या है?

उत्तर

111

रिमोट ग्राहक दृश्य

जब आपके EJB और उसके ग्राहकों के एक वितरित वातावरण में हो जाएगा - जिसका अर्थ है EJBs और ग्राहकों अलग जावा आभासी मशीनों पर निवास करेंगे। उदाहरण: ईजेबी वेबस्पेयर एप्लिकेशन सर्वर और सर्वलेट्स पर होस्ट किए गए हैं जो टॉमकैट सर्वर पर होस्ट किए गए ईजेबी एपीआई का उपभोग करते हैं।

स्थानीय ग्राहक दृश्य

केवल जब यह गारंटी है कि अन्य उद्यम सेम या ग्राहकों के केवल एक ही JVM भीतर सेम संबोधित करेंगे। उदाहरण, ईजेबी के साथ-साथ उसी वेबस्पेयर सर्वर पर तैनात सर्वलेट्स।

कोई इंटरफ़ेस दृश्य

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

के बीच

अंतर नहीं-इंटरफेस देखने के लिए, ग्राहक और लक्ष्य सेम के मामले में एक ही आवेदन (ईएआर) में पैक किया जाना चाहिए। स्थानीय दृश्य के मामले में, ग्राहक को एंटरप्राइज़ एप्लिकेशन की तुलना में एक अलग एप्लिकेशन में पैक किया जा सकता है। इसलिए, यह आपके घटकों को ठीक करने के मामले में अधिक लचीलापन देता है।

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

कारण

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

+4

मुझे आश्चर्य है कि यह वास्तव में मामला है, कि स्थानीय क्लाइंट व्यू का उपयोग विभिन्न एंटरप्राइज़ अनुप्रयोगों के बीच किया जा सकता है। ईजेबी 3.2 विनिर्देशन में, खंड 3.2.2 में, यह कहा गया है कि स्थानीय क्लाइंट दृश्यों के माध्यम से विभिन्न अनुप्रयोगों से बीन्स का आह्वान करना विक्रेता विशिष्ट है और कंटेनर में समर्थित नहीं हो सकता है। आपके मन में कोई विशिष्ट ऐप सर्वर था? – mcmil

+0

क्या होता है? अगर हम एक ईजेबी "नया" करते हैं (यह तब हो सकता है जब क्लाइंट और ईजेबी एक ही एप्लीकेशन में रहें) – lovespring

+2

यदि आप 'नया' का उपयोग करते हैं तो आप एक नया उदाहरण प्राप्त कर लेते हैं। बस इतना ही। उस नए उदाहरण में पूलिंग के मामले में कंटेनर से कोई "समर्थन" नहीं होगा, इसके संदर्भ को स्थापित करना आदि। आप अपने आप चल रहे हैं। –

3

की धारा 3.2.2 के रूप में EJB 3.1 विशिष्टता की:

स्थानीय ग्राहक दृश्य के माध्यम से एक उद्यम सेम को

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

नो-इंटरफ़ेस दृश्य केवल एक सुविधा सुविधा है जो पर एक बीन को एक अलग ग्राहक दृश्य का खुलासा करता है बिना अलग इंटरफ़ेस घोषित किए।

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