OSGi, जावा मॉड्युलैरिटी और आरा


95

इसलिए कल सुबह तक मुझे इस बात का कोई सुराग नहीं था कि OSGi क्या था। OSGi बस कुछ थी कि मैं बार-बार फसल को देखता रहा, और इसलिए मैंने आखिरकार उस पर ब्रश करने के लिए कुछ समय निर्धारित किया।

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

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

मेरे लिए - एक काफी नए (अब कुछ साल) जावा ईई डेवलपर के रूप में, यह बिल्कुल दिमाग से भरा हुआ है कि हम वर्ष 2011 में हैं और वर्तमान में जावा 7 के युग में रह रहे हैं, और यह कि ये क्लास लोडिंग मुद्दे अभी भी मौजूद हैं; विशेष रूप से उद्यम के वातावरण में जहां एक ऐप सर्वर पर सैकड़ों JAR हो सकते हैं, उनमें से कई एक दूसरे के विभिन्न संस्करणों के आधार पर और सभी (अधिक या कम) समवर्ती रूप से चल रहे हैं।

मेरा प्रश्न:

जैसा कि मैं OSGi में हूं, और जितना मैं इसके बारे में सीखना शुरू करना चाहता हूं, यह देखने के लिए कि मैं अपनी परियोजनाओं के लिए कहां / अगर इसका उपयोग कर सकता हूं, तो मेरे पास बैठने का समय नहीं है और कुछ सीखने के लिए समय नहीं है। कम से कम अब।

जब ये समस्याएँ आती हैं तो गैर-OSGi डेवलपर्स क्या करें? वर्तमान में क्या जावा (ओरेकल / सन / जेसीपी) समाधान मौजूद हैं, यदि कोई हो? आरा को जे 7 से क्यों काटा गया? यह कैसे सुनिश्चित किया जाता है कि J8 में अगले साल आरा लागू हो जाएगा? क्या यह अभी तक जावा प्लेटफ़ॉर्म का हिस्सा नहीं होने के बावजूद आपकी परियोजना के लिए आरा प्राप्त करना संभव है?

मुझे लगता है कि मैं यहां जो पूछ रहा हूं वह घबराहट, साज़िश और एक चेहरे का मेल है। अब जब मैं अंततः समझ गया कि OSGi क्या है, तो मुझे "प्राप्त" नहीं है कि कैसे कुछ ऐसा किया गया है जैसे कि आरा को आने में 20+ साल लग गए हैं, और फिर वह कैसे रिलीज़ से डिब्बाबंद हो सकता है। यह सिर्फ मौलिक लगता है।

और, एक डेवलपर के रूप में, मैं यह भी उत्सुक हूं कि मेरे समाधान क्या हैं, ओएसआईआईआई।

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

लेकिन, आप में से जो इस बात पर जोर देते हैं कि कुछ कोड खंड के साथ एक SO प्रश्न का समर्थन किया जाना चाहिए:

int x = 9;

(इस OSGi / आरा / classloader / namespace / JAR नरक सामान का वजन करने वाले किसी भी व्यक्ति को धन्यवाद!)


खैर, जावा 9 कल के रूप में यहाँ है, आरा के साथ। पढ़ने के लिए अच्छा है: शीर्ष 10 आरा और जावा 9 गलतफहमी Debunked
डेविड टोनहोफर

जवाबों:


100

पहले समझते हैं कि आरा का प्राथमिक उपयोग मामला JRE को ही संशोधित करना है। एक माध्यमिक लक्ष्य के रूप में यह एक मॉड्यूल प्रणाली की पेशकश करेगा जिसका उपयोग अन्य जावा पुस्तकालयों और अनुप्रयोगों द्वारा किया जा सकता है।

मेरी स्थिति यह है कि आरा जैसा कुछ शायद JRE के लिए ही आवश्यक है, लेकिन यह अन्य जावा पुस्तकालयों या ऐप्स द्वारा उपयोग किए जाने पर इसे हल करने के दावों की तुलना में कहीं अधिक समस्याएं पैदा करेगा।

JRE एक बहुत ही कठिन और विशेष मामला है। यह 12 साल से अधिक है और निर्भरता चक्र और निरर्थक निर्भरता के साथ riddled, यह एक सुखद गड़बड़ है। एक ही समय में लगभग 9 मिलियन डेवलपर्स और शायद अरबों रनिंग सिस्टम द्वारा उपयोग किया जाता है । इसलिए आप पूरी तरह से JRE को रिफैक्टर नहीं कर सकते हैं यदि वह रिफैक्टिंग ब्रेकिंग परिवर्तन बनाता है।

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

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

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

अंत में: OSGi मौजूद है जबकि आरा अभी तक मौजूद नहीं है और कभी मौजूद नहीं हो सकता है। OSGi समुदाय को मॉड्यूलर अनुप्रयोगों को विकसित करने में 12 वर्षों का अनुभव है। यदि आप मॉड्यूलर अनुप्रयोगों को विकसित करने में गंभीरता से रुचि रखते हैं, तो OSGi शहर का एकमात्र गेम है।


यह तुम भी हो? स्लाइडशेयर . net/mfrancis/… लगभग समान सामग्री।
जिन क्वॉन

JBoss मॉड्यूल भी है: docs.jboss.org/author/display/MODULES/Introduction यह सीलोन (ceylonlang.org) द्वारा भी उपयोग किया जाता है। : सीलोन उपयोगकर्ता मंच पर इस सूत्र देखें groups.google.com/forum/?hl=de#!topic/ceylon-users/RmDskLDNkug
OlliP

क्या अंतिम कथन: "यदि आप मॉड्यूलर अनुप्रयोगों को विकसित करने में गंभीरता से रुचि रखते हैं, तो OSGi शहर में एकमात्र गेम है" फिर भी पकड़ है?
एडम एरॉल्ड

1
@AdamArold मैं ऐसा मानता हूं। आरा अभी भी जावा के किसी भी जारी संस्करण में मौजूद नहीं है। JSR 376 (जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम) अभी भी अपने विशेषज्ञ समूह का गठन कर रहा है और अभी तक पहले मसौदे पर भी शुरू नहीं हुआ है। जावा 9 एक वर्ष से अधिक समय के लिए नहीं है, और यहां तक ​​कि जब जारी किया जाता है तो प्रतिरूपकता की गारंटी नहीं है (यह जावा 7 से फिसल गया, फिर जावा 8 से, और आसानी से फिर से फिसल सकता है)। अंत में, JSR376 के लिए प्रकाशित आवश्यकताएं बताती हैं कि OSGi इंटरॉप की आवश्यकता है ... इसलिए OSGi को अपनाना एक सुरक्षित विकल्प है, और आज एकमात्र व्यावहारिक विकल्प है।
नील बार्टलेट

2
@AadArold ठीक है कि एक अलग सवाल का एक सा है! आप कह सकते हैं कि OSGi एक माइक्रोसॉफ़्ट आर्किटेक्चर है, लेकिन मुझे पता है कि आप क्या कह रहे हैं। मेरे लिए, प्रत्येक सेवा को एक प्रक्रिया के रूप में मॉडलिंग करने का विचार एक बहुत अधिक जटिल समस्या है, प्रबंधन और सुरक्षा और कोमेड्स ओवरहेड के संदर्भ में। OSGi सरल और तेज है। कहा कि, यह बहुत आसान है कि OSGi Remote Services का उपयोग प्रक्रिया अवरोध के अंदर और बाहर सेवाओं को परिवर्तित करने के लिए किया जाए, इसलिए मेरा मानना ​​है कि यह microservices के लिए कार्यान्वयन तकनीक के लिए एक अच्छा विकल्प है।
नील बार्टलेट

21

यह सरल है, यदि आप आज जावा में वास्तविक घटक-आधारित विकास करना चाहते हैं तो ओएसजीआई शहर में एकमात्र गेम है।

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

OSGi कोई रामबाण नहीं है अगर आप एक विशिष्ट उद्यम सेटिंग में काम कर रहे हैं और आपको इस बात से परिचित होना होगा कि क्लास लोडिंग कई प्रसिद्ध पुस्तकालयों के रूप में कैसे काम करता है (आपको देखते हुए, हाइबरनेट) ने क्लास दृश्यता के बारे में ऐसी धारणाएँ बनाईं जो अब मान्य नहीं हैं। OSGi के अंदर।

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

यदि आप OSGi नहीं कर रहे हैं, तो आपकी किस्मत से बाहर है अगर आप एक ऐसी प्रणाली के साथ आए हैं जिसमें एक ही पुस्तकालय के विभिन्न संस्करणों पर निर्भरताएं हैं - आप कर सकते हैं, तो आप कोशिश कर सकते हैं और समस्या से बच सकते हैं, हालांकि कई संस्करणों की आवश्यकता है पुस्तकालय मुझे एक वास्तुकला 'गंध' की तरह लगता है।


हाँ, मुझे लगा कि सूर्य और OSGi एलायंस के बीच बहुत बुरा खून था। मैं कल्पना नहीं कर सकता कि ओरेकल चीजों को उनके नियंत्रण से बाहर जाने दे रहा है, हालांकि। आप वास्तव में मुझे बता रहे हैं कि इस JAR नरक सामान को जल्द ही सही मायने में (हैक नहीं) करने की कोई योजना नहीं है? जो मेरे दिमाग को उड़ा देता है!
IAmYourFaja

6
@ मेरा कहना है कि वास्तव में यह कहना उचित नहीं है कि खून खराब है। आखिरकार, सूर्य लगभग 12 साल पहले (जेएसआर 8) ओएसजीआई के सह-रचनाकारों में से एक था। ओरेकल अधिग्रहण से एक साल पहले, सन ने ओएसजी एलायंस को एक पूर्ण सदस्य के रूप में फिर से शामिल किया। वे पूर्व-ओरेकल के ओएसजीआई के शीर्ष पर काफी सॉफ्टवेयर विकसित करते थे। ग्लासफिश होने का सबसे स्पष्ट उदाहरण है। हालांकि यह कहना उचित है कि सन / ओरेकल और ओएसजीआई में कुछ व्यक्तियों के बीच घर्षण है।
नील बार्टलेट

15

मुझे मौजूदा स्थिति का वर्णन करने के लिए वाक्यांश "कोने के मामलों" के आपके उपयोग से प्यार है।

जेएआर फ़ाइल विनिर्देश के साथ कमियां हैं जो कुछ कोने के मामलों में नेमस्पेस रिज़ॉल्यूशन और क्लास लोडिंग मुद्दों को जन्म दे सकती हैं

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

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

और, एक बोनस के रूप में, यह आपको बहुत सारी चीजें करने का मौका देगा। कल्पना कीजिए, एक डेमो के दौरान, ऑउथ का समर्थन करने के लिए, यातायात हानि के बिना, मूल रूप से प्रमाणीकरण मॉड्यूल को अपग्रेड करना ... सामान बनाने के लिए यह फिर से एक खुशी है!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.