Добавлен: 22.04.2023
Просмотров: 94
Скачиваний: 1
Одним из значимых элементов при разработке СОМ-приложений выступает создание приложений, которых мы называем СОМ-клиентами. Их основная функция заключается в том, что бы они могли запрашивать интерфейсы объектов, чтобы определить те услуги, которые может предоставить СОМ-объект. [13]
Давайте рассмотрим один из самых распространенных видов клиентов. К ним мы можем отнести: СОМ-клиент, который является диспетчером автоматизации (Automation Controller). Диспетчер автоматизации - это одна из частей приложения, которая знает, какой тип информации необходим ему от разных объектов сервера, и она запрашивает данную информацию по мере надобности. [14]
Технология СОМ изначально была разработана, как ядро для осуществления взаимодействия между программами.[15] Уже на одном из этапов разработки предполагалось расширение возможностей технологии при помощи, так называемых расширений СОМ. Вот мы и дошли до расширений нашей программы, о, которой мы говорили еще в самом начале нашего раздела. СОМ имеет возможность расширять собственную функциональность, благодаря тому, что создает специальный наборов интерфейсов для
решения определенных задач.
Вот теперь, когда мы уже знаем, что такое расширение программы COM, мы можем поговорить о видах, которые были разработаны для данного расширения. Что бы было более понятно, мы все данные привели в виде таблицы, которая будет расположена ниже.
Итак, технология ActiveX – это одна из технологий, которая использует компоненты СОМ, особенно элементы управления. Данная технология была создана для того, чтобы работа с элементами управления была более эффективной. Это особенно необходимо при работе с приложениями Internet/Intranet, в которых элементы управления должны быть загружены на компьютер клиента, прежде чем они будут использоваться.
Технология ActiveX - не является единственной расширение СОМ. В табл. 3.2 представлены некоторые из используемых в настоящее время расширений СОМ.
Перечисленные в табл. 3.2 расширения СОМ - это далеко не все из имеющихся. Мы привели более распространенные и использующиеся на данный момент времени. Так же следует отметить тот факт, что постоянно идет доработка старых и создание новых расширений, более совершенных технологий межпрограммного взаимодействия.
Таблица 3.2. Список расширений СОМ
Расширение СОМ |
Краткое описание |
||
Серверы автоматизации (Automation servers) |
Серверы автоматизации – представляют собой объекты, которыми можно управлять из других приложений во время работы приложения. Таким образом, автоматизация - это способность приложения программно контролировать объекты других приложений |
||
Диспетчеры автоматизации или СОМ-клиенты (Automation Controllers, COM Clients) |
Диспетчеры автоматизации – представляют собой клиентов серверов автоматизации. Они позволяют разработчику или пользователю писать сценарии для управления серверами автоматизации |
||
Элементы управления ActiveX (ActiveX Controls) |
Элементы управления ActiveX предназначены для серверов внутри процесса (in-process COM servers). Элементы ActiveX обычно используются путем встраивания в приложение-клиент |
||
Библиотеки типов (Type Libraries) |
Библиотеки типов представляют собой статичные структуры данных, которые часто сохраняются как файлы ресурсов. Они содержат более детальную информацию об объекте и его интерфейсах. Клиенты серверов автоматизации и элементы управления ActiveX используют данную информацию и всегда считают ее доступной |
||
Страницы активного сервера (Active Server Pages) |
Активные серверные страницы- это компоненты ActiveX, которые позволяют вам создавать динамически изменяющиеся Web-страницы |
||
Активные документы (Active Documents) |
Активные документы - это объекты, которые поддерживают связывание и внедрение, визуальное редактирование, перенос (drag-and-drop). В качестве примера таких документов можно представить документы Microsoft Word и книги Microsoft Excel |
||
Визуальные межпроцессные объекты (Visual Cross-process Objects) |
Визуальные межпроцессные объекты- это визуальные объекты, которыми можно управлять из других процессов |
||
На рис. 3.7 представлена диаграмма, которая показывает связь некоторых расширений СОМ и их связь с технологией СОМ.
Использование СОМ-объектов имеет как преимущества, так и некоторые ограничения. СОМ-объекты могут быть как визуальными, так и невизуальными. Какие-то СОМ-объекты должны быть запущены в одном процессе с клиентом, другие - в разных процессах либо на разных,,компьютерах.
Приведенная ниже табл. 3.3 кратко описывает особенности объектов каждого из вышеприведенных расширений СОМ.
Рис. 3.7. Технологии, основанные на СОМ
Таблица 3.3. Особенности объектов СОМ
СОМ-объект |
Визуаль-ность |
Процесс |
Связь |
Библиотека типов |
||
Активный документ (Active Document) |
Обычно визуальный |
Внутренний или локальный |
OLE |
Нет |
||
Автоматизация (Automation) |
Может быть как визуальным, так и невизуальным |
Внутренний, локальный или удаленный |
Автоматический маршалинг при помощи интерфейса IDispatch |
Требуется для автоматического маршалмнга |
||
Элемент управления ActiveX (ActiveX Control) |
Обычно визуальный |
Внутренний |
Автоматический маршалинг при помощи интерфейса IDispatch |
Требуется |
||
Произвольный объект интерфейса |
По выбору |
Внутренний |
Не требуется маршалинг |
Рекомендуется |
||
Произвольный объект интерфейса |
По выбору |
Внутренний, локальный или удаленный |
Автоматический маршалинг в зависимости от библиотеки типов, в противном случае-ручной маршалинг |
Рекомендуется |
В данном разделе мы поговорили о COM - клиентах, дали им общую характеристику, которая позволила нам определить их значимость. Так же, как уже говорилось ранее, мы затронули небольшую часть расширения программы COM. Как мы уже сказали, данные программные расширения очень быстро меняются, изменяются и т.д., поэтому мы сделали анализ существующих расширений на данный момент времени и выбрали самые объективные на наш взгляд, и описали их в виде таблицы, которую вы можете наблюдать выше. В ней мы сделали описание данных расширений. Далее мы расскажем более подробно о них и о каждой в отдельности.
Диспечертский интерфейс
Диспетчерский интерфейс (dispatch interface) – стандартная специальная реализация интерфейса IDispatch, которую предлагает COM. Данная реализация обеспечивает выполнение процедур позднего связывания (late binding) и маршаллинга. Диспетчерский интерфейс хранит внутри себя таблицу диспетчерских идентификаторов (dispID), каждый из которых является уникальным идентификатором члена интерфейса, и таблица, по сути, реализует отображение соответствующего dispID на имя каждого члена интерфейса. Клиент, желающий получить доступ к ресурсу сервера (к методу или к свойству), должен знать dispID для соответствующего ресурса. Такую информацию можно получить через вызов метода интерфейса IDispatch, который называется GetIDsOfNames, и который является первой записью в vtable для интерфейса IDispatch.[16] Таким образом, клиент получает информацию типах данных, используемых сервером, и получает таблицу диспетчерских идентификаторов, с отображением имени каждого ресурса сервера на соответствующий dispID. Данная операция и со стороны клиента, и со стороны сервера, при использовании стандартной реализации интерфейса IDispatch реализуется автоматически. Эта процедура называется поздним связыванием , т.к. осуществляется на этапе выполнения программы, а не на этапе компиляции.[17] Имея для каждого имени ресурса сервера соответствующий dispID, клиент может осуществить обращение к нему, используя метод интерфейса dispID, который именуется Invoke.[18] Метод Invoke имеет сигнатуру, допускающую вызов с любым количеством параметров, чем обеспечивается его универсальность. Реализация Invoke распаковывает параметры и осуществляет вызов соответствующего метода или свойства и осуществляет контроль над выдачей исключений при выполнении метода или свойства. Когда выполнение метода или обработка свойства заканчивается, возвращаемые значения метода или свойства отправляются обратно клиенту. Если обращение клиента к серверу переходит через границы процесса или машины, то автоматически реализуются все действия по организации маршаллинга. Такая прозрачность является основным достоинством использования интерфейса диспетчеризации.
Основным недостатком диспетчерского интерфейса является ограничение на типы данных, которые можно использовать при передаче параметров. Это следует из необходимости упаковки и распаковки параметров при осуществлении маршаллинга. Допускается использовать 13 стандартных типов данных. На пользовательские типы данных устанавливаются достаточно строгие ограничения. Если требования задачи не укладываются в эти ограничения, разработчик имеет возможность реализовать маршаллиг, путем написания своего proxy/stub кода. Еще одним недостаток проявляется в том, что при компиляции программы не выполняется проверка соответствия типов вызываемых функций, т.к. связывание диспетчерских интерфейсов осуществляется на этапе выполнения программы, и таким образом, не контролируется вызов Invoke с неверным набором аргументов, что вызывает ошибку выполнения.
COM предлагает возможность привязки диспетчерских интерфейсов на этапе компиляции. Если объект описан в библиотеке типов, то dispID может быть прочитан для каждого ресурса объекта, т.к. dispID является для каждого метода или свойства фиксирован, и является частью описания используемых типов данных объекта. Такая процедура называется привязкой идентификаторов (ID bindig). Метод GetIDsOfNames вызывается компилятором во время трансляции программы, таким образом, привязка идентификаторов является формой раннего связывания (early binding). В результате, на этапе выполнения, при первом вызове сервера клиентом, не требуется вызов процедуры привязки интерфейсов, что ускоряет работу. Еще одним достоинством данного подхода является проверка соответствия типов в обращениях к ресурсам сервера.
Расширения COM
OLE/Active document
Документы OLE (OLE/Active documents) – один из набора сервисов, которые предлагает технология OLE. Объекты OLE documents имеют все свойства OLE по связи и внедрению данных, визуального редактирования, поддержки drag-and-drop, активизации по месту (in-place-activation). Используя OLE document можно определить любой количество интерфейсов, через которые обеспечивается стандартное поведения объекта, такое как визуальное редактирования и drag-and-drop.[19] Посредством реализации этих интерфейсов, объекты OLE documents могут быть свободно объединены в единую систему взаимодействующих объектов с разными форматами данных, таких, как звуковые фрагменты, текстовые документы и растровые изображения.[20]
Объект OLE documents может быть реализован как внутренний и внешний COM-сервер.[21] Такой объект состоит из двух частей: визуальной (presentation data), предназначенной для отображения визуальной части объекта и из внутренней части (native data), используемой для редактирования объекта. Объекты OLE documents могут быть контейнерами документов (document container) и серверами документов (document server). Сервер документов обеспечивает функциональность объектов OLE documents. В среде контейнера документов может быть активизирован любой сервер документов.
Automation
Технология автоматизации (automation) предлагает возможность программного управления одного приложения другим. В данной технологии различаются две составные компоненты:
· Клиентская часть, называемая контроллером автоматизации (automation controller);
· Серверная часть, которая носит название объекта автоматизации (automation object) – объект, которым управляет клиент.
Объекты автоматизации могут быть реализованы как внутренние, внешние и удаленные сервера. Технология автоматизации характеризуется двумя положениями:
· Объекты автоматизации должны иметь возможность определить множество свойств и команд через описания типов, т.е. они должны получить информацию об интерфейсах объекта, с которым идет взаимодействие, о методах интерфейсов и о типах аргументов. Такая информация предоставляется через библиотеки типов. Однако, использование библиотеки типов необязательно при использовании интерфейса диспетчеризации, т.к. с помощью последнего осуществляется привязка интерфейсов на этапе выполнения программы (недостатком такого подхода является отсутствие проверки соответствия типов на этапе компиляции);
· Объекты автоматизации должны предоставлять свои методы общедоступными для внешнего использования, так, чтобы ими могли пользоваться внешние приложения. Для этого, в объектах автоматизации должен быть реализован интерфейс диспетчеризации.
Основным достоинством технологии автоматизации является возможность создания объектов, работающих в любом процессном пространстве. Таким образом, вместо создания невизуального OLE-объекта предпочтительнее использовать Automation.
ActiveX control
Технология ActiveX расширяет COM и OLE новыми функциями, специфичными для элементов управления ActiveX (ActiveX control). ActiveX control – визуальные объекты управления, реализуемые как внутренние COM-сервера, и которые включаются в OLE-контейнеры, и работают в их среде. Элементы управления ActiveX не являются законченными приложениями, но представляют собой объект, который решает некоторую частную задачу и может быть встроен в различные приложения. Основными характерными особенностями ActiveX controls является возможность обработки событий, привязки к источникам данных и поддержка лицензирования.
Элементы управления ActiveX особенно широко используются в разработке Web-приложений, где ActiveX controls используются как интерактивные объекты на Web-страницах. По существу, ActiveX становится стандартом, специально направленным на интерактивную часть World Wide Web, например, для просмотра в Web-браузере не гипертекстовых документов, доступ к базам данных и т.д.