Преподаватель который помогает студентам и школьникам в учёбе.

Технология COM. Понятие и история развития

Содержание:

ВВЕДЕНИЕ

Разработка различных программных продуктов сегодня является одной из наиболее перспективных отраслей. В связи с этим многие молодые люди выбирают программирование в качестве своей специализации. Современные технологии, применяемые в процессе программирования, позволяют создавать не только полезные и функциональные программные продукты, но и по-настоящему удобные – с дружественным и интуитивно понятным интерфейсом, с которым зачастую может справиться даже самый неопытный пользователь.

Применяемые технологии могут разниться в зависимости назначения, количества ресурсов, а также функциональности, требуемой от конечного продукта. Одной из распространенных на сегодня технологий является технология COM, нашедшая достаточно широкое применение в процессе разработки различных программных продуктов и прочих элементов программного обеспечения. Кроме того, данная технология используется для обеспечения интеграции разнообразных программных оболочек и продуктов в единые системы.

Разработчики технологии COM целью ставили интеграцию программного обеспечения посредством стандартизации механизмов и операций взаимодействия программных модулей друг с другом. К сегодняшнему дню технология COM стала основой огромного числа дочерних технологий, которые в свое время преобразовались в стандарты в самых разных сферах, начиная управлением технологическими процессами в промышленности и заканчивая домашними персональными компьютерами.

Широкое использование технологии COM можно связать с массовостью, масштабностью и мощью самого ее разработчика, а именно, – фирмы Microsoft. Данная компания давно уже завоевала достаточную репутацию и престиж, с которыми приходится считаться. Так, любая программа, выпущенная на платформу Windows, должна быть соответственной новшествам и инновациям Microsoft, что обеспечит коммерческий успех и экономическую эффективность разработки.

Для более подробного изучения вопроса необходимо выполнить следующую цель работы – изучение технологии COM.

Для достижения данной цели необходимо выполнить следующие задачи:

охарактеризовать понятие технологии COM;
рассмотреть историю развития технологии COM;
разобрать терминологию технологии COM;
проанализировать состав объектов технологии COM;
подвести итоги по проделанной работе.

Объектом изучения предметной области являются технологии обработки информации, а предметом – технология COM.

Структура работы включает в себя несколько элементов, среди них – введение, заключение и список использованной литературы, а также две главы, каждая из которых содержит по два параграфа.

Теоретическая база работы – исследования известных авторов, чьи работы приведены в списке использованной литературы. Разнообразие точек зрения на проблему, изложенных в данных источниках, позволило полноценно и разносторонне рассмотреть предмет работы.

Технология COM. Понятие и история развития

Понятие технологии COM

Технология COM (Component Object Technology) является объектно–ориентированной программной спецификацией, которая была предложена фирмой Microsoft. Изначально замысел разработчиков видел предназначением технологии COM повышение надежности взаимодействия программных продуктов между собой. Вопреки расхожему мнению, технология COM не является определяющей для структуры программного продукта, языка программирования и прочих деталей реализации.

В то же время, COM представляет собой стандарт, регламентирующий модель программного объекта, и который соответствует требованиям COM–технологии. Таким образом, программный продукт или любой малейший объект, который был создан соответственно стандарту и технологии COM, носит название «COM–объект». Так, технология COM способствует определению механизма взаимодействия COM–объектов друг с другом. Как стандарт, COM можно отнести к так называемым двоичным стандартам, так как он является прилагаемым к оттранслированному в двоичный код программному объекту.

Механизмы воздействия COM–объектов друг на друга обеспечиваются набором предопределенных подпрограмм, которые носят название «интерфейсы». Доступ к интерфейсам может быть обеспечен посредством уникальных идентификаторов интерфейсов GUID (Global Unique Interface Identifyer), а уникальность этих самых идентификаторов обеспечивается операционной системой. Такой механизм напоминает применение указателей при получении доступа к объектам в объектно–ориентированных языках программирования, что, в свою очередь, предоставляет ценную возможность прозрачного управления объектами, т.к. доступ к ним обеспечивается именно через указатели. Несмотря на схожесть, COM–технология в некотором роде масштабирует этот механизм, так как переносит использование указателей (в виде GUID) для доступа к объектам на уровень операционной системы. Благодаря этому COM–объекты могут быть друг для друга прозрачно модифицированы, так как доступ к объектам получается именно посредством идентификаторов GUID.

Помимо вышеуказанного, COM технология включает в себя библиотеку, которая, в свою очередь, содержит в себе определенный набор стандартных интерфейсов, определяющих ядро функциональности COM и небольшой набор API функций, которые были разработаны для создания COM–объектов и управления ими.

Технология COM обладает расширяемой архитектурой, и, благодаря этому, на ней базируются многие другие технологии Microsoft, среди основных – OLE и ActiveX. На сегодняшний день данные технологии представляют собой расширения операционной системы, посредством чего могут определять свои собственные правила функционирования и предлагать собственные библиотеки при создании объектов и при управлении объектами на основе названных технологий.

Применяя технологию COM как основу, разработчики программного обеспечения обретают ценную возможность проектировать новые расширения так, что программные продукты, которые были созданы по правилам COM–технологии, могут успешно функционировать с другими COM–объектами посредством унифицированного механизма взаимодействия, предлагаемым COM.

В технологии COM распространено такое понятие как «класс», обозначающее по смыслу то же, что означает и в объектно–ориентированных средствах разработки. Кроме того, как было указано выше, технология СОМ работает с СОМ–объектами. СОМ–объекты, в свою очередь, схожи со стандартными объектами, входящими в визуальную библиотеку компонентов Delphi. Но, несмотря на сходства, в отличие от объектов VCL Delphi, СОМ–объекты сами включают в себя свойства, методы и интерфейсы. COM–объект в некотором роде представляет собой составляющий элемент COM–класса (COM class). Для того, чтобы отличать COM–классы от классов объектно–ориентированных языков, COM–классы обычно называются соклассами (CoClass).

Помимо вышеперечисленного, технология СОМ используется при описании API и двоичного стандарта для связи объектов различных языков и сред программирования. СОМ также предоставляет модель взаимодействия между компонентами и приложениями.

История развития технологии COM

Как было указано в предыдущем параграфе, наиболее значимой задачей, которая стояла перед разработчиком исследуемой технологии, а именно – перед компанией Microsoft, стояло обеспечение максимально эффективного механизма взаимодействия различных программных продуктов, работающих в одной системе Windows.

Для решения названной задачи в первую очередь были разработаны такие объекты, как буфер обмена, разделяемые файлы и технология динамического обмена данными, сегодня более распространенная под аббревиатурой DDE.

Уже после разработки перечисленных объектов было положено начало и успешное внедрение технологии связывания и внедрения объектов, известной как OLE. Первая версия OLE – OLE 1 по замыслу и реализации обеспечивала создание составных документов. Но, со временем первоначальная версия дала слабину и ее признали недостаточно совершенной, после чего разработки продолжились и появилась вторая версия – OLE 2. Данная версия предоставляла возможность решения вопроса передачи различными программами друг другу собственных функций. И вторая версия технологии была довольно успешна и масштабно применялась вплоть до 1996 года, который ознаменовался появлением в массовом распространении технологии ActiveX. Данная технология включила в себя автоматизацию (OLE–автоматизацию), контейнеры, управляющие элементы, Web–технологию и т. д.

Но еще в 1993 компанией Microsoft была предпринята попытка модернизации технологии OLE, в рамках которой был разработан стандарт COM. К тому времени технология OLE 1.0 уже позволяла создавать так называемые «составные документы«. Наглядным примером составного документа является включение диаграмм Microsoft Excel в документы Microsoft Word.

После выхода в 1996 году технологии ActiveX началась путаница в названиях технологий, которая не исчезла и на сегодняшний день. Все началось с того, что в 1996 году компания Microsoft предприняла попытку переименовать технологию OLE в ActiveX, но это удалось лишь частично. Рассмотрим процесс переименования подробнее – так, технология OLE предоставляла возможность проектировать своеобразные элементы управления OLE, которые являлись повторно используемыми элементами пользовательского интерфейса, построенными согласно положениям стандарта COM. Эти элементы управления OLE были переименованы в элементы управления ActiveX, несмотря на то, что сохранили расширение «.ocx». После этого технология ActiveX стала широко внедряться и распространятся, вследствие чего, как было указано ранее, «выместила» технологию OLE. Наиболее активное распространение технологии ActiveX осуществлялось в сети Интернет благодаря включению элементов технологии в браузер Internet Explorer. Как следствие, наименование OLE осталось только за технологией составных документов и локальных внедряемых объектов. А сетевые OLE–объекты стали называть согласно нововведениям – ActiveX.

Следовательно, несмотря на то, что путаница в некоторой степени сохраняется и до сих пор, речь идет об одних и тех же COM–технологиях. Бывает даже, что в источниках происходит путаница между понятиями OLE и COM. Например, внедряемы OLE–объекты иногда называют COM–объектами, а OLE–контейнеры – COM–контейнерами, и т. п.

Из первой главы становится очевидно, что технология СОМ имеет два явных плюса:

Независимость от языка и среды программирования создания СОМ–объектов. Благодаря этому СОМ–объекты могут быть написаны на самых разнообразных языках программирования;
Возможность использования СОМ–объектов в любой среде программирования под Windows. Сюда можно включить такие среды, как Delphi, Visual C++, C++Builder, Visual Basic, и многие другие.

Но, несмотря на данные существенные преимущества технологии, она обладает и некоторыми отрицательными сторонами, основная из которых – это зависимость от платформы. Иначе говоря, технология СОМ может быть применена исключительно в операционной системе Windows и на платформе Intel.

2 Терминология и состав технологии COM

2.1 Терминология технологии COM

Всякая новая технология приносит с собой новые термины для ее описания. Технология COM не является исключением. В данном параграфе будут рассмотрены наиболее значительные термины, обозначающие составные части исследуемой технологии.

СОМ–объект

СOM–oбъeкт прeдcтaвляeт coбoй двoичный код, который выполняет какую–либо функцию и имeeт oдин или бoлee интерфейс. СОМ–объект содержит методы, которые позволяют прилoжeнию пoльзoвaтьcя СOM–oбъeктoм. Эти методы доступны благодаря СОМ–интерфейсам. Клиенту достаточно знaть нecкoлькo бaзoвых интeрфeйcoв СОМ–объекта, чтобы получить полную информацию о cocтaвe cвoйcтв и мeтoдoв объекта. СОМ–объект может содержать один или нecкoлькo интeрфeйcoв. Для прoгрaммиcтa СОМ–объект работает так же, как и клacc в Object Pascal.

СОМ–интерфейсы

СОМ–интерфейс применяется для объединения методов СOM–oбъeктa. Интeрфeйc пoзвoляeт клиeнту правильно обратиться к СОМ–объекту, а объекту – прaвильнo oтвeтить клиeнту. Названия СОМ–интерфейсов начинаются с буквы I. Клиeнт мoжeт нe знaть, какие интерфейсы имеются у СОМ–объекта. Для тoгo чтoбы пoлучить их список, клиент использует базовый интерфейс lunknown, кoтoрый ecть у кaждoгo СОМ–объекта.

Пользователь СОМ–объекта

Пользователем СОМ–объекта называется приложение или часть приложения, которое использует СОМ–объект и его интерфейсы в своих собственных целях. Как правило, СОМ–объект находится в другом приложении.

СОМ–классы

СОМ со–классы (coclass) – это классы, которые содержат один или более СОМ–интерфейс. Вы можете не обращаться к СОМ–интерфейсу непосредственно, а получать доступ к СОМ–интерфейсу через со–класс. Со–классы идентифицируются при помощи идентификаторов класса (CLSID).

Библиотеки типов

СОМ–объекты часто используют библиотеки типов. Библиотека типов – это специальный файл, который содержит информацию о СОМ–объекте. Данная информация содержит список свойств, методов, интерфейсов, структур и других элементов, которые содержатся в СОМ–объекте. Библиотека типов содержит также информацию о типах данных каждого свойства и Типах данных, возвращаемых методами СОМ–объекта. Файлы библиотеки типов имеют расширение TLB.

Технология DCOM

Технология DCOM (Distributed COM) – это распределенная СОМ–технология. Она применяется для предоставления средств доступа к СОМ–объектам, расположенным на других компьютерах в сети (в том числе и сети Internet). Операционные системы Windows NT 4 и Windows 98 имеют встроенную поддержку DCOM.

Счетчики ссылок

Каждый СОМ–объект имеет счетчик ссылок. Данный счетчик содержит число процессов, которые в текущий момент времени используют СОМ–объект. Под процессом здесь подразумевается любое приложение или DLL, которые используют СОМ–объект, т. е. пользователи СОМ–объекта. Счетчик ссылок на СОМ–объект нужен для того, чтобы высвобождать процессорное время и оперативную память, занимаемую СОМ–объектом, в том случае, когда он не используется.

После создания и обращения к СОМ–объекту счетчик ссылок увеличивается на единицу. Всякий раз, когда новое приложение подключается к СОМ–объекту – счетчик увеличивается. Когда процесс отключается от СОМ–объекта – счетчик уменьшается. При достижении счетчиком нуля память, занимаемая СОМ–объектом, высвобождается.

OLE–объекты

Часть данных, использующаяся совместно несколькими приложениями, называется OLE–объектом. Те приложения, которые могут содержать в себе OLE–объекты, называются OLE–контейнерами. Приложения, имеющие возможность содержать свои данные в OLE–контейнерах, называются OLE–серверами.

Составные документы

Документ, включающий в себя один или несколько OLE–объектов, называется составным документом. Приложение, которое может содержаться внутри документа, называется ActiveX–документом.

Состав СОМ–приложения

При создании СОМ–приложения необходимо обеспечить следующее:

СОМ–интерфейс;
СОМ–сервер;
СОМ–клиент.

Рассмотрим эти три составляющие СОМ–приложения более подробно.

СОМ–интерфейс

Клиенты СОМ связываются с объектами при помощи СОМ–интерфейсов. Интерфейсы – это группы логически или семантически связанных процедур, которые обеспечивают связь между поставщиком услуги (сервером) и его клиентом. На рисунке 1 схематично изображен стандартный СОМ–интерфейс.

Рисунок 3.1

Рис. 1 СОМ–интерфейс

Для примера, каждый СОМ–объект всегда поддерживает основной СОМ–интерфейс lUnknown, который применяется для передачи клиенту сведений о поддерживаемых интерфейсах.

Как уже говорилось выше, СОМ–объект может иметь несколько интерфейсов, каждый из которых обеспечивает какую–либо свою функцию.

Ключевыми аспектами СОМ–интерфейсов являются следующие:

Однажды определенные, интерфейсы не могут быть изменены. Таким образом, вы можете возложить на один интерфейс определенный набор функций. Дополнительную функциональность можно реализовать с помощью дополнительных интерфейсов.
По взаимному соглашению, все имена интерфейсов начинаются с буквы I, например IPersist, IMalloc.
Каждый интерфейс гарантированно имеет свой уникальный идентификатор, который называется глобальный уникальный идентификатор (GUID). Уникальные идентификаторы интерфейсов называют идентификаторами интерфейсов (IIDs). Данные идентификаторы обеспечивают устранение конфликтов имен различных версий приложения или разных приложений.
Интерфейсы не зависят от языка программирования. Вы можете воспользоваться любым языком программирования для реализации СОМ–интерфейса. Язык программирования должен поддерживать структуру указателей, а также иметь возможность вызова функции при помощи указателя явно или неявно.
Интерфейсы не являются самостоятельными объектами, они лишь обеспечивают доступ к объектам. Таким образом, клиенты не могут напрямую обращаться к данным, доступ осуществляется при помощи указателей интерфейсов.
Все интерфейсы всегда являются потомками базового интерфейса Iunknown.

Основной СОМ–интерфейс IUnknown

Базовый интерфейс lunknown достаточно подробно был рассмотрен во второй главе книги. В дополнение ко всему вышесказанному, добавим, что интерфейс lunknown обеспечивает механизм учета ссылок (счетчик ссылок на СОМ–объект). При передаче указателя на интерфейс выполняется метод интерфейса lunknown AddRef. По завершении работы с интерфейсом приложение–клиент вызывает метод Release, который уменьшает счетчик ссылок.

При вызове метода Querylnterface интерфейса Iunknown в метод передается параметр IID, имеющий тип TGUID, т. е. идентификатор интерфейса. Параметр метода out возвращает либо ссылку на запрашиваемый интерфейс, либо значение NH. Результатом вызова метода может быть одно из значений, перечисленных в таблице 1.

Таблица 1

Значения, возвращаемые методом Queryinterface

Значение	Описание
S_OK	Интерфейс поддерживается
E_NOINTERFACE	Интерфейс не поддерживается
E_UNEXPECTED	Неизвестная ошибка

Указатели СОМ–интерфейса

Указатель интерфейса – это 32–битный указатель на экземпляр объекта, который является, в свою очередь, указателем на реализацию каждого метода интерфейса. Реализация методов доступна через массив указателей на эти методы, который называется vtable. Использование массива vtable похоже на механизм поддержки виртуальных функций в Object Pascal. Наглядное представление работы указателей СОМ–интерфейса представлено на рисунке 2.

Рисунок 3.2

Рис. 2 Схема работы указателя СОМ–интерфейса

СОМ–серверы

СОМ–сервер представляет собой приложение или библиотеку, которая предоставляет услуги приложению–клиенту или библиотеке. СОМ–сервер содержит один или более СОМ–объектов, где СОМ–объекты выступают в качестве наборов свойств, методов и интерфейсов.

Клиeнты нe знaют, кaк СОМ–объект выполняет свои действия. СОМ–объект предоставляет cвoи уcлуги при пoмoщи интерфейсов. В дополнение приложению–клиенту не нужно знaть, гдe нaхoдитcя СOM–oбъeкт.

Технология СОМ обеспечивает прозрачный доступ независимо oт мecтoнaхoждeния СOM–oбъeктa. Кoгдa клиент запрашивает услугу от СОМ–объекта, он пeрeдaeт СOM–oбъeкту идeнтификaтoр клacca (CLSID). CLSID – всего лишь GUID, кoтoрый примeняeтcя при oбрaщeнии к СОМ–объекту. После передачи CLSID, СОМ–сервер дoлжeн oбecпeчить тaк нaзывaeмую фабрику класса (см. следующий раздел), которая coздaeт экзeмпляры СOM–oбъeктoв.

В общих чертах, СОМ–сервер должен выполнять следующее:

регистрировать данные в системном реестре Windows для связывания модуля сервера с идентификатором класса (CLSID);
предоставлять фабрику СОМ–класса, создающую экземпляры СОМ–объектов;
обеспечивать механизм, который выгружает из памяти серверы СОМ, которые в текущий момент времени не предоставляют услуг клиентам

Фабрика класса

СОМ–объекты представляют собой экземпляры coclass. Напомним, что Coclass – это класс, поддерживающий один или более интерфейс. СОМ–объекты могут предоставлять только те услуги, которые определены в интерфейсах coclass. Экземпляры Cociass создаются при помощи специального типа объекта, называемого фабрикой класса.

Фабрика класса – это специальный СОМ–объект, который поддерживает интерфейс IclassFactory и отвечает за создание экземпляров того класса, с которым ассоциирована данная фабрика класса.

Локальные и удаленные серверы

С использованием СОМ клиент не должен беспокоиться о том, где располагается объект, он просто делает вызов интерфейса данного объекта. Технология СОМ обеспечивает все необходимые шаги для того, чтобы сделать этот вызов. Шаги могут отличаться, в зависимости от местонахождения объекта. Объект может находиться в том же процессе, где и клиент, в другом процессе на том же компьютере, где расположен клиент, или на другом компьютере в сети. В зависимости от этого применяются разные типы серверов:

внутренний сервер (In–process server);
локальный сервер или сервер вне процесса (Local server, Out–of–process server);
удаленный сервер (Remote server).

Внутренний сервер – это библиотека DLL, которая запущена в одном процессе вместе с клиентом. Например, элемент управления ActiveX, который внедрен на Web–страницу и просматривается при помощи Internet Explorer или Netscape Navigator. В данном случае элемент управления ActiveX загружен на клиентскую машину и находится в том же процессе, что и обозреватель Web. Приложение–клиент связывается с сервером внутри процесса при помощи прямых вызовов СОМ–интерфейса. Локальный сервер – это приложение ЕХЕ, которое запущено в другом процессе, но на одном компьютере вместе с клиентом. Например, лист электронной таблицы Microsoft Excel связан с документом Microsoft Word. При этом два разных приложения работают на одном компьютере. Локальные серверы используют СОМ для соединения с клиентом.

Когда клиент и сервер находятся в различных приложениях, а также, когда они находятся на разных компьютерах в сети, СОМ использует внутренний прокси для реализации процедуры удаленного вызова. Прокси располагается в одном процессе вместе с клиентом, поэтому, с точки зрения клиента, вызов интерфейсов осуществляется так же, как и в случае, когда клиент и сервер находятся внутри одного процесса. Задача прокси заключается в том, чтобы перехватывать вызовы клиента и перенаправлять их туда, где запущен сервер. Механизм, который позволяет клиенту получать доступ к объектам, расположенным в другом адресном пространстве или на другом компьютере, называется маршалинг.

Функции маршалинга:

принимать указатель интерфейса из процесса сервера и делать указатель прокси в процессе клиента доступным;
передавать аргументы вызовов интерфейса таким образом, как будто они произошли от клиента и размещать аргументы в процесс удаленного объекта.

Удаленный сервер – это библиотека DLL или иное приложение, запущенное на другом компьютере. То есть клиент и сервер работают на разных компьютерах в сети. Например, приложение базы данных, написанное с помощью Delphi, соединяется с сервером на другом компьютере в сети. Удаленный сервер использует распределенные СОМ–интерфейсы (DCOM) для связи с клиентом.

Удаленный сервер работает также с помощью прокси. Различие в работе между локальным и удаленным сервером заключается в типе используемой межпроцессной связи. В случае локального сервера – это СОМ, а в случае удаленного сервера – DCOM. Схема взаимодействия клиента и удаленного сервера показана на рисунке 3.

Рисунок 3.6

Рис. 3 Схема взаимодействия клиента с сервером на разных компьютерах

СОМ–клиенты

Очень важным при разработке СОМ–приложений является создание приложений, называемых СОМ–клиентами, которые могут запрашивать интерфейсы объектов, чтобы определить те услуги, которые может предоставить СОМ–объект.

Типичным СОМ–клиентом является диспетчер автоматизации. Диспетчер автоматизации – это часть приложения, которая знает какой тип информации необходим ему от.разных объектов сервера, и она запрашивает данную информацию по мере надобности.

Расширения СОМ

Тeхнoлoгия СOM изнaчaльнo рaзрaбaтывaлacь как ядро для осуществления межпрограммного взаимодействия. Ужe нa этaпe рaзрaбoтки предполагалось расширять возможности технологии при помощи тaк нaзывaeмых рacширeний СOM. СОМ расширяет собственную функциональность, благодаря созданию cпeциaлизирoвaнных нaбoрoв интeрфeйcoв для решения конкретных задач.

Технология ActiveX – этo тeхнoлoгия, кoтoрaя иcпoльзуeт компоненты СОМ, особенно элементы управления. Она былa coздaнa для тoгo, чтобы работа с элементами управления была бoлee эффeктивнoй. Этo ocoбeннo необходимо при работе с приложениями Internet/Intranet, в кoтoрых элeмeнты упрaвлeния должны быть загружены на компьютер клиента, прeждe чeм oни будут использоваться.

2.2 Состав объектов COM

В COM–технологии различаются следующие «строительные блоки», используемые для создания объектов:

Interface (COM–интерфейс) – множество прототипов функций (методов), чисто определенных. Термин «чисто определенный метод» или «абстрактный метод» исходит теории объектно–ориентированного анализа, и означает, что в определении класса отсутствует реализация метода, а присутствует только его определение. От такого класса нельзя создавать объекты. Его предназначение – описать фундаментальные общности для всех производных классов;
COM–объект – объект класса CoClass, который содержит реализацию COM интерфейса;
COM сервер или ActiveX сервер – модуль, такой как EXE, DLL или OCX, который содержит машинный код COM или ActiveX объектов;
Фабрика классов – объект, который может создавать COM–объекты из CoClass;
Библиотека типов – файл, содержащий информацию о типах данных, которые использует COM/ActiveX сервер.

Интерфейсы

Интерфейсы являются основными строительными единицами COM. Они объединяются на семантически связанные группы подпрограмм, через которые COM–объекты осуществляют взаимодействие:

COM определяет следующие ключевые аспекты, связанные с COM–интерфейсами:

Методы интерфейса абстрактны (чисто определены). Интерфейс представляет собой набор прототипов методов, чье назначение состоит только в определении интерфейса. Определения прототипов методов включает в себя определения числа и типов передаваемых значений, возвращаемого значения, а также ожидаемого поведения объекта. Как методы реализованы, в определение интерфейса не включается. Таким образом, реализуется полиморфизм интерфейса, т.к. каждый потомок, наследующий интерфейс, может включать собственную реализацию метода;
Интерфейс подчиняется двоичному стандарту. Так как все методы интерфейса абстрактны, интерфейс представлен как указатель на vtable. Каждая запись в vtable представляет собой ссылку на соответствующий метод класса, который содержит реализацию интерфейса. Определение интерфейса как указателя устанавливает протокол для доступа к COM–объекту, который является двоичным. Таким образом, получение доступа к реализации метода интерфейса объекта представляет собой через последовательную процедуру получения указателей:
С GUID система связывает указатель на интерфейс. Указатель на интерфейс, в свою очередь является указателем на vtable, через которую обеспечивается указатель на таблицу указателей на код с реализациями методов. Множество объектов одного класса в системе используют одну общую vtable, и для каждого такого объекта создается структура с частными данными, необходимыми для корректного вызова функций.
Интерфейс включает в себя определенную функциональность. Методы интерфейса семантически связаны по функциональности и назначению. Согласно этому, методы интерфейса обычно именуется согласно своему назначению, и имя предваряется заглавной I. Для примера, метод IMalloc предназначен для размещения и освобождения памяти;
Интерфейс имеет уникальный идентификатор. Интерфейсы различаются посредством использования глобальных идентификаторов GUID, которые используются для ссылки на идентификаторы конкретных интерфейсов IID. Каждый интерфейс имеет свой IID, и при регистрации в системе получает связанный с ним GUID. Использование GUID более совершенно, чем использование символьных имен, т.к. гарантирует отсутствие конфликтов имен при обновлении программных продуктов (выхода новых версий) и при использовании программного обеспечения от различных производителей;
Интерфейс не может измениться после регистрации в системе. Каждый интерфейс предназначен для выполнения определенной задачи, и определяет, какие данные поступают на обработку и какие данные выводятся. Таким образом, после того, как интерфейс опубликован в системе, и стал доступен для использования, он не должен меняться. Любое изменение в семантике интерфейса ведет к необходимости появления нового интерфейса. Однако существует возможность безопасной реализации многоинтерфейсных объектов посредством использования для доступа к разным версиям интерфейса разные IID.
Интерфейсы наследуют функциональность от одного базового предка. Все интерфейсы прямо или косвенно являются потомками интерфейса IUnknown. Этот интерфейс обеспечивает базовую функциональность интерфейса, которая включает в себя динамический опрос объекта (dynamic quering) и управление жизненным циклом объекта (lifetime managment). Эта функциональность обеспечивается тремя методами интерфейса IUnknown: QueryInterface, AddRef и Release. Каждый класс, который реализует интерфейс, должен реализовать эти три метода, наряду с методами, унаследованные от другого интерфейса, и своими собственными методами.

Свойства COM–объектов

COM–объект – это объект CoClass, который является классом, реализующим один или более интерфейсов. COM–объект предоставляет функции, которые доступны через указатель на один из его интерфейсов. Всвязи с этим, COM–объект обладает следующими особенностями:

COM–объект защищен от прямого изменения внешними программами в своих данных, т.к. доступ к COM–объекту возможен только через указатель на интерфейс;
COM–объект может быть использован приложениями, реализованными практически на любых современных средствах разработки приложений (алгоритмических языках), с любой внутренней организацией приложения, главное, чтобы средство разработки позволяло работать с указателями на структуры, на массивы и на функции.

COM–серверы

Объект COM–класса должен иметь в своем составе фабрику классов, и идентификатор класса CLSID, так чтобы COM–объект мог быть создан на основе существующего модуля.

COM–сервер – это приложение, или библиотека, предоставляющее определенный набор сервисных функций для клиентских приложений или библиотек.

COM–сервер состоит из COM–объектов. Например, COM–сервер, который включает в себя код элементов управления ActiveX – является ActiveX–сервером. Для разработчика имеется большое число библиотек, которые можно использовать для создания COM–объектов. В качестве примера можно привести библиотеку Microsoft Active Template Library, предоставляющую набор шаблонов, на основе которых можно создавать свои собственные программные продукты, построенные по COM–технологии. Например, шаблон для COM–сервера включает в себя код для основных функций, которые должен обеспечивать COM–сервер: регистрация сервера в системе, загрузка/выгрузка сервера, создание объектов, управления фабриками классов, обеспечение выдачи информации о сервере, включая: тип сервера, help–файл, имя сервера, библиотека типов и т.д.

Клиенты не должны знать, каким образом сервер выполняет свои функции, и клиенты не должны знать, где сервер находится – все взаимодействие осуществляется через указатели на интерфейс сервера. COM–сервер, как было указано в предыдущем параграфе, может быть следующих типов:

внутренний сервер – программный DLL модуль, работающий в рабочем пространстве памяти клиентского приложения:
локальный сервер – программный EXE модуль, работающий в отдельном адресном пространстве;
удаленный сервер – программный EXE модуль, работающий на удаленной машине.

Механизм маршаллинга

Разница между внутренним и удаленным серверами в том, какой тип межпроцессной связи используется. В данном случае существует необходимость использования посредников, которые обеспечивают передачу параметров и вызов функций. Такой механизм называется маршаллингом. Т.к. в случае, когда клиент и сервер находятся в разных адресных пространствах, доступ к ресурсам не может быть осуществлен непосредственно через указатели. Поэтому посредники со стороны клиента осуществляют упаковку аргументов в пакеты маршаллинга, и обеспечивают удаленный вызов процедур. Посредник со стороны сервера реализуют распаковку параметров, и помещение их в стек. Далее осуществляется вызов непосредственно реализации метода. По сути, сервер создает клиентский вызов процедуры в своем собственном адресном пространстве.

Посредники используют COM–средства, для осуществления взаимодействия в разных процессах. Для взаимодействия объектов, находящихся на разных машинах, используются средства расширения COM – распределенная COM. COM предлагает стандартный механизм маршаллинга – интерфейс диспетчеризации.

Фабрики классов

Фабрики или производители классов – специальный тип COM–объектов, используемый для создания и регистрации COM–объектов. Производители классов реализуют стандартный механизм создания объектов COM–классов. Классы без идентификаторов класса (CLSID) и фабрики классов могут быть созданы посредством вызова конструктора. Использование фабрики классов для создания объектов означает, что для клиентского приложения, которому необходимо создать объект класса, не нужно знать об этом классе ничего, кроме его идентификатора CLSID. Фабрика классов возьмет вызов конструктора на себя, включая передачу аргументов в конструктор и остальные специфичные действия. Класс фабрики классов может быть объединен со многими COM–классами, для каждого из которых могут создаваться объекты. При создании же объекта фабрики классов, в конструктор передается идентификатор CLSID класса, для создания объектов которого предназначается фабрика. Этот идентификатор определяет, объекты какого класса могут быть созданы с помощью данной фабрики классов. Таким образом, каждый экземпляр фабрики классов в системе может быть использован для создания объектов только одного определенного класса.

Создание объекта класса производится посредством следующих действий:

вызова глобальной API–функции CoGetClass, которая ищет в системном реестре зарегистрированный класс с данным CLSID, определяет путь к серверу, загружает сервер и выдает указатель на интерфейс производителя классов;
Указатель на IСlassFactory может быть использован для вызова методов производителя классов, например: CoCreateInstance (создание объекта).

Альтернативой рассмотренному методу может служить вызов глобальной API–функции CoCreateInstance, которая выполняет перечисленный выше действия и создает объект класса с идентификатором CLSID, но таким образом можно создать только один объект данного класса, т.к. функция не возвращает указатель на интерфейс производителя классов.

Библиотеки типов

Библиотека типов предоставляет информацию об используемых типах объектов и интерфейсах, которые предоставляются ActiveX–серевером. Библиотека типов по смыслу аналогична, например, заголовочному файлу (header) для разработок на языке C и любому другому модулю, содержащему информацию об используемых типах данных и объектах. Большинство информации подобного рода может быть записано в библиотеку типов. Получить информацию из библиотеки типов можно путем опроса запущенного объекта или же посредством загрузки непосредственно библиотеки типов. После создания библиотеки типов, к ней обеспечивается доступ через специальный тип интерфейсов: ITypeLib, ITypeInfo и ITypeComp. Интерфейс ITypeLib обеспечивает доступ к информации о типах в библиотеке типов, а также к описаниям конкретных объектов, которые, в свою очередь, могут быть получены через интерфейс ITypeInfo.

Библиотека типов содержит информацию о том, какой интерфейс, в каком COM–объекте содержится, количество и тип методов интерфейсов и их параметров. Эти описания включают в себя уникальные идентификаторы классов (CLSID) и их интерфейсов (IID), через которые осуществляется корректный доступ к объектам. В библиотеке типов также может содержаться следующая информация:

Описания пользовательских типов данных, связанных с пользовательскими интерфейсами;
Функции, которые экспортируются ActiveX–сервером, но которые не являются интерфейсными методами;
Информация об нумерованных типах данных (символьных константах);
Ссылки на описания типов в других библиотеках типов.

Использование библиотеки типов очень важно для объектов, которые предназначены для распространения и последующего использования многими пользователями. Также существует еще ряд причин использования библиотек типов:

Объекты, которые используют непосредственную привязку к vtable, должны быть описаны в библиотеке типов, т.к. ссылки в vtable формируются во время компиляции;
Объекты, созданные из классов, которые поддерживают интерфейс IProvideClassInfo, должны иметь библиотеку типов. Объекты, имеющие в своем составе данные интерфейс, являются типизированными COM–объектами, т.к. предоставляют информацию об используемых типах (из библиотеки типов);
Элементы управления ActiveX должны иметь библиотеку типов, которая содержится непосредственно в DLL или OCX файле, содержащем код ActiveX–сервера;
Приложения, которые являются Automation–серверами, должны иметь библиотеку типов, для более удобно связывания с клиентами;
Использование библиотеки типов в любом случае облегчает работу с внешними приложениями, которые могут узнать об используемых типах данных, и т.о. исключается использование более громоздкого метода передачи параметров в системе через универсальный механизм

Во второй главе работы подробно рассмотрена терминология, используемая в технологии COM, а также входящие в ее структуру объекты. Также рассмотрены основные свойства этих объектов, которые оказывают значительное влияние на применение самой технологии

ЗАКЛЮЧЕНИЕ

В ходе реализации исследования была достигнута цель работы – изучена технология COM.

Для достижения данной цели были выполнены следующие задачи:

Изучено понятие технологии COM, определено, что технология COM представляет собой объектно–ориентированную программную спецификацию;
Рассмотрена история развития технологии COM, представленной фирмой Microsoft с целью обеспечения эффективного взаимодействия между различными программами, работающими в Windows;
Разобрана терминология технологии COM, которая включает в себя такие понятия как СОМ–объект, СОМ–интерфейс, Пользователь СОМ–объекта и мн. др.;
Проанализирован состав объектов технологии COM. В данном параграфе выделены основные составляющие построения объектов, среди них – интерфейсы, объекты, серверы, библиотеки и др.

Технология COM – достаточно перспективная и многообещающая технология. Сейчас она находится в стадии активного развития, и уже сегодня с ее помощью можно разрабатывать функциональные и удобные программные продукты, вариативные по масштабу и назначению. Важно также, что данная технология ориентирована на пользователя и стремится к снижению затрат.

При этом есть у технологии и недостатки – она является замкнутой, действуя только в рамках Windows, а также очень сложной как в концептуальном, так и в практическом смысле.

СПИСОК ЛИТЕРАТУРЫ

Анашкина, Н. В. Технологии и методы программирования: Учебное пособие / Н. В. Анашкина. – М.: Академия, 2013. – 384 c.
Гаврилов, М. В. Информатика и информационные технологии: Учебник / М. В. Гаврилов, В. А. Климов. – Люберцы: Юрайт, 2016. – 383 c.
Гагарина, Л. Г. Информационные технологии: Учебное пособие / Л. Г. Гагарина, Я. О. Теплова, Е. Л. Румянцева и др. – М.: Форум, 2018. – 144 c.
Гергель, В. П. Современные языки и технологии паралелльного программирования: Учебник / В. П. Гергель. – М.: МГУ, 2012. – 408 c.
Гохберг, Г. С. Информационные технологии: Учебник / Г. С. Гохберг. – М.: Academia, 2018. – 416 c.
Дарков, А. В. Информационные технологии: теоретические основы: Учебное пособие / А. В. Дарков, Н.Н. Шапошников. – СПб.: Лань, 2016. – 448 c
Дейтел, Х. М. Технологии программирования на Java2. Распределенные приложения / Х. М. Дейтел. – М.: Бином, 2015. – 464 c.
Камаев, В. А. Технологии программирования / В. А. Камаев, В. В. Костерин. – М.: Высшая школа, 2016. – 454 c.
Кулямин, В. В. Технологии программирования. Компонентный подход / В. В. Кулямин. – М.: Интуит, 2014. – 463 c.
Синаторов, С. В. Информационные технологии / С. В. Синаторов. – М.: КноРус, 2016. – 200 c.
Советов, Б. Я. Информационные технологии: учебник для прикладного бакалавриата / Б. Я. Советов, В. В. Цехановский. – Люберцы: Юрайт, 2016. – 263 c.
Схиртладзе, А. Г. Информационные технологии: Учебник / А. Г. Схиртладзе. – М.: Академия, 2015. – 352 c.
Федотова, Е. Л. Информационные технологии в проф. деят.: Учебное пособие / Е. Л. Федотова. – М.: Форум, 2016. – 32 c.
Федотова, Е. Л. Информационные технологии и системы: Уч.пос / Е. Л. Федотова. – М.: Форум, 2018. – 149 c.
Черников, Б. В. Информационные технологии управления: Учебник / Б. В. Черников. – М.: Форум, 2017. – 352 c.