ओएसजीआई

Question

किसी ऐसे व्यक्ति के रूप में सेवा लोडर का उपयोग कब करें, जो निर्भरता के लिए एलर्जी है, जब मैं जावा 6 http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html (मैं प्लगइन जार को बस छोड़ना चाहता हूं) के बजाय ओएसजीआई की तरह कुछ उपयोग करता हूं।

(एफवाईआई यह एक स्कैला ऐप में है, किसी भी सुझाव के लिए खुला है, सर्विसलोडर जो चाहता है उसके करीब बहुत करीब है)।

Answer 1

यदि ServiceLoader अधिकतर आपकी आवश्यकताओं के अनुरूप है, तो यह कहता है कि आप कक्षा पथ पर फ़ाइलों की उपस्थिति के माध्यम से सेवा खोज की तलाश में हैं। ओएसजीआई क्या प्रदान करता है यह केवल एक छोटा सा हिस्सा है।

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

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

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

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

Answer 2

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

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

सर्विसलोडर के साथ ध्यान में रखना एक और बात है जो लुकअप तंत्र को सारणीबद्ध करने का प्रयास करना है। प्रकाशन तंत्र काफी अच्छा और साफ और घोषणात्मक है। लेकिन लुकअप (java.util.ServiceLoader के माध्यम से) नरक के रूप में बदसूरत है, जो क्लासपाथ स्कैनर के रूप में लागू होता है जो कोड को किसी भी पर्यावरण (जैसे ओएसजीआई या जावा ईई) में डाल देता है जिसमें वैश्विक दृश्यता नहीं होती है। यदि आपका कोड उस के साथ उलझ जाता है तो आपको बाद में ओएसजीआई पर इसे चलाने में कठिन समय लगेगा। एक समय सारिणी लिखने के लिए बेहतर है जिसे आप समय के साथ बदल सकते हैं।