مدل شیء مؤلفه

COM

Component Object Model
کوته‌نوشت	COM
وضعیت	در حال استفاده
انتشار اولیه	۱۹۹۳؛ ۳۲ سال پیش (۱۹۹۳-خطا: زمان نامعتبر}})
آخرین ویرایش	استاندارد زنده ۲۰۲۱
سازمان	مایکروسافت
سری‌ها	System Services
استانداردهای پایه	MIDL, UUID
استانداردهای مرتبط	جایگزین: DDE ساخته‌شده براساس سی‌اوام: OLE, OLE Automation, Browser Helper Object, ActiveX, COM+, DCOM, Windows shell, DirectX, UMDF , Windows Runtime
دامنه	واسط‌دهی به مولفه
وبگاه	docs.microsoft.com/en-us/windows/win32/com/the-component-object-model

مدل شیء مؤلفه (به انگلیسی: Component Object Model) با کوته‌نوشت COM یک استاندارد واسط دودویی برای مولفه‌های نرم‌افزاری است که توسط شرکت مایکروسافت در سال ۱۹۹۳ (سال ۱۳۷۲ شمسی) معرفی شد. از این فناوری برای ایجاد توانمندی «ارتباط بین‌پردازه‌ای» در ایجاد شیء در بسیاری از زبان‌های برنامه‌نویسی استفاده می‌شود. COM مبنای چندین فناوری و چارچوب دیگر مایکروسافت است، مثلاً OLE, OLE Automation, Browser Helper Object, ActiveX, COM+, DCOM, Windows shell, DirectX, UMDF، و Windows Runtime براساس COM هستند. ماهیت COM ایجاد یک روش «خنثی از نظر زبان» برای پیاده‌سازی اشیایی است که قابلیت استفاده در محیطی را دارند که با محیطی که در آن ایجاد شده‌اند متفاوت است، یعنی حتی می‌توان در محدودهٔ بین ماشینی از آن استفاده کرد. برای مولفه‌هایی که به‌خوبی نوشته شده باشند، COM امکان استفاده مجدد از اشیا را بدون هیچ دانشی از پیاده‌سازی درونی آن‌ها می‌دهد، زیرا این فناوری پیاده‌سازهای مولفه را مجبور می‌کند تا «واسطهای خوش‌تعریف» تهیه کنند، که این واسط‌ها از پیاده‌سازی جدا هستند. معانی تخصیص در زبان‌های مختلف متفاوت است، اما این موضوع به این صورت سازگارسازی می‌شوند که اشیا «خودشان» مسئول ساخت خودشان باشند و از بین بردن آن‌ها از طریق شمارش ارجاع انجام می‌شود. ریختگری تبدیل نوع بین واسط‌های متفاوت یک شیء از طریق شگرد QueryInterface به دست می‌آید. شگرد ارجح «ارث‌بری» در COM، ساخت زیرشیءهایی است که به آن‌ها «تماس» شگردی واگذار می‌شوند.

COM یک فناوری واسط است که به عنوان یک «فقط استاندارد» در مایکروسافت ویندوز و بنیاد هسته اپل ۱٫۳ و سپس در افزونه‌های واسط برنامه‌نویسی کاربردی (API) تعریف و پیاده‌سازی شده‌است.^[۱] در API فقط بخشی از کل واسط COM پیاده‌سازی می‌شود.^[۲] در بعضی از کاربردها، COM تاحدی به‌وسیله چارچوب دات‌نت مایکروسافت جایگزین شده‌است، و در پشتیبانی از خدمات وب توسط بنیاد ارتباطات ویندوز (WCF) جایگزین شده‌است. با این حال، اشیای COM را می‌توان با همه زبان‌های دات‌نت، از طریق COM Interop در دات‌نت استفاده کرد. DCOMهای شبکه‌ای از قالب‌های اختصاصی دودویی استفاده می‌کنند، درحالی‌که WCF (بنیاد ارتباط ویندوز) استفاده از پیام‌های SOAP که مبتنی بر XML اند را تشویق کرده‌است. COM به دیگر فن‌آوری‌های واسط نرم‌افزار مولفه، مثل CORBA، و جاوابینز سازمانی بسیار شبیه است، اگرچه هرکدام از آن‌ها نقاط قوت و ضعف خودشان را دارند. برخلاف C++، در COM یک واسط دودویی کاربردی پایدار (ABI) فراهم شده‌است، و این واسط بین انتشارهای مختلف کامپایلر، تغییر نمی‌کند.^[۳] این موضوع واسط‌های COM را برای کتابخانه‌های شیءگرای C++ جذاب ساخته‌است؛ زیرا این واسط‌ها باید توسط کارخواه‌های کامپایل شده توسط نسخه‌های کامپایلر مختلف استفاده شوند.

الگوی COM به منظور توانمندسازی ارتباطات بین پردازشی و ساختن اشیاء به صورت پویا، برای تعداد زیادی از زبان‌های برنامه‌نویسی مورد استفاده قرار گرفته‌است. اصطلاح COM در صنعت توسعه نرم‌افزاری مایکروسافت، به عنوان چتری که دربرگیرنده فناوریهای زیرمی‌باشد مورد استفاده قرار می‌گیرد.^[۴]

• +COM
• DCOM
• OLE
• OLE Automation
• ActiveX اکتیوایکس

نکته: هرگز نباید با قالب پروندهای COM، که پسوندی برای یک نوع از پرونده‌های اجرایی می‌باشد، اشتباه گرفته شود.

امنیت

مولفه‌های COM و ActiveX به صورت کد محلی در ماشین کاربر اجرا می‌شوند، و هیچ جعبه شنی در اینجا وجود ندارد. درنتیجه محدودیت‌های کمی روی این موضوع که کد چه می‌تواند انجام دهد وجود دارد. تلاش‌های قبلی برای توکارسازی مولفه‌های ActiveX در صفحات وب با اینترنت اکسپلورر منجر به مسائلی در زمینه سرایت بدافزار شده‌اند. مایکروسافت مشکل با ActiveX را در سال ۱۹۹۶ تشخیص داد، موقعی چارلز فیتزجرالد گفته بود «ما هیچ وقت ادعا نکرده‌ایم که ActiveX به صورت ذاتی امن است».^[۵] ورژن‌های جدید اینترنت اکسپلورر قبل از نصب کنترل‌های ActiveX از کاربر اجازه می‌گیرند، و این موضوع به کاربر امکان آن را می‌دهد تا اجازه نصب کنترل‌ها از سایت‌هایی که کاربر به آن‌ها اعتماد ندارد، را ندهد. کنترل‌های ActiceX توسط «امضای دیجیتال» امضا شده‌اند، تا درستی و صحت آنها تضمین گردد. این موضوع مقدور هست که همه کنترل‌های ActiveX را غیرفعال کنیم، یا فقط تعدادی اندکی که انتخاب شده‌اند را مجاز بدانیم. «پشتیبانی شفاف برای سرورهای خارج‌ از فرآیند COM» هم امنیت نرم‌افزار را، در قالب جداسازی فرایندها، افزایش می‌دهد. این موضوع برای جداسازی زیرسامانه‌های برنامه‌کاربردی بزرگ به فرایندهای مجزا می‌تواند مفید باشد. انزوای فرایند، خرابی حالت در یک فرایند را، از تأثیر مخرب در درستی دیگر فرایندها، محدود می‌کند، زیرا آنها فقط از طریق واسط‌های موکداً تعریف شده ارتباط برقرار می‌کنند؛ بنابراین، فقط زیرسامانه تأثیر پذیرفته، برای بازیابی حالت مجاز، باید راه‌اندازی مجدد گردد. این موضوع برای زیر سامانه‌های موجود در فرایند مشابه درست نیست، چراکه در آن یک اشاره‌گر سرکش در یک زیرسیستم به صورت تصادفی، می‌تواند دیگر زیرسامانه‌ها را خراب کند.

جزئیات فنی

برنامه‌نویسان COM نرم‌افزارشان را به کمک مولفه‌های مطلع از COM می‌سازند. انواع مختلف مولفه توسط ID کلاس شناسایی می‌شوند (CLSIDs) که شناسانه‌های یکتای جهانی هستند (GUIDs). هر مولفه COM، کارایی اش را از طریق یک یا بیشتر واسط در معرض دید قرار می‌دهد. واسط‌های مختلفی که توسط یک مولفه پشتیبانی می‌شوند، توسط ID واسط شان (IID) از یکدیگر مجزا می‌گردند، که این IIDها GUID هم هستند. واسط‌های COM بستگی‌هایی در زبان‌های مختلف مثل C, C++، ویژوال بیسیک، دلفی، پایتون،^[۶][۷] و دیگر زبان‌های اجرانامه‌نویسی که در بن‌سازه ویندوز پیاده‌سازی شده‌اند دارند. تمام دسترسی‌ها به مولفه‌ها از طریق شگردهای واسط‌ها انجام می‌شود. این موضوع امکان فن‌آوری‌هایی مثل برنامه‌نویسی بین‌پردازه‌ای یا حتی برنامه‌نویسی بین‌رایانه‌ای را فراهم می‌کند (که دومی از طریق پشتیبانی از DCOM انجام می‌شود).

واسط‌ها

همه مولفه‌های COM واسط (سفارشی) IUnknown را پیاده‌سازی می‌کنند، که شگردهایی برای شمارش ارجاع و تبدیل نوع (ریخته‌گری نوع) نمایان می‌سازند. یک واسط سفارشی IUnknown شامل یک اشاره‌گر به جدول شگرد مجازی است، که شامل یک لیست از اشاره‌گرها به توابعی است که توابع اعلان شده در واسط را پیاده‌سازی می‌کنند، و این موضوع به همان ترتیبی انجام می‌شود که در واسط اعلان شده‌اند. از این رو سربار فراخوانی بین‌پردازشی قابل مقایسه با تماس‌های شگرد مجازی در C++ است. علاوه بر واسط‌های سفارشی، COM از واسط‌های اعزامی نیز پشتیبانی می‌کند، که از IDispatch ارث‌بری می‌کنند. واسط‌های اعزامی از «بستگی دیرموقع» برای خودکارسازی OLE پشتیبانی می‌کنند. این موضوع به واسط‌های اعزامی امکان می‌دهد تا به صورت محلی توسط محدوده گسترده‌تری از زبان‌های برنامه‌نویسی نسبت به واسط‌های سفارشی دسترسی بیابند.

کلاس‌ها

یک کلاس COM یا «coclass» یک پیاده‌سازی عینی از یک یا بیشتر واسط است، و خیلی به کلاس‌های موجود در زبان‌های برنامه‌نویسی شیءگرا شبیه است. این کلاس‌ها بر اساس ID کلاس‌شان (CLSID)، یا براساس رشته شناسه برنامه‌نویسی‌شان (ProgID) ساخته می‌شوند. مثل خیلی از زبان‌های شیءگرا، COM قابلیت جداسازی واسط از پیاده‌سازی را فراهم می‌بیند. این تفکیک مخصوصاً در COM زیاد است، زیرا در آن اشیا را نمی‌توان به صورت مستقیم به اشیا دسترسی یافت، بلکه فقط از طریق واسط شان قابل دسترسی هستند. COM از موضوع چندین پیاده‌سازی برای یک واسط پشتیبانی می‌کند، که در نتیجه آن کارخواه‌ها در زمان اجرا می‌توانند انتخاب کنند که کدام پیاده‌سازی از یک واسط را نمونه برداری کنند.

زبان تعریف واسط و کتابخانه‌های نوع

کتابخانه‌های نوع شامل فراداده‌هایی هستند که می‌توانند انواع COM را نمایش دهند. این نوع‌ها توسط زبان تعریف واسط مایکروسافت (MSIDL/IDL) توصیف شده‌اند. فایل‌های IDL تعریف کننده کلاس‌ها، واسط‌ها، ساختارها، فهرست‌شمارای شیءگرا، و دیگر انواع تعریف شده توسط کاربر هستند و این تعریف‌ها به حالت مستقل از زبان هستند. IDL از نظر ظاهری مشابه اعلان‌های C++ است، اما در آن کلیدواژه‌های اضافی مثل «interface", "library»، برای تعریف واسط‌ها و گردآوردهای کلاس‌ها وجود دارد. IDL از ویژگی‌های قلابی، قبل از اعلان‌ها پشتیبانی می‌کند، تا اطلاعات اضافی را تهیه ببیند مثلاً GUIDهای واسط، و رابطه بین پارامترهای اشاره‌گر و فیلدهای طول. فایل‌های IDL توسط کامپایلر MIDL کامپایل می‌شوند. برای C/C++، کامپایلر MIDL بک فایل سرایند مستقل از کامپایلر تولید می‌کند، که شامل تعاریف سختارها است تا vtblهای واسط‌های اعلان‌شده و یک فایل C شامل اعلان‌های GUIDهای واسط را منطبق کند. کد منبع C++ برای یک پودمان پراکسی را نیز می‌توان توسط کامپایلر MIDL تولید کرد. این پراکسی شامل سه‌رسید شگرد برای تبدیل تماس COM به تماس‌های رویه دوردست است تا به DCOM امکان ارتباطات بیرون از فرایند را بدهد. فایل‌های IDL را توسط کامپایلر MIDL می‌توان به یک کتابخانه نوع (TLB) کامپایل کرد. فایل‌های TLB شامل فراداده‌های دودویی است که قابلیت پردازش توسط کامپایلرهای زبانی مختلف و محیط‌های زمان‌اجرای مختلف (مثل VB، دلفی، دات‌نت، و غیره) را دارد، و در نتیجه ساختارهای خاص‌زبانه‌ای تولید می‌شود که نمایش‌دهنده انواع COM تعریف شده در TLB هستند. برای C++، این موضوع TLB را به نمایش IDL آن برمی‌گرداند.

COM به عنوان یک چارچوب شیء

به دلیل آنکه COM یک چارچوب زمان‌اجرا است، انواع را باید به صورت منفرد در زمان‌اجرا تشخیص داد و تعیین کرد. برای این موضوع از شناسه‌های یکتای جهانی (GUIDها) استفاده می‌شود. هر نوع COM یک GUID طراحی شده خاص خودش برای شناسایی در زمان اجرا دارد. برای آنکه اطلاعات انواع COM هم در زمان‌اجرا و هم‌زمان کامپایل دردسترس باشند، COM از کتابخانه‌های نوع استفاده می‌کند. این موضوع از طریق استفاده مؤثر از «کتابخانه‌های نوع» به دست می‌آید، که COM از طریق یک چارچوب پویا برای تعامل با اشیا به توانمندی‌اش می‌رسد.

این مثال تعریف coclass در یک IDL را درنظر بگیرید:

coclass SomeClass {
  [default] interface ISomeInterface;
};

در قطعه کد بالا یک کلاس COM اعلان شده‌است، که SomeClass نام‌دارد، که یک واسط با نام ISomeInterface را پیاده‌سازی می‌کند. این از نظر معنایی معادل تعریف کلاس C++ زیر است:

class SomeClass : public ISomeInterface {
  ...
  ...
};

در اینجا ISomeInterface یک کلاس کاملاً مجازی C++ است (که گاهی به آن کلاس مبنای انتزاعی گفته می‌شود).

فایل‌های IDL شامل واسط‌ها و کلاس‌های COM به فایل‌های کتابخانه نوع (TLB) کامپایل می‌شوند، که بعداً در زمان‌اجرا توسط کارخواه‌ها قابل تجزیه اند، تا تعیین کنند که کدام یک پشتیبانی شیء را واسط سازی می‌کنند، و شگردهای واسط شیء را فراخوانی می‌کنند.

در C++، اشیای COM توسط تابع CoCreateInstance نمونه‌برداری می‌شوند، که ID کلاس (CLSID) و ID واسط (IID) را به عنوان آرگومان می‌گیرد. نمونه‌برداری از SomeClass را به اینگونه می‌توان پیاده‌سازی کرد:

ISomeInterface* interface_ptr = NULL;
HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL,
                              IID_ISomeInterface, (void**)&interface_ptr);

در این مثال، زیرسامانه COM برای به دست آوردن یک اشاره‌گر به شیء ای که واسط ISomeInterface را پیاده‌سازی می‌کند، استفاده می‌شود، و پیاده‌سازی خاص coclass با نام CLSID_SomeClass از این واسط مورد نیاز است.

شمارش ارجاع

همه اشیای COM از شمارش ارجاع برای مدیریت زمان‌زندگی اشیاء استفاده می‌کنند. تعداد ارجاع‌ها توسط کارخواه‌ها از طریق شگردهای AddRef و Release در واسط اجباری IUnknown کنترل می‌شوند، که این واسط را همه اشیای COM پیاده‌سازی کرده‌اند. اشیای COM آنوقت مسئول خالی‌سازی حافظه خودشان اند و این موضوع وقتی رخ می‌دهد که تعداد ارجاع‌ها به صفر کاهش می‌یابد. زبان‌های خاص (مثل ویژوال بیسیک) امکان شمارش خودکار ارجاع را فراهم می‌کنند، که در نتیجه آن توسعه‌دهندگان اشیای COM نیازی به نگهداری صریح هیچ شمارشگر ارجاع درونی در کد منبع‌شان را ندارند. در C++، یک کدنویس برای مدیریت تعداد ارجاع‌ها، یا از انجام شمارش صریح ارجاع استفاده می‌کند، یا از اشاره‌گرهای هوشمند استفاده می‌کند، تا به صورت خودکار مدیریت تعداد ارجاع انجام شود.

در زیر راهبردهایی برای زمان استفاده فراخوانی AddRef و Release روی اشیای COM آمده‌است:

• توابع و شگردهایی که ارجاع‌های واسط را برمی‌گردانند (از طریق مقدار بازگشتی یا از طریق پارامتر "out") باید تعداد ارجاع شیء بازگشتی را قبل از بازگردانی افزایش دهند.
• Release باید قبل از آنکه اشاره‌گر رونویسی شود یا از دسترس خارج شود، روی یک اشاره‌گر واسط، صدا زده شود.
• اگر یک کپی روی اشاره‌گر ارجاع واسط انجام شود، AddRef باید روی آن اشاره‌گر صدازده شود.
• AddRef و Release باید روی واسط خاصی که ارجاع داده می‌شود صدازده شود زیرا ممکن است یک شیء تعداد ارجاع برای هر واسط را پیاده‌سازی کند تا منابع درونی را تنها برای واسط‌هایی که ارجاع داده شده‌اند، تخصیص دهد.

همه تعداد ارجاع‌ها به اشیای دوردست روی یک خط ارسال نمی‌شوند؛ بلکه یک پراکسی فقط یک ارجاع را روی شیء دوردست نگه‌می‌دارد و تعداد ارجاع محلی خودش را نگهداری می‌کند. برای ساده‌سازی توسعه COM، مایکروسافت ATL را برای توسعه‌دهندگان C++ معرفی کرده‌است که کوته‌نوشت «کتابخانه الگوی فعال Active Template Library» است. ATL یک فراالگوی توسعه COM سطح بالاتر را فراهم می‌بیند. این موضوع توسعه‌دهندگان کاربردی کارخواه COM را از نیاز برای نگهداری مستقیم تعداد ارجاع محافظت می‌کند، این کار از طریق تهیه اشیای اشاره‌گر هوشمند انجام می‌شود. دیگر کتابخانه‌ها و زبان‌های مطلع از COM شامل کتابخانه کلاس‌های بنیاد مایکروسافت، پشتیبانی COM در کامپایلر VC,^[۸] و VBScript، و ویژوال بیسیک؛ و اکمااسکریپت (جاوااسکریپت) و برلند دلفی می‌شوند.

برنامه‌نویسی

COM یک استاندارد دودویی منکر زبان است، که می‌توان آن را در هر زبان برنامه‌نویسی که قادر به فهم و پیاده‌سازی انواع داده و واسط‌های دودویی تعریف شده اش هستند، توسعه داد. پیاده‌سازی‌های COM مسئول ورود و خروج از محیط COM، نمونه‌برداری و شمارش-ارجاع اشیای COM، پزسمان از اشیا برای واسط‌های پشتیبانی شده، و نیز رسیدگی به حالت استثنا هستند. کامپایلر C++ دیداری مایکروسافت، از افزونه‌های زبان C++ که به آن C++ Attributes گفته می‌شود، پشتیبانی می‌کنند.^[۹] این افزونه‌ها برای ساده‌سازی توسعه COM و حذف بسیاری از کدهای لوله‌کشی مورد نیاز برای پیاده‌سازی سرور COM در C++ طراحی شده‌اند.^[۱۰]

استفاده از رجیستری

در ویندوز، کلاس‌های COM، واسط‌ها، و کتابخانه‌های نوع، توسط GUIDها در رجیستری فهرست شده‌اند، و برای کلاس‌ها تحت HKEY_CLASSES_ROOT\CLSID و برای واسط‌ها تحت HKEY_CLASSES_ROOT\Interface قرار دارند. کتابخانه‌های COM از رجیستری برای تعیین محل یا کتابخانه‌های محلی صحیح برای هر شیء COM یا محل شبکه‌ای برای یک خدمت دوردست استفاده می‌کنند.

COMهای بدون رجیستری

COMهای بدون رجیستری (RegFree COM) یک فناوری معرفی شده توسط ویندوز اکس‌پی است که به مولفه‌های مدل شیء مولفه (COM) امکان ذخیره فراداده فعال‌سازی و CLSID (یا Class ID) را برای مولفه‌ها بدون استفاده از رجیستری می‌دهد. در عوض، فراداده و CLSIDهای کلاس‌های پیاده‌سازی شده در مولفه در صورت‌کد اسمبلی اعلان می‌شوند (به کمک XML توصیف می‌شوند) یا به صورت یک منبع در اجراپذیر ذخیره می‌شوند، یا به صورت یک فایل مجزا همراه مولفه نصب می‌گردند.^[۱۱] این موضوع امکان آن را فراهم می‌کند تا نسخه‌های مختلفی از یک مولفه مشابه در دایرکتوری‌های مختلف نصب گردند، و توسط صورت‌کدهای خاص خودشان توصیف شوند، مثلاً در استقرار XCOPY این موضوع وجود دارد.^[۱۲] این فناوری پشتیبانی کمی در سرورهای EXE COM دارد^[۱۳] و در مولفه‌های سطح سیستم، مثل MDAC, MSXML, DirctX یا اینترنت اکسپلورر قابل استفاده نیستند.

در مدت بارگذاری برنامه‌کاربردی، بارگذار ویندوز دنبال صورت‌کد می‌گردد.^[۱۴] اگر موجود باشد، بارگذار، اطلاعات آن را به بافت فعال‌سازی اضافه می‌کند. موقعی که کارخانه کلاس COM بخواهد یک کلاس را نمونه‌برداری کند، بافت فعال‌سازی اول بررسی می‌شود تا ببیند آیا یک پیاده‌سازی از CLSID را می‌توان یافت یا نه. فقط موقعی که نتیجه جستجو منفی باشد، رجیستری بررسی می‌شود.^[۱۲]

نمونه‌برداری دستی از اشیای COM

اشیای COM را به صورت دستی هم می‌توان ساخت. در این موقع باید مسیر فایل DLL، و GUID شیء را داشته باشیم. این موضوع نیازی به بایگانی DLL یا GUID در رجیستری سامانه ندارد، و از فایل‌های صورت‌کد هم استفاده نمی‌کند. یک DLL یک تابع به نام DllGetClassObject را صادر می‌کند. صدازدن DllGetClassObject با GUIDها و IID_IClassFactory مورد نیاز، یک نمونه از یک شیء کارخانه را تهیه می‌بیند. شیء کتابخانه یک شگرد CreateInstance دارد، که می‌تواند نمونه‌های یک شیء را اگر یک GUID واسط به آن بدهیم، بسازد.^[۱۵] این فرایند مشابهی است که موقعی که به صورت درونی نمونه‌های مولفه‌های COM رجیستر شده را می‌سازیم، استفاده می‌شود.^[۱۶]

اگر شیء COM ساخته شده، از شیء COM دیگری به کمک CoCreateInstance API همگانی نمونه‌برداری کند، این کار را از طریق روش عمومی معمول انجام می‌دهد، یعنی از رجیستری یا فایل‌های صورت‌کد استفاده می‌کند. اما می‌تواند اشیای درونی را بسازد (که ممکن است اصلاً رجیستر نشود)، و ارجاع‌ها به واسط‌های آن را به دست چیز بیرونی بدهد، و این کار را به کمک دانش خصوصی خودش انجام دهد.

شفافیت فرایندی یا شبکه‌ای

اشیای COM را می‌توان در داخل پردازه مشابه (in-process) یا در مرزهای بین پردازه‌ای (out-of-process)، یا از راه‌دور روی شبکه (DCOM) به صورت شفاف نمونه‌برداری کرد و ارجاع داد. اشیای برون‌پردازه‌ای یا راه‌دور از صف‌آرایی برای پیاپی‌سازی تماس‌های شگردی، و مقادیر بازگشتی روی مرزهای پردازه، یا شبکه استفاده می‌کنند. این صف‌آرایی برای کارخواه قابل دیدن نیست، زیرا او به شیء به این صورت دسترسی دارد که مثل آن است که این یک شیء محلی درون پردازه‌ای است.

ریسه‌دهی

در COM، ریسه‌دهی توسط مفهومی به نام آپارتمان (apartments) تعیین می‌شود.^[۱۷] یک شیء COM منفرد دقیقاً در یک آپارتمان زندگی می‌کند، که این آپارتمان می‌تواند یا یک-ریسه‌ای یا چند-ریسه‌ای باشد. سه نوع آپارتمان در COM وجود دارد: آپارتمان تک-ریسه‌ای (STA)، آپارتمان چند-ریسه‌ای (MTA) و آپارتمان خنثی از نظر ریسه. هر آپارتمان نمایش‌دهنده یک سازکار است که به کمک آن حالت درونی شیء را می‌توان بین چندین ریسه همزمان‌سازی کرد. یک پردازه می‌تواند شامل چندین شیء COM باشد، که بعضی از آن‌ها از STA استفاده می‌کنند، بقیه می‌توانند از MTA استفاده کنند. همهٔ ریسه‌هایی که به اشیای COM دسترسی می‌یابند، به صورت مشابه در یک آپارتمان زندگی می‌کنند. انتخاب نوع آپارتمان برای اشیای COM و ریسه‌ها در زمان‌اجرا تعیین می‌شود، و این موضوع قابل تغییر نیست.

نوع آپارتمان	توضیحات
Single-Threaded Apartment[۱۸] (STA), (ThreadingModel=Apartment)	یک ریسه منفرد برای اجرای شگردهای شیء تخصیص داده شده‌است. در این ترتیب، تماس‌های شگردی از ریسه‌های بیرون از آپارتمان صف‌آرایی می‌شوند، و به صورت خودکار توسط سامانه صف‌دهی می‌شوند (یعنی از طریق صف پیام ویندوز استاندارد). از این رو، زمان‌اجرای COM هم‌زمانی خودکار فراهم می‌کند، و این موضوع از این اطمینان حاصل می‌کند که هر فراخوانی شگرد از یک شیء همیشه تا تکمیل اجرا می‌گردد، قبل از آنکه شگرد دیگری فراخوانی شود. ازاین‌رو توسعه‌دهنده نیازی به نگران شدن دربارهٔ قفل ریسه‌ای یا وضعیت رقابت ندارد.
Multi-Threaded Apartment[۱۹] (MTA), (ThreadingModel=Free)	زمان‌اجرای COM هیچ همزمانی فراهم نمی‌کند، و چندین ریسه اجازه صدازدن به صورت همزمان اشیای COM را دارند. اشیای COM از این رو نیاز به اجرای همزمانی خاص خود را دارند تا در موقع دسترسی همزمان از چندین ریسه، از ایجاد وضعیت رقابت جلوگیری شود. صدازدن‌ها به یک شیء MTA از یک ریسه در یک STA نیز صف‌آرایی می‌شود.
Dynamically determined apartment (ThreadingModel=Both)	در حالت آپارتمان Both، سرور به صورت خودکار STA یا MTA را در موقع ساخت شیء انتخاب می‌کند، تا با نوع آپارتمان ریسه صدازننده منطبق گردد.[۲۰] این موضوع برای جلوگیری از سرباز صف‌آرایی موقعی که سرورهای MTA توسط یک ریسه STA دسترسی می‌یابد، مفید است.
Thread Neutral Apartment (NA), (ThreadingModel=Neutral)	آپارتمان خاص، بدون هیچ ریسه منتسب شده. موقعی که یک ریسه STA یا MTA یک شیء NA را در پردازه مشابه صدابزند، آنوقت ریسه صدازننده به صورت موقت آپارتمانش را ترک می‌کند، و کد مستقیماً موجود در NA را بدون هیچ تعویض ریسه‌ای انجام می‌دهد.[۲۱] از این رو می‌توان به NA را به صورت یک بهینه‌سازی برای صدازدن‌های شگرد بین آپارتمانی با کارایی بالا تصور کرد.

اشیا و ریسه‌هایی که به یک آپارتمان تعلق دارند، از قواعد دسترسی به ریسه مشابهی پیروی می‌کنند. فراخوانی شگردی که در داخل آپارتمان مشابهی انجام می‌شوند، به صورت مستقیم انجام می‌شوند، یعنی هیچ کمکی از جانب COM نمی‌گیرند. فراخوانی شگرد که بین آپارتمان‌ها انجام می‌شوند، از طریق صف‌آرایی به دست می‌آیند. این موضوع نیاز به استفاده از پراکسی و ته‌رسید دارد.

انتقادات

به دلیل آنکه COM پیاده‌سازی واقعاً پیچیده‌ای دارد، ممکن است برنامه‌نویسان توسط بعضی از مسائل «لوله‌کشی» پریشان شوند.

پمپ‌کردن پیام

موقعی که یک STA نمونه‌برداری می‌شود، یک پنجرهٔ پنهان را می‌سازد که از آن برای راه‌یابی برای پیام‌های داخل آپارتمانی یا داخل پردازه‌ای استفاده می‌شود. در این پنجره، باید صف پیامی‌اش به صورت مرتب «پمپ» شود. به این ساختار «پمپ پیامی» می‌گویند. در ورژن‌های قدیمی ویندوز، ناتوانی در انجام این کار می‌توانست منجر به بن‌بست‌های سطح سامانه شود. این موضوع توسط بعضی از APIهای ویندوز که COM را به عنوان بخشی از پیاده‌سازی شان راه‌اندازی می‌کردند، پیچیده‌تر می‌شد، و این کار باعث «نشت» جزئیات پیاده‌سازی می‌شود.

شمارش ارجاع

اگر دو یا بیشتر شیء به صورت چرخه‌ای ارجاع‌دهی شوند، شمارش ارجاع در داخل COM می‌تواند منجر به مشکل‌هایی شود. طراحی برنامه‌کاربردی باید این موضوع را درنظر بگیرد، و درنتیجه آن اشیا نباید یتیم باقی بمانند. اگر مدل «غرق وقعه» COM استفاده شود، اشیا ممکن است با وجود تعداد ارجاع فعال از بین بروند. به دلیل آنکه شیءای که وقعه را بیرون داده‌است، نیاز به یک ارجاع به شیءای دارد که به وقعه واکنش نشان می‌دهد، تعداد ارجاع دومی هیچگاه به صفر نمی‌رسد. ارجاع‌های دایره‌وار معمولاً یا توسط فن «خاتمهٔ خارج از باند»، یا توسط فن «هویت جداکننده» شکسته می‌شوند. در تکنیک خاتمه خارج از باند، یک شیء یک شگرد را نمایان می‌سازد که موقعی که صدازده شود، آن شیء را مجبور می‌سازد که ارجاع‌هایش به دیگر اشیاء را از بین ببرد، و از این رو چرخه را بشکند. در فن هویت جداکننده، یک پیاده‌سازی منفرد، دو شیء COM را نمایان می‌سازد (که به آن هویت گفته می‌شود). این موضوع باعث ایجاد یک ارجاع ضعیف، بین اشیای COM می‌شود، و از یک چرخه ارجاع جلوگیری می‌کند.

جهنم DLL

به دلیل آنکه مولفه‌های COM درون-پردازه‌ای در فایل‌های DLL پیاده‌سازی می‌شوند، و رجیسترکردن تنها به یک ورژن منفرد برای هر CLSID امکان حضور می‌دهد، آن‌ها ممکن است در بعضی حالات در معرض اثر «جهنم DLL» قرار گیرند. توانمندی COMهای بدون رجیستری این مسئله را برای مولفه‌های درون-پردازه‌ای حذف می‌کند؛ اما توانمندی COM بدون رجیستری برای سرورهای برون-پردازه‌ای در دسترس نیستند.

پانویس

1. "Documentation Archive". developer.apple.com.
2. "Plug-ins and Microsoft's COM". Apple Inc. Retrieved 2010-10-05.
3. Microsoft forum: Binary compatibility across Visual C++ versions
4. Wikipedia contributors, "Component Object Model," Wikipedia, The Free Encyclopedia,, (accessed December 10, 2012).
5. Steinberg, Jill (مارس 1, 1997). "Competing components make for prickly panelists". JavaWorld. Retrieved 2020-07-16.
6. "win32com Documentation Index". docs.activestate.com.
7. "Python and COM". www.boddie.org.uk.
8. "Compiler COM Support". MSDN. Microsoft.
9. Microsoft MSDN: C++ Attributes Reference
10. MSDN Magazine: C++ Attributes: Make COM Programming a Breeze with New Feature in Visual Studio .NET
11. "Assembly Manifests". MSDN. Retrieved 2009-11-05.
12. Dave Templin. "Simplify App Deployment with ClickOnce and Registration-Free COM". MSDN Magazine. Retrieved 2008-04-22.
13. "How to use an out-of-process COM server without its tlb file". Retrieved 2011-04-16.
14. "Concepts of Isolated Applications and Side-by-side Assemblies". MSDN. Retrieved 2016-02-05.
15. Arkhipov, Mikhail (1 April 2005). "Registration-free COM". MSDN Blogs. Retrieved 29 April 2016.
16. "DllGetClassObject entry point (COM)". MSDN. If a call to the CoGetClassObject function finds the class object that is to be loaded in a DLL, CoGetClassObject uses the DLL's exported DllGetClassObject function.
17. Microsoft MSDN: Processes, Threads, and Apartments
18. Microsoft MSDN: Single-Threaded Apartments
19. Microsoft MSDN: Multithreaded Apartments
20. Microsoft MSDN: Understanding and Using COM Threading Models
21. Codeguru: Understanding COM Apartments بایگانی‌شده در ۲۴ مه ۲۰۲۱ توسط Wayback Machine

منابع

• مشارکت‌کنندگان ویکی‌پدیا. «Component Object Model». در دانشنامهٔ ویکی‌پدیای انگلیسی، بازبینی‌شده در ۱۲ اسفند ۱۳۹۹.