java - OSGI वातावरण में निर्भरता इंजेक्शन




dependency-injection guice (4)

पहले कुछ पृष्ठभूमि:

मैं अपाचे स्लिंग जो OSGI आधारित है और अपाचे फेलिक्स पर आधारित है, पर आधारित कुछ वेबएप्प प्रोटोटाइप कोड पर काम कर रहा हूं। मैं अभी भी OSGI के लिए अपेक्षाकृत नया हूं, हालांकि मुझे लगता है कि मैंने अब तक अधिकांश अवधारणाओं को समझ लिया है। हालाँकि, मुझे कौन सी पहेलियां हैं कि मैं "पूर्ण" निर्भरता इंजेक्शन (DI) ढांचे को खोजने में सक्षम नहीं हूं। मैंने डिक्लेरेटिव सर्विसेज (डीएस) का उपयोग करके अल्पविकसित डीआई को सफलतापूर्वक नियोजित किया है। लेकिन मेरी समझ यह है कि डीएस का उपयोग संदर्भ के लिए किया जाता है - मैं इसे कैसे डालूं? - OSGI पंजीकृत सेवाओं और घटकों को एक साथ। और इसके लिए यह ठीक काम करता है, लेकिन मैं व्यक्तिगत रूप से पूरे फ्रेम ग्राफ को एक साथ तार करने के लिए Guice जैसे DI फ्रेमवर्क का उपयोग करता हूं और वस्तुओं को सही दायरे में @SessionScoped (लगता है कि @SessionScoped या @SessionScoped उदाहरण के लिए)। हालाँकि, मैंने जिस OSGI विशिष्ट ढांचे को देखा है, उनमें से कोई भी इस अवधारणा का समर्थन नहीं करता है।

मैंने OSGI ब्लूप्रिंट और iPOJO बारे में पढ़ना शुरू कर दिया है, लेकिन ये रूपरेखाएँ पूर्ण DI समाधान प्रदान करने की तुलना में एक साथ वायरिंग OSGI सेवाओं के साथ अधिक चिंतित हैं। मुझे यह स्वीकार करना होगा कि मैंने अभी तक कोई नमूना नहीं लिया है, इसलिए मेरी धारणा गलत हो सकती है।

Guice का एक विस्तार होने के नाते, मैंने Peaberry साथ प्रयोग किया है, हालांकि मुझे खोजने के लिए प्रलेखन बहुत कठिन लगा, और जब मुझे बुनियादी DI काम करने लगे, तो बहुत-सी गाइस-सर्वलेट की उन्नत कार्यक्षमता (फ़िल्टर, सर्वलेट्स आदि में स्वचालित इंजेक्शन) नहीं किया। ' काम बिल्कुल नहीं।

तो, मेरे प्रश्न निम्नलिखित हैं:

  1. कैसे घोषणात्मक सेवाओं की तुलना "पारंपरिक" DI जैसे Guice या Spring से की जाती है? क्या वे एक ही समस्या का समाधान करते हैं या वे अलग-अलग समस्याओं की ओर बढ़ रहे हैं?
  2. सभी OSGI विशिष्ट समाधान मैंने अब तक DI के लिए स्कोप की अवधारणा का अभाव देखा है। उदाहरण के लिए, Guice + guice-servlet ने scoped निर्भरता का अनुरोध किया है जो वेब एप्लिकेशन को वास्तव में साफ और आसान बनाता है। क्या मुझे सिर्फ यह याद था कि डॉक्स में या इन चिंताओं में से किसी भी फ्रेमवर्क द्वारा कवर नहीं किया गया है?
  3. क्या JSR 330 और OSGI आधारित DI दो अलग-अलग दुनिया हैं? उदाहरण के लिए iPOJO अपने स्वयं के एनोटेशन लाता है और फेलिक्स एससीआर एनोटेशन एक पूरी तरह से अलग दुनिया लगती है।
  4. क्या किसी के पास OSGI आधारित सिस्टम और DI के निर्माण का अनुभव है? शायद गिटहब पर भी कुछ नमूना कोड?
  5. क्या कोई भी एक साथ Guice और iPOJO जैसी विभिन्न तकनीकों का उपयोग करता है या यह सिर्फ एक पागल विचार है?

बल्कि लंबे प्रश्न के लिए क्षमा करें।

किसी भी प्रतिक्रिया का स्वागत है।

अपडेट

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

JSR 330 बनाम DS : आपके सभी उत्कृष्ट उत्तरों से मुझे लगता है कि ये दो अलग-अलग चीजें हैं। यह सवाल है कि, OSG संदर्भ में उपयोग किए जाने पर JSR 330 एनोटेशन का उपयोग करने वाले थर्ड पार्टी लाइब्रेरी और फ्रेमवर्क से कैसे निपटा जाए? एक अच्छा तरीका क्या है? बंडल के भीतर एक जेएसआर 330 कंटेनर चल रहा है?

मैं आपके सभी उत्तरों की सराहना करता हूं, आप बहुत मददगार रहे हैं!


समग्र दृष्टिकोण

अपाचे स्लिंग के साथ निर्भरता इंजेक्शन लगाने का सबसे सरल तरीका, और पूरे कोडबेस में उपयोग किया जाने वाला maven-scr-plugin का उपयोग करना है।

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

उदाहरण के लिए, एक सर्वलेट पंजीकृत करने के लिए आप निम्नलिखित कार्य कर सकते हैं:

@Component // signal that it's OSGI-managed
@Service(Servlet.class) // register as a Servlet service
public class SampleServlet implements Servlet {   
   @Reference SlingRepository repository; // get a reference to the repository    
}

विशिष्ट उत्तर

कैसे घोषणात्मक सेवाओं की तुलना "पारंपरिक" DI जैसे Guice या Spring से की जाती है? क्या वे एक ही समस्या का समाधान करते हैं या वे अलग-अलग समस्याओं की ओर बढ़ रहे हैं?

वे एक ही समस्या का समाधान करते हैं - निर्भरता इंजेक्शन। हालाँकि (नीचे देखें) वे डायनेमिक सिस्टम को ध्यान में रखने के लिए भी बनाए गए हैं जहाँ सेवाएँ किसी भी समय दिखाई या गायब हो सकती हैं।

सभी OSGI विशिष्ट समाधान मैंने अब तक DI के लिए स्कोप की अवधारणा का अभाव देखा है। उदाहरण के लिए, Guice + guice-servlet ने scoped निर्भरता का अनुरोध किया है जो वेब एप्लिकेशन को वास्तव में साफ और आसान बनाता है। क्या मुझे सिर्फ यह याद था कि डॉक्स में या इन चिंताओं में से किसी भी फ्रेमवर्क द्वारा कवर नहीं किया गया है?

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

चूंकि आप स्लिंग का उपयोग कर रहे हैं, मुझे लगता है कि सत्र-स्कोप या अनुरोध-स्कोप बाइंडिंग के लिए बहुत कम आवश्यकता होगी क्योंकि स्लिंग ने प्रत्येक अनुरोध के लिए ऑब्जेक्ट बनाए हैं जो वर्तमान उपयोगकर्ता के लिए उचित रूप से बनाए गए हैं।

एक अच्छा उदाहरण जेसीआर सत्र है। यह स्वचालित रूप से सही विशेषाधिकारों के साथ निर्मित किया गया है और यह एक अनुरोधित scoped DAO है। वही गोफन संसाधन के लिए जाता है।

यदि आप स्वयं को प्रति उपयोगकर्ता के काम की आवश्यकता पाते हैं, तो सबसे आसान तरीका यह है कि ऐसी सेवाएँ प्राप्त करें जो JCR Session या एक स्लिंग ResourceResolver Resolver प्राप्त करें और उन कार्यों का उपयोग करें जिनकी आपको आवश्यकता है। परिणाम बिना किसी अतिरिक्त प्रयास के वर्तमान उपयोगकर्ता के विशेषाधिकारों के लिए स्वचालित रूप से समायोजित हो जाएंगे।

क्या JSR 330 और OSGI आधारित DI दो अलग-अलग दुनिया हैं? उदाहरण के लिए iPOJO अपने स्वयं के एनोटेशन लाता है और फेलिक्स एससीआर एनोटेशन एक पूरी तरह से अलग दुनिया लगती है।

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

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

यह लचीलापन का एक बड़ा सौदा है जो OSGi आपको देता है।

क्या किसी के पास OSGI आधारित सिस्टम और DI के निर्माण का अनुभव है? शायद गिटहब पर भी कुछ नमूना कोड?

स्लिंग नमूने SVN रिपॉजिटरी में बड़ी संख्या में नमूने हैं। आपको वहां सबसे ज्यादा चाहिए जो आपको चाहिए।

क्या कोई भी एक साथ Guice और iPOJO जैसी विभिन्न तकनीकों का उपयोग करता है या यह सिर्फ एक पागल विचार है?

यदि आपके पास चौखटे हैं जो जेएसआर 330 एनोटेशन के साथ कॉन्फ़िगर किए गए हैं, तो यह समझ में आता है कि उन्हें गुइसे या स्प्रिंग या जो भी आपके लिए काम करता है, रनटाइम पर कॉन्फ़िगर करें। हालांकि, जैसा कि नील बार्टलेट ने कहा है, यह क्रॉस-बंडल का काम नहीं करेगा।


मुझे मेष ब्लूप्रिंट का उपयोग करके अनुप्रयोगों के निर्माण में कुछ अनुभव है। इसमें OSGi सेवाओं और कॉन्फिग एडमिन सपोर्ट के बारे में कुछ बहुत अच्छी विशेषताएं हैं।

यदि आप कुछ महान उदाहरणों की खोज करते हैं तो अपाचे करफ के कोड पर एक नज़र डालते हैं जो अपने सभी तारों के लिए ब्लूप्रिंट का उपयोग करता है। http://svn.apache.org/repos/asf/karaf/ देखें

मेरी वेबसाइट पर ब्लूप्रिंट और अपाचे करफ के लिए कुछ टॉर्टोरियल भी हैं: http://www.liquid-reality.de/display/liquid/Karaf+Tutorials

एम्बेडेड फेलिक्स के साथ आपके वातावरण में यह थोड़ा अलग होगा क्योंकि आपके पास करफ की प्रबंधन विशेषताएं नहीं हैं, लेकिन आपको बस एक ही बंडल स्थापित करने की आवश्यकता है और इसे अच्छी तरह से काम करना चाहिए।


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


मैं विशेष रूप से JSR330 और DS के संबंध में, रॉबर्ट के उत्कृष्ट उत्तर में थोड़ी और जानकारी जोड़ना चाहूंगा।

Declarative Services, Blueprint, iPOJO और अन्य OSGi "घटक मॉडल" मुख्य रूप से OSGi सेवाओं को इंजेक्ट करने के लिए अभिप्रेत हैं। ये नियमित निर्भरता से निपटने के लिए थोड़ा कठिन हैं क्योंकि वे किसी भी समय आ सकते हैं और जा सकते हैं, जिसमें बाहरी घटनाओं (जैसे नेटवर्क डिस्कनेक्ट किया गया) या उपयोगकर्ता कार्यों (जैसे बंडल हटाए गए) के जवाब में शामिल हैं। इसलिए ये सभी घटक मॉडल शुद्ध निर्भरता इंजेक्शन रूपरेखा पर एक अतिरिक्त जीवनचक्र परत प्रदान करते हैं।

यह मुख्य कारण है कि डीएस एनोटेशन JSR330 वाले से अलग हैं ... JSR330 वाले जीवनचक्र से निपटने के लिए पर्याप्त शब्दार्थ प्रदान नहीं करते हैं। उदाहरण के लिए वे कहते हैं:

  • निर्भरता को कब इंजेक्ट किया जाना चाहिए?
  • निर्भरता वर्तमान में उपलब्ध नहीं होने पर हमें क्या करना चाहिए (यानी, क्या यह वैकल्पिक या अनिवार्य है)?
  • जब हम किसी सेवा का उपयोग कर रहे होते हैं तो हमें क्या करना चाहिए?
  • क्या हम गतिशील रूप से सेवा के एक उदाहरण से दूसरे में स्विच कर सकते हैं?
  • आदि...

दुर्भाग्य से क्योंकि घटक मॉडल मुख्य रूप से सेवाओं पर केंद्रित होते हैं - अर्थात, बंडलों के बीच संबंध - वे तुलनात्मक रूप से संयमी होते हैं जो बंडल के अंदर निर्भरता को दूर करने के संबंध में होते हैं (हालांकि ब्लूप्रिंट इसके लिए कुछ समर्थन प्रदान करता है)।

बंडल के अंदर निर्भरता को कम करने के लिए मौजूदा डीआई ढांचे का उपयोग करने में कोई समस्या नहीं होनी चाहिए। उदाहरण के लिए मेरे पास एक ग्राहक था जिसने कुछ घोषणा सेवाओं के घटकों के आंतरिक टुकड़ों को तार करने के लिए Guice का उपयोग किया था। हालाँकि मैं ऐसा करने के मूल्य पर सवाल उठाता हूं, क्योंकि यदि आपको अपने बंडल के अंदर DI की आवश्यकता है तो यह सुझाव देता है कि आपका बंडल बहुत बड़ा और असंगत हो सकता है।

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





apache-felix