2011-02-09 12 views
5

मैं जानना चाहता हूं कि फ्रेमवर्क कोड से विशेष रूप से ओएसजीआई के संबंध में एप्लिकेशन कोड को डीकॉप्लिंग करने के लिए सर्वोत्तम प्रथाओं या पैटर्न को क्या माना जाता है।ओएसजीआई ढीला-युग्मन सर्वोत्तम अभ्यास

मैं example from the Felix SCR pages

उदाहरण सेवा का उपयोग करने जा रहा हूँ, एक तुलनाकारी

package sample.service; 
import java.util.Comparator; 
public class SampleComparator implements Comparator 
{ 
    public int compare(Object o1, Object o2) 
    { 
     return o1.equals(o2) ? 0 : -1; 
    } 
} 

कोड के ऊपर कोई ढांचा पाइपलाइन शामिल है यह ध्यान केंद्रित और संक्षिप्त है। ओएसजीआई का उपयोग करते समय इसे एप्लिकेशन में उपलब्ध कराने में, इसे सेवा रजिस्ट्री के साथ पंजीकृत करना शामिल है। एक तरीका, जैसा कि फ़ेलिक्स पृष्ठों से जुड़ा हुआ है, सेवा घटक रनटाइम का उपयोग करके है।

// OSGI-INF/sample.xml 
<?xml version="1.0" encoding="UTF-8"?> 
<component name="sample.component" immediate="true"> 
    <implementation class="sample.service.SampleComparator" /> 
    <property name="service.description" value="Sample Comparator Service" /> 
    <property name="service.vendor" value="Apache Software Foundation" /> 
    <service> 
    <provide interface="java.util.Comparator" /> 
    </service> 
</component> 

और

Service-Component: OSGI-INF/sample.xml 

सभी अच्छा और प्यारा है, मेरी सेवा कार्यान्वयन कोई युग्मन बिल्कुल OSGi गया है।

अब मैं सेवा का उपयोग करना चाहते हैं ...

package sample.consumer; 
import java.util.Comparator; 
public class Consumer { 
    public void doCompare(Object o1, Object o2) { 
     Comparator c = ...; 
    } 
} 

एससीआर देखने रणनीति का उपयोग करते हुए मैं ढांचा-केवल तरीकों जोड़ने की जरूरत:

protected void activate(ComponentContext context) { 
    Comparator c = (Comparator) context.locateService("sample.component"); 
} 

एससीआर घटना रणनीति का उपयोग करते हुए मैं भी जोड़ने की जरूरत ढांचा-केवल विधि:

protected void bindComparator(Comparator c) { 
    this.c = c; 
} 

protected void unbindComparator(Comparator c) { 
    this.c = null; 
} 

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

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

package sample.internal; 
public class OsgiDependencyInjector { 
    private Consumer consumer; 
    protected void bindComparator(Comparator c) { 
     this.consumer.setComparator(c); 
    } 

    protected void unbindComparator(Comparator c) { 
     this.consumer.setComparator(null); 
    } 
} 

हालांकि मुझे यकीन नहीं है कि आप इसे एससीआर कॉन्फ़िगरेशन में कैसे व्यवस्थित करेंगे।

org.apache.felix.scr.annotations भी है, हालांकि इसका मतलब है कि यह केवल तभी काम करेगा जब आप मेवेन-स्क्र-प्लगइन के साथ निर्माण कर रहे हों। वास्तव में इतना बुरा नहीं है और, AFAICT, वे कोई रनटाइम प्रभाव नहीं लगाते हैं।

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

उत्तर

3

1) मुझे नहीं लगता कि बाइंड विधियां आपके कोड को प्रदूषित कर रही हैं, वे सिर्फ बीन सेटर्स हैं (आप उन्हें अधिक पारंपरिक होने के लिए सेट XXX भी कह सकते हैं)। आपको यूनिट परीक्षण के लिए भी उन लोगों की आवश्यकता होगी।

2) यदि आप बीएनडी (जो मैवेन, चींटी, बेंडटॉल्स, एक्लिप्स प्लगइन इत्यादि में हैं) का उपयोग करते हैं तो आप बीएनडी एनोटेशन का भी उपयोग कर सकते हैं। बीएनडी स्वचालित रूप से आपके लिए (हमेशा भयानक) xml बना देगा।

package sample.service; 
import java.util.Comparator; 
import aQute.bnd.annotations.component.*; 

@Component 
public class SampleComparator implements Comparator { 
    public int compare(Object o1, Object o2) { 
     return o1.equals(o2) ? 0 : -1; 
    } 
} 

@Component 
class Consumer { 
    Comparator comparator; 

    public void doCompare(Object o1, Object o2) { 
     if (comparator.compare(o1,o2)) 
     .... 
    } 

    @Reference 
    protected setComparator(Comparator c) { 
     comparator = c; 
    } 
} 

अपने प्रकट में, बस जोड़ें:

Service-Component: * 

यह bnd द्वारा उठाया हो जाएगा। तो आपके डोमेन कोड में कोई ओएसजीआई कोड नहीं है। आप परेशान हो सकते हैं कि कोई अनसेट विधि नहीं है लेकिन बीएनडी के लिए डिफ़ॉल्ट स्थिर बाध्यकारी है। तो आपके द्वारा सक्रिय किए जाने से पहले सेट विधि को कॉल किया जाता है और अनसेट होने से पहले आप निष्क्रिय हो जाते हैं। जब तक आपका उपभोक्ता वस्तु एक μservice भी होगा, आप सुरक्षित हैं। bndtools, bnd होम पेज, और मेरे blogs को μservices के बारे में अधिक जानकारी के लिए देखें।

पीएस। आपका नमूना अमान्य कोड है क्योंकि ओ 1 ओ 2 से अधिक और उससे कम दोनों का जवाब देगा यदि ओ 1! = ओ 2, यह तुलनात्मक अनुबंध द्वारा अनुमति नहीं है और अस्थिर प्रकार बना देगा।

2

मैं आपको लिखूंगा कि हम इसे अपने प्रोजेक्ट में कैसे करते हैं। एक ओएसजीआई कंटेनर के रूप में हम फ्यूज ईएसबी का उपयोग कर रहे हैं, हालांकि अपाचे कराफ के अंदर कहीं भी पाया जा सकता है। हमारे कोड को प्रदूषित न करने के लिए हम स्प्रिंग डीएम (http://www.springsource.org/osgi) का उपयोग करते हैं, जो ओएसजीआई कंटेनर के साथ बातचीत को बहुत सुविधाजनक बनाता है। यह "निरंतर एकीकरण प्रक्रिया" (नवीनतम रिलीज) के हिस्से के रूप में "विषुव 3.2.x, फ़ेलिक्स 1.0.3+, और Knopflerfish 2.1.x के खिलाफ" परीक्षण किया जाता है।

इस दृष्टिकोण का लाभ:

  • सभी "OSGi" xml फ़ाइलें में विन्यास - OSGi कंटेनर

यह कैसे लग रहा है के विभिन्न कार्यान्वयन के साथ काम करने के लिए कोड नहीं प्रदूषित

  • क्षमता? OSGi रजिस्ट्री में

    • प्रकाशन सेवा:

    < OSGi: सेवा आईडी = "कुछ-आईडी" रेफरी = इंटरफेस "सेम के लागू करने-सेवा करने वाली बेनकाब" = "इंटरफ़ेस की-अपने-सेवा " />

    • OSGi रजिस्ट्री से सेवा का आयात:

    < OSGi: संदर्भ आईडी = "सेम-आईडी" इंटरफेस = "इंटरफेस के- उजागर-सेवा" />

    इसके अलावा, वैध OSGi बंडलों हम Maven गठरी-प्लगइन का उपयोग बनाने के लिए ।

  • 1

    aQute.bnd.annotations.component में की तुलना में फ़ेलिक्स एनोटेशन का लाभ यह प्रतीत होता है कि बाध्य और अनबिंड विधियां स्वचालित रूप से फ़ेलिक्स स्क्रू प्लगइन द्वारा बनाई गई हैं (आप एक निजी क्षेत्र को एनोटेट कर सकते हैं)। फ़ेलिक्स प्लगइन का नुकसान यह है कि यह जावा स्रोतों पर कार्य करता है और इसलिए अन्य भाषाओं (जैसे स्कैला) में बनाए गए वर्ग फ़ाइलों के लिए काम नहीं करता है।

    संबंधित मुद्दे