प्लग-इन आधारित आर्किटेक्चर के फायदे और नुकसान क्या हैं?

Question

मैं ऐसे सॉफ़्टवेयर के लिए आर्किटेक्चरल डिज़ाइन करना चाहता हूं जिसका उपयोग एक मंच के तहत विभिन्न तृतीय पक्ष सॉफ़्टवेयर (निष्पादन योग्य) को एकीकृत करने के लिए किया जा सकता है।

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

उपयोगकर्ता उपलब्ध मानक प्रोजेक्ट प्रकार को अनुकूलित कर सकता है और इसे प्लेटफ़ॉर्म में नए प्रोजेक्ट प्रकार के रूप में जोड़ा जाएगा जो नए कस्टम निष्पादन प्रवाह को परिभाषित करता है।

इसके अलावा इसे सुविधाओं के आसान विस्तार और अनुकूलन का समर्थन करना चाहिए। मैंने पढ़ा है कि प्लग-इन आधारित आर्किटेक्चर दोनों का समर्थन करता है।

प्लग-इन आधारित आर्किटेक्चर के फायदे और नुकसान क्या हैं? क्या हमारे पास कोई बेहतर वास्तुकला है जिसका उपयोग इस तरह के परिदृश्य के लिए किया जा सकता है?

अग्रिम में :)

Answer 1

एक प्लगेबल प्रणाली के लाभ

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

लेकिन इन शक्तियों में से कुछ भी कमजोरियों रहे हैं:

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

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

"Second-system syndrome" फ्रेड ब्रूक्स ने वर्णित की सलाह है कि दूसरे विकसित प्रणाली अक्सर जरूरत से ज्यादा सामान्य है, परम लचीलापन के लिए लक्ष्य है, कभी कभी एक "एक मंच के भीतर मंच" उत्पादन/"inner platform effect"। एक प्लग करने योग्य डिज़ाइन को अक्सर एक तरीके के रूप में देखा जाता है जब आवश्यकताएं मौजूद नहीं होती हैं या अंडरस्पेसिस्ड होती हैं। क्षतिपूर्ति करने के लिए, सॉफ़्टवेयर को "जो कुछ भी आता है" को संभालने का प्रयास करने के लिए जितना संभव हो उतना लचीला बनाया जाता है।

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

Answer 2

धन्यवाद आप लाभ प्राप्त कर सकते हैं और एक छोटे से प्लग में ढांचे आप पर link text

Answer 3

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

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

प्लग-इन आर्किटेक्चर बनाने के तरीके पर चर्चा के लिए this प्रश्न देखें।

Answer 4

हालांकि प्लगइन आधारित वास्तुकला को बनाए रखना आसान नहीं है, फिर लोग इस तरह से क्यों विकसित होते हैं? क्योंकि अभी भी इसके बेहतर "निश्चित" दृष्टिकोण बेहतर है। कहें कि क्या आपकी आवश्यकताएं एक के बाद एक बदल रही हैं और डिजाइन को ठीक करने की जरूरत है, तो सोचें कि अन्य दृष्टिकोणों के साथ क्या होगा?

इसके बारे में सबसे अच्छी बात समानांतर विकास है। जब क्लाइंट एएसएपी की कुछ विशेषताएं चाहता है, तो डेवलपर्स समानांतर में काम कर सकते हैं और प्लगइन/घटक के रूप में अपने कोड को प्लग कर सकते हैं। असल में प्लग-एन-प्ले आर्किटेक्चर जटिलता के साथ लचीलापन प्रदान करता है, लेकिन जटिलता पहली बार है। एक बार आपकी टीम इसके साथ सहज हो जाने के बाद, उनके लिए कोड, बग इत्यादि को संभालना आसान है ...

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

संदर्भ के लिए, आप निम्नलिखित जावा फ्रेमवर्क देख सकते हैं। कई ईएसबी उपलब्ध हैं जो घटक/सेवा आधारित प्लग-एन-प्ले आर्किटेक्चर प्रदान करते हैं।

• jBPM (JBOSS Business Process Manager)
• Apache ServiceMix (An Enterprise Service Bus)

मुझे आशा है कि इस मदद करता है।

धन्यवाद।