2. Обзор COM-технологии…………………………………………………………………………………………………………………………… 3
2.1. Состав COM-объекта…………………………………………………………………………………………………………………………………… 4
2.2. Интерфейсы……………………………………………………………………………………………………………………………………………………. 4
2.3. Свойства COM-объектов…………………………………………………………………………………………………………………………….. 6
2.4. COM-серверы………………………………………………………………………………………………………………………………………………….. 7
2.5. Механизм маршаллинга……………………………………………………………………………………………………………………………. 7
2.6. Фабрики классов…………………………………………………………………………………………………………………………………………… 8
Обзор технологий, используемых в цифровых произведениях искусства (2015-2019г.)
... статей, которые лишь вкратце обозревают это направление. Целью данной курсовой работы является обзор и анализ технологий, использовавшихся в цифровых произведениях искусства в период с 2015 по 2019 год. К ...
2.7. Библиотеки типов………………………………………………………………………………………………………………………………………… 9
2.8. Диспетчерский интерфейс……………………………………………………………………………………………………………………….. 10
2.9. Привязка идентификаторов…………………………………………………………………………………………………………………….. 11
2.10. Пользовательские интерфейсы……………………………………………………………………………………………………………….. 11
2.11. Двойные интерфейсы………………………………………………………………………………………………………………………………… 12
3. Расширения COM………………………………………………………………………………………………………………………………………. 12
3.1. OLE/Active document………………………………………………………………………………………………………………………………… 13
3.2. Automation………………………………………………………………………………………………………………………………………………….. 13
3.3. ActiveX control…………………………………………………………………………………………………………………………………………. 14
Интеграция информационных технологий в системе государственного управления
... максимального применения персоналом управления информационных технологий. Развитие экономики информационного общества основано на широком распространении и интеграции информационных технологий обучения в процессах ... взаимодействия управленческих систем в значительной степени зависит от научно-технического уровня, интенсивности и степени использования и совместимости информационных технологий. ...
3.4. Межпроцессные визуальные объекты………………………………………………………………………………………………….. 14
3.5. OPC…………………………………………………………………………………………………………………………………………………………………. 14
4. Средства разработки COM-приложений…………………………………………………………………………………….. 15
В данной работе кратко рассмотрена технология COM, которая в настоящее время широко применяется при разработке программного обеспечения, интеграции программных продуктов в единые информационные системы. Целью разработки COM-технологии являлось стремление к интеграции программного обеспечения через стандартизацию механизмов взаимодействия программных модулей между собой. На основе данной технологии, которая является масштабируемой, разработано огромное число технологий, которые стали стандартами в разнообразных сферах применения информационных технологий – от управления технологическими процессами в промышленности до домашних персональных компьютеров. Массовое применение COM отчасти связано с мощью ее разработчика, фирмы Microsoft. С этим приходится считаться, и каждый программный продукт, выпущенный под платформу Windows, для достижения коммерческого успеха обязан соответствовать инновациям Microsoft.
Технология COM (Component Object Technology) – объектно-ориентированная программная спецификация, предложенная Microsoft. 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-класса
В COM-технологии различаются следующие строительные блоки, используемые для создания объектов:
Interface
COM object
COM/ActiveX server
Class factory
Type library
2.2.
Интерфейсы являются основными строительными единицами COM. Они объединяются на семантически связанные группы подпрограмм, через которые COM-объекты осуществляют взаимодействие:
 |
COM определяет следующие ключевые аспекты, связанные с COM-интерфейсами:
Методы интерфейса абстрактны (чисто определены)., Интерфейс подчиняется двоичному стандарту.
 |
С GUID система связывает указатель на интерфейс. Указатель на интерфейс, в свою очередь является указателем на vtable, через которую обеспечивается указатель на таблицу указателей на код с реализациями методов. Множество объектов одного класса в системе используют одну общую vtable, и для каждого такого объекта создается структура с частными данными, необходимыми для корректного вызова функций.
Интерфейс включает в себя определенную функциональность., Интерфейс имеет уникальный идентификатор., Интерфейс не может измениться после регистрации в системе., Интерфейсы наследуют функциональность от одного базового предка.
QueryInetrface
- AddRef и Release находятся на втором и третьем местах в vtable. Это простые счетные функции, которые предоставляются для управления временем жизни объекта. Пока внутренний счетчик объекта, отражающий количества раз вызова AddRef и Release больше нуля (вызов AddRef может увеличивать его значение), объект остается в памяти. Как только значение счетчика достигает нуля (вызов Release может уменьшать его значение), реализация интерфейса может безопасно удалить все зависимые нижележащие объекты. Это функция носит название lifetime managment;
2.3.
COM-объект – это объект CoClass, который является классом, реализующим один или более интерфейсов. COM-объект предоставляет функции, которые доступны через указатель на один из его интерфейсов. Всвязи с этим, COM-объект обладает следующими особенностями:
- COM-объект защищен от прямого изменения внешними программами в своих данных, т.к. доступ к COM-объекту возможен только через указатель на интерфейс;
— COM-объект может быть использован приложениями, реализованными практически на любых современных средствах разработки приложений (алгоритмических языках), с любой внутренней организацией приложения, главное, чтобы средство разработки позволяло работать с указателями на структуры, на массивы и на функции.
Объект COM-класса должен иметь в своем составе фабрику классов, и идентификатор класса CLSID (Class Identifier), так чтобы COM-объект мог быть создан на основе существующего модуля.
COM-сервер – это приложение, или библиотека, предоставляющее определенный набор сервисных функций для клиентских приложений или библиотек.
COM-сервер состоит из COM-объектов. Например, COM-сервер, который включает в себя код элементов управления ActiveX (ActiveX control)– является ActiveX-сервером. Для разработчика имеется большое число библиотек, которые можно использовать для создания COM-объектов. В качестве примера можно привести библиотеку Microsoft Active Template Library, предоставляющую набор шаблонов, на основе которых можно создавать свои собственные программные продукты, построенные по COM-технологии. Например, шаблон для COM-сервера включает в себя код для основных функций, которые должен обеспечивать COM-сервер: регистрация сервера в системе, загрузка/выгрузка сервера, создание объектов, управления фабриками классов, обеспечение выдачи информации о сервере, включая: тип сервера, help-файл, имя сервера, библиотека типов и т.д.
Клиенты не должны знать, каким образом сервер выполняет свои функции, и клиенты не должны знать, где сервер находится – все взаимодействие осуществляется через указатели на интерфейс сервера. COM-сервер может быть следующих типов:
In-process server
 |
Local server
Remote server
2.5.
маршаллингом
 |
Посредники используют COM-средства, для осуществления взаимодействия в разных процессах. Для взаимодействия объектов, находящихся на разных машинах, используются средства расширения COM – распределенная COM (Distributed COM или DCOM).
COM предлагает стандартный механизм маршаллинга – интерфейс диспетчеризации (Dispatch Interface).
Фабрики или производители классов (class factories) — специальный тип COM-объектов, используемый для создания и регистрации COM-объектов. Производители классов реализуют стандартный механизм создания объектов COM-классов. Классы без идентификаторов класса (CLSID) и фабрики классов могут быть созданы посредством вызова конструктора. Использование фабрики классов для создания объектов означает, что для клиентского приложения, которому необходимо создать объект класса, не нужно знать об этом классе ничего, кроме его идентификатора CLSID. Фабрика классов возьмет вызов конструктора на себя, включая передачу аргументов в конструктор и остальные специфичные действия. Класс фабрики классов может быть объединен со многими COM-классами, для каждого из которых могут создаваться объекты. При создании же объекта фабрики классов, в конструктор передается идентификатор CLSID класса, для создания объектов которого предназначается фабрика. Этот идентификатор определяет, объекты какого класса могут быть созданы с помощью данной фабрики классов. Таким образом, каждый экземпляр фабрики классов в системе может быть использован для создания объектов только одного определенного класса.
Создание объекта класса производится посредством следующих действий:
- вызова глобальной API-функции CoGetClass, которая ищет в системном реестре зарегистрированный класс с данным CLSID, определяет путь к серверу, загружает сервер и выдает указатель на интерфейс производителя классов (обычно IClassFactory);
- Указатель на IСlassFactory может быть использован для вызова методов производителя классов, например: CoCreateInstance (создание объекта);
— Альтернативой рассмотренному методу может служить вызов глобальной API-функции CoCreateInstance, которая выполняет перечисленный выше действия и создает объект класса с идентификатором CLSID, но таким образом можно создать только один объект данного класса, т.к. функция не возвращает указатель на интерфейс производителя классов.
Библиотека типов (type library) предоставляет информацию об используемых типах объектов и интерфейсах, которые предоставляются ActiveX-серевером. Библиотека типов по смыслу аналогична, например, заголовочному файлу (header) для разработок на языке C и любому другому модулю, содержащему информацию об используемых типах данных и объектах. Большинство информации подобного рода может быть записано в библиотеку типов. Получить информацию из библиотеки типов можно путем опроса запущенного объекта или же посредством загрузки непосредственно библиотеки типов. После создания библиотеки типов, к ней обеспечивается доступ через специальный тип интерфейсов: ITypeLib, ITypeInfo и ITypeComp. Интерфейс ITypeLib обеспечивает доступ к информации о типах в библиотеке типов, а также к описаниям конкретных объектов, которые, в свою очередь, могут быть получены через интерфейс ITypeInfo.
Библиотека типов содержит информацию о том, какой интерфейс, в каком COM-объекте содержится, количество и тип методов интерфейсов и их параметров. Эти описания включают в себя уникальные идентификаторы классов (CLSID) и их интерфейсов (IID), через которые осуществляется корректный доступ к объектам. В библиотеке типов также может содержаться следующая информация:
- Описания пользовательских типов данных, связанных с пользовательскими интерфейсами;
- Функции, которые экспортируются ActiveX-сервером, но которые не являются интерфейсными методами;
- Информация об энумерованных типах данных (символьных константах);
- Ссылки на описания типов в других библиотеках типов.
Использование библиотеки типов очень важно для объектов, которые предназначены для распространения и последующего использования многими пользователями. Также существует еще ряд причин использования библиотек типов:
- Объекты, которые используют непосредственную привязку к vtable, должны быть описаны в библиотеке типов, т.к. ссылки в vtable формируются во время компиляции;
- Объекты, созданные из классов, которые поддерживают интерфейс IProvideClassInfo, должны иметь библиотеку типов.
Объекты, имеющие в своем составе данные интерфейс, являются типизированными COM-объектами, т.к. предоставляют информацию об используемых типах (из библиотеки типов);
- Элементы управления ActiveX должны иметь библиотеку типов, которая содержится непосредственно в DLL или OCX файле, содержащем код ActiveX-сервера;
- Приложения, которые являются Automation-серверами, должны иметь библиотеку типов, для более удобно связывания с клиентами;
- Использование библиотеки типов в любом случае облегчает работу с внешними приложениями, которые могут узнать об используемых типах данных, и т.о. исключается использование более громоздкого метода передачи параметров в системе через универсальный механизм;
2.8.
позднего связывания
Основным недостатком диспетчерского интерфейса является ограничение на типы данных, которые можно использовать при передаче параметров. Это следует из необходимости упаковки и распаковки параметров при осуществлении маршаллинга. Допускается использовать 13 стандартных типов данных. На пользовательские типы данных устанавливаются достаточно строгие ограничения. Если требования задачи не укладываются в эти ограничения, разработчик имеет возможность реализовать маршаллиг, путем написания своего proxy/stub кода. Еще одним недостаток проявляется в том, что при компиляции программы не выполняется проверка соответствия типов вызываемых функций, т.к. связывание диспетчерских интерфейсов осуществляется на этапе выполнения программы, и таким образом, не контролируется вызов Invoke с неверным набором аргументов, что вызывает ошибку выполнения.
2.9.
раннего связывания
Основным недостатком является отсутствие возможности проверки имени ресурса, если он вдруг изменился. В клиентском объекте все вызовы будут осуществляться через однажды связанные на этапе компиляции интерфейсные идентификаторы.
2.10.
Vtable-интерфейсы
В случае если сервер имеет библиотеку типов и реализует диспетчерский интерфейс, то клиент может получить информацию из библиотеки типов, без осуществления вызова функций через привязки. Достаточно получить идентификаторы dispID диспетчерского интерфейса, и осуществить привязку непосредственно к vtable. Таким образом, можно осуществить более быстрый доступ к ресурсам объекта, осуществляя прямой вызов через ссылки в vtable, не используя диспетчерский интерфейс. Код непосредственной привязки к vtable может быть автоматически сгенерирован на этапе компиляции. Разумеется, такой метод вызова функций гораздо быстрее, чем методы привязки идентификаторов (т.к. вызов осуществляется через Invoke, что вызывает процедуры упаковки/распаковки параметров) и позднего связывания (т.к. осуществляется полный цикл работы с диспетчерским интерфейсом).
Несмотря на то, что COM предоставляет возможность обращения к ресурсам серверов используя vtable-интерфейсы, что повышает скорость взаимодействия клиента и сервера, некоторые клиенты могут быть разработаны таким образом, что обращаются к объектам только через интерфейс диспетчеризации. Это могут быть, например, интерпретируемые макроязыки, которые включают в себя средства для работы с COM-объектами, и в которых не реализованы возможности для привязки к vtable. Таким образом, COM предлагает то, что называется двойственным, или двойным интерфейсом (dual interface).
Двойные интерфейсы предлагают два пути для доступа к ресурсам сервера: через диспетчерский интерфейс и через vtable-интерфейс. Двойной интерфейс определяется как наследник IDispatch.
Преимущества использования двойных интерфейсов:
- Двойные интерфейсы предлагают возможность получения указателей на ресурсы сервера по их именам при компиляции объекта, таким образом, позволяя создавать клиентов, с привязкой к vtable на этапе компиляции;
- Двойные интерфейсы позволяют клиентам осуществить прямой доступ к ресурсам сервера через vtable-интерфейсы, что увеличивает скорость взаимодействия объектов;
- Двойные интерфейсы имею преимущества проверки соответствия типов на этапе компиляции (преимущества раннего связывания);
- Клиенты, не работающие напрямую с vtable-интерфейсами имеют возможность взаимодействовать с объектами через диспетчерские интерфейсы;
— Двойные интерфейсы предоставляют возможность маршаллинга для обоих своих частей – для диспетчерского интерфейса и vtable-интерфейса. При обращении к серверу, находящемуся в другом адресном пространстве осуществляется автомаршаллинг при обращении через любую часть интерфейса.
Существует набор ограничений по использованию двойных интерфейсов. Они в основном связаны с типами данных, т.к. двойной интерфейс является наследником интерфейса IDispatch. Однако, существует путь для частичного избежания таких ограничений, определяя не двойной интерфейс, а два отдельных, один из которых – диспетчерский, другой — пользовательский (без ограничений на тип данных).
Таким образом, можно осуществить доступ к ресурсам сервера как через диспетчерский, так и через vtabl-интерфейс.
3.
Одним из расширением технологии COM является OLE, представляющая собой библиотеку собственных интерфейсов, типов данных и подпрограмм, предназначенных для обеспечения функциональности OLE. Каждая функция именуется с префиксом IOle.
Еще одним расширением COM является не так давно созданная технология ActiveX. Основные ответвления ActiveX носят названия ActiveX Documents (документы ActiveX) и элементы управления ActiveX (ActiveX controls).
ActiveX «моложе» OLE, и была разработана как COM-расширение, оптимизированное по скорости и по размеру. Однако, OLE с появлением ActiveX уже была неплохо развита, и сейчас различия между этими двумя технологиями начинают уменьшаться, а их функциональности все больше перекрываться.
Документы OLE (OLE/Active documents) – один из набора сервисов, которые предлагает технология OLE. Объекты OLE documents имеют все свойства OLE по связи и внедрению данных, визуального редактирования, поддержки drag-and-drop, активизации по месту (in-place-activation).
Используя OLE document можно определить любой количество интерфейсов, через которые обеспечивается стандартное поведения объекта, такое как визуальное редактирования и drag-and-drop. Посредством реализации этих интерфейсов, объекты OLE documents могут быть свободно объединены в единую систему взаимодействующих объектов с разными форматами данных, таких, как звуковые фрагменты, текстовые документы и растровые изображения.
Объект OLE documents может быть реализован как внутренний и внешний COM-сервер. Такой объект состоит из двух частей: визуальной (presentation data), предназначенной для отображения визуальной части объекта и из внутренней части (native data), используемой для редактирования объекта. Объекты OLE documents могут быть контейнерами документов (document container) и серверами документов (document server).
Сервер документов обеспечивает функциональность объектов OLE documents. В среде контейнера документов может быть активизирован любой сервер документов.
Технология автоматизации (automation) предлагает возможность программного управления одного приложения другим. В данной технологии различаются две составные компоненты:
- Клиентская часть, называемая контроллером автоматизации (automation controller);
- Серверная часть, которая носит название объекта автоматизации (automation object) – объект, которым управляет клиент.
Объекты автоматизации могут быть реализованы как внутренние, внешние и удаленные сервера. Технология автоматизации характеризуется двумя положениями:
- Объекты автоматизации должны иметь возможность определить множество свойств и команд через описания типов, т.е. они должны получить информацию об интерфейсах объекта, с которым идет взаимодействие, о методах интерфейсов и о типах аргументов. Такая информация предоставляется через библиотеки типов. Однако, использование библиотеки типов необязательно при использовании интерфейса диспетчеризации, т.к. с помощью последнего осуществляется привязка интерфейсов на этапе выполнения программы (недостатком такого подхода является отсутствие проверки соответствия типов на этапе компиляции);
- Объекты автоматизации должны предоставлять свои методы общедоступными для внешнего использования, так, чтобы ими могли пользоваться внешние приложения.
Для этого, в объектах автоматизации должен быть реализован интерфейс диспетчеризации.
Основным достоинством технологии автоматизации является возможность создания объектов, работающих в любом процессном пространстве. Таким образом, вместо создания невизуального OLE-объекта предпочтительнее использовать Automation. Еще одно достоинство технологии Automation заключается в механизме взаимодействия приложений, реализуемый интерфейсом диспетчеризации, который автоматизирует процесс маршаллинга. Однако, этот механизм ограничивает набор типов данных, которые можно использовать при автомаршаллинге.
Технология ActiveX расширяет COM и OLE новыми функциями, специфичными для элементов управления ActiveX (ActiveX control).
ActiveX control – визуальные объекты управления, реализуемые как внутренние COM-сервера, и которые включаются в OLE-контейнеры, и работают в их среде. Элементы управления ActiveX не являются законченными приложениями, но представляют собой объект, который решает некоторую частную задачу и может быть встроен в различные приложения. Основными характерными особенностями ActiveX controls является возможность обработки событий, привязки к источникам данных и поддержка лицензирования.
Элементы управления ActiveX особенно широко используются в разработке Web-приложений, где ActiveX controls используются как интерактивные объекты на Web-страницах. По существу, ActiveX становится стандартом, специально направленным на интерактивную часть World Wide Web, например, для просмотра в Web-браузере не гипертекстовых документов, доступ к базам данных и т.д.
Объекты автоматизации, документы OLE и элементы управления ActiveX являются общими используемыми объектами для всех приложений. Менее общее использование COM-объектов присутствует в межпроцессных объектах, которые визуально отображаются и используются в многопроцессных приложениях. Эти типы объектов гораздо сложнее создавать, т.к. протокол взаимодействия, применяемый в управлении визуальными объектами в мнопроцессных приложениях стандартизован только для визуальных объектов, которые используют интерфейс OLE document. Следовательно, необходимо создать пользовательские интерфейсы объектов и их реализации, которые будут управлять маршаллингом интерфейсов. Также, это можно реализовать через:
- Использование двойственного интерфейса IDispatch, который поддерживает автомаршаллинг;
- Написание собственного класса, реализующего маршаллинг.
3.5.
Спецификация одной из модификаций OLE, которая называется OPC (OLE for Process Control) была разработана группой фирм, занимающихся разработкой программного обеспечения для систем промышленной автоматизации. Данная технология включает в себя набор стандартных соглашений, применяемых в системах промышленной автоматизации. В настоящее время особое развитие получило использование OPC как связующей механизм взаимодействия отдельных компонент SCADA-систем, а также систем различных производителей друг с другом, обеспечивая эффективную по времени и стоимости интеграцию компонент программного обеспечения. Связь по OPC осуществляется прозрачно для разработчика, используя все средства, которые предоставляет COM, что позволяет не внедряясь в технику связи организовывать взаимодействующие в единых информационных системах программные компоненты.
Основным инструментом разработки COM-приложений, что закономерно, являются продукты Microsoft, относящиеся к семейству визуальных средств программирования Visual Studio. Все компоненты этого семейства предлагают средства работы по технологии COM, и направлены в основном именно на разработку продуктов в рамках этой технологии.
Основной фигурой для рассмотрения в данном разделе будет семейство средств разработки приложений фирмы Inrise Inc., относящиеся к классу RAD (Rapid Application Development) – средства быстрой разработки приложений. Это продукты Borland С++ Builder и Borland Delphi, которые начиная с версии 3 поддерживают разработку COM-приложений.
С++ Builder и Delphi (далее, просто C++ Builder, т.к. оба этих продукта предоставляют идентичные возможности, даже более того, используют одни и те же объектные библиотеки) предлагают набор готовых компонент, используя которые как шаблоны, можно легко начать разработку приложения в рамках COM. C++ Builder предлагает набор классов с реализаций основных функций интерфейсов IDispatch, пользовательских и двойных интерфейсов, работы с библиотеками типов и фабриками классов. Форма, созданная в визуальном редакторе легко портируется в COM-класс, с перенесением всех свойств и методов автоматически в библиотеку типов. Работа над описанием интерфейсов и объектов не требует знания языка описания интерфейсов IDL (interface definition language) и языка описания объектов ODL (object definition language), т.к. вся работа ведется в визуальном редакторе. Код на IDL все равно создается, но этот процесс может быть для разработчика прозрачен.
