घटक वस्तु मॉडल

कंपोनेंट ऑब्जेक्ट मॉडल (COM) एक एप्लिकेशन बाइनरी इंटरफ़ेस है। 1993 में Microsoft द्वारा पेश किए गए घटक-आधारित सॉफ़्टवेयर इंजीनियरिंग के लिए बाइनरी-इंटरफ़ेस मानक। इसका उपयोग प्रोग्रामिंग भाषाओं की एक बड़ी रेंज में अंतःप्रक्रम संचार   वस्तु (कंप्यूटर विज्ञान)  के निर्माण को सक्षम करने के लिए किया जाता है।. COM कई अन्य Microsoft तकनीकों और फ्रेमवर्क का आधार है, जिसमें जोडकर परनिगरानी और उद्देश् य, OLE ऑटोमेशन, ब्राउज़र सहायक वस्तु, ActiveX, #COM+|COM+, वितरित घटक वस्तु मॉडल, Windows शेल, DirectX, UMDF और Windows रनटाइम शामिल हैं। COM का सार वस्तुओं को लागू करने का एक भाषा-तटस्थ तरीका है जिसका उपयोग उन वातावरणों से भिन्न वातावरण में किया जा सकता है जिनमें वे बनाए गए थे, यहां तक ​​कि मशीन की सीमाओं के पार भी। अच्छी तरह से लिखे गए घटकों के लिए, COM उन वस्तुओं के पुन: उपयोग की अनुमति देता है जिनके आंतरिक कार्यान्वयन का कोई ज्ञान नहीं है, क्योंकि यह घटक कार्यान्वयनकर्ताओं को अच्छी तरह से परिभाषित इंटरफ़ेस (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) प्रदान करने के लिए मजबूर करता है जो कार्यान्वयन से अलग होते हैं। भाषाओं के विभिन्न आबंटन शब्दार्थों को सन्दर्भ गणना|संदर्भ-गणना के माध्यम से वस्तुओं को उनके स्वयं के निर्माण और विनाश के लिए जिम्मेदार बनाकर समायोजित किया जाता है। किसी वस्तु के विभिन्न इंटरफेस के बीच प्रकार रूपांतरण किसके माध्यम से प्राप्त किया जाता है  तरीका। COM के भीतर वंशानुक्रम की पसंदीदा विधि उप-ऑब्जेक्ट्स का निर्माण है, जिसके लिए विधि कॉल प्रत्यायोजित की जाती हैं।

COM एक इंटरफ़ेस तकनीक है जिसे केवल Microsoft Windows और Apple के Core Foundation 1.3 और बाद में प्लग-इन अप्लिकेशन प्रोग्रामिंग अंतरफलक (API) पर मानक के रूप में परिभाषित और कार्यान्वित किया गया है। उत्तरार्द्ध केवल पूरे COM इंटरफ़ेस का सबसेट लागू करता है। कुछ अनुप्रयोगों के लिए, COM को कम से कम कुछ हद तक .NET Framework|Microsoft .NET फ़्रेमवर्क, और Windows संचार फ़ाउंडेशन (WCF) के माध्यम से वेब सेवाओं के लिए समर्थन द्वारा प्रतिस्थापित किया गया है। हालांकि, .NET COM इंटरऑप के माध्यम से COM ऑब्जेक्ट्स का उपयोग सभी .NET भाषाओं के साथ किया जा सकता है। नेटवर्क्ड DCOM बाइनरी मालिकाना प्रारूप  का उपयोग करता है, जबकि WCF XML- आधारित SOAP (प्रोटोकॉल) मैसेजिंग के उपयोग को प्रोत्साहित करता है। COM अन्य घटक सॉफ़्टवेयर इंटरफ़ेस तकनीकों के समान है, जैसे CORBA और एंटरप्राइज JavaBeans, हालांकि प्रत्येक की अपनी ताकत और कमजोरियां हैं। C++ के विपरीत, COM एक स्थिर अनुप्रयोग बाइनरी इंटरफ़ेस (ABI) प्रदान करता है जो कंपाइलर रिलीज़ के बीच नहीं बदलता है। यह COM इंटरफेस को ऑब्जेक्ट-ओरिएंटेड C++ लाइब्रेरी के लिए आकर्षक बनाता है, जिनका उपयोग ग्राहकों द्वारा विभिन्न कंपाइलर संस्करणों का उपयोग करके संकलित किया जाता है।

इतिहास
विंडोज़ में इंटरप्रोसेस संचार के पहले तरीकों में से एक डायनेमिक डेटा एक्सचेंज (डीडीई) था, पहली बार 1987 में पेश किया गया, जो अनुप्रयोगों के बीच तथाकथित वार्तालापों में संदेश भेजने और प्राप्त करने की अनुमति देता है। एंटनी विलियम्स (प्रौद्योगिकीविद्), जो COM आर्किटेक्चर के निर्माण में शामिल थे, ने बाद में Microsoft में दो आंतरिक पेपर वितरित किए जिन्होंने सॉफ्टवेयर घटकों की अवधारणा को अपनाया: ऑब्जेक्ट आर्किटेक्चर: डीलिंग विथ द अननोन - या - टाइप सेफ्टी इन ए डायनेमिकली एक्सटेंसिबल क्लास लाइब्रेरी 1988 में और इनहेरिटेंस: व्हाट इट मीन्स एंड हाउ टू यूज़ इट इन 1990। इसने COM के पीछे कई विचारों की नींव प्रदान की। ऑब्जेक्ट लिंकिंग एंड एंबेडिंग (OLE), Microsoft का पहला ऑब्जेक्ट-आधारित फ्रेमवर्क, DDE के शीर्ष पर बनाया गया था और विशेष रूप से मिश्रित दस्तावेज़ों के लिए डिज़ाइन किया गया था। इसे 1991 में विंडोज और Microsoft Excel  के लिए वर्ड के साथ पेश किया गया था, और बाद में 1992 में वर्जन 3.1 के साथ शुरू करते हुए विंडोज के साथ शामिल किया गया था। कंपाउंड डॉक्यूमेंट का एक उदाहरण विंडोज डॉक्यूमेंट के लिए वर्ड में एम्बेडेड स्प्रेडशीट है: जैसा कि इसमें बदलाव किए जाते हैं। एक्सेल में स्प्रेडशीट, वे स्वचालित रूप से वर्ड डॉक्यूमेंट के अंदर दिखाई देते हैं।

1991 में, Microsoft ने Visual Basic एक्सटेंशन (VBX) को Visual Basic 1.0 के साथ पेश किया। एक VBX एक डायनेमिक-लिंक लाइब्रेरी (DLL) के रूप में एक पैकेज्ड एक्सटेंशन है जो वस्तुओं को ग्राफिक रूप से एक रूप में रखने और संपत्ति (प्रोग्रामिंग) और विधि (कंप्यूटर विज्ञान) द्वारा हेरफेर करने की अनुमति देता है। इन्हें बाद में अन्य भाषाओं जैसे विजुअल सी ++ ++ द्वारा उपयोग के लिए अनुकूलित किया गया था। 1992 में, जब Windows का Windows 3.1x|3.1 संस्करण जारी किया गया था, तो Microsoft ने इसके अंतर्निहित वस्तु मॉडल  के साथ OLE 2 जारी किया। COM एप्लिकेशन बाइनरी इंटरफ़ेस (ABI) MAPI ABI (1992 में जारी) के समान था, और जैसे यह MSRPC पर आधारित था और अंततः  खुला समूह  के DCE/RPC पर आधारित था। जबकि OLE 1 यौगिक दस्तावेज़ों पर केंद्रित था, COM और OLE 2 को सामान्य रूप से सॉफ़्टवेयर घटकों को संबोधित करने के लिए डिज़ाइन किया गया था। टेक्स्ट वार्तालाप और विंडोज संदेश एक मजबूत और एक्स्टेंसिबल तरीके से एप्लिकेशन सुविधाओं को साझा करने की अनुमति देने के लिए पर्याप्त लचीले साबित नहीं हुए थे, इसलिए COM को एक नई नींव के रूप में बनाया गया था, और OLE को OLE2 में बदल दिया गया था। 1994 में OLE कस्टम नियंत्रण (OCXs) को VBX नियंत्रणों के उत्तराधिकारी के रूप में पेश किया गया था। उसी समय, Microsoft ने कहा कि OLE 2 को केवल OLE के रूप में जाना जाएगा, और यह कि OLE अब एक संक्षिप्त नाम नहीं था, बल्कि कंपनी की सभी घटक तकनीकों के लिए एक नाम था। 1996 की शुरुआत में, Microsoft ने OLE कस्टम नियंत्रणों के लिए एक नया उपयोग पाया, सामग्री को प्रस्तुत करने के लिए अपने वेब ब्राउज़र की क्षमता का विस्तार करते हुए, इंटरनेट ActiveX से संबंधित OLE के कुछ हिस्सों का नाम बदल दिया, और धीरे-धीरे सभी OLE तकनीकों का नाम बदलकर ActiveX कर दिया, यौगिक दस्तावेज़ तकनीक को छोड़कर माइक्रोसॉफ्ट ऑफिस में उपयोग किया जाता है। उस वर्ष बाद में, Microsoft ने वितरित घटक ऑब्जेक्ट मॉडल के साथ पूरे नेटवर्क में काम करने के लिए COM का विस्तार किया।

संबंधित प्रौद्योगिकियां
COM विंडोज के लिए प्रमुख सॉफ्टवेयर डेवलपमेंट प्लेटफॉर्म था और इस तरह, कई सहायक तकनीकों के विकास को प्रभावित किया। यह वैसे ही पहले की तकनीकों से काफी प्रभावित था।

डीडीई
COM ने डायनेमिक डेटा एक्सचेंज को इंटरप्रोसेस संचार के पसंदीदा रूप के रूप में बदल दिया।

डीसीई/आरपीसी और एमएसआरपीसी
क्रॉस-भाषा घटक मॉडल के रूप में, COM वस्तुओं और संबंधित कार्यों का वर्णन करने के लिए इंटरफ़ेस परिभाषा भाषा या आईडीएल पर निर्भर करता है। COM IDL ऑब्जेक्ट-ओरिएंटेड एक्सटेंशन के साथ, सुविधा संपन्न DCE/RPC IDL पर बहुत अधिक आधारित है। Microsoft का खुद का DCE/RPC का कार्यान्वयन, जिसे MSRPC के रूप में जाना जाता है, का उपयोग Windows NT सेवाओं और आंतरिक घटकों के लिए प्राथमिक अंतर-प्रक्रिया संचार तंत्र के रूप में किया जाता है, जिससे यह नींव का एक स्पष्ट विकल्प बन जाता है।

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

कॉम+
माइक्रोसॉफ्ट के लिए डेवलपर्स को वितरित लेनदेन, संसाधन पूलिंग, डिस्कनेक्ट किए गए एप्लिकेशन, इवेंट प्रकाशन और सदस्यता, बेहतर मेमोरी और प्रोसेसर (थ्रेड) प्रबंधन के साथ-साथ विंडोज को अन्य एंटरप्राइज़-स्तरीय ऑपरेटिंग सिस्टम के विकल्प के रूप में स्थापित करने के लिए समर्थन प्रदान करने के लिए, Microsoft ने Windows NT 4 पर Microsoft Transaction Server (MTS) नामक एक तकनीक पेश की। Windows 2000 के साथ, COM के उस महत्वपूर्ण विस्तार को ऑपरेटिंग सिस्टम में शामिल किया गया (जैसा कि Microsoft Transaction Server द्वारा प्रदान किए गए बाहरी उपकरणों की श्रृंखला के विपरीत) और COM+ का नाम बदल दिया गया। उसी समय, Microsoft ने एक अलग इकाई के रूप में वितरित घटक ऑब्जेक्ट मॉडल पर जोर दिया। COM+ सेवाओं का उपयोग करने वाले घटकों को सीधे COM+ की अतिरिक्त परत द्वारा नियंत्रित किया जाता था, विशेष रूप से इंटरसेप्शन के लिए ऑपरेटिंग सिस्टम समर्थन द्वारा। एमटीएस की पहली रिलीज में, इंटरसेप्शन पर काम किया गया था - एमटीएस घटक स्थापित करने से एमटीएस सॉफ्टवेयर को कॉल करने के लिए विंडोज रजिस्ट्री को संशोधित किया जाएगा, न कि सीधे घटक को। Windows 2000 ने COM+ घटकों को कॉन्फ़िगर करने के लिए उपयोग किए जाने वाले घटक सेवा नियंत्रण कक्ष अनुप्रयोग को भी संशोधित किया।

COM+ का एक फायदा यह था कि इसे घटक फार्मों में चलाया जा सकता था। एक घटक के उदाहरणों को, यदि ठीक से कोडित किया गया है, तो पूल किया जा सकता है और नए कॉल द्वारा इसकी आरंभिक दिनचर्या में इसे मेमोरी से अनलोड किए बिना पुन: उपयोग किया जा सकता है। घटक भी वितरित किए जा सकते हैं (किसी अन्य मशीन से बुलाए गए)। COM+ और Microsoft Visual Studio ने क्लाइंट-साइड प्रॉक्सी उत्पन्न करना आसान बनाने के लिए उपकरण प्रदान किए, इसलिए यद्यपि DCOM का उपयोग दूरस्थ कॉल करने के लिए किया गया था, लेकिन डेवलपर्स के लिए ऐसा करना आसान था। COM+ ने COM+ ईवेंट्स नामक एक सब्सक्राइबर/प्रकाशक ईवेंट मैकेनिज़्म भी प्रस्तुत किया, और क्यूड कंपोनेंट्स नामक घटकों के साथ Microsoft संदेश क्यूइंग (एक तकनीक जो इंटर-एप्लिकेशन एसिंक्रोनस मैसेजिंग प्रदान करती है) का लाभ उठाने का एक नया तरीका प्रदान किया। COM+ इवेंट प्रकाशक या सब्सक्राइबर और इवेंट सिस्टम के बीच लेट-बाउंड (देर देर से बांधना देखें) इवेंट या मेथड कॉल को सपोर्ट करने के लिए COM+ प्रोग्रामिंग मॉडल का विस्तार करते हैं।

नेट
Microsoft .NET घटक प्रौद्योगिकी प्रदान करने और COM+ (COM-इंटरॉप-असेंबली के माध्यम से) के साथ इंटरैक्ट करने के लिए साधन प्रदान करता है; .NET आमतौर पर उपयोग किए जाने वाले अधिकांश COM नियंत्रणों को रैपर प्रदान करता है। Microsoft .NET घटक निर्माण से अधिकांश विवरण छुपाता है और इसलिए विकास को आसान बनाता है। .NET, System.EnterpriseServices नामस्थान के माध्यम से COM+ का लाभ उठा सकता है, और COM+ द्वारा प्रदान की जाने वाली कई सेवाओं को .NET की हाल की रिलीज़ में डुप्लिकेट किया गया है। उदाहरण के लिए, .NET में System.Transactions नेमस्पेस TransactionScope वर्ग प्रदान करता है, जो COM+ का सहारा लिए बिना लेनदेन प्रबंधन प्रदान करता है। इसी तरह, कतार (डेटा संरचना) को विंडोज कम्युनिकेशन फाउंडेशन द्वारा MSMQ ट्रांसपोर्ट के साथ बदला जा सकता है। (एमएसएमक्यू एक देशी COM घटक है, हालांकि।) पिछड़े संगतता के लिए सीमित समर्थन है। रनटाइम कॉल करने योग्य रैपर  (RCW) को लागू करके .NET में COM ऑब्जेक्ट का उपयोग किया जा सकता है। NET ऑब्जेक्ट्स जो कुछ इंटरफ़ेस प्रतिबंधों के अनुरूप होते हैं, COM ऑब्जेक्ट में COM कॉल करने योग्य रैपर (CCW) को कॉल करके उपयोग किए जा सकते हैं। COM और .NET दोनों पक्षों से, अन्य तकनीक का उपयोग करने वाली वस्तुएँ मूल वस्तुओं के रूप में दिखाई देती हैं। कॉम इंटरऑप देखें। विंडोज कम्युनिकेशन फाउंडेशन (विंडोज कम्युनिकेशन फाउंडेशन) COM की कई दूरस्थ निष्पादन चुनौतियों को आसान बनाता है। उदाहरण के लिए, यह वस्तुओं को पारदर्शी रूप से प्रक्रिया या मशीन की सीमाओं के मूल्य से अधिक आसानी से मार्शल करने की अनुमति देता है।

विंडोज रनटाइम
माइक्रोसॉफ्ट का विंडोज रनटाइम (या विनआरटी, विंडोज आरटी के साथ भ्रमित नहीं होना) प्रोग्रामिंग और एप्लिकेशन मॉडल अनिवार्य रूप से एक कॉम-आधारित एपीआई है, हालांकि यह एक उन्नत कॉम पर निर्भर करता है। इसके COM जैसे आधार के कारण, Windows रनटाइम कई भाषाओं से अपेक्षाकृत आसान इंटरफेसिंग की अनुमति देता है, जैसा कि COM करता है, लेकिन यह अनिवार्य रूप से एक अप्रबंधित, देशी API है। हालाँकि, एपीआई परिभाषाएँ .winmd फ़ाइलों में संग्रहीत हैं, जो ECMA 335 मेटाडेटा प्रारूप में एन्कोडेड हैं, वही मेटाडेटा (सीएलआई)CLI) प्रारूप जो .NET कुछ संशोधनों के साथ उपयोग करता है। जब WinRT को .NET अनुप्रयोगों से मंगाया जाता है, तो यह सामान्य मेटाडेटा प्रारूप P/Invoke की तुलना में काफी कम ओवरहेड की अनुमति देता है, और इसका सिंटैक्स बहुत सरल है।

नैनो-कॉम (उर्फ XPCOM)
नैनो-कॉम कंपोनेंट ऑब्जेक्ट मॉडल का एक बहुत छोटा उपसमुच्चय है जो विशेष रूप से कॉम के एप्लिकेशन बाइनरी इंटरफेस (एबीआई) पहलुओं पर केंद्रित है जो स्वतंत्र रूप से संकलित मॉड्यूल/घटकों में फ़ंक्शन और विधि कॉल को सक्षम करता है। नैनो-कॉम को एक सी++ हेडर फ़ाइल में आसानी से व्यक्त किया जा सकता है जो सभी सी++ कंपाइलरों के लिए पोर्टेबल है। नैनो-कॉम टाइप किए गए ऑब्जेक्ट संदर्भों के लिए समर्थन जोड़ने के लिए अंतर्निहित निर्देश आर्किटेक्चर और ओएस के मूल एबीआई को बढ़ाता है (सामान्य एबीआई केवल परमाणु प्रकार, संरचनाओं, सरणियों और फ़ंक्शन कॉलिंग सम्मेलनों पर ध्यान केंद्रित करता है)। नैनो-कॉम के आधार का उपयोग Mozilla द्वारा Firefox (XPCOM कहा जाता है) को बूटस्ट्रैप करने के लिए किया गया था, और वर्तमान में DirectX/Direct3D/DirectML के लिए आधार ABI तकनीक के रूप में उपयोग में है।

एक नैनो-कॉम हेडर फ़ाइल कम से कम तीन प्रकारों को परिभाषित या नाम देती है: नैनो-कॉम के कई उपयोग परिणाम के रूप में कैली-आवंटित मेमोरी बफ़र्स को संबोधित करने के लिए दो कार्यों को भी परिभाषित करते हैं
 * इंटरफ़ेस प्रकारों की पहचान करने के लिए GUID - यह प्रभावी रूप से 128 बिट संख्या है
 * विधि कॉल से त्रुटि कोड की पहचान करने के लिए HRESULT - यह प्रभावी रूप से 32-बिट ints के प्रसिद्ध मानों (S_OK, E_FAIL, E_OUTOFMEMORY, आदि) का मानकीकृत उपयोग है।
 * Iसभी टाइप किए गए ऑब्जेक्ट संदर्भों के लिए आधार प्रकार के रूप में अज्ञात - यह समर्थन करने के लिए प्रभावी रूप से सार वर्चुअल फ़ंक्शंस है नए इंटरफ़ेस प्रकारों का -स्टाइल अधिग्रहण और एक ला की गिनती करना
 * Alloc - कॉल करने वाले को लौटाए जाने वाले कच्चे बफर (ऑब्जेक्ट नहीं) आवंटित करने के लिए विधि कार्यान्वयन द्वारा बुलाया जाता है
 * निःशुल्क - विधि कॉल करने वालों द्वारा कैली-आवंटित बफ़र्स को एक बार उपयोग में नहीं होने पर मुक्त करने के लिए कॉल किया जाता है

नैनो-कॉम के कुछ कार्यान्वयन जैसे कि डायरेक्ट 3 डी एलोकेटर फ़ंक्शंस से बचते हैं और केवल कॉलर-आवंटित बफ़र्स का उपयोग करने के लिए खुद को प्रतिबंधित करते हैं।

नैनो-कॉम में कक्षाओं, अपार्टमेंट्स, मार्शलिंग, पंजीकरण आदि की कोई धारणा नहीं है। बल्कि, वस्तु संदर्भों को केवल कार्य सीमाओं के पार भेज दिया जाता है और मानक भाषा निर्माण (जैसे, C++ नया ऑपरेटर) के माध्यम से आवंटित किया जाता है।

सुरक्षा
COM और ActiveX घटकों को बिना किसी सैंडबॉक्सिंग के उपयोगकर्ता की मशीन पर देशी कोड के रूप में चलाया जाता है। इसलिए कोड क्या कर सकता है, इस पर कुछ प्रतिबंध हैं। इंटरनेट एक्सप्लोरर के साथ वेब पेजों पर ActiveX घटकों को एम्बेड करने के पूर्व अभ्यास ने मैलवेयर संक्रमणों के साथ समस्याओं को जन्म दिया। Microsoft ने ActiveX के साथ समस्या को 1996 में ही पहचान लिया था जब चार्ल्स फिट्जगेराल्ड ने कहा था, हमने कभी भी यह दावा नहीं किया कि ActiveX आंतरिक रूप से सुरक्षित है। हाल ही का Internet Explorer के संस्करण ActiveX नियंत्रणों को स्थापित करने से पहले उपयोगकर्ता को संकेत देते हैं, उपयोगकर्ता को उन साइटों से नियंत्रणों की स्थापना को अस्वीकार करने में सक्षम बनाता है जिन पर उपयोगकर्ता भरोसा नहीं करता है। ActiveX नियंत्रण उनकी प्रामाणिकता की गारंटी के लिए डिजिटल हस्ताक्षर के साथ कोड हस्ताक्षर कर रहे हैं। ActiveX नियंत्रणों को पूरी तरह से अक्षम करना या केवल कुछ चुनिंदा को अनुमति देना भी संभव है। आउट-ऑफ-प्रोसेस COM सर्वरों के लिए पारदर्शी समर्थन अभी भी प्रक्रिया अलगाव के संदर्भ में सॉफ़्टवेयर सुरक्षा को बढ़ावा देता है। यह बड़े अनुप्रयोग के सबसिस्टम को अलग-अलग प्रक्रियाओं में अलग करने के लिए उपयोगी हो सकता है। प्रक्रिया अलगाव एक प्रक्रिया में राज्य के भ्रष्टाचार को अन्य प्रक्रियाओं की अखंडता को नकारात्मक रूप से प्रभावित करने से रोकता है, क्योंकि वे केवल कड़ाई से परिभाषित इंटरफेस के माध्यम से संचार करते हैं। इस प्रकार, वैध स्थिति को पुनः प्राप्त करने के लिए केवल प्रभावित सबसिस्टम को पुनः आरंभ करने की आवश्यकता है। यह एक ही प्रक्रिया के भीतर सबसिस्टम के मामले में नहीं है, जहां एक सबसिस्टम में एक दुष्ट सूचक अन्य सबसिस्टम को बेतरतीब ढंग से दूषित कर सकता है।

तकनीकी विवरण
COM प्रोग्रामर COM-जागरूक सॉफ़्टवेयर घटकों का उपयोग करके अपने सॉफ़्टवेयर का निर्माण करते हैं। क्लास आईडी (CLSIDs) द्वारा विभिन्न घटक प्रकारों की पहचान की जाती है, जो वैश्विक रूप से विशिष्ट पहचानकर्ता (GUIDs) हैं। प्रत्येक COM घटक एक या अधिक इंटरफ़ेस (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) के माध्यम से अपनी कार्यक्षमता को उजागर करता है। एक घटक द्वारा समर्थित विभिन्न इंटरफेस इंटरफ़ेस आईडी (आईआईडी) का उपयोग करके एक दूसरे से अलग होते हैं, जो कि GUID भी हैं। COM इंटरफेस में कई भाषाओं में भाषा बंधन  होती है, जैसे C (प्रोग्रामिंग लैंग्वेज), C++, विजुअल बेसिक,  डेल्फी (प्रोग्रामिंग भाषा), पायथन (प्रोग्रामिंग लैंग्वेज)।  और कई स्क्रिप्टिंग भाषाओं को विंडोज प्लेटफॉर्म पर लागू किया गया। घटकों तक सभी पहुंच इंटरफेस की विधि (कंप्यूटर विज्ञान) के माध्यम से की जाती है। यह इंटर-प्रोसेस, या यहां तक ​​कि इंटर-कंप्यूटर प्रोग्रामिंग (DCOM के समर्थन का उपयोग करने वाला बाद वाला) जैसी तकनीकों की अनुमति देता है।

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

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

इंटरफ़ेस परिभाषा भाषा और प्रकार पुस्तकालय
प्रकार पुस्तकालयों में COM प्रकारों का प्रतिनिधित्व करने के लिए मेटाडेटा होता है। इन प्रकारों को Microsoft इंटरफ़ेस परिभाषा भाषा  (एमएसआईडीएल/आईडीएल) का उपयोग करके वर्णित किया गया है। IDL फाइलें ऑब्जेक्ट-ओरिएंटेड क्लासेस, इंटरफेस, स्ट्रक्चर्स, एन्यूमरेशन और अन्य यूजर-डिफाइन्ड टाइप्स को भाषा स्वतंत्र तरीके से परिभाषित करती हैं। IDL कुछ अतिरिक्त कीवर्ड जैसे इंटरफेस और कक्षाओं के संग्रह को परिभाषित करने के लिए इंटरफ़ेस और लाइब्रेरी के साथ C ++ घोषणाओं के समान है। IDL अतिरिक्त जानकारी प्रदान करने के लिए घोषणा से पहले ब्रैकेटेड विशेषताओं के उपयोग का भी समर्थन करता है, जैसे कि इंटरफ़ेस GUID और पॉइंटर पैरामीटर और लंबाई फ़ील्ड के बीच संबंध। आईडीएल फाइलें एमआईडीएल कंपाइलर द्वारा संकलित की जाती हैं। C/C++ के लिए, MIDL कंपाइलर एक कंपाइलर-स्वतंत्र हेडर फ़ाइल बनाता है जिसमें घोषित इंटरफेस की वर्चुअल मेथड टेबल से मिलान करने के लिए स्ट्रक्चर डेफिनिशन होता है और एक C फाइल जिसमें इंटरफ़ेस ग्लोबली यूनिक आइडेंटिफायर की घोषणा होती है। एक प्रॉक्सी मॉड्यूल के लिए C++ स्रोत कोड भी MIDL संकलक द्वारा उत्पन्न किया जा सकता है। इस प्रॉक्सी में प्रक्रिया से बाहर संचार के लिए DCOM को सक्षम करने के लिए COM कॉल को दूरस्थ प्रक्रिया कॉल में परिवर्तित करने के लिए विधि स्टब्स हैं। आईडीएल फाइलों को एमआईडीएल कंपाइलर द्वारा टाइप लाइब्रेरी (टीएलबी) में भी संकलित किया जा सकता है। TLB फ़ाइलों में बाइनरी मेटाडेटा होता है जिसे TLB में परिभाषित COM प्रकारों का प्रतिनिधित्व करने के लिए भाषा-विशिष्ट निर्माण उत्पन्न करने के लिए विभिन्न भाषा संकलक और रनटाइम वातावरण (जैसे VB, डेल्फी, .NET आदि) द्वारा संसाधित किया जा सकता है। सी ++ के लिए, यह टीएलबी को वापस अपने आईडीएल प्रतिनिधित्व में परिवर्तित कर देगा।

ऑब्जेक्ट फ्रेमवर्क
क्योंकि COM एक रनटाइम फ्रेमवर्क है, प्रकारों को व्यक्तिगत रूप से पहचाने जाने योग्य और रनटाइम पर निर्दिष्ट करने योग्य होना चाहिए। इसे प्राप्त करने के लिए, विश्व स्तर पर विशिष्ट पहचानकर्ता (GUIDs) का उपयोग किया जाता है। रनटाइम पर पहचान के लिए प्रत्येक COM प्रकार को अपना स्वयं का GUID नामित किया गया है। संकलन समय और रनटाइम दोनों पर COM प्रकारों की जानकारी तक पहुँचने के लिए, COM प्रकार पुस्तकालयों का उपयोग करता है। यह प्रकार पुस्तकालयों के प्रभावी उपयोग के माध्यम से है कि COM वस्तुओं की बातचीत के लिए गतिशील ढांचे के रूप में अपनी क्षमताओं को प्राप्त करता है।

IDL में निम्नलिखित उदाहरण कोक्लास परिभाषा पर विचार करें: उपरोक्त कोड खंड नामित एक COM वर्ग घोषित करता है  जो नाम के एक इंटरफ़ेस को लागू करता है.

यह वैचारिक रूप से निम्नलिखित C++ वर्ग को परिभाषित करने के बराबर है: जहाँ ISomeInterface एक C++ शुद्ध आभासी वर्ग है (जिसे कभी-कभी एब्स्ट्रैक्ट बेस क्लास भी कहा जाता है)।

COM इंटरफेस और कक्षाओं वाली IDL फाइलें टाइप लाइब्रेरी (TLB) फाइलों में संकलित की जाती हैं, जिन्हें बाद में रनटाइम पर क्लाइंट द्वारा पार्स किया जा सकता है, यह निर्धारित करने के लिए कि कौन सा इंटरफेस किसी ऑब्जेक्ट का समर्थन करता है, और किसी ऑब्जेक्ट के इंटरफ़ेस तरीकों को लागू करता है।

सी ++ में, COM ऑब्जेक्ट्स को तत्काल किया जाता है  फ़ंक्शन जो क्लास आईडी (CLSID) और इंटरफ़ेस आईडी (IID) को तर्क के रूप में लेता है। की तात्कालिकता   निम्नानुसार कार्यान्वित किया जा सकता है: इस उदाहरण में, COM सब-सिस्टम का उपयोग किसी ऑब्जेक्ट के लिए पॉइंटर प्राप्त करने के लिए किया जाता है जो लागू होता है  इंटरफ़ेस, और coclass CLSID_SomeClass के इस इंटरफ़ेस के विशेष कार्यान्वयन की आवश्यकता है।

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

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

तार पर दूरस्थ वस्तुओं को सभी संदर्भ गणना कॉल नहीं भेजी जाती हैं; एक प्रॉक्सी दूरस्थ वस्तु पर केवल एक संदर्भ रखता है और अपनी स्थानीय संदर्भ संख्या को बनाए रखता है। COM के विकास को सरल बनाने के लिए, Microsoft ने C++ डेवलपर्स के लिए सक्रिय टेम्पलेट लाइब्रेरी | ATL (एक्टिव टेम्प्लेट लाइब्रेरी) की शुरुआत की। ATL एक उच्च-स्तरीय COM विकास प्रतिमान प्रदान करता है। यह COM क्लाइंट एप्लिकेशन डेवलपर्स को स्मार्ट पॉइंटर ऑब्जेक्ट प्रदान करके सीधे संदर्भ गिनती बनाए रखने की आवश्यकता से भी बचाता है। अन्य पुस्तकालय और भाषाएँ जो COM-जागरूक हैं, उनमें Microsoft Foundation Classes, Visual C++ Compiler COM Support, शामिल हैं। वीबीस्क्रिप्ट, विजुअल बेसिक 2005 एक्सप्रेस संस्करण, ईसीएमएस्क्रिप्ट ([[एकमा स्क्रिप्ट]]) और बोरलैंड डेल्फी ।

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

रजिस्ट्री उपयोग
विंडोज में, COM क्लासेस, इंटरफेस और टाइप लाइब्रेरी को GUID द्वारा विंडोज रजिस्ट्री में सूचीबद्ध किया गया है, HKEY_CLASSES_ROOT\CLSID के तहत कक्षाओं के लिए और HKEY_CLASSES_ROOT\Interface इंटरफेस के लिए। COM लायब्रेरी प्रत्येक COM ऑब्जेक्ट या किसी दूरस्थ सेवा के लिए नेटवर्क स्थान के लिए या तो सही स्थानीय लायब्रेरी का पता लगाने के लिए रजिस्ट्री का उपयोग करें।

पंजीकरण मुक्त कॉम
पंजीकरण-मुक्त COM (RegFree COM) Windows XP के साथ शुरू की गई एक तकनीक है जो घटक ऑब्जेक्ट मॉडल (COM) सॉफ़्टवेयर घटक को सक्रियण मेटा डेटा  और CLSID को संग्रहीत करने की अनुमति देती है  Windows रजिस्ट्री का उपयोग किए बिना घटक के लिए। इसके बजाय, घटक में लागू वर्गों के मेटाडेटा और सीएलएसआईडी को एक मेनिफेस्ट (सीएलआई) (एक्सएमएल का उपयोग करके वर्णित) में घोषित किया जाता है, या तो निष्पादन योग्य संसाधन के रूप में या घटक के साथ स्थापित एक अलग फ़ाइल के रूप में संग्रहीत किया जाता है। यह एक ही घटक के कई संस्करणों को अलग-अलग निर्देशिकाओं में स्थापित करने की अनुमति देता है, जो उनके स्वयं के प्रकटीकरण के साथ-साथ XCOPY परिनियोजन द्वारा वर्णित है। इस तकनीक में EXE COM सर्वरों के लिए सीमित समर्थन है और सिस्टम-व्यापी घटकों जैसे Microsoft डेटा एक्सेस घटक, MSXML, DirectX या Internet Explorer के लिए उपयोग नहीं किया जा सकता है।

एप्लिकेशन लोड होने के दौरान, विंडोज लोडर मेनिफेस्ट की खोज करता है। यदि यह मौजूद है, तो लोडर इससे सक्रियण संदर्भ में जानकारी जोड़ता है। जब COM क्लास फ़ैक्टरी किसी क्लास को इंस्टेंट करने की कोशिश करती है, तो सक्रियण संदर्भ को पहले यह देखने के लिए चेक किया जाता है कि क्या CLSID के लिए कार्यान्वयन पाया जा सकता है। केवल अगर लुकअप विफल हो जाता है, तो Windows रजिस्ट्री स्कैन की जाती है।

मैन्युअल रूप से COM ऑब्जेक्ट्स को इंस्टेंट करना
डायनेमिक-लिंक लाइब्रेरी फ़ाइल और ऑब्जेक्ट के GUID के पथ को देखते हुए COM ऑब्जेक्ट मैन्युअल रूप से भी बनाए जा सकते हैं। इसके लिए DLL या GUID को सिस्टम रजिस्ट्री में पंजीकृत करने की आवश्यकता नहीं है, और मेनिफेस्ट फ़ाइलों का उपयोग नहीं करता है। एक COM DLL DllGetClassObject नामक फ़ंक्शन निर्यात करता है। वांछित GUID और IID_IClassFactory के साथ DllGetClassObject को कॉल करना फ़ैक्टरी (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) का एक उदाहरण प्रदान करता है। फ़ैक्टरी ऑब्जेक्ट में एक CreateInstance विधि है, जो एक इंटरफ़ेस GUID दिए गए ऑब्जेक्ट के उदाहरण बना सकती है। पंजीकृत COM घटकों के उदाहरण बनाते समय आंतरिक रूप से उपयोग की जाने वाली यह वही प्रक्रिया है। यदि बनाया गया COM ऑब्जेक्ट जेनेरिक CoCreateInstance API का उपयोग करके किसी अन्य COM ऑब्जेक्ट को तुरंत चालू करता है, तो यह रजिस्ट्री या मेनिफेस्ट फ़ाइलों का उपयोग करके सामान्य सामान्य तरीके से ऐसा करने का प्रयास करेगा। लेकिन यह आंतरिक वस्तुओं (जो बिल्कुल भी पंजीकृत नहीं हो सकता है) बना सकता है, और अपने स्वयं के निजी ज्ञान का उपयोग करते हुए, उन्हें इंटरफेस के संदर्भ सौंप सकता है।

प्रक्रिया और नेटवर्क पारदर्शिता
COM ऑब्जेक्ट्स को पारदर्शी रूप से तत्काल और एक ही प्रक्रिया (इन-प्रोसेस) के भीतर, प्रक्रिया सीमाओं (आउट-ऑफ-प्रोसेस), या दूरस्थ रूप से नेटवर्क (DCOM) पर संदर्भित किया जा सकता है। आउट-ऑफ-प्रोसेस और रिमोट ऑब्जेक्ट्स विधि कॉल को क्रमबद्ध करने और प्रक्रिया या नेटवर्क सीमाओं पर मान वापस करने के लिए क्रमबद्धता का उपयोग करते हैं। यह मार्शलिंग क्लाइंट के लिए अदृश्य है, जो ऑब्जेक्ट को एक्सेस करता है जैसे कि यह एक स्थानीय इन-प्रोसेस ऑब्जेक्ट था।

थ्रेडिंग
COM में, थ्रेडिंग को एक अवधारणा के माध्यम से संबोधित किया जाता है जिसे अपार्टमेंट कहा जाता है। एक व्यक्तिगत COM ऑब्जेक्ट बिल्कुल एक अपार्टमेंट में रहता है, जो सिंगल-थ्रेडेड या मल्टी-थ्रेडेड हो सकता है। COM में तीन प्रकार के अपार्टमेंट हैं: सिंगल थ्रेडिंग | सिंगल-थ्रेडेड अपार्टमेंट (STA), मल्टी-थ्रेडेड अपार्टमेंट (MTA) और थ्रेड न्यूट्रल अपार्टमेंट (NA)। प्रत्येक अपार्टमेंट एक तंत्र का प्रतिनिधित्व करता है जिससे किसी वस्तु की आंतरिक स्थिति को कई धागों में सिंक्रनाइज़ किया जा सकता है। एक प्रक्रिया में कई COM ऑब्जेक्ट शामिल हो सकते हैं, जिनमें से कुछ STA का उपयोग कर सकते हैं और अन्य MTA का उपयोग कर सकते हैं। COM ऑब्जेक्ट तक पहुँचने वाले सभी थ्रेड समान रूप से एक अपार्टमेंट में रहते हैं। COM ऑब्जेक्ट्स और थ्रेड्स के लिए अपार्टमेंट का चुनाव रन-टाइम पर निर्धारित होता है, और इसे बदला नहीं जा सकता।

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

आलोचना
चूंकि COM का कार्यान्वयन काफी जटिल है, प्रोग्रामर कुछ प्लंबिंग मुद्दों से विचलित हो सकते हैं।

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

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

डीएलएल नरक
क्योंकि इन-प्रोसेस COM घटक DLL फ़ाइलों में कार्यान्वित किए जाते हैं और पंजीकरण केवल CLSID प्रति एक संस्करण के लिए अनुमति देता है, वे कुछ स्थितियों में DLL नरक प्रभाव के अधीन हो सकते हैं। पंजीकरण-मुक्त COM क्षमता इन-प्रोसेस घटकों के लिए इस समस्या को समाप्त करती है; आउट-ऑफ़-प्रोसेस सर्वर के लिए पंजीकरण-मुक्त COM उपलब्ध नहीं है।

यह भी देखें

 * पोर्टेबल वस्तु (कंप्यूटिंग) क्रॉस लैंग्वेज क्रॉस प्लेटफॉर्म ऑब्जेक्ट मॉडल परिभाषा
 * वितरित घटक ऑब्जेक्ट मॉडल (DCOM), एक्सटेंशन COM को नेटवर्क में काम करने में सक्षम बनाता है
 * सामान्य भाषा अवसंरचना करंट .NET क्रॉस लैंग्वेज क्रॉस प्लेटफॉर्म ऑब्जेक्ट मॉडल
 * विंडोज रनटाइम, एक एप्लिकेशन मॉडल, विंडोज 8 को लक्षित करने वाले COM का विकसित संस्करण
 * कॉर्बा कॉमन ऑब्जेक्ट रिक्वेस्ट ब्रोकर आर्किटेक्चर, ओपन क्रॉस लैंग्वेज क्रॉस प्लेटफॉर्म ऑब्जेक्ट मॉडल
 * डी-बस ओपन क्रॉस लैंग्वेज क्रॉस प्लेटफॉर्म ऑब्जेक्ट मॉडल
 * केपार्ट्स कहाँ  घटक ढांचा
 * आईबीएम सिस्टम ऑब्जेक्ट मॉडल IBM सिस्टम ऑब्जेक्ट मॉडल, COM का सुविधा संपन्न विकल्प
 * XPCOM मोज़िला एप्लिकेशन प्लेटफ़ॉर्म कंपोनेंट ऑब्जेक्ट मॉडल को पार करते हैं
 * उद्यम जावाबीन
 * जावा रिमोट मेथड इनवोकेशन
 * इंटरनेट संचार इंजन
 * भाषा बंधन
 * विदेशी फ़ंक्शन इंटरफ़ेस
 * कॉलिंग कन्वेंशन
 * नाम मंगलिंग
 * एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस - एपीआई
 * एप्लिकेशन बाइनरी इंटरफ़ेस - एबीआई
 * SWIG ओपनसोर्स स्वचालित इंटरफेस बाइंडिंग जनरेटर कई भाषाओं से अन्य भाषाओं में

बाहरी संबंध

 * Component Object Model on MSDN
 * Interview with Tony Williams, Co-Inventor of COM (Video Webcast, August 2006)
 * Info: Difference Between OLE Controls and ActiveX Controls from Microsoft
 * TypeLib Data Format Specification (unofficial) with open source dumper utility.
 * The COM / DCOM Glossary