МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
Харківський національний університет радіоелектронікі
Кафедра економічної кібернетики
Контрольна робота
З дісціпліні «Сучасні Економічні Технології»
ПІБ студента: Яницька Катерина Юріївна
Курс: ІІІ
Група: екз-04-06
Шифр:
Домашня адреса: м. Маріуполь, пр. Будівельників 109 - 73
Телефон: 8 (0629) 33-34-76
Харків 2006
Харківський національний університет радіоелектронікі
Кафедра економічної кібернетики
Контрольна робота
З дісціпліні «Сучасні Економічні Технології»
ПІБ студента: Яницька Катерина Юріївна
Курс: ІІІ
Група: екз-04-06
Шифр:
Домашня адреса: м. Маріуполь, пр. Будівельників 109 - 73
Телефон: 8 (0629) 33-34-76
Харків 2006
План
1. Що таке СОМ
2. Двійковий стандарт (чи незалежність від мови програмування)
3. Особливості застосування
1. Що таке СОМ
2. Двійковий стандарт (чи незалежність від мови програмування)
3. Особливості застосування
COM - це Component Object Model, тобто Компонентна Об'єктна Модель. Модель ця розроблена фірмою Microsoft і служить розробникам програмного забезпечення вже більше 10 років.
COM не є єдиною доступною в даний час об'єктною моделлю, і навіть не є найбільш розвиненою з наявних. Існують альтернативні моделі, наприклад, CORBA, яка підтримується OMG (Object Management Group) і реалізована на різних апаратних і програмних платформах.
COM реалізована в середовищі операційних систем сімейства Microsoft Windows. COM має еталонну реалізацію від Microsoft. Це забезпечує високу ступінь сумісності компонентів, написаних різними виробниками ПЗ. Проблеми сумісності досить актуальні, наприклад, для тієї ж CORBA, яка при її відсутності в принципі могла б скласти дуже істотну конкуренцію COM.
Об'єктна модель Microsoft виникла не відразу, вона розвивалася більш 10 років, час від часу змінюючи назву. Абревіатури OLE, OLE2, COM, DCOM, COM +, ActiveX - це різні іпостасі COM.
Ідея COM виникла не на порожньому місці. З моменту появи перших комп'ютерів стало очевидно, що завдання створення програмного забезпечення для них не настільки тривіальна, як могло б видатися збоку. І проблема ця погіршувалася буквально з кожним днем, тому що обладнання дешевшало і ставало доступним, а значить, всі нові категорії користувачі приєднувалися до існуючих, додаючи свої завдання до списку невирішених.
Одним із наріжних каменів у фундаменті будь-якої технології є уніфікація. При створенні будь-якого нового пристрою зазвичай виявляється, що велика частина його компонентів вже була використана в аналогічних виробах. Спочатку з'явилася концепція підпрограми, яка дозволила викликати фрагмент коду багаторазово з різних ділянок програми, уникаючи дублювання. Потім в якості природного розвитку з'явилася ідея створення бібліотек стандартних підпрограм. Перші бібліотеки підключалися до головної програми на рівні початкового тексту - до колоди перфокарт з програмою додавалася пачка карт зі стандартними підпрограмами, і вся ця конструкція піддавалася спільної компіляції.
Хоча такий підхід і з'явився певним прогресом на шляху до підвищення продуктивності праці програмістів, тим не менш він не позбавлений певних недоліків. Крім того, що маніпуляції з пачками карт самі по собі не надто зручні (хоча програмісти здогадалися фарбувати корінці карток в різні кольори, щоб легше було знаходити потрібну ділянку), при цьому програміст змушений писати програму на тій мові, на якому написана бібліотека, т. к. інакше спільна компіляція буде неможлива. На початковому етапі, коли не спостерігалося особливого достатку мов програмування, це ще не було таким уже гальмом, але надалі відсутність можливості вибору мови ставало важким тягарем.
Підхід з використанням об'єктних бібліотек, безумовно, більш прогресивні, але теж не вирішує всіх проблем. Перша з них - різні мови використовують різні механізми передачі параметрів підпрограм. Друга серйозна проблема - це неможливість перевірити відповідність кількості і типів фактичних параметрів формальним при виклику підпрограми як на етапі компіляції, так і під час виконання. Подібні помилки відбуваються досить часто по недбалості або з-за поганої якості документації до бібліотек і призводять до вельми несподіваним і непередбачуваним збоїв під час виконання програми.
COM призначена по суті для тієї ж мети - дозволити програмістові досить ефективно вирішити проблему повторного використання коду (як створеного власноруч, так і написаного іншими) і при цьому уникнути перерахованих вище проблем. Для цього в COM є відповідні механізми, основним з яких є поняття інтерфейсу.
Замість традиційної підпрограми модель COM пропонує більш високорівневу конструкцію - компонент, який набагато краще, ніж підпрограма, узгоджується із загальноприйнятими нині принципами об'єктного проектування та програмування.
Однією з найбільш важливих рис СОМ є її здатність надавати двійковий стандарт для програмних компонентів. Цей двійковий стандарт забезпечує засоби, за допомогою яких об'єкти і компоненти, розроблені на різних мовах програмування різними постачальниками і працюють у різних операційних системах, можуть взаємодіяти без будь-яких змін у двійковому (виконуваному) коді. Це є основним досягненням творців СОМ і відповідає насущним потребам спільноти розробників програм.
Багаторазове використання програмного забезпечення є однією з першочергових завдань при його розробці та забезпечується складовими його модулями, які повинні працювати в різноманітних середовищах. Зазвичай програмне забезпечення розробляється з використанням певної мови програмування, наприклад, C + +, і може ефективно застосовуватися тільки в тому випадку, якщо інші розробники компонентів також застосовують C + +.
Наприклад, якщо ми розробляємо С + + - клас, призначений для маніпулювання з даними, то необхідною умовою його використання в інших додатках є їх розробка на мові C + +. Тільки С + + - компілятори можуть розпізнати С + + - класи. Фактично, оскільки кошти C + + не підтримують жодного стандартного способу адаптації викликів С + + - функцій до нової програмної середовищі, використання програмного забезпечення в цій новому середовищі вимагає застосування такого ж (або аналогічного) інструментального засобу для його обробки. Іншими словами, використання класу в іншому операційному середовищі вимагає обов'язкового перенесення в цю середу вихідного тексту програми даного класу.
Застосування двійкового коду дозволяє розробнику створювати програмні компоненти, які можуть застосовуватися без використання мов, засобів і систем програмування, а тільки за допомогою двійкових компонентів (наприклад, DLL-або ЕХЕ - файлів). Ця можливість є для розробників дуже привабливою. Адже тепер вони можуть вибирати найбільш зручний для себе мову і засіб розробки компонентів, не піклуючись про мову і засобах, які буде використовувати інший розробник.
Порівняння об'єктів C + + і СОМ
Інша важлива властивість СОМ відомо під назвою незалежності від місця розташування (Location Transparency). Незалежність від місця розташування означає, що користувач компонента, клієнт, не обов'язково повинен знати, де знаходиться певний компонент. Клієнтський додаток використовує однакові сервіси СОМ для створення екземпляра і використання компонента незалежно від його фактичного розташування. Компонент може знаходитися безпосередньо в адресному просторі завдання клієнта (DLL-файл), в просторі іншої задачі на тому ж комп'ютері (ЕХЕ-файл) або на комп'ютері, розташованому за сотні миль (розподілений об'єкт). Технології СОМ і DCOM (Distributed СОМ - розподілена СОМ) забезпечують незалежність від місця розташування. Іншими засобами, що реалізують цю здатність, є сервіси розподілених об'єктів. Аналогічні можливості забезпечує стандарт CORBA. Оскільки клієнтське додаток взаємодіє з СОМ - компонентами, незалежно від їх положення, однаковим чином, інтерфейс клієнта теж не змінюється. Незалежність від місця розташування дозволяє розробнику створювати масштабовані додатки.
Основна особливість COM - це незалежність від мови програмування. Нерідко зустрічається ситуація, коли клієнтське додаток, написаний на Visual Basic, використовує компоненти, створені за допомогою Visual C + +. Для досягнення цієї незалежності в COM є власний механізм передачі параметрів і власна система типів, нейтральні по відношенню до використовуваних мов програмування.
Для того, щоб позбавитися від мовної залежності, в СОМ було введено два фундаментальні поняття: тип даних VARIANT і інтерфейс.
Тип даних VARIANT знаком тим, хто має досвід роботи з MS Visual Basic, оскільки з усіх систем програмування зі складу MS Visual Studio саме VB має найбільшу орієнтацію в напрямку СОМ. Змінна типу VARIANT може зберігати практично що завгодно: логічне, цілочисельне або дійсне значення, дату, покажчики на них, на масив або інтерфейс і т.п. Причому така мінлива зберігає не тільки значення, але і «знає», до якого типу воно відноситься. Це дозволяє налагодити контроль типів на етапі виконання, оскільки компілятор не знає, що насправді виявиться в цій змінній надалі.
Фізична реалізація типу VARIANT дуже проста. Якщо подивитися її опис мовою С, то ми побачимо просту структуру з двома полями: теги (VARTYPE vt), який зберігає інформацію про тип вмісту змінної (VARTYPE - це перерахування всіляких «підтипів» VARIANT), і об'єднання (union), в якому зібрані воєдино всі ці підтипи.
Поняття інтерфейсу дещо складніше. Інтуїтивно інтерфейс - дуже широке поняття, яке має на увазі звід правил і угод для взаємодії між двома і більше об'єктами. Тобто в принципі під це визначення потрапляє навіть оголошення функції із зазначенням кількості параметрів та їх типів.
Інтерфейс СОМ - це окремий, чітко визначене поняття. Спрощено його можна уявити собі як перелік методів, які компонент СОМ надає користувачеві. Інтерфейс включає в себе тільки методи. Якщо потрібно передати компоненту будь-які дані чи, навпаки, отримати їх від нього, слід передавати їх як параметри відповідних методів.
В якості моделі COM визначає набір правил, за якими мають будуватися компоненти. Тільки при їх строгому дотриманні компоненти забезпечують коректне і надійне функціонування.
Також COM регламентує способи використання компонентів з клієнтських програм. Найбільш загальні завдання, які дозволяє виконати COM, не є унікальними для цієї технології. Це досить тривіальна послідовність: створення необхідних об'єктів, їх використання і подальше знищення зі звільненням виділених ресурсів. Подібним чином працюють практично всі програмні продукти. Особливість COM полягає саме в тому, як це робиться.
Різноманітність різновидів COM виникло швидше через різноманітність вирішуваних завдань, а не з-за будь-яких вад, притаманних самої моделі.
Так, наприклад, область ActiveX - це відповідні елементи управління, які виконуються в контексті викликав їх процесу (так звані in-proc servers). Найчастіше ці елементи мають графічний інтерфейс (всілякі кнопочки, віконця і т.п.), хоча це і не обов'язково, трапляються елементи, позбавлені візуального представлення, начебто ADO. Типовий приклад - палітра інструментів Visual Basic 6.0, багата елементами управління ActiveX, які досить перетягнути мишкою на вікно форми.
OLE Automation - інший розділ COM. Тут клієнт вже управляє самостійним додатком, що виконується в контексті власного процесу, в ізольованій області пам'яті. Зрозуміло, управляти таким способом можна далеко не кожним додатком. Він повинен бути написаний спеціальним чином, у вигляді сервера Automation. На щастя, дуже багато популярні додатки написані саме як сервера COM, включаючи Microsoft Office, Microsoft Visio, програми сімейства Corel Draw, інтегрована оболонка Visual Studio і т.д. Таким чином, у програміста з'являється вибір реалізовувати складне оформлення і виведення документа на друк самостійно або ж скористатися для цієї мети тим же MS Word, керуючи їм за допомогою OLE Automation.
Ще один приклад - DCOM, тобто Distributed COM, - розподілена різновид COM, здатна працювати в локальній мережі. Використовуючи DCOM, можна, наприклад, скористатися комп'ютером сусіда і виконати розрахунок таблиці в середовищі Excel, при цьому будуть задіяні ресурси іншого комп'ютера, залишиться тільки дочекатися готового результату і отримати його у своє розпорядження. Таким чином, можна будувати розподілені додатки, в яких спеціально виділені сервери додатків, оснащені відповідним чином, вирішують певні завдання по запитах клієнтів і видають їм готові результати.
Таким чином, наявність кількох гілок або напрямків в COM свідчить не про безпорадність технології як такої, а швидше про широкий спектр завдань, що вирішуються її допомогою. Усі ці різновиди мають у своїй основі загальну ідею, яка дозволяє вважати їх саме приватними випадками єдиною технологією.
OLE Automation - це спеціальна технологія, яка дозволяє одному з додатком керувати іншим приблизно таким же чином, як користувач комп'ютера управляє ним при інтерактивній роботі. Наприклад, можна запустити Excel, створити в ньому нову книгу, в ній - робочий лист, заповнити таблицю даними з прикладної програми, додати до неї формули для автоматичного обчислення підсумків і вивести її на друк. У результаті увагу програміста концентрується на предметній області, тобто на головному завданні - отриманні даних, а оформлення і висновок він може доручити відповідному додатком, в якому ці завдання успішно вирішені.
Додаток, який написано спеціальним чином і може управлятися ззовні, називається «сервером автоматизації OLE» (Automation Server). Наприклад, програми зі складу MS Office є серверами автоматизації, що робить їх набагато корисніше звичайного текстового редактора або табличного процесора. Також керованими через OLE Automation є Visual Studio, MS Visio, пакет Corel Draw, поштові програми і багато інших популярні додатки.
Компоненти від Microsoft, як правило, добре документовані, зокрема в MSDN. А в загальному випадку вони не відрізняються від звичайних програм - трапляються як екземпляри з недбалою і неточною документацією, з якими доводиться розбиратися методом проб і помилок, так і блискуче документовані компоненти.
У силу особливостей своєї будови, компоненти все ж містять в собі деяку інформацію про своїх власних інтерфейсах, яка може бути використана в крайньому випадку, коли нормальна документація недоступна. MS Visual Studio своєму розпорядженні деякими засобами, які дозволяють спростити використання компонентів і мінімізувати кількість помилок, принаймні, що стосується кількості та типів аргументів при викликах методів, а також при роботі з властивостями.
На практиці необхідно почати з написання найпростішого клієнта, який звертається до послуг одного з готових серверів, наприклад, MS Excel. Найпростіше це зробити в середовищі MS Visual Basic V6, хоча при хорошому знайомстві з С + + можна скористатися і їм. Правда, VB приховає від програміста більшість деталей взаємодії клієнта і сервера, в той час як в С + + всі вони будуть як на долоні.
Висновок
Модель компонентного об'єкта (СОМ) фірми Microsoft є основою таких технологій, як OLE і ActiveX. Модель СОМ принесла в розробку програм деякі речі, необхідність у яких відчувалася протягом тривалого часу. СОМ поряд з незалежністю від розташування надала для програмних компонентів ще і незалежний від мови програмування двійковий стандарт. Під незалежністю від розташування розуміється можливість розміщення програмних модулів незалежно від розв'язуваних завдань і використовуваних для цього комп'ютерів. OLE і ActiveX представляють собою надбудовані над СОМ технології прикладного рівня.
У середовищі СОМ велике значення має реєстр Windows. Його роль полягає в управлінні кількома розділами, які використовуються як СОМ, так і програмами клієнта. У СОМ широко використовується поняття GUID - унікального 128-розрядного числа, однозначно ідентифікує інтерфейси та компоненти. До складу СОМ входять декілька Win32 API і великий набір оголошень інтерфейсів.
Активна бібліотека шаблонів (ATL) представляє собою структуру, яка полегшує створення невеликих СОМ компонентів. У ATL використані новітні засоби створення шаблонів C + +. Вона оснащена також вихідною програмою, що представляє собою частина середовища розробки Visual C + +. Створення проекту починається з визначення способу реалізації сховища. У цьому істотну допомогу надає утиліта ATL СОМ AppWizard. Після цього для додавання певних компонентів використовується майстер об'єктів ATL. В состав ATL входят несколько классов, обеспечивающих реализацию по умолчанию наиболее общих потребностей СОМ. Класс CComModule обеспечивает основную поддержку по организации хранилища посредством реализации функций DllGetClassObject и DilCanUnloadNow. Благодаря компоненту ATL Registrar обеспечивается также поддержка саморегистрации, что облегчает обновление регистра Windows.
COM не є єдиною доступною в даний час об'єктною моделлю, і навіть не є найбільш розвиненою з наявних. Існують альтернативні моделі, наприклад, CORBA, яка підтримується OMG (Object Management Group) і реалізована на різних апаратних і програмних платформах.
COM реалізована в середовищі операційних систем сімейства Microsoft Windows. COM має еталонну реалізацію від Microsoft. Це забезпечує високу ступінь сумісності компонентів, написаних різними виробниками ПЗ. Проблеми сумісності досить актуальні, наприклад, для тієї ж CORBA, яка при її відсутності в принципі могла б скласти дуже істотну конкуренцію COM.
Об'єктна модель Microsoft виникла не відразу, вона розвивалася більш 10 років, час від часу змінюючи назву. Абревіатури OLE, OLE2, COM, DCOM, COM +, ActiveX - це різні іпостасі COM.
Ідея COM виникла не на порожньому місці. З моменту появи перших комп'ютерів стало очевидно, що завдання створення програмного забезпечення для них не настільки тривіальна, як могло б видатися збоку. І проблема ця погіршувалася буквально з кожним днем, тому що обладнання дешевшало і ставало доступним, а значить, всі нові категорії користувачі приєднувалися до існуючих, додаючи свої завдання до списку невирішених.
Одним із наріжних каменів у фундаменті будь-якої технології є уніфікація. При створенні будь-якого нового пристрою зазвичай виявляється, що велика частина його компонентів вже була використана в аналогічних виробах. Спочатку з'явилася концепція підпрограми, яка дозволила викликати фрагмент коду багаторазово з різних ділянок програми, уникаючи дублювання. Потім в якості природного розвитку з'явилася ідея створення бібліотек стандартних підпрограм. Перші бібліотеки підключалися до головної програми на рівні початкового тексту - до колоди перфокарт з програмою додавалася пачка карт зі стандартними підпрограмами, і вся ця конструкція піддавалася спільної компіляції.
Хоча такий підхід і з'явився певним прогресом на шляху до підвищення продуктивності праці програмістів, тим не менш він не позбавлений певних недоліків. Крім того, що маніпуляції з пачками карт самі по собі не надто зручні (хоча програмісти здогадалися фарбувати корінці карток в різні кольори, щоб легше було знаходити потрібну ділянку), при цьому програміст змушений писати програму на тій мові, на якому написана бібліотека, т. к. інакше спільна компіляція буде неможлива. На початковому етапі, коли не спостерігалося особливого достатку мов програмування, це ще не було таким уже гальмом, але надалі відсутність можливості вибору мови ставало важким тягарем.
Підхід з використанням об'єктних бібліотек, безумовно, більш прогресивні, але теж не вирішує всіх проблем. Перша з них - різні мови використовують різні механізми передачі параметрів підпрограм. Друга серйозна проблема - це неможливість перевірити відповідність кількості і типів фактичних параметрів формальним при виклику підпрограми як на етапі компіляції, так і під час виконання. Подібні помилки відбуваються досить часто по недбалості або з-за поганої якості документації до бібліотек і призводять до вельми несподіваним і непередбачуваним збоїв під час виконання програми.
COM призначена по суті для тієї ж мети - дозволити програмістові досить ефективно вирішити проблему повторного використання коду (як створеного власноруч, так і написаного іншими) і при цьому уникнути перерахованих вище проблем. Для цього в COM є відповідні механізми, основним з яких є поняття інтерфейсу.
Замість традиційної підпрограми модель COM пропонує більш високорівневу конструкцію - компонент, який набагато краще, ніж підпрограма, узгоджується із загальноприйнятими нині принципами об'єктного проектування та програмування.
Однією з найбільш важливих рис СОМ є її здатність надавати двійковий стандарт для програмних компонентів. Цей двійковий стандарт забезпечує засоби, за допомогою яких об'єкти і компоненти, розроблені на різних мовах програмування різними постачальниками і працюють у різних операційних системах, можуть взаємодіяти без будь-яких змін у двійковому (виконуваному) коді. Це є основним досягненням творців СОМ і відповідає насущним потребам спільноти розробників програм.
Багаторазове використання програмного забезпечення є однією з першочергових завдань при його розробці та забезпечується складовими його модулями, які повинні працювати в різноманітних середовищах. Зазвичай програмне забезпечення розробляється з використанням певної мови програмування, наприклад, C + +, і може ефективно застосовуватися тільки в тому випадку, якщо інші розробники компонентів також застосовують C + +.
Наприклад, якщо ми розробляємо С + + - клас, призначений для маніпулювання з даними, то необхідною умовою його використання в інших додатках є їх розробка на мові C + +. Тільки С + + - компілятори можуть розпізнати С + + - класи. Фактично, оскільки кошти C + + не підтримують жодного стандартного способу адаптації викликів С + + - функцій до нової програмної середовищі, використання програмного забезпечення в цій новому середовищі вимагає застосування такого ж (або аналогічного) інструментального засобу для його обробки. Іншими словами, використання класу в іншому операційному середовищі вимагає обов'язкового перенесення в цю середу вихідного тексту програми даного класу.
Застосування двійкового коду дозволяє розробнику створювати програмні компоненти, які можуть застосовуватися без використання мов, засобів і систем програмування, а тільки за допомогою двійкових компонентів (наприклад, DLL-або ЕХЕ - файлів). Ця можливість є для розробників дуже привабливою. Адже тепер вони можуть вибирати найбільш зручний для себе мову і засіб розробки компонентів, не піклуючись про мову і засобах, які буде використовувати інший розробник.
Порівняння об'єктів C + + і СОМ
| C + +-об'єкт (екземпляр класу) | СОМ-об'єкт |
| Дозволяє використовувати тільки один загальний інтерфейс, що представляє собою безліч С + +-методів. | Зазвичай надає більше одного спільного інтерфейсу |
| Залежить від мови програмування. | Забезпечується незалежність від мови - CОМ-об'єкти реалізуються і використовуються в різних мовах програмування. |
| Відсутня вбудована можливість перевірки версії. | Підтримується вбудований спосіб перевірки версій об'єктів. Забезпечується незалежність від місця розташування на жорсткому диску. |
Інша важлива властивість СОМ відомо під назвою незалежності від місця розташування (Location Transparency). Незалежність від місця розташування означає, що користувач компонента, клієнт, не обов'язково повинен знати, де знаходиться певний компонент. Клієнтський додаток використовує однакові сервіси СОМ для створення екземпляра і використання компонента незалежно від його фактичного розташування. Компонент може знаходитися безпосередньо в адресному просторі завдання клієнта (DLL-файл), в просторі іншої задачі на тому ж комп'ютері (ЕХЕ-файл) або на комп'ютері, розташованому за сотні миль (розподілений об'єкт). Технології СОМ і DCOM (Distributed СОМ - розподілена СОМ) забезпечують незалежність від місця розташування. Іншими засобами, що реалізують цю здатність, є сервіси розподілених об'єктів. Аналогічні можливості забезпечує стандарт CORBA. Оскільки клієнтське додаток взаємодіє з СОМ - компонентами, незалежно від їх положення, однаковим чином, інтерфейс клієнта теж не змінюється. Незалежність від місця розташування дозволяє розробнику створювати масштабовані додатки.
Основна особливість COM - це незалежність від мови програмування. Нерідко зустрічається ситуація, коли клієнтське додаток, написаний на Visual Basic, використовує компоненти, створені за допомогою Visual C + +. Для досягнення цієї незалежності в COM є власний механізм передачі параметрів і власна система типів, нейтральні по відношенню до використовуваних мов програмування.
Для того, щоб позбавитися від мовної залежності, в СОМ було введено два фундаментальні поняття: тип даних VARIANT і інтерфейс.
Тип даних VARIANT знаком тим, хто має досвід роботи з MS Visual Basic, оскільки з усіх систем програмування зі складу MS Visual Studio саме VB має найбільшу орієнтацію в напрямку СОМ. Змінна типу VARIANT може зберігати практично що завгодно: логічне, цілочисельне або дійсне значення, дату, покажчики на них, на масив або інтерфейс і т.п. Причому така мінлива зберігає не тільки значення, але і «знає», до якого типу воно відноситься. Це дозволяє налагодити контроль типів на етапі виконання, оскільки компілятор не знає, що насправді виявиться в цій змінній надалі.
Фізична реалізація типу VARIANT дуже проста. Якщо подивитися її опис мовою С, то ми побачимо просту структуру з двома полями: теги (VARTYPE vt), який зберігає інформацію про тип вмісту змінної (VARTYPE - це перерахування всіляких «підтипів» VARIANT), і об'єднання (union), в якому зібрані воєдино всі ці підтипи.
Поняття інтерфейсу дещо складніше. Інтуїтивно інтерфейс - дуже широке поняття, яке має на увазі звід правил і угод для взаємодії між двома і більше об'єктами. Тобто в принципі під це визначення потрапляє навіть оголошення функції із зазначенням кількості параметрів та їх типів.
Інтерфейс СОМ - це окремий, чітко визначене поняття. Спрощено його можна уявити собі як перелік методів, які компонент СОМ надає користувачеві. Інтерфейс включає в себе тільки методи. Якщо потрібно передати компоненту будь-які дані чи, навпаки, отримати їх від нього, слід передавати їх як параметри відповідних методів.
В якості моделі COM визначає набір правил, за якими мають будуватися компоненти. Тільки при їх строгому дотриманні компоненти забезпечують коректне і надійне функціонування.
Також COM регламентує способи використання компонентів з клієнтських програм. Найбільш загальні завдання, які дозволяє виконати COM, не є унікальними для цієї технології. Це досить тривіальна послідовність: створення необхідних об'єктів, їх використання і подальше знищення зі звільненням виділених ресурсів. Подібним чином працюють практично всі програмні продукти. Особливість COM полягає саме в тому, як це робиться.
Різноманітність різновидів COM виникло швидше через різноманітність вирішуваних завдань, а не з-за будь-яких вад, притаманних самої моделі.
Так, наприклад, область ActiveX - це відповідні елементи управління, які виконуються в контексті викликав їх процесу (так звані in-proc servers). Найчастіше ці елементи мають графічний інтерфейс (всілякі кнопочки, віконця і т.п.), хоча це і не обов'язково, трапляються елементи, позбавлені візуального представлення, начебто ADO. Типовий приклад - палітра інструментів Visual Basic 6.0, багата елементами управління ActiveX, які досить перетягнути мишкою на вікно форми.
OLE Automation - інший розділ COM. Тут клієнт вже управляє самостійним додатком, що виконується в контексті власного процесу, в ізольованій області пам'яті. Зрозуміло, управляти таким способом можна далеко не кожним додатком. Він повинен бути написаний спеціальним чином, у вигляді сервера Automation. На щастя, дуже багато популярні додатки написані саме як сервера COM, включаючи Microsoft Office, Microsoft Visio, програми сімейства Corel Draw, інтегрована оболонка Visual Studio і т.д. Таким чином, у програміста з'являється вибір реалізовувати складне оформлення і виведення документа на друк самостійно або ж скористатися для цієї мети тим же MS Word, керуючи їм за допомогою OLE Automation.
Ще один приклад - DCOM, тобто Distributed COM, - розподілена різновид COM, здатна працювати в локальній мережі. Використовуючи DCOM, можна, наприклад, скористатися комп'ютером сусіда і виконати розрахунок таблиці в середовищі Excel, при цьому будуть задіяні ресурси іншого комп'ютера, залишиться тільки дочекатися готового результату і отримати його у своє розпорядження. Таким чином, можна будувати розподілені додатки, в яких спеціально виділені сервери додатків, оснащені відповідним чином, вирішують певні завдання по запитах клієнтів і видають їм готові результати.
Таким чином, наявність кількох гілок або напрямків в COM свідчить не про безпорадність технології як такої, а швидше про широкий спектр завдань, що вирішуються її допомогою. Усі ці різновиди мають у своїй основі загальну ідею, яка дозволяє вважати їх саме приватними випадками єдиною технологією.
OLE Automation - це спеціальна технологія, яка дозволяє одному з додатком керувати іншим приблизно таким же чином, як користувач комп'ютера управляє ним при інтерактивній роботі. Наприклад, можна запустити Excel, створити в ньому нову книгу, в ній - робочий лист, заповнити таблицю даними з прикладної програми, додати до неї формули для автоматичного обчислення підсумків і вивести її на друк. У результаті увагу програміста концентрується на предметній області, тобто на головному завданні - отриманні даних, а оформлення і висновок він може доручити відповідному додатком, в якому ці завдання успішно вирішені.
Додаток, який написано спеціальним чином і може управлятися ззовні, називається «сервером автоматизації OLE» (Automation Server). Наприклад, програми зі складу MS Office є серверами автоматизації, що робить їх набагато корисніше звичайного текстового редактора або табличного процесора. Також керованими через OLE Automation є Visual Studio, MS Visio, пакет Corel Draw, поштові програми і багато інших популярні додатки.
Компоненти від Microsoft, як правило, добре документовані, зокрема в MSDN. А в загальному випадку вони не відрізняються від звичайних програм - трапляються як екземпляри з недбалою і неточною документацією, з якими доводиться розбиратися методом проб і помилок, так і блискуче документовані компоненти.
У силу особливостей своєї будови, компоненти все ж містять в собі деяку інформацію про своїх власних інтерфейсах, яка може бути використана в крайньому випадку, коли нормальна документація недоступна. MS Visual Studio своєму розпорядженні деякими засобами, які дозволяють спростити використання компонентів і мінімізувати кількість помилок, принаймні, що стосується кількості та типів аргументів при викликах методів, а також при роботі з властивостями.
На практиці необхідно почати з написання найпростішого клієнта, який звертається до послуг одного з готових серверів, наприклад, MS Excel. Найпростіше це зробити в середовищі MS Visual Basic V6, хоча при хорошому знайомстві з С + + можна скористатися і їм. Правда, VB приховає від програміста більшість деталей взаємодії клієнта і сервера, в той час як в С + + всі вони будуть як на долоні.
Висновок
Модель компонентного об'єкта (СОМ) фірми Microsoft є основою таких технологій, як OLE і ActiveX. Модель СОМ принесла в розробку програм деякі речі, необхідність у яких відчувалася протягом тривалого часу. СОМ поряд з незалежністю від розташування надала для програмних компонентів ще і незалежний від мови програмування двійковий стандарт. Під незалежністю від розташування розуміється можливість розміщення програмних модулів незалежно від розв'язуваних завдань і використовуваних для цього комп'ютерів. OLE і ActiveX представляють собою надбудовані над СОМ технології прикладного рівня.
У середовищі СОМ велике значення має реєстр Windows. Його роль полягає в управлінні кількома розділами, які використовуються як СОМ, так і програмами клієнта. У СОМ широко використовується поняття GUID - унікального 128-розрядного числа, однозначно ідентифікує інтерфейси та компоненти. До складу СОМ входять декілька Win32 API і великий набір оголошень інтерфейсів.
Активна бібліотека шаблонів (ATL) представляє собою структуру, яка полегшує створення невеликих СОМ компонентів. У ATL використані новітні засоби створення шаблонів C + +. Вона оснащена також вихідною програмою, що представляє собою частина середовища розробки Visual C + +. Створення проекту починається з визначення способу реалізації сховища. У цьому істотну допомогу надає утиліта ATL СОМ AppWizard. Після цього для додавання певних компонентів використовується майстер об'єктів ATL. В состав ATL входят несколько классов, обеспечивающих реализацию по умолчанию наиболее общих потребностей СОМ. Класс CComModule обеспечивает основную поддержку по организации хранилища посредством реализации функций DllGetClassObject и DilCanUnloadNow. Благодаря компоненту ATL Registrar обеспечивается также поддержка саморегистрации, что облегчает обновление регистра Windows.
Література
1. Том Армстрон "ActiveX-Создание Web-приложений"
2. http://www.microsoft.com
3. http://www.codenet.ru
1. Том Армстрон "ActiveX-Создание Web-приложений"
2. http://www.microsoft.com
3. http://www.codenet.ru