क्या ओएसजीआई जटिलता को कम करने में मदद कर सकता है?

Question

मैंने OSGi पर कई प्रस्तुतियों को देखा और मुझे लगता है कि यह बेहतर मॉड्यूलरलाइजेशन लागू करने के लिए वादा करता है। स्पष्ट रूप से "हॉट डिप्लॉयमेंट" और "समानांतर में एक्स के विभिन्न संस्करणों को चलाना" मेयर बेचने वाले बिंदु भी हैं।

मुझे आश्चर्य है कि क्या ओएसजीआई हल करने का वादा करता है, यह भी एक मुद्दा है ...? यह मुझे ओओ के शुरुआती दिनों की याद दिलाता था जब इसी तरह के दावे नौकरानी थे:

जब ओओ नया था, तो बड़ा तर्क पुन: प्रयोज्यता था। यह व्यापक रूप से दावा किया गया था कि ओओ का उपयोग करते समय, केवल एक को "एक बार लिखना होगा" और फिर "हर जगह उपयोग" कर सकता था।

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

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

सबसे कठिन समस्या जब लागू करने OSGi है, मुझे लगता है होता है, मॉड्यूलर "सही" मिलता है। ओएसजीआई के साथ ओओ में सही ढंग से अपने वर्गों के इंटरफेस प्राप्त करने के समान, समस्या इस समय, पैकेज या यहां तक ​​कि सेवा स्तर के बड़े स्तर पर भी रहती है।

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

• कोई ढांचा कभी क्या modularize आप के लिए, OSGi कभी बंद भुगतान किया गया है तय करने में मदद कर सकते देखते हुए?
• क्या टीमों में काम करते समय यह आपके जीवन को आसान बना देता है?
• क्या इससे बग गिनती को कम करने में मदद मिली है?
• क्या आपने कभी सफलतापूर्वक "हॉटडियोजित" प्रमुख घटक हैं?
• क्या ओएसजीआई समय के साथ जटिलता को कम करने में मदद करता है?
• क्या ओएसजीआई ने अपने वादे बनाए रखा?
• क्या यह आपकी अपेक्षाओं को पूरा करता है?

धन्यवाद!

Answer 1

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

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

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

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

जब तक आप अपने मॉड्यूल और निर्भरता प्रबंधन कर सकते हैं, बड़े परियोजनाओं प्रबंधनीय रहने और आसानी से विकसित किया जा सकता है (यकीनन बुरा "बार फिर से लिखने" से बचाने)।

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

एक आम ख़तरा OSGi के शीर्ष पर कपोल-कल्पना का उपयोग नहीं करने के लिए औसत डेवलपर के लिए यह आसान बनाने के लिए है। कभी भी उन्हें सर्विसलिस्टर्स या सर्विसट्रैकर्स के साथ मैन्युअल रूप से गड़बड़ न करें। ध्यान से विचार करें कि बंडल क्या हैं और इन्हें करने की अनुमति नहीं है: क्या आप डेवलपर्स को बंडल कॉन्टेक्स्ट तक पहुंचने के इच्छुक हैं या आप घोषणात्मक मॉडल के कुछ रूपों का उपयोग कर इन सब से छिपाते हैं।

Answer 2

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

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

ओएसजीआई जटिलता को कम नहीं करता है। लेकिन यह निश्चित रूप से इसे संभालने में मदद करता है।

Answer 3

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

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

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

मैंने गर्म तैनाती सुविधा का उपयोग नहीं किया है, इसलिए मैं इसके बारे में टिप्पणी नहीं कर सकता।

अपने आखिरी बिंदु का उत्तर देने के लिए, यह मेरी अपेक्षाओं को पूरा करता था, लेकिन इसे सीखने की वक्र और कुछ अनुकूलन की आवश्यकता होती थी, और भुगतान केवल लंबी अवधि के लिए होता है।

Answer 4

मैं अब 8 साल के लिए OSGi का उपयोग कर रहा है, और हर बार जब मैं में गोता (एक तरफ ध्यान दें के रूप में, अपने प्रश्न मुझे कहावत का एक सा है कि "Maven निर्माण प्रणालियों के AWT है" याद दिलाता है) एक गैर-ओएसजीआई परियोजना मुझे सीटबेट के बिना overspeeding पर महसूस हो रही है। ओएसजीआई परियोजना सेटअप और तैनाती को कठिन बनाता है, और आपको मॉड्यूलरलाइजेशन के बारे में सोचने के लिए मजबूर करता है, लेकिन आपको रनटाइम पर नियमों को लागू करने के दिमाग को आसान बनाता है। उदाहरण के रूप में मेवेन अपाचे ऊंट ले लो। जब आप एक नया मेवेन प्रोजेक्ट बनाते हैं और निर्भरता के रूप में अपाचे ऊंट जोड़ते हैं, तो अनुप्रयोगों में इसकी सभी निर्भरताएं होती हैं, और आप केवल रनटाइम पर ClassNotFoundExceptions को नोटिस करेंगे, जो खराब है। जब आप ओएसजीआई कंटेनर में चलाते हैं और अपाचे कैमल मॉड्यूल लोड करते हैं, तो अनमेट निर्भरताओं वाले मॉड्यूल शुरू नहीं होते हैं, और आप समस्या को आगे बताते हैं।

मैं हर समय गर्म-तैनाती का भी उपयोग करता हूं, और पुन: प्रारंभ करने की आवश्यकता के बिना फ्लाई पर अपने आवेदन के कुछ हिस्सों को अद्यतन करता हूं।

Answer 5

ओएसजीआई भुगतान नहीं करता है। तथ्य यह है, OSGi का उपयोग करें और दिन या वर्ष के अंत में करने के लिए कितना समय ले जाता है के आधार पर चीजों को काम करना आरंभ करने के लिए आसान नहीं है यह नहीं जोड़ता मूल्य:

• आपका आवेदन अधिक मॉड्यूलर समग्र नहीं होगा इसके विपरीत, यह अधिक खुलासा होता है और अन्य अनुप्रयोगों से अलग नहीं होता है क्योंकि यह साझा करने के बजाय कुछ भी साझा नहीं करता है।
• संशोधन ढेर नीचे धकेल दिया जाता है, तो आप Maven सकर्मक निर्भरता के साथ कुश्ती केवल OSGi में कार्यावधि में फिर से ऐसा करने के लिए।
• अधिकांश पुस्तकालयों को एप्लिकेशन क्लासलोडर में पुस्तकालयों के रूप में काम करने के लिए डिज़ाइन किया गया है जो कि अपने स्वयं के क्लासलोडर के साथ बंडल नहीं हैं।
• शायद प्लगइन आर्किटेक्चर के लिए उपयुक्त जहां तीसरे पक्ष के डेवलपर्स को सैंडबॉक्स होना चाहिए या शायद यह फिर से EJB2.0 है।

मैंने निम्नलिखित स्लाइड्स को जोड़ा और मैं यह दिखाने के लिए उदाहरण कोड के साथ अनुवर्ती हूं कि यह आपके लिए मजबूर होने पर ओएसजीआई के साथ सफलतापूर्वक काम कैसे करें। http://www.slideshare.net/ielian/tdd-on-osgi

Answer 6

नहीं, ओएसजीआई आपको भूरे रंग के शुरुआती बना देगा।