सामान्य वस्तु अनुरोध ब्रोकर आर्किटेक्चर

From alpha
Jump to navigation Jump to search

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 फिर IDL से C++ या Java (प्रोग्रामिंग भाषा) जैसी विशिष्ट कार्यान्वयन भाषा के लिए मैपिंग निर्दिष्ट करता है। Ada (प्रोग्रामिंग भाषा), C (प्रोग्रामिंग भाषा), C++, C++11, COBOL, Java (प्रोग्रामिंग भाषा), लिस्प (प्रोग्रामिंग भाषा), PL/I, ऑब्जेक्ट पास्कल, पायथन (प्रोग्रामिंग भाषा), रूबी (प्रोग्रामिंग भाषा) और स्मॉलटॉक के लिए मानक मैपिंग मौजूद हैं। सी शार्प (प्रोग्रामिंग भाषा)|सी#, एर्लांग (प्रोग्रामिंग भाषा), पर्ल, टी.सी.एल और मूल दृश्य के लिए गैर-मानक मैपिंग मौजूद हैं जो उन भाषाओं के लिए लिखे गए वस्तु अनुरोध दलाल ्स (ओआरबी) द्वारा कार्यान्वित की जाती हैं।

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

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

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

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

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

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

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

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

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

Version Version Date Highlights
1.0 October 1991 First version, C mapping
1.1 February 1992 Interoperability, C++ mapping
1.2 December 1993 -
2.0 August 1996 First major update of the standard, also dubbed CORBA 2
2.1 August 1997 -
2.2 February 1998 Java mapping
2.3 June 1999 -
2.4 August 2000 -
2.5 September 2001 -
2.6 December 2001 -
3.0 July 2002 Second major update of the standard, also dubbed CORBA 3
CORBA Component Model (CCM)
3.0.1 November 2002 -
3.0.2 December 2002 -
3.0.3 March 2004 -
3.1 January 2008 -
3.1.1 August 2011 Adopted as 2012 edition of ISO/IEC 19500
3.2 November 2011 -
3.3 November 2012 Addition of ZIOP
3.4 February 2021


नौकर

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

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

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

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

विशेषताएँ

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

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

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

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

मूल्य के अनुसार डेटा

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

मूल्य के अनुसार वस्तुएं (ओबीवी)

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

कॉर्बा घटक मॉडल (सीसीएम)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सामान्य वस्तु अनुरोध ब्रोकर: वास्तुकला और विशिष्टता (CORBA 2.3)

कोरबा स्थान (कॉर्बालोक)

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

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

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

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

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

लाभ

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

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

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

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

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

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

रेफरी>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 मानक के संशोधनों को बार-बार जारी किया गया, जिसे कुछ ORB कार्यान्वयनकर्ताओं ने सुनिश्चित किया कि मालिकाना एक्सटेंशन के बिना उपयोग करना मुश्किल था।[6]कम नैतिक CORBA विक्रेताओं ने ग्राहक लॉक-इन को प्रोत्साहित किया और मजबूत अल्पकालिक परिणाम प्राप्त किए। समय के साथ पोर्टेबिलिटी को प्रोत्साहित करने वाले ओआरबी विक्रेताओं ने बाजार हिस्सेदारी पर कब्जा कर लिया।[citation needed]
कार्यान्वयन में समस्याएँ
अपने पूरे इतिहास में, कोरबा खराब ओआरबी कार्यान्वयन में कमियों से ग्रस्त रहा है। दुर्भाग्य से एक मानक के रूप में कॉर्बा की आलोचना करने वाले कई दस्तावेज़ केवल विशेष रूप से खराब कॉर्बा ओआरबी कार्यान्वयन की आलोचना करते हैं।
CORBA कई विशेषताओं वाला एक व्यापक मानक है। कुछ कार्यान्वयन सभी विशिष्टताओं को लागू करने का प्रयास करते हैं,[7] और प्रारंभिक कार्यान्वयन अपूर्ण या अपर्याप्त थे। चूँकि संदर्भ कार्यान्वयन प्रदान करने की कोई आवश्यकता नहीं थी, सदस्य उन सुविधाओं का प्रस्ताव करने के लिए स्वतंत्र थे जिनकी उपयोगिता या कार्यान्वयन क्षमता के लिए कभी परीक्षण नहीं किया गया था। मानक की क्रियात्मक होने की सामान्य प्रवृत्ति और सभी प्रस्तुत प्रस्तावों के योग को अपनाकर समझौता करने की सामान्य प्रथा के कारण कार्यान्वयन में और बाधा उत्पन्न हुई, जिससे अक्सर ऐसे एपीआई बनाए गए जो असंगत और उपयोग में कठिन थे, भले ही व्यक्तिगत प्रस्ताव पूरी तरह से उचित थे।[citation needed]
CORBA का मजबूत कार्यान्वयन अतीत में हासिल करना बहुत कठिन रहा है, लेकिन अब इसे ढूंढना बहुत आसान है। SUN Java SDK कॉर्बा बिल्ट-इन के साथ आता है। कुछ ख़राब डिज़ाइन वाले कार्यान्वयन जटिल, धीमे, असंगत और अपूर्ण पाए गए हैं। मजबूत व्यावसायिक संस्करण सामने आने लगे लेकिन काफी लागत पर। जैसे ही अच्छी गुणवत्ता वाले निःशुल्क कार्यान्वयन उपलब्ध हुए, ख़राब व्यावसायिक कार्यान्वयन शीघ्र ही ख़त्म हो गए।
फ़ायरवॉल
CORBA (अधिक सटीक रूप से, जनरल इंटर-ओआरबी प्रोटोकॉल) किसी विशेष संचार परिवहन से बंधा नहीं है। जीआईओपी की एक विशेषज्ञता इंटरनेट इंटर-ओआरबी प्रोटोकॉल या आईआईओपी है। IIOP डेटा संचारित करने के लिए कच्चे टीसीपी/आईपी कनेक्शन का उपयोग करता है।
यदि क्लाइंट बहुत ही प्रतिबंधात्मक फ़ायरवॉल या पारदर्शी प्रॉक्सी सर्वर वातावरण के पीछे है जो केवल पोर्ट 80 के माध्यम से बाहरी HTTP कनेक्शन की अनुमति देता है, तो संचार असंभव हो सकता है, जब तक कि प्रश्न में प्रॉक्सी सर्वर टनलिंग प्रोटोकॉल विधि या SOCKS कनेक्शन की भी अनुमति नहीं देता है। एक समय में, कार्यान्वयन को एकल मानक पोर्ट का उपयोग करने के लिए मजबूर करना भी मुश्किल था - वे इसके बजाय कई यादृच्छिक पोर्ट चुनते थे। आज की स्थिति के अनुसार, वर्तमान ओआरबी में ये कमियाँ हैं। ऐसी कठिनाइयों के कारण, कुछ उपयोगकर्ताओं ने CORBA के बजाय वेब सेवाओं का उपयोग बढ़ाना शुरू कर दिया है। ये पोर्ट 80 के माध्यम से XML/SOAP का उपयोग करके संचार करते हैं, जिसे आमतौर पर HTTP के माध्यम से वेब ब्राउज़िंग के लिए संगठन के अंदर HTTP प्रॉक्सी के माध्यम से खुला या फ़िल्टर किया जाता है। हालाँकि, हाल के CORBA कार्यान्वयन सिक्योर सॉकेट लेयर का समर्थन करते हैं और इसे एकल पोर्ट पर काम करने के लिए आसानी से कॉन्फ़िगर किया जा सकता है। कुछ ORBS, जैसे TAO (सॉफ़्टवेयर), omniORB और JacORB भी द्विदिशात्मक GIOP का समर्थन करते हैं, जो 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.


अग्रिम पठन


बाहरी संबंध