2011-02-07 12 views
12

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

धन्यवाद !!

उत्तर

23

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

  • जो अन्य घटकों या जावा इसे इस्तेमाल करता है पैकेज,
  • और जो इसे अन्य घटकों द्वारा प्रयोग की जाने वाली बेनकाब करने के लिए चाहता है पैकेज।

तकनीकी बिंदु से बंडल जार फाइलें हैं जिनकी थोड़ी विस्तार META-INF/MANIFEST.MF फ़ाइल है। सभी उपर्युक्त जानकारी MANIFEST.MF फ़ाइल में संग्रहीत है।

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

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

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

ओएसजीआई काफी जटिल है और कुछ शब्दों में इसकी संभावनाओं और इसकी संभावनाओं का वर्णन करना मुश्किल है।मैंने जो लिखा वह ओएसजीआई के सबसे महत्वपूर्ण (आईएमओ) तत्व हैं। लेकिन ओएसजीआई बहुत अधिक है, उदा। बंडल एक दूसरे को घटना भेज सकते हैं, वे एक दूसरे को सेवाएं प्रदान कर सकते हैं। यदि आप अधिक जानकारी में रूचि रखते हैं तो मैं एक ट्यूटोरियल के माध्यम से जाने का सुझाव देता हूं। मैं this one in Java World की सिफारिश कर सकता हूं। उसके बाद आप ओएसजीआई के बारे में this free e-book पर एक नज़र डाल सकते हैं (इसमें बहुत सारे विवरण हैं)। ओएसजीआई के बारे में सभी विवरण आधिकारिक विनिर्देशों में पाए जा सकते हैं लेकिन मैं नहीं कहूंगा कि उन्हें पढ़ने में आसान है (कम से कम शुरुआत में) - आप उन्हें here (डाउनलोड करने से पहले आपको लाइसेंस और कुछ कानूनी नोटिस स्वीकार करना होगा) ।

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

कुछ अतः संबंधित प्रश्नों:

+0

आपके विस्तृत उत्तर के लिए बहुत बहुत धन्यवाद :) – Izza

+0

अब माइक्रोस्कोर्सेस के आगमन के साथ, ओएसजीआई की तुलना में माइक्रोस्कोर्सेस कितने अलग या बेहतर हैं? – yathirigan

1

आपको उस प्रश्न का सही उत्तर देने के लिए एक पुस्तक लिखनी होगी। दरअसल इस विषय पर कई किताबें लिखी गई हैं। यदि आप वास्तव में ओएसजीआई के बारे में जानना चाहते हैं, तो मैं ऐसी पुस्तक की खोज करने की सलाह देता हूं।

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

1

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

मैंने ओएसजीआई का उपयोग करके काम पर दो परियोजनाओं का विकास किया, यह परियोजना की शुरुआत में बहुत धीमी है क्योंकि आपको बहुत से सार्वजनिक पुस्तकालयों को लपेटने की जरूरत है और उनमें से सभी को लपेटना संभव नहीं है, क्योंकि आप प्रॉक्सी ऑब्जेक्ट्स के साथ काम करते समय क्लासलोडर समस्याओं के कारण रन टाइम पर ClassNotDefoundError का सामना कर सकते हैं।

ओएसजीआई का उपयोग करने वाली परियोजनाओं में हमारे पास जो मॉड्यूलरिटी है, वह ओवेजी के साथ काम करते समय हासिल किया जा सकता है, ओएसजीआई के साथ काम करते समय कोई भी आपको बहुत अच्छे दाग बंडलों को लिखने के लिए लागू नहीं करता है, अगर आप चाहते हैं कि आप एक बड़े में छेद आवेदन लिख सकें बंडल।

यदि हम घटकों के बीच हार युग्मन के बारे में बात करते हैं तो यह वसंत-कोर या Google-guice निर्भरता इंजेक्शन ढांचे से ऑटो-तारों का उपयोग करके हासिल किया जा सकता है।

3

ओएसजीआई के साथ मेरा व्यक्तिगत (2 साल) अनुभव यह है कि तकनीकी बिल परिमाण के आदेशों से कार्यात्मक लाभ से अधिक है।

मुझे सामना करना पड़ा है कि आपको एक लाइनर नकली को लागू करने के लिए 25+ पोम फाइलें बनाना/संपादित करना होगा!
डिज़ाइन एक बड़ा हिस्सा निभाता है, लेकिन मुझे यह परेशान लगता है कि डेवलपर्स विषयों (जैसे मैवेन) में विशेषज्ञ बन जाते हैं जिन पर ग्राहक के मूल्य पर कोई प्रभाव नहीं पड़ता है।
आगे, यह दृष्टिकोण Agile के साथ अच्छी तरह से सामना नहीं करता है। वास्तव में, यह एक महान फिट होगा ... Waterfall
यह आपके प्राथमिक फोकस IMHO के बारे में है। वितरण पैटर्न बनाम Deliverables।

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

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

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