ओएसजीआई के तहत, घटक बनाम सेवाओं के बीच मुख्य अंतर क्या हैं? जैसा कि मैं इसे समझता हूं, सभी सेवाएं घटक होना चाहिए, लेकिन सभी घटक सेवाओं के लिए नहीं होना चाहिए।ओएसजीआई घटक और सेवाओं के बीच क्या अंतर है
नमूना उपयोग के मामलों के साथ एक दूसरे का उपयोग करने के क्या फायदे हैं?
"घटक" सेवाओं की तुलना में कम औपचारिक रूप से परिभाषित हैं।
एक सेवा कोई ऑब्जेक्ट है जो ओएसजीआई सेवा रजिस्ट्री में पंजीकृत है और इसे अपने इंटरफ़ेस नामों का उपयोग करके देखा जा सकता है। एकमात्र शर्त यह है कि एक सेवा को कुछ इंटरफ़ेस लागू करना चाहिए ... कोई इंटरफ़ेस। उदाहरण के लिए मैं java.lang.Runnable इंटरफ़ेस के तहत एक चलने योग्य ऑब्जेक्ट पंजीकृत कर सकता हूं, और ग्राहक उस इंटरफ़ेस नाम का उपयोग करके इसे देख सकते हैं।
एक "घटक" एक ऐसा ऑब्जेक्ट होता है जिसका जीवन चक्र प्रबंधित होता है, आमतौर पर डेक्लेरेटिव सर्विसेज (डीएस), ब्लूप्रिंट या आईपीओजेओ जैसे घटक ढांचे द्वारा। विभिन्न घटक ढांचे के बारे में चर्चा के लिए ओएसजीआई सामुदायिक विकी पर this page देखें।
एक घटक निम्नलिखित सुविधाओं के किसी भी हो सकता है संयोजन या अकेले में,:
सामान्य रूप से, एक घटक ढांचे का उपयोग करना ओएसजीआई सेवाओं के साथ काम करने का सबसे आसान तरीका है क्योंकि ढांचा उन सेवाओं के लिए बाध्यकारी प्रबंधन करेगा जिन्हें आप उपभोग करना चाहते हैं। उदाहरण के लिए आप कह सकते हैं कि आपका घटक "किसी विशेष सेवा पर निर्भर करता है", इस मामले में घटक केवल तभी बनाया जाएगा जब वह सेवा उपलब्ध हो और सक्रिय हो जाए - और सेवा अनुपलब्ध होने पर भी इसे नष्ट कर दिया जाएगा।
संपादित करें: नील बार्टलेट के जवाब देखें, मैंने काफी विशेष रूप से wrt घोषणात्मक सेवाओं का उत्तर दिया है, लेकिन यह गलत है कि मैंने यहां गलत तरीके से कहा है।
संक्षेप में: घटक सेवा के उपभोक्ता नहीं हैं प्रदाता नहीं, सेवाएं सेवा प्रदाताओं के रूप में पंजीकृत घटक का विस्तार हैं।
एक घटक में जीवन चक्र (डी/सक्रिय और संशोधित), सेवा निर्भरता प्रबंधन (अन/बांध) है।
एक सेवा एक घटक का विस्तार है; सेवा रजिस्ट्री के माध्यम से, यह कार्यान्वित इंटरफेस और गुणों को प्रकाशित करके अन्य बंडलों आदि के लिए इसकी सेवाएं प्रदान करता है।
सेवाओं के लिए उपयोग-मामला स्पष्ट है, घटक का उपयोग करने के लिए सामान्य मामलों में जीवन चक्र, विन्यास या सेवा निर्भरताओं के प्रबंधन की आवश्यकता है, लेकिन अंतर-बंडल उपयोग के लिए घटक प्रकाशित करने की आवश्यकता नहीं है।
मैं असहमत हूं कि "घटक प्रदाता नहीं हैं"।एक घटक उपभोक्ता या सेवा का प्रदाता हो सकता है, या दोनों, या न तो। –
हाय @ नील, AFAIK (और कृपया मुझे यहां सही करें) मैंने सोचा था कि एक घटक जो सेवा के रूप में पंजीकृत नहीं था, किसी अन्य घटक द्वारा बाध्य नहीं किया जा सकता है (यहां तक कि उसी बंडल में - निश्चित रूप से फ़ेलिक्स डीएस के मामले में लगता है) – earcam
यह सच है यदि आप किसी घटक की डीएस परिभाषा को सीमित करते हैं। ब्लूप्रिंट और अन्य ढांचे में, घटक सेवाओं को प्रकाशित किए बिना उसी बंडल में अन्य घटकों के लिए उपभोग या वायर्ड कर सकते हैं। मुझे नहीं लगता कि यह प्रासंगिक है हालांकि: आपके पास ऐसे घटक हो सकते हैं जो सेवाएं, घटक हैं जो सेवाएं नहीं हैं, और सेवाएं जो घटक नहीं हैं .... –
क्या आप एक ऐसे घटक का उदाहरण प्रदान कर सकते हैं जो सेवा नहीं है? – santiagozky
@ सैंटियागोस्की निश्चित। मान लीजिए कि आप एक सर्वर सर्वर लिखना चाहते हैं जो सॉकेट पर बैठता है और टीसीपी/आईपी पर अनुरोधों का जवाब देता है। जब घटक शुरू होता है, तो यह सॉकेट खोलता है और ग्राहकों की सेवा के लिए आवश्यक धागे बनाता है। जब यह बंद हो जाता है, तो यह थ्रेड (एस) और सॉकेट बंद कर देता है। एक और उदाहरण: एक घटक जो स्विंग, एसडब्ल्यूटी या जावाएफएक्स का उपयोग कर जीयूआई बनाता है। इन उदाहरणों में से कोई भी घटक स्वयं सेवा नहीं है, हालांकि वे * अन्य घटकों द्वारा प्रकाशित * सेवाओं का उपयोग कर सकते हैं। –
@neal, धन्यवाद। मुझे ये अब मिला। – santiagozky