कॉमन ऑब्जेक्ट रिक्वेस्ट ब्रोकर आर्किटेक्चर

From Vigyanwiki
Revision as of 15:07, 19 May 2023 by alpha>Govind0190 (→‎अवलोकन)

Common Object Request Broker Architecture
AbbreviationCORBA
StatusPublished
Year started1991; 33 years ago (1991)
Latest version3.4
February 2021; 3 years ago (2021-02)
OrganizationObject Management Group
Websitecorba.org

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

अवलोकन

CORBA विभिन्न भाषाओं में लिखे गए और विभिन्न कंप्यूटरों पर चलने वाले सॉफ़्टवेयर के बीच संचार को सक्षम बनाता है। विशिष्ट ऑपरेटिंग सिस्टम्स, प्रोग्रामिंग भाषाओ और हार्डवेयर प्लेटफॉर्म्स से कार्यान्वयन विवरण सभी को CORBA का उपयोग करने वाले डेवलपर्स की जिम्मेदारी से हटा दिया गया है। CORBA एक ही एड्रेस-स्पेस (एप्लिकेशन) या रिमोट एड्रेस-स्पेस (एक ही होस्ट, या नेटवर्क पर रिमोट होस्ट) में रहने वाले एप्लिकेशन ऑब्जेक्ट्स के बीच मेथड-कॉल शब्दार्थ को सामान्य करता है। संस्करण 1.0 अक्टूबर 1991 में जारी किया गया था।

CORBA बाहरी दुनिया में मौजूद वस्तुओं को इंटरफेस निर्दिष्ट करने के लिए एक इंटरफ़ेस परिभाषा भाषा (आईडीएल) का उपयोग करता है। CORBA तब आईडीएल से एक विशिष्ट कार्यान्वयन भाषा जैसे C ++ या जावा (प्रोग्रामिंग भाषा) में मैपिंग निर्दिष्ट करता है। Ada (प्रोग्रामिंग लैंग्वेज), सी (प्रोग्रामिंग भाषा), सी++, सी++11, COBOL, जावा (प्रोग्रामिंग लैंग्वेज), लिस्प (प्रोग्रामिंग भाषा) , PL/I, वस्तु पास्कल , पायथन (प्रोग्रामिंग लैंग्वेज), के लिए मानक मैपिंग मौजूद हैं। रूबी (प्रोग्रामिंग भाषा) और स्मॉलटाक। सी Sharp (प्रोग्रामिंग लैंग्वेज) के लिए गैर-मानक मैपिंग मौजूद हैं। सी#, Erlang, Perl, Tcl और Visual Basic के लिए गैर-मानक मैपिंग मौजूद हैं जो उन भाषाओं के लिए लिखे गए ऑब्जेक्ट रिक्वेस्ट ब्रोकर्स (ORBs) द्वारा कार्यान्वित किए गए हैं।

CORBA विनिर्देश निर्धारित करता है कि एक ओआरबी होना चाहिए जिसके माध्यम से एक एप्लिकेशन अन्य वस्तुओं के साथ इंटरैक्ट करेगा। इस प्रकार इसे व्यवहार में कार्यान्वित किया जाता है:

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

कुछ आईडीएल मैपिंग दूसरों की तुलना में उपयोग करने में अधिक कठिन हैं। उदाहरण के लिए, जावा की प्रकृति के कारण, आईडीएल-जावा मैपिंग अपेक्षाकृत सीधी है और जावा एप्लिकेशन में CORBA के उपयोग को बहुत सरल बनाती है। यह आईडीएल से पाइथन मैपिंग के लिए भी सही है। सी++ मैपिंग के लिए प्रोग्रामर को डेटाटाइप सीखने की आवश्यकता होती है जो सी++ मानक टेम्पलेट लाइब्रेरी (एसटीएल) से पहले होती है। इसके विपरीत, सी++11 मैपिंग का उपयोग करना आसान है, लेकिन इसके लिए STL के भारी उपयोग की आवश्यकता होती है। चूंकि सी भाषा ऑब्जेक्ट-ओरिएंटेड नहीं है, आईडीएल से C मैपिंग के लिए ऑब्जेक्ट-ओरिएंटेड सुविधाओं को मैन्युअल रूप से अनुकरण करने के लिए सी प्रोग्रामर की आवश्यकता होती है।

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

CORBA आईडीएल का उपयोग करके परिभाषित एक इंटरफ़ेस से इन्फ्रास्ट्रक्चर कोड के ऑटोजेनरेशन का चित्रण

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

उपयोगकर्ताओं को एक भाषा और एक प्लेटफ़ॉर्म-तटस्थ दूरस्थ प्रक्रिया कॉल (RPC) विनिर्देश प्रदान करने के अलावा, CORBA लेनदेन और सुरक्षा, घटनाओं, समय और अन्य डोमेन-विशिष्ट इंटरफ़ेस मॉडल जैसी सामान्य रूप से आवश्यक सेवाओं को परिभाषित करता है।

संस्करणों का इतिहास

यह तालिका CORBA मानक संस्करणों का इतिहास प्रस्तुत करती है।[1][2]

संस्करण संस्करण तिथि हाइलाइट्स
1.0 अक्टूबर 1991 पहला संस्करण, सी मैपिंग
1.1 फ़रवरी 1992 इंटरऑपरेबिलिटी, सी++ मैपिंग
1.2 दिसंबर 1993 -
2.0 अगस्त 1996 मानक का पहला प्रमुख अद्यतन, जिसे डब भी किया गया CORBA 2
2.1 अगस्त 1997 -
2.2 फ़रवरी 1998 जावा मैपिंग
2.3 जून 1999 -
2.4 अगस्त 2000 -
2.5 सितंबर 2001 -
2.6 दिसंबर 2001 -
3.0 जुलाई 2002 मानक का दूसरा प्रमुख अद्यतन, जिसे CORBA 3 भी कहा जाता है

CORBA घटक मॉडल (सीसीएम)

3.0.1 नवंबर 2002 -
3.0.2 दिसंबर 2002 -
3.0.3 मार्च 2004 -
3.1 जनवरी 2008 -
3.1.1 अगस्त 2011 आईएसओ/आईईसी 19500 के 2012 संस्करण के रूप में अपनाया गया
3.2 नवंबर 2011 -
3.3 नवंबर 2012 जिओप (ZIOP) का जोड़
3.4 फ़रवरी 2021


सेवक

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

अवतार एक नौकर को एक कोरबा वस्तु के साथ जोड़ने का कार्य है ताकि यह सेवा अनुरोधों को पूरा कर सके। अवतार वर्चुअल CORBA ऑब्जेक्ट के लिए एक ठोस नौकर रूप प्रदान करता है। एक्टिवेशन और डिएक्टिवेशन केवल CORBA ऑब्जेक्ट्स को संदर्भित करते हैं, जबकि अवतार और ईथरलाइजेशन नौकरों को संदर्भित करते हैं। हालाँकि, वस्तुओं और नौकरों का जीवनकाल स्वतंत्र होता है। एक्टिव_ऑब्जेक्ट () को कॉल करने से पहले आप हमेशा एक नौकर का अवतार लेते हैं, लेकिन इसका उल्टा भी संभव है, create_reference () एक नौकर को अवतरित किए बिना एक वस्तु को सक्रिय करता है, और नौकर का अवतार बाद में एक नौकर प्रबंधक के साथ मांग पर किया जाता है।

Portable Object Adapter (POA) CORBA ऑब्जेक्ट है जो सर्वर साइड रिमोट इनवोकेशन हैंडलर को रिमोट ऑब्जेक्ट और उसके नौकर में विभाजित करने के लिए जिम्मेदार है। दूरस्थ आह्वान के लिए वस्तु का खुलासा किया गया है, जबकि नौकर में वे विधियाँ हैं जो वास्तव में अनुरोधों को संभाल रही हैं। प्रत्येक वस्तु के लिए नौकर को या तो स्थिर रूप से (एक बार) या गतिशील रूप से (प्रत्येक दूरस्थ मंगलाचरण के लिए) चुना जा सकता है, दोनों मामलों में कॉल को दूसरे सर्वर पर अग्रेषित करने की अनुमति देता है।

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

सुविधाएँ

निम्नलिखित कुछ सबसे महत्वपूर्ण तरीकों का वर्णन करता है जो CORBA का उपयोग वितरित वस्तुओं के बीच संचार को सुविधाजनक बनाने के लिए किया जा सकता है।

संदर्भ द्वारा वस्तुएं

यह संदर्भ या तो एक कड़े यूनिफ़ॉर्म रिसोर्स लोकेटर (URL), NameService लुकअप (डोमेन की नामांकन प्रणाली (DNS) के समान) के माध्यम से प्राप्त किया जाता है, या कॉल के दौरान एक विधि पैरामीटर के रूप में पास-इन किया जाता है।

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

डेटा द्वारा मूल्य

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

ऑब्जेक्ट बाय वैल्यू (ओबीवी)

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

CORBA घटक मॉडल (सीसीएम)

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

CCM में एक घटक कंटेनर होता है, जहाँ सॉफ़्टवेयर घटकों को परिनियोजित किया जा सकता है। कंटेनर सेवाओं का एक सेट प्रदान करता है जिसका घटक उपयोग कर सकते हैं। इन सेवाओं में सम्मिलित हैं (लेकिन इन तक सीमित नहीं हैं) अधिसूचना प्रणाली, प्रमाणीकरण, दृढ़ता (कंप्यूटर विज्ञान) और लेनदेन प्रसंस्करण। ये किसी भी वितरित प्रणाली के लिए सबसे अधिक उपयोग की जाने वाली सेवाएं हैं, और इन सेवाओं के कार्यान्वयन को सॉफ्टवेयर घटकों से घटक कंटेनर में ले जाने से, घटकों की जटिलता नाटकीय रूप से कम हो जाती है।

पोर्टेबल इंटरसेप्टर

पोर्टेबल इंटरसेप्टर हुक हैं, जिनका उपयोग CORBA और RMI-IIOP द्वारा CORBA प्रणाली के सबसे महत्वपूर्ण कार्यों में मध्यस्थता करने के लिए किया जाता है। CORBA मानक निम्न प्रकार के इंटरसेप्टर को परिभाषित करता है:

  1. इंटरऑपरेबल ऑब्जेक्ट रेफरेंस इंटरसेप्टर वर्तमान सर्वर द्वारा प्रस्तुत रिमोट ऑब्जेक्ट्स के नए संदर्भों के निर्माण में मध्यस्थता करते हैं।
  2. क्लाइंट इंटरसेप्टर आमतौर पर क्लाइंट (कॉलर) की ओर से रिमोट मेथड कॉल को मध्यस्थ करते हैं। यदि ऑब्जेक्ट सर्वेंट (CORBA) उसी सर्वर पर मौजूद है जहां विधि लागू की गई है, तो वे स्थानीय कॉलों की मध्यस्थता भी करते हैं।
  3. सर्वर इंटरसेप्टर सर्वर (हैंडलर) की ओर से दूरस्थ विधि कॉल को संभालने में मध्यस्थता करता है।

इंटरसेप्टर भेजे जा रहे संदेशों और बनाए जा रहे IORs के लिए विशिष्ट जानकारी संलग्न कर सकते हैं। इस जानकारी को बाद में रिमोट साइड पर संबंधित इंटरसेप्टर द्वारा पढ़ा जा सकता है। इंटरसेप्टर अग्रेषण अपवादों को भी फेंक सकते हैं, अनुरोध को किसी अन्य लक्ष्य पर पुनर्निर्देशित कर सकते हैं।

सामान्य इंटरऑर्ब प्रोटोकॉल (जीआईओपी)

Main article: General Inter-ORB Protocol

सामान्य इंटर-ओआरबी प्रोटोकॉल एक सार प्रोटोकॉल है जिसके द्वारा ऑब्जेक्ट अनुरोध ब्रोकर (ओआरबी) संवाद करते हैं। प्रोटोकॉल से जुड़े मानकों को ऑब्जेक्ट मैनेजमेंट ग्रुप (ओएमजी) द्वारा बनाए रखा जाता है। जीआईओपी आर्किटेक्चर कई ठोस प्रोटोकॉल प्रदान करता है, जिनमें निम्न सम्मिलित हैं:

  1. इंटरनेट इंटरओआरबी प्रोटोकॉल (आईआईओपी) - इंटरनेट इंटर-ऑर्ब प्रोटोकॉल इंटरनेट पर उपयोग के लिए जीआईओपी का कार्यान्वयन है, और जीआईओपी संदेशों और इंटरनेट प्रोटोकॉल सूट के बीच मैपिंग प्रदान करता है। टीसीपी/आईपी परत।
  2. एसएसएल इंटरओआरबी प्रोटोकॉल (एसएसएलआईओपी) - एसएसएलआईओपी सुरक्षित सॉकेट लेयर पर आईआईओपी है, जो कूटलेखन और प्रमाणीकरण प्रदान करता है।
  3. हाइपरटेक्स्ट इंटरओआरबी प्रोटोकॉल (HTIOP) - HTIOP HTTP पर IIOP है, पारदर्शी प्रॉक्सी बायपासिंग प्रदान करता है।
  4. Zipped IOP (ZIOP) - GIOP का एक ज़िपित संस्करण जो बैंडविड्थ उपयोग को कम करता है।

वीएमसीआईडी ​​(वेंडर माइनर कोडसेट आईडी)

प्रत्येक मानक CORBA अपवाद में अपवाद की उपश्रेणी निर्दिष्ट करने के लिए एक मामूली कोड सम्मिलित होता है। लघु अपवाद कोड अहस्ताक्षरित लंबे प्रकार के होते हैं और इसमें 20-बिट वेंडर माइनर कोडसेट आईडी (VMCID) होता है, जो उच्च क्रम 20 बिट्स पर कब्जा कर लेता है, और मामूली कोड उचित होता है जो निम्न क्रम 12 बिट्स पर कब्जा कर लेता है।

मानक अपवादों के लिए मामूली कोड OMG को असाइन किए गए VMCID द्वारा प्रस्तुत किए जाते हैं, जिन्हें अहस्ताक्षरित लंबे स्थिर CORBA::OMGVMCID के रूप में परिभाषित किया गया है, जिसमें VMCID को OMG को आवंटित किया गया है जो उच्च क्रम 20 बिट्स पर कब्जा कर रहा है। पृष्ठ 3-58 पर तालिका 3–13 में पाए जाने वाले मानक अपवादों से जुड़े मामूली अपवाद कोड OMGVMCID के साथ or-ed हैं जो मामूली कोड मान प्राप्त करने के लिए हैं जो ex_body संरचना में लौटाए गए हैं (धारा 3.17.1, मानक अपवाद देखें) परिभाषाएँ, पृष्ठ 3-52 पर और धारा 3.17.2, मानक लघु अपवाद कोड, पृष्ठ 3-58 पर)।

एक वेंडर असाइन किए गए स्थान के भीतर, मामूली कोड के मानों का असाइनमेंट वेंडर पर छोड़ दिया जाता है। विक्रेता ईमेल भेजकर वीएमसीआईडी ​​के आवंटन का अनुरोध कर सकते हैं tagrequest@omg.org. वर्तमान में असाइन किए गए वीएमसीआईडी ​​की एक सूची ओएमजी वेबसाइट पर यहां पाई जा सकती है: http://www.omg.org/cgi-bin/doc?vendor-tags

VMCID 0 और 0xffffff प्रायोगिक उपयोग के लिए आरक्षित हैं। VMCID OMGVMCID (धारा 3.17.1, मानक अपवाद परिभाषाएँ, पृष्ठ 3-52 पर) और 1 से 0xf OMG उपयोग के लिए आरक्षित हैं।

कॉमन ऑब्जेक्ट रिक्वेस्ट ब्रोकर: आर्किटेक्चर एंड स्पेसिफिकेशन (CORBA 2.3)

Corba स्थान (CorbaLoc)

Corba स्थान (CorbaLoc) एक CORBA ऑब्जेक्ट के लिए कड़े ऑब्जेक्ट संदर्भ को संदर्भित करता है जो URL के समान दिखता है।

सभी CORBA उत्पादों को दो ओएमजी-परिभाषित यूआरएल का समर्थन करना चाहिए:corbaloc: औरcorbaname: . इनका उद्देश्य उस स्थान को निर्दिष्ट करने के लिए मानव पठनीय और संपादन योग्य तरीका प्रदान करना है जहां एक आईओआर प्राप्त किया जा सकता है।

कॉर्बॉक का एक उदाहरण नीचे दिखाया गया है:

corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root

एक CORBA उत्पाद वैकल्पिक रूप से समर्थन कर सकता हैhttp: ,ftp: औरfile: प्रारूप। इनका शब्दार्थ यह है कि वे एक कड़े आईओआर को डाउनलोड करने के तरीके का विवरण प्रदान करते हैं (या, पुनरावर्ती रूप से, एक और यूआरएल डाउनलोड करें जो अंततः एक कड़े आईओआर प्रदान करेगा)। कुछ ओआरबी अतिरिक्त प्रारूप प्रदान करते हैं जो उस ओआरबी के लिए मालिकाना हैं।

लाभ

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

भाषा की स्वतंत्रता
CORBA को इंजीनियरों को उनके डिजाइन को एक विशेष सॉफ्टवेयर भाषा में युग्मित करने की सीमाओं से मुक्त करने के लिए डिज़ाइन किया गया था। वर्तमान में विभिन्न CORBA प्रदाताओं द्वारा समर्थित कई भाषाएं हैं, जिनमें सबसे लोकप्रिय जावा और सी++ हैं। C++11, C-only, Smalltalk, Perl, Ada, Ruby, और पाइथन कार्यान्वयन भी हैं, केवल कुछ का उल्लेख करने के लिए।
OS-स्वतंत्रता
CORBA का डिज़ाइन OS-स्वतंत्र होने के लिए है। CORBA जावा (OS-स्वतंत्र) में उपलब्ध है, साथ ही Linux/Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, थ्रेडएक्स, इंटीग्रिटी, और अन्य के लिए मूल रूप से उपलब्ध है।
प्रौद्योगिकियों से स्वतंत्रता
मुख्य निहित लाभों में से एक यह है कि CORBA इंजीनियरों को विभिन्न नई और पुरानी प्रणालियों के बीच इंटरफेस को सामान्य करने में सक्षम होने के लिए एक तटस्थ खेल का मैदान प्रदान करता है। सी, C ++, ऑब्जेक्ट पास्कल, जावा, फोरट्रान, पायथन, और किसी भी अन्य भाषा या ओएस को एक एकल एकजुट प्रणाली डिजाइन मॉडल में एकीकृत करते समय, CORBA क्षेत्र को समतल करने के लिए साधन प्रदान करता है और अलग-अलग टीमों को सिस्टम और यूनिट परीक्षण विकसित करने की अनुमति देता है जो बाद में कर सकते हैं एक पूरे सिस्टम में एक साथ सम्मिलित हो। यह बुनियादी सिस्टम इंजीनियरिंग निर्णयों की आवश्यकता से इंकार नहीं करता है, जैसे कि थ्रेडिंग, टाइमिंग, ऑब्जेक्ट लाइफ़टाइम, आदि। ये मुद्दे किसी भी सिस्टम का हिस्सा हैं, भले ही तकनीक कोई भी हो। CORBA सिस्टम तत्वों को एक एकल संसक्त प्रणाली मॉडल में सामान्यीकृत करने की अनुमति देता है।
उदाहरण के लिए, वेब सर्वर में जावा सर्वलेट्स और व्यापार तर्क वाले विभिन्न CORBA सर्वरों का उपयोग करके एक बहुस्तरीय वास्तुकला का डिज़ाइन सरल बनाया गया है और डेटाबेस एक्सेस को लपेटता है। यह व्यापार तर्क के कार्यान्वयन को बदलने की अनुमति देता है, जबकि इंटरफ़ेस परिवर्तनों को किसी अन्य तकनीक के रूप में नियंत्रित करने की आवश्यकता होगी। उदाहरण के लिए, बाहरी इंटरफेस को प्रभावित किए बिना, बेहतर डिस्क उपयोग या प्रदर्शन (या यहां तक ​​कि पूरे पैमाने पर डेटाबेस विक्रेता परिवर्तन) के लिए सर्वर द्वारा लिपटे डेटाबेस में डेटाबेस स्कीमा परिवर्तन हो सकता है। उसी समय, C ++ विरासत कोड सी / फोरट्रान विरासत कोड और जावा डेटाबेस कोड से बात कर सकता है, और वेब इंटरफ़ेस को डेटा प्रदान कर सकता है।
डेटा-टाइपिंग
CORBA लचीला डेटा टाइपिंग प्रदान करता है, उदाहरण के लिए कोई भी डेटाटाइप। CORBA मानवीय त्रुटियों को कम करते हुए कसकर युग्मित डेटा टाइपिंग को भी लागू करता है। ऐसी स्थिति में जहां नाम-मूल्य जोड़े पास हो जाते हैं, यह कल्पना की जा सकती है कि एक सर्वर एक संख्या प्रदान करता है जहां एक स्ट्रिंग अपेक्षित थी। CORBA इंटरफ़ेस डेफिनिशन लैंग्वेज यह सुनिश्चित करने के लिए तंत्र प्रदान करती है कि उपयोगकर्ता-कोड विधि-नामों, रिटर्न-, पैरामीटर-प्रकारों और अपवादों के अनुरूप हो।
उच्च ट्यूनेबिलिटी
कई कार्यान्वयन (जैसे ORBexpress (Ada, C++, और जावा कार्यान्वयन)[4] और ओमनीओआरबी (ओपन सोर्स C ++ और पायथन कार्यान्वयन))[5] थ्रेडिंग और कनेक्शन प्रबंधन सुविधाओं को ट्यून करने के विकल्प हैं। सभी ओआरबी कार्यान्वयन समान सुविधाएँ प्रदान नहीं करते हैं।
डेटा-ट्रांसफर विवरण से मुक्ति
निम्न-स्तरीय कनेक्शन और थ्रेडिंग को संभालते समय, CORBA त्रुटि स्थितियों में उच्च स्तर का विवरण प्रदान करता है। इसे CORBA-परिभाषित मानक अपवाद सेट और कार्यान्वयन-विशिष्ट विस्तारित अपवाद सेट में परिभाषित किया गया है। अपवादों के माध्यम से, एप्लिकेशन यह निर्धारित कर सकता है कि छोटी समस्या जैसे कारणों से कॉल विफल हो गई है, इसलिए पुनः प्रयास करें, सर्वर मर चुका है या संदर्भ समझ में नहीं आता है। सामान्य नियम है: अपवाद प्राप्त नहीं करने का अर्थ है कि विधि कॉल सफलतापूर्वक पूर्ण हो गई। यह एक बहुत शक्तिशाली डिज़ाइन सुविधा है।
संपीड़न
CORBA अपने डेटा को बाइनरी रूप में मार्शल करता है और संपीड़न का समर्थन करता है। IONA, Remedy IT, और Telefonica|Telefónica ने CORBA मानक के विस्तार पर काम किया है जो संपीड़न प्रदान करता है। इस विस्तार को ZIOP कहा जाता है और यह अब एक औपचारिक OMG मानक है।

समस्याएं और आलोचना

जबकि CORBA ने जिस तरह से कोड लिखा गया था और सॉफ्टवेयर का निर्माण किया, उसमें बहुत कुछ दिया, यह आलोचना का विषय रहा है।[6]

CORBA की अधिकांश आलोचना मानक के खराब कार्यान्वयन से उत्पन्न होती है न कि स्वयं मानक की कमियों से। मानक की कुछ विफलताएं स्वयं उस प्रक्रिया के कारण थीं जिसके द्वारा CORBA विनिर्देश बनाया गया था और राजनीति में निहित समझौता और एक सामान्य मानक लिखने का व्यवसाय कई प्रतिस्पर्धी कार्यान्वयनकर्ताओं द्वारा तैयार किया गया था।

प्रारंभिक कार्यान्वयन असंगतताएँ

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

स्थान पारदर्शिता

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

रेफरी>Waldo, Jim; Geoff Wyant; Ann Wollrath; Sam Kendall (November 1994). "वितरित कंप्यूटिंग पर एक नोट" (PDF). Sun Microsystem Laboratories. Archived (PDF) from the original on 10 October 2022. Retrieved 4 November 2013.</ref>[failed verification] क्योंकि यह सभी ऑब्जेक्ट एक्सेस को सबसे जटिल मामले के रूप में जटिल बनाता है (यानी, विफलताओं की एक विस्तृत श्रेणी के साथ दूरस्थ नेटवर्क कॉल जो स्थानीय कॉल में संभव नहीं है)। यह दो वर्गों के बीच अपरिहार्य अंतर को भी छुपाता है, जिससे अनुप्रयोगों के लिए एक उपयुक्त उपयोग रणनीति का चयन करना असंभव हो जाता है (अर्थात, 1µs विलंबता वाली कॉल और संभावित परिवहन विफलता के साथ 1s विलंबता वाली कॉल से गारंटीकृत रिटर्न का उपयोग बहुत अलग तरीके से किया जाएगा, जिसमें डिलीवरी की स्थिति संभावित रूप से अज्ञात है और समय समाप्त होने में 30 सेकंड लग सकते हैं)। डिजाइन और प्रक्रिया की कमियां

CORBA मानक का निर्माण भी अक्सर समिति द्वारा इसकी डिजाइन की प्रक्रिया के लिए उद्धृत किया जाता है। परस्पर विरोधी प्रस्तावों के बीच मध्यस्थता करने या निपटने के लिए समस्याओं के पदानुक्रम पर निर्णय लेने की कोई प्रक्रिया नहीं थी। इस प्रकार सभी प्रस्तावों में सुविधाओं के संघ को उनके सुसंगतता के संबंध में मानक बनाकर बनाया गया था।[7]इसने विनिर्देश को जटिल, पूरी तरह से लागू करने के लिए महंगा और अक्सर अस्पष्ट बना दिया।
कार्यान्वयन विक्रेताओं और ग्राहकों के मिश्रण से बनी एक डिजाइन समिति ने रुचियों का एक विविध सेट तैयार किया। इस विविधता ने एक सामंजस्यपूर्ण मानक को कठिन बना दिया। मानकों और अंतर-संचालनीयता ने प्रतिस्पर्धा में वृद्धि की और वैकल्पिक कार्यान्वयन के बीच ग्राहकों की आवाजाही को आसान बनाया। इससे समिति के भीतर बहुत अधिक राजनीतिक लड़ाई हुई और CORBA मानक के संशोधनों की लगातार रिलीज हुई, जो कि कुछ ओआरबी कार्यान्वयनकर्ताओं ने सुनिश्चित किया कि मालिकाना विस्तार के बिना उपयोग करना मुश्किल था।[6]कम नैतिक CORBA विक्रेताओं ने ग्राहक लॉक-इन को प्रोत्साहित किया और मजबूत अल्पकालिक परिणाम प्राप्त किए। समय के साथ पोर्टेबिलिटी को प्रोत्साहित करने वाले ओआरबी विक्रेताओं ने बाजार हिस्सेदारी पर कब्जा कर लिया।[citation needed]
कार्यान्वयन में समस्याएं
अपने इतिहास के माध्यम से, CORBA खराब ओआरबी कार्यान्वयन में कमियों से ग्रस्त रहा है। दुर्भाग्य से मानक के रूप में CORBA की आलोचना करने वाले कई कागजात केवल एक विशेष रूप से खराब CORBA ओआरबी कार्यान्वयन की आलोचना हैं।
CORBA कई विशेषताओं के साथ एक व्यापक मानक है। कुछ कार्यान्वयन सभी विशिष्टताओं को लागू करने का प्रयास करते हैं,[7] और आरंभिक कार्यान्वयन अपूर्ण या अपर्याप्त थे। चूंकि एक संदर्भ कार्यान्वयन प्रदान करने की कोई आवश्यकता नहीं थी, सदस्य उन विशेषताओं का प्रस्ताव करने के लिए स्वतंत्र थे जिनकी उपयोगिता या कार्यान्वयन के लिए कभी परीक्षण नहीं किया गया था। क्रियान्वित करने के लिए मानक की सामान्य प्रवृत्ति वर्बोज़ होने के कारण, और सभी सबमिट किए गए प्रस्तावों के योग को अपनाकर समझौता करने की सामान्य प्रथा से बाधा उत्पन्न हुई, जो अक्सर एपीआई बनाते थे जो असंगत और उपयोग करने में कठिन थे, भले ही व्यक्तिगत प्रस्ताव पूरी तरह से उचित थे .[citation needed]
CORBA के मजबूत कार्यान्वयन अतीत में हासिल करना बहुत मुश्किल रहा है, लेकिन अब इसे खोजना बहुत आसान है। SUN जावा SDK CORBA बिल्ट-इन के साथ आता है। कुछ खराब तरीके से डिजाइन किए गए कार्यान्वयन जटिल, धीमे, असंगत और अपूर्ण पाए गए हैं। मजबूत व्यावसायिक संस्करण दिखाई देने लगे लेकिन महत्वपूर्ण लागत के लिए। जैसे ही अच्छी गुणवत्ता मुक्त कार्यान्वयन उपलब्ध हुआ खराब व्यावसायिक कार्यान्वयन जल्दी ही समाप्त हो गया।

फ़ायरवॉल

याकूब (अधिक सटीक, सामान्य इंटर-ओआरबी प्रोटोकॉल) किसी विशेष संचार परिवहन से बंधा नहीं है। जीआईओपी की विशेषज्ञता इंटरनेट इंटर-ओआरबी प्रोटोकॉल या आईआईओपी है। आईआईओपी डेटा संचारित करने के लिए कच्चे टीसीपी/आईपी कनेक्शन का उपयोग करता है।
यदि क्लाइंट एक बहुत ही प्रतिबंधित फ़ायरवॉल या पारदर्शी प्रॉक्सी सर्वर वातावरण के पीछे है जो पोर्ट 80 के माध्यम से केवल HTTP कनेक्शन को बाहर की अनुमति देता है, तो संचार असंभव हो सकता है, जब तक कि प्रश्न में प्रॉक्सी सर्वर टनलिंग प्रोटोकॉल विधि या SOCKS कनेक्शन को भी अनुमति नहीं देता है। एक समय में, एक मानक बंदरगाह का उपयोग करने के लिए कार्यान्वयन को मजबूर करना भी मुश्किल था - इसके बजाय वे कई यादृच्छिक बंदरगाहों को चुनते थे। आज तक, मौजूदा ओआरबी में ये कमियां हैं। ऐसी कठिनाइयों के कारण, कुछ उपयोगकर्ताओं ने CORBA के बजाय वेब सेवाओं का अधिकाधिक उपयोग करना शुरू कर दिया है। ये पोर्ट 80 के माध्यम से XML/SOAP का उपयोग करते हुए संचार करते हैं, जिसे HTTP के माध्यम से वेब ब्राउज़िंग के लिए संगठन के अंदर एक HTTP प्रॉक्सी के माध्यम से सामान्य रूप से खुला या फ़िल्टर किया जाता है। हाल ही में CORBA कार्यान्वयन, हालांकि, सिक्योर सॉकेट्स लेयर का समर्थन करते हैं और इसे एक पोर्ट पर काम करने के लिए आसानी से कॉन्फ़िगर किया जा सकता है। कुछ ओआरबीएस, जैसे टीएओ (सॉफ्टवेयर), ओम्नीओआरबी और जैकोरब भी द्विदिश जीआईओपी का समर्थन करते हैं, जो CORBA को वेब सेवा कार्यान्वयन के मतदान दृष्टिकोण विशेषता के बजाय कॉलबैक संचार का उपयोग करने में सक्षम होने का लाभ देता है। इसके अलावा, अधिकांश आधुनिक फ़ायरवॉल GIOP और IIOP का समर्थन करते हैं और इस प्रकार CORBA के अनुकूल फ़ायरवॉल हैं।

यह भी देखें

सॉफ्टवेयर इंजीनियरिंग

घटक-आधारित सॉफ़्टवेयर प्रौद्योगिकियाँ

भाषा बंधन

संदर्भ

  1. ↑ "History of CORBA". Object Management Group. Retrieved 12 March 2017.
  2. ↑ "History of CORBA". Object Management Group. Retrieved 4 June 2017.
  3. ↑ "The CORBA Component Model". Dr. Dobb's Journal. 1 September 2004. Retrieved 13 March 2017.
  4. ↑ "ORBexpress : Real-time CORBA ORB".
  5. ↑ "omniORB : Free CORBA ORB". sourceforge.net. Retrieved 9 January 2014.
  6. ↑ 6.0 6.1 Chappel, David (May 1998). "कोरबा के साथ परेशानी". davidchappel.com. Archived from the original on 3 December 2012. Retrieved 15 March 2010.
  7. ↑ 7.0 7.1 Henning, Michi (30 June 2006). "कॉर्बा का उदय और पतन". ACM Queue. Association for Computing Machinery. 4 (5): 28–34. doi:10.1145/1142031.1142044. S2CID 12103742. Retrieved 15 March 2010.


अग्रिम पठन


बाहरी संबंध

Wikibooks has a book on the topic of: CORBA Programming
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=कॉमन_ऑब्जेक्ट_रिक्वेस्ट_ब्रोकर_आर्किटेक्चर&oldid=186847’