ओएसजीआई बनाम जेबॉस हॉट तैनाती

Question

जो मैं समझता हूं, ओएसजीआई में आप सर्वर को पुनरारंभ किए बिना रनटाइम पर जार अपडेट कर सकते हैं। लेकिन jboss में भी हॉट-परिनियोजन है जिसमें पूरा कान अपडेट किया गया है और सर्वर अभी भी चल रहा है।

तो jboss में एंटरप्राइज़ जावा प्रोजेक्ट में ओएसजीआई के लाभ क्या होंगे?

Answer 1

मुझे विश्वास है कि उत्तर प्रत्येक ओएसजीआई उपयोग मामले के समान है: मॉड्यूलरिटी और बेहतर अद्यतन ग्रैन्युलरिटी।

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

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

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

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

Answer 2

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

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

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

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

ओएसजीआई सेवा रजिस्ट्री का उपयोग करने के कई तरीके हैं, आप इसे ServiceTracker API के साथ उपयोग कर सकते हैं, जो काफी कम स्तर पर है। ज्यादातर मामलों में ओएसजीआई डिक्लेरेटिव सर्विसेज (डीएस), ओएसजीआई ब्लूप्रिंट या अन्य ढांचे जैसे फ्रेमवर्क का उपयोग करना बेहतर होता है। ज्यादातर मामलों में ये ढांचे इंजेक्शन के माध्यम से काम करते हैं और आपके लिए ओएसजीआई सेवा रजिस्ट्री की गतिशीलता को संभालते हैं। डीएस या ब्लूप्रिंट पर जानकारी के लिए OSGi 4.2 Enterprise Specification देखें।