हम करफ प्लेटफार्म पर ओएसजीआई को लागू कर रहे हैं

OSGI मुश्किल नहीं है

मैं कई बार मिल चुका हूं कि ओएसजीआई मुश्किल है। और इसके अलावा, वह खुद भी एक बार ऐसी राय रखते थे। वर्ष 2009 में, सटीक होने के लिए। उस समय, हमने मेवेन टाइको का उपयोग करके परियोजनाएं एकत्र कीं, और उन्हें विषुव में तैनात किया। और यह वास्तव में JavaEE के लिए प्रोजेक्ट्स को विकसित करने और असेंबल करने से ज्यादा कठिन था (उस समय EJB 3 का संस्करण बस दिखाई दिया, जिसे हमने स्विच किया था)। उदाहरण के लिए, विषुव वेबलॉजिकल की तुलना में बहुत कम सुविधाजनक था, और ओएसजीआई के लाभ मेरे लिए तब स्पष्ट नहीं थे।

लेकिन फिर, कई सालों के बाद, मुझे एक नई नौकरी पर एक परियोजना शुरू करनी पड़ी, जिसकी कल्पना अपाचे कैमल और अपाचे करफ के आधार पर की गई थी। यह मेरा विचार नहीं था, मैं उस समय तक कैमल को लंबे समय से जानता था, और करफ के बारे में पढ़ने का फैसला किया, यहां तक ​​कि एक प्रस्ताव के बिना भी। मैंने इसे एक शाम पढ़ा, और महसूस किया - यहाँ यह एक सरल JavaEE की कुछ समस्याओं का लगभग एक ही समाधान है, सरल और तैयार है, जिसके समान मैंने एक बार अपने घुटने पर Weblogic WLST, Jython, और Mav Aether का उपयोग किया था।

तो, चलिए बताते हैं कि आप Karaf प्लेटफॉर्म पर OSGI को आज़माने का फैसला करते हैं। हम कहां से शुरू करते हैं?

अगर आप एक गहरी समझ चाहते हैं

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

यह ध्यान दिया जाना चाहिए कि जब Jboss फ्यूज, या Apache ServiceMix का उल्लेख किया गया है, तो इसे "पूर्वनिर्मित घटकों के साथ करफ" के रूप में पढ़ा जाना चाहिए, अर्थात्। वास्तव में - एक ही चीज, केवल विक्रेता द्वारा एकत्र की गई। मैं व्यवहार में इसे शुरू करने की सलाह नहीं दूंगा, लेकिन उदाहरण के लिए, सेवामिक्स के बारे में समीक्षा लेख पढ़ना काफी संभव है।

इसके साथ शुरू करने के लिए, मैं बहुत संक्षेप में यह निर्धारित करने की कोशिश करूँगा कि OSGI क्या है और इसका क्या उपयोग किया जा सकता है।

द्वारा और बड़े, OSGI मॉड्यूल से जावा अनुप्रयोगों को बनाने के लिए एक उपकरण है। एक करीबी एनालॉग माना जा सकता है, उदाहरण के लिए, JavaEE, और कुछ हद तक OSGI कंटेनर JavaEE मॉड्यूल (वार के रूप में वेब एप्लिकेशन) को निष्पादित कर सकते हैं, और दूसरी ओर, कई JavaEE कंटेनरों में OSGI को अपने आप में मॉड्यूलरता लागू करने के साधन के रूप में शामिल किया जाता है। "। यही है, JavaEE और OSGI संगतता के समान चीजें हैं, और सफलतापूर्वक पूरक हैं।

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

बंडल मेटाडेटा META-INF / MANIFEST.MF से सभी को परिचित है। OSGI मैनिफ़ेस्ट के हेडर, JRE के हेडर के साथ प्रतिच्छेद नहीं करते हैं, क्रमशः, OSGI कंटेनर बंडल के बाहर एक नियमित जार है। यह महत्वपूर्ण है कि मेटाडेटा के बीच हमेशा होते हैं:

Bundle-SymbolicName: com.example.myosgi Bundle-Version: 1.0.0 

ये बंडल के "निर्देशांक" हैं, और यह तथ्य कि हम एक ही कंटेनर में एक ही बंडल के दो या अधिक एक साथ स्थापित और काम कर रहे संस्करण महत्वपूर्ण हैं।

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

पैकेज आयात को वैकल्पिक, साथ ही सेवा आयात घोषित किया जा सकता है। और यह काफी महत्वपूर्ण है कि आयात और निर्यात में संस्करण (या संस्करणों की श्रेणी) का संकेत होता है।

JavaEE से अंतर

खैर, यह अच्छा है कि वे एक जैसे हैं - हम समझ गए। और वे कैसे भिन्न होते हैं?

मेरी राय में, मुख्य अंतर यह है कि ओएसजीआई हमें बहुत अधिक लचीलापन देता है। एक बार बंडल STARTED स्थिति में है, तो संभावनाएँ केवल आपकी कल्पना द्वारा सीमित हैं। मान लें कि आप आसानी से थ्रेड्स बना सकते हैं (हां, हां, मुझे ManagedExecutorService के बारे में पता है), डेटाबेस से कनेक्शन पूल आदि। एक कंटेनर जावा रिसोर्स के समान सभी संसाधनों पर नियंत्रण नहीं रखता है।

आप इस प्रक्रिया में नई सेवाओं का निर्यात कर सकते हैं। JavaEE में कहें कि गतिशील रूप से एक नया सर्वलेट बनाएं? और यहां यह काफी संभव है, इसके अलावा, जेटी के आधार पर निर्मित कराफ सर्वलेट कंटेनर को आपके बनाए गए सर्वलेट द्वारा तुरंत पता लगाया जाएगा और यह एक विशिष्ट URL पर ग्राहकों के लिए उपलब्ध होगा।

हालांकि यह थोड़ा सरलीकरण है, लेकिन अगर इसके शास्त्रीय रूप में JavaEE अनुप्रयोग में मुख्य रूप से घटक शामिल हैं:

• निष्क्रिय, ग्राहक से कॉल की प्रतीक्षा में
• वैधानिक रूप से परिभाषित, अर्थात्, आवेदन की तैनाती के समय।

दूसरी ओर, OSGI- आधारित अनुप्रयोग में हो सकता है:

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

हां, JavaEE पर, इसका अधिकांश भाग आंशिक रूप से संभव है (उदाहरण के लिए, JNDI के माध्यम से), लेकिन OSGI के मामले में, व्यवहार में इसे आसान बना दिया जाता है। हालाँकि यहाँ शायद कुछ और जोखिम हैं।

करफ और शुद्ध OSGI के बीच अंतर

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

और चलो पहले से ही अभ्यास करते हैं?

ठीक है, चलो स्थापना के तुरंत बाद शुरू करते हैं। यहां लिखने के लिए बहुत कुछ नहीं है - karaf.apache.org पर जाएं, वितरण पैकेज डाउनलोड करें, इसे अनपैक करें। विभिन्न OSGI विशिष्टताओं (4, 5 या 6), और जावा संस्करणों के समर्थन में करफ के संस्करण भिन्न होते हैं। मैं 2.x परिवार की सिफारिश नहीं करता, लेकिन यहां 3 हैं (यदि आपके पास जावा 8 है, मेरी तरह), और 4 का उपयोग किया जा सकता है, हालांकि आज केवल 4.x परिवार विकसित हो रहा है (वर्तमान संस्करण 4.2.2, यह OSGI 6 का समर्थन करता है (जावा 10 तक)।

Karaf विंडोज और लिनक्स के तहत ठीक काम करता है, आपको एक सेवा बनाने और ऑटोरन उपलब्ध करने की आवश्यकता है। MacOS और कई अन्य प्रकार के यूनिक्स के लिए समर्थन भी घोषित किया गया है।

यदि आप इंटरनेट पर हैं, तो आप आमतौर पर करफ को तुरंत शुरू कर सकते हैं। यदि नहीं, तो यह आमतौर पर कॉन्फ़िगरेशन फ़ाइल को ठीक करने के लायक है, यह दर्शाता है कि आपके पास कहां से रिपॉजिटरी है। आमतौर पर यह एक कॉर्पोरेट नेक्सस होगा, या कहें कि आर्टिफैक्ट, जो भी पसंद करता है। वितरण के आदि फ़ोल्डर में karaf कॉन्फ़िगरेशन स्थित है। कॉन्फ़िगरेशन फ़ाइलों के नाम बहुत स्पष्ट नहीं हैं, लेकिन इस मामले में आपको org.ops4j.pax.url.mvn.cfg फ़ाइल की आवश्यकता है। इस फ़ाइल का प्रारूप जावा गुण है।

आप कॉन्फ़िगरेशन फ़ाइल में ही रिपॉजिटरी (एस) दोनों को निर्दिष्ट कर सकते हैं, सेटिंग्स में यूआरएल की सूची को सूचीबद्ध कर सकते हैं, या बस यह दिखा सकते हैं कि आपकी सेटिंग्स कहाँ हैं। वहां, कराफ आपके प्रॉक्सी का स्थान लेगा, जिसे आमतौर पर इंट्रानेट पर जानना आवश्यक है।

कफ़र को कई बंदरगाहों की आवश्यकता है, ये HTTP, HTTPS (यदि वेब डिफ़ॉल्ट रूप से कॉन्फ़िगर नहीं किया गया है), SSH, RMI, JMX हैं। यदि वे आपके साथ व्यस्त हैं, या आप एक ही मेजबान पर कई प्रतियां चलाना चाहते हैं, तो आपको उन्हें भी बदलना होगा। इनमें से लगभग पाँच बंदरगाह हैं।

Jmx और rmi जैसे पोर्ट - यहाँ: org.apache.karaf.management.cfg, ssh - org.apache.karaf.shell.cfg, http / https पोर्ट को बदलने के लिए, आपको आदि (फ़ाइल में सबसे अधिक संभावना नहीं) बनाने की आवश्यकता होगी org.ops4j.pax.web.cfg, और value लिखिए। org.osgi.service.http.port = पोर्ट आपको इसमें चाहिए।

फिर आप निश्चित रूप से इसे शुरू कर सकते हैं, और एक नियम के रूप में, सब कुछ शुरू हो जाएगा। औद्योगिक उपयोग के लिए, स्पष्ट रूप से, आपको बिन / सेटेनव, या बिन / सेटेनव.बैट फ़ाइल में परिवर्तन करना होगा, उदाहरण के लिए, आवश्यक मात्रा में स्मृति आवंटित करने के लिए, लेकिन सबसे पहले, देखने के लिए, यह आवश्यक नहीं है।

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

मैं अनुशंसा करता हूं कि डेटा / लॉग / karaf.log में स्थित लॉग देखने के लिए तुरंत एक अतिरिक्त कंसोल विंडो हो (और अन्य फाइलें आमतौर पर वहां होती हैं, हालांकि यह कॉन्फ़िगर है)। लॉग आपके लिए उपयोगी हैं, कंसोल में छोटे संदेशों से, सब कुछ स्पष्ट नहीं है।

मैं तुरंत वेब, और hawtio वेब कंसोल स्थापित करने की सलाह दूंगा। ये दो चीजें आपके लिए कंटेनर में क्या हो रहा है इसे नेविगेट करना और वहां से प्रक्रिया को काफी हद तक आगे बढ़ाना आसान बना देगा (एक बोनस के रूप में, आपको जोलोकिया और http के माध्यम से निगरानी करने की क्षमता मिलेगी)। ह्वाटियो को इंस्टाल करना karaf कंसोल ( जैसा कि यहाँ वर्णित है ) से दो कमांड्स द्वारा किया जाता है, और अफसोस, आज karaf 3.x का संस्करण अब समर्थित नहीं है (आपको hawtio के पुराने संस्करणों की तलाश करनी होगी)।

बॉक्स से बाहर, https तुरंत नहीं होगा, इसके लिए आपको कुछ प्रयास करने होंगे जैसे प्रमाण पत्र बनाना, आदि। कार्यान्वयन जेटी पर आधारित है, इसलिए इन सभी प्रयासों को ज्यादातर उसी तरह किया जाता है।

ठीक है, यह शुरू हो गया, आगे क्या है?

वास्तव में, आपको क्या उम्मीद थी? मैंने कहा यह ssh होगा। टैब काम करता है, अगर वह।

यह कुछ एप्लिकेशन इंस्टॉल करने का समय है। ओएसजीआई के लिए एक आवेदन या तो एक बंडल है, या कई बंडल हैं। करफ कई प्रारूपों में आवेदन कर सकते हैं:

• एक जार बंडल, एक OSGI प्रकट के साथ या उसके बिना
• स्प्रिंग डीएम या ब्लूप्रिंट युक्त xml
• xml तथाकथित सुविधा से युक्त है, जो बंडलों, अन्य सुविधाओं और संसाधनों (कॉन्फ़िगरेशन फ़ाइलों) का एक संग्रह है
• .कर संग्रह में कई विशेषताएं हैं और निर्भरता के साथ एक मावेन भंडार है
• जावा (कुछ अतिरिक्त शर्तों के तहत) अनुप्रयोग, उदाहरण के लिए .war

ऐसा करने के कई तरीके हैं:

• एप्लिकेशन को परिनियोजन फ़ोल्डर में रखें
• इंस्टॉल कमांड के साथ कंसोल से इंस्टॉल करें
• सुविधा से कमांड के साथ सुविधा स्थापित करें: कंसोल स्थापित करें
• kar: स्थापित करें

ठीक है, सामान्य तौर पर, यह काफी कुछ वैसा ही होता है जैसा कि एक सामान्य JavaEE कंटेनर कर सकता है, लेकिन यह कुछ हद तक सुविधाजनक है (मैं इसे बहुत अधिक सुविधाजनक कहूंगा)।

सरल जार

सबसे आसान विकल्प नियमित जार स्थापित करना है। यदि आपके पास मावेन रिपॉजिटरी में है, तो कमांड स्थापित करने के लिए पर्याप्त है:

 install mvn:groupId/artifactId/version 

उसी समय, करफ को पता चलता है कि उसके सामने एक नियमित जार है, और इसे संसाधित करता है, मक्खी पर एक बंडल आवरण बनाता है, तथाकथित रैपर, पैकेज आयात और निर्यात के साथ एक डिफ़ॉल्ट प्रकटन पैदा करता है।

सिर्फ एक जार स्थापित करने की भावना आमतौर पर ज्यादा नहीं है, क्योंकि यह बंडल निष्क्रिय होगा - यह केवल उन वर्गों को निर्यात करता है जो अन्य बंडलों के लिए उपलब्ध होंगे।

इस विधि का उपयोग अपाचे कॉमन्स लैंग जैसे घटकों को स्थापित करने के लिए किया जाता है, उदाहरण के लिए:

 install mvn:org.apache.commons.lang3/commons-lang/3.8.1 

लेकिन यह काम नहीं किया गया :) यहां सही निर्देशांक हैं:

 install mvn:org.apache.commons/commons-lang3/3.8.1 

आइए देखें कि क्या हुआ: सूची -यू हमें बंडल और उनके स्रोत दिखाएगा:

 karaf@root()> list -u START LEVEL 100 , List Threshold: 50 ID | State | Lvl | Version | Name | Update location ------------------------------------------------------------------------------------------------- 87 | Installed | 80 | 3.8.1 | Apache Commons Lang | mvn:org.apache.commons/commons-lang3/3.8.1 88 | Installed | 80 | 3.6.0 | Apache Commons Lang | mvn:org.apache.commons/commons-lang3/3.6 

जैसा कि आप देख सकते हैं, एक घटक के दो संस्करणों को स्थापित करना काफी संभव है। अद्यतन स्थान - यह वह जगह है जहां हमें बंडल मिला है, और यदि आवश्यक हो तो इसे अपडेट किया जा सकता है।

जार और वसंत संदर्भ

अगर आपके जार के अंदर स्प्रिंग कॉन्टेक्स्ट है, तो चीजें अधिक दिलचस्प हो जाती हैं। मेटा-इन / स्प्रिंग फ़ोल्डर में Karaf Deployer स्वचालित रूप से xml संदर्भों की खोज करता है, और उन्हें बनाता है यदि बंडल द्वारा आवश्यक सभी बाहरी बंडल सफलतापूर्वक मिल गए हैं।

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

बस स्प्रिंग एक्सएमएल संदर्भ

यदि आपके पास, उदाहरण के लिए, स्प्रिंग कॉन्टेक्स्ट के अंदर जेडीबीसी डेटास् की परिभाषाएँ हैं, तो आप उन्हें अलग से कराफ में स्थापित कर सकते हैं। यानी एक xml फ़ाइल लें जिसमें केवल <b> या घटकों के किसी अन्य सेट के रूप में एक डेटा स्रोत है, आप इसे तैनाती फ़ोल्डर में रख सकते हैं। मानक तरीके से संदर्भ लॉन्च किया जाएगा। एकमात्र समस्या यह है कि इस तरह से बनाए गए डेटा स्रोत अन्य बंडलों को दिखाई नहीं देंगे। उन्हें OSGI को सेवाओं के रूप में निर्यात करने की आवश्यकता है। इसके बारे में - थोड़ी देर बाद।

स्प्रिंग डी.एम.

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

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

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

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

वास्तव में, सब कुछ थोड़ा अधिक जटिल है, क्योंकि बंडल समान सेवाओं की सूची का उपयोग कर सकता है, और सूची में तुरंत सदस्यता ले सकता है। यानी एक सेवा, सामान्य तौर पर, कार्डिनैलिटी जैसी एक संपत्ति होती है, जो मान 0..N लेती है। इस मामले में, सदस्यता, जहां 0..1 निर्दिष्ट किया गया है, एक वैकल्पिक सेवा का वर्णन करता है, और इस मामले में बंडल सफलतापूर्वक शुरू होता है, भले ही सिस्टम में ऐसी कोई सेवा न हो (और इसके लिए लिंक के बजाय, यह एक स्टब मिलेगा)।

मैं ध्यान देता हूं कि एक सेवा केवल कोई इंटरफ़ेस है (या आप केवल कक्षाएं प्रकाशित कर सकते हैं), इसलिए आप सेवा के रूप में डेटा के साथ java.util.Map को अच्छी तरह से प्रकाशित कर सकते हैं।

अन्य बातों के अलावा, सेवा आपको मेटाडेटा निर्दिष्ट करने की अनुमति देती है, और संदर्भ आपको इस मेटाडेटा द्वारा सेवा की खोज करने की अनुमति देता है।

खाका

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

यहाँ सार एक ही है - यह एक्सएमएल है, जिसमें उन घटकों का वर्णन किया गया है जिनसे बंडल संदर्भ इकट्ठा होता है। जो लोग वसंत को जानते हैं, उनके लिए अपरिचित कुछ भी नहीं है।

एक डेटा स्रोत का वर्णन करने और इसे एक सेवा के रूप में निर्यात करने का तरीका इस प्रकार है:

 <?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> <bean id="dataSource" class="oracle.jdbc.pool.OracleDataSource"> <property name="URL" value="URL"/> <property name="user" value="USER"/> <property name="password" value="PASSWORD"/> </bean> <service interface="javax.sql.DataSource" ref="dataSource" id="ds"> <service-properties> <entry key="osgi.jndi.service.name" value="jdbc/ds"/> </service-properties> </service> </blueprint> 

खैर, हमने इस फाइल को तैनाती फ़ोल्डर में तैनात किया, और सूची कमांड के परिणामों को देखा। उन्होंने देखा कि बंडल शुरू नहीं हुआ - Indtalled स्थिति में। हम शुरू करने की कोशिश करते हैं, और हमें एक त्रुटि संदेश मिलता है।

अब स्थिति में बंडलों की सूची में विफल। क्या हो रहा है? जाहिर है, उसे भी निर्भरता की आवश्यकता है, इस मामले में, ओरेकल जेडडीबीसी वर्गों के साथ एक जार, या अधिक सटीक रूप से, oracle.jdbc.pool पैकेज।
हम भंडार में आवश्यक जार पाते हैं, या ओरेकल साइट से डाउनलोड करते हैं, और स्थापित करते हैं, जैसा कि पहले वर्णित है। हमारा डेटा स्रोत शुरू हो गया है।

यह सब कैसे उपयोग करें? सेवा लिंक को ब्लूप्रिंट संदर्भ में कहा जाता है (कहीं, एक बंडल के संदर्भ में):

 <reference id="dataSource" interface="javax.sql.DataSource"/> 

फिर, यह बीन हमेशा की तरह, अन्य बीन्स के लिए एक निर्भरता बन जाती है (ऊंट-वर्ग उदाहरण में):

 <bean id="sql" class="org.apache.camel.component.sql.SqlComponent"> <property name="dataSource" ref="dataSource"/> </bean> 

जार और एक्टिवेटर

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

सेटिंग्स और कॉन्फ़िगरेशन

यह स्पष्ट है कि डेटा स्रोत का ऐसा विन्यास, जैसा कि उदाहरण में दिखाया गया है, कम लोगों की आवश्यकता है। लॉगिन, पासवर्ड, और अधिक, सब कुछ XML के अंदर हार्डकोड किया गया है। इन मापदंडों को बाहर निकालना आवश्यक है।

 <property name="url" value="${oracle.ds.url}"/> <property name="user" value="${oracle.ds.user}"/> <property name="password" value="${oracle.ds.password}"/> 

समाधान काफी सरल है, और क्लासिक स्प्रिंग में उपयोग किए जाने के समान है: संदर्भ जीवन चक्र में एक निश्चित बिंदु पर, विभिन्न स्रोतों से संपत्ति मूल्यों को प्रतिस्थापित किया जाता है।

इस पर हम पहला भाग समाप्त करेंगे। यदि इस विषय में रुचि है, तो जारी रखा जाना चाहिए। हम इस प्लेटफ़ॉर्म पर बंडलों से एप्लिकेशन को इकट्ठा करने, कॉन्फ़िगर करने, मॉनिटर करने और स्वचालित रूप से सिस्टम को तैनात करने का तरीका समझेंगे।