Сюди перенаправляється запит " DCOM ". На цю тему потрібна окрема стаття .

COM ( англ. Component Object Model - Об'єктна модель компонентів; вимовляється як [кому]) - це технологічний стандарт від компанії Microsoft, призначений для створення програмного забезпечення на основі взаємодіючих компонентів, кожен з яких може використовуватися в багатьох програмах одночасно. Стандарт втілює в собі ідеї поліморфізму та інкапсуляції об'єктно-орієнтованого програмування. Стандарт COM міг би бути універсальним і платформно-незалежним, але закріпився в основному на операційних системах сімейства Microsoft Windows. У сучасних версіях Windows COM використовується дуже широко. На основі COM були реалізовані технології: Microsoft OLE Automation, ActiveX, DCOM, COM +, DirectX, а також XPCOM.


1. Історія COM

Стандарт COM був розроблений в 1993 корпорацією Microsoft як основа для розвитку технології OLE. Технологія OLE 1.0 вже дозволяла створювати т. н. " складові документи "( англ. compound documents ): Наприклад, в пакеті Microsoft Office ця технологія дозволяла включати діаграми Microsoft Excel в документи Microsoft Word.


1.1. Плутанина в назвах

В 1996 Microsoft спробувала перейменувати технологію OLE в ActiveX, але це вдалося лише частково. Наприклад, технологія OLE дозволяла створювати так звані елементи управління OLE ( англ. OLE Controls , Або OCX) - повторно використовувані елементи користувальницького інтерфейсу, які були побудовані на стандарті COM. Ці елементи управління OLE були перейменовані в елементи керування ActiveX ( англ. ActiveX controls ), Хоча розширення файлів ". ocx" за ними залишилося. Потім Microsoft стала активно просувати ActiveX в Інтернет, включивши підтримку елементів ActiveX у свій браузер Internet Explorer. В результаті назва OLE залишилося тільки за технологією складових документів і локальних впроваджуваних об'єктів. А мережеві OLE-об'єкти стали називати по-новому - ActiveX.

Деяка плутанина між поняттями OLE і ActiveX зберігається і досі, але мова йде про одних і тих же COM-технологіях. Причому, іноді навіть плутають поняття OLE і COM. Так, впроваджувані OLE-об'єкти іноді називають COM-об'єктами, а OLE-контейнери COM-контейнерами, і т. п.


2. Принципи роботи COM

Основним поняттям, яким оперує стандарт COM, є COM-компонент. Програми, побудовані на стандарті COM, фактично не є автономними програмами, а представляють собою набір взаємодіючих між собою COM-компонентів. Кожен компонент має унікальний ідентифікатор ( GUID) і може одночасно використовуватися багатьма програмами. Компонент взаємодіє з іншими програмами через COM-інтерфейси - набори абстрактних функцій і властивостей. Кожен COM-компонент повинен, як мінімум, підтримувати стандартний інтерфейс "IUnknown", який надає базові засоби для роботи з компонентом. Інтерфейс "IUnknown" включає в себе три методи: QueryInterface, AddRef, Release.

Windows API надає базові функції, що дозволяють використовувати COM-компоненти. Бібліотеки MFC і, особливо, ATL / WTL надають набагато більш гнучкі і зручні засоби для роботи з COM. Бібліотека ATL від Microsoft до цих пір залишається найпопулярнішим засобом створення COM-компонентів. Але найчастіше COM-розробка залишається ще досить складною справою, програмістам доводиться вручну виконувати багато рутинних завдання, пов'язані з COM (особливо це помітно у випадку розробки на C + +). Згодом (в технологіях COM + і особливо . NET ) Microsoft спробувала спростити завдання розробки COM-компонентів.


3. Технології, засновані на стандарті COM

3.1. DCOM

Випущена в 1996 технологія DCOM ( англ. Distributed COM - Розподілена COM) заснована на технології DCE / RPC (різновиди RPC). DCOM дозволяє COM-компонентів взаємодіяти один з одним по мережі. Головним конкурентом DCOM є інша відома розподілена технологія - CORBA.

Як DCOM, так і CORBA вирішують завдання виклику методу об'єкта, розташованого на іншій машині, а також передачу посилання на об'єкт з однієї машини на іншу.

Мережевий рівень DCOM називається ORPC (Object RPC) і є об'єктно-орієнтованим розширенням DCE RPC.

Технологія DCOM забезпечує базові установки безпеки, дозволяючи задавати, хто і з яких машин може створювати екземпляри об'єкту і викликати його методи.


3.2. COM +

Microsoft Transaction Server був включений в Option Pack для Windows NT4 ще в 1997 році.

У складі Windows 2000 була випущена технологія COM +, яка була новою версією Microsoft Transaction Server.

Технологія розширювала можливості розробників COM-компонентів, надаючи їм деякі готові послуги, наприклад:

  • автоматичний пул потоків, створюваний стандартним процесом-завантажувачем mtx.exe
  • доступ до контексту, в якому виконується компонент (наприклад, компоненти, що використовуються в ASP, можуть з цією можливістю отримати доступ до внутрішніх об'єктам тієї сторінки, на якій вони виконуються).
  • інтеграція з транзакціями монітора MS DTC (контекст COM + може автоматично містити в собі транзакцію MS DTC)

MTS / COM + використовувався усередині ряду версій веб-сервера MS IIS для завантаження і виконання веб-додатків, як бінарних за технологією ISAPI, так і скриптових за технологією ASP (сама asp.dll є ISAPI-додаток).

COM + об'єднує компоненти в так звані програми COM +, що спрощує адміністрування і обслуговування компонентів. Безпека та продуктивність - основні напрямки удосконалень COM +. Деякі ідеї, закладені в основу COM +, були також реалізовані в Microsoft. NET .


3.3. . NET і майбутнє COM

В 2002 була офіційно випущена платформа Microsoft. NET , Яка на сьогоднішній день оголошена Microsoft рекомендованої основою для створення додатків і компонентів під Windows. З цієї причини в . NET включені і засоби, що дозволяють звертатися до компонентів COM з додатків . NET , І навпаки. За словами представників Microsoft, COM (точніше, COM +) та . NET є відмінно взаємодоповнюючими технологіями.

3.4. DCOM через інтернет і вирішення проблеми XP SP2

У 2009 році DComLab опублікував комерційний продукт ComBridge. При використанні ComBridge для роботи з DCOM через інтернет не потрібно CIS, не використовується 135 порт, в локальній мережі не потрібні налаштування dcomcnfg. ComBridge вбудовується в транспортний рівень DCOM, повністю виділяючи весь трафік створеного об'єкта і всіх отриманих з нього об'єктів в окремий потік.

3.5. OPC

OPC (OLE for Process Control) - сімейство програмних технологій, що надають єдиний інтерфейс для управління об'єктами автоматизації і технологічними процесами. Багато хто з OPC протоколів базуються на Windows-технологіях: OLE, ActiveX, COM / DCOM. Такі OPC протоколи, як OPC XML DA і OPC UA є платформно-незалежними.

3.6. OLE

OLE (англ. Object Linking and Embedding, вимовляється як oh-lay [олей] - Зв'язування та вбудовування об'єкта) - технологія зв'язування та впровадження об'єктів в інші документи та об'єкти, розроблені корпорацією Майкрософт.

OLE дозволяє передавати частину роботи від однієї програми редагування до іншої і повертати результати назад. Наприклад, встановлена ​​на персональному комп'ютері видавнича система може послати якийсь текст на обробку в текстовий редактор, або деяке зображення в редактор зображень за допомогою OLE-технології.


4. Критика

Технологія часто критикується за невиправдану складність, конкретно:

  • необхідність використання двох мов програмування (. idl для опису інтерфейсів і, звичайно, C + + для написання реалізацій). Необхідність виникає тільки при створенні власних інтерфейсів, і не виникає у випадку, якщо розробник обмежив себе використанням готових інтерфейсів.
  • необхідність "прокладочного" коду (у його ролі зазвичай виступає ATL) для того, щоб створити COM-об'єкт на базі Сі + + класу. Хоча цей код і тривіальний у використанні для досвідченої людини, він не дуже простий для початківців. Як і в попередньому пункті, ця проблема виникає тільки при написанні власних класів і не виникає при одному лише використанні стандартних чужих класів (для яких MS розробив бібліотеку смарт-пойнтерів - comdef.h, _com_ptr_t , ця бібліотека робить використання COM-об'єктів тривіальним).
  • необхідність реєстрації компонент в реєстрі операційної системи, причому при цьому в якості ідентифікатора класу використовується нечитаний людиною GUID (хоча його і можливо доповнити читаним ім'ям).
  • інфраструктура remoting (віддаленого виклику методів) використовує бінарний формат запитів і відповідей, будучи розширенням DCE RPC. Це призводить до виникнення величезної "поверхні уразливості" з точки зору безпеки, і не раз призводило до великих епідеміям шкідливого ПЗ (MSBlaster).
  • інфраструктура remoting використовує за замовчуванням (слідом за DCE RPC) динамічно призначаються номери TCP і UDP портів, що робить її вкрай складною в настройці при наявності міжмережевих екранів.
  • обробка помилок. В COM прийнято використовувати 32бітние коди помилки HRESULT, які мають значення зразок 0x80070123, і абсолютно не читані людиною (хоча останнім часом всі вони тривіально шукаються пошуковими машинами Інтернету).

Крім того, runtime type information в COM, відома під назвою type libraries, підтримується тільки для т.зв. Automation-compatible інтерфейсів, що мають величезні обмеження на типи параметрів (масиви - тільки SAFEARRAY, рядки - тільки BSTR, ніяких довільних структур, тільки числа, дата / час, масиви, рядки і посилання на інші Automation-compatible об'єкти).

Помітно, однак, що багато з цих недоліків є платою за гідність COM - незалежність від мови програмування і виконуючого середовища, і не існують в "істинно об'єктних" мовах, таких, як C # або ж (припинена) реалізація Java компанії Microsoft. Ці мови надають і повну runtime type information, і відсутність необхідності реєстрації, і можливість написання як інтерфейсів, так і класів стандартним для мови чином, без "прокладок" на зразок ATL. Так, у MS J + + будь клас Java тривіально публікувався зовнішньому світу як клас COM, достатньо було лише реєстрації. Те ж існує і в C #.

З протилежного боку, "істинно об'єктні" мови або взагалі не здатні стикуватися з компонентами з інших об'єктних мов і вимагають написання всієї системи (і нижележащих підсистем і фреймворків) "зверху донизу" на одній мові в одній виконуючою середовищі (Java, Objective C), або ж накладають таку саму вимогу хоча і не на мову, але на виконуючу середу (. NET, мови C #, C + + managed і VB.NET).

Більш нові аналогічні технології (наприклад, в світі. NET) намагаються вирішити ці проблеми. Там зазвичай стек remoting поліморфа і кастомізіруем, що дає можливість самостійно вибирати формат запитань / відповідей і транспортний протокол (за замовчуванням використовується вже не DCE RPC, а SOAP, в якості формату даних - XML, а в якості транспорту - HTTP, який не покладається на динамічні номери портів).

Використання механізму пізнього зв'язування може істотно знизити продуктивність у порівнянні, наприклад, з викликом експортованої функції з динамічної бібліотеки. Однак цей механізм застосовується тільки в скриптових мовах, і тільки в тому випадку, якщо мова не підтримує оголошення посилань на об'єкти як посилань на COM-інтерфейси з type libraries (у вигляді Dim obj As Excel.Workbook), а підтримує тільки абстрактні COM-об'єкти (у вигляді Dim obj As Object). Крім того, такий самий підхід застосовується в Objective C і Cocoa.