Файл: Технология СОМ (Создание и повторное применение объектов СОМ. Маршалинг).pdf

При передаче данных должны использоваться стандартные форматы представления данных. Для описания данных, передаваемых методами интерфейса IDataObject используется структура FORMATETC (от format, etc - формат и прочие).

Наиболее важные методы интерфейса IDataObject:

- GetData - передает данные от объекта его клиенту. Клиент, вызывая этот метод передает структуру FORMATETC, где указывает формат, в котором желает получить данные. Объект возвращает ссылку на данные в параметре типа STGMEDIUM;

- SetData - передает объект)' данные от его клиента, параметры те же, что и в GetData,

- QueryGetData - позволяет клиенту запросить объект данных, поддерживает ли тот пересылку конкретного типа данных;

- EnumFormalEtc - возвращает описание форматов данных (в виде структур FORMATETC), поддерживаемых данным объектом;

- DAdvise - устанавливает связь между объектом данных и объектом приемника уведомлений (advise sink object);

- DUnadvise - разрывает связь, установленную DAdvise.

Необходимо, чтобы объект данных оповещал клиента об изменениях в своих данных. Кроме этого нужно, чтобы клиент как-то сообщил объекту данных, какие именно данные ему нужны. Интерфейса IDataObject для этого не достаточно.

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

Объект данных для оповещения клиента об изменениях в своих данных посылает ему уведомления. Клиент должен реализовать интерфейс, позволяющий источнику данных уведомлять его при их изменениях. Это интерфейс IAdviseSink. Т.е. клиент должен содержать объект, реализующий IAdviseSink и передать его адрес объекту данных с помощью метода IDataObject::DAdvise. После этого объект данных при изменении своих данных выбывает метод IAdviseSink::OnDataChange, параметрами которого являются структура FORMATETC, описывающая формат изменившихся данных и структура STGMEDIUM, указывающая на местонахождение данных (рис. 10). Когда клиенту требуется прекратить получение уведомлений, он вызывает IDataObject::DUnadvise.

Рис. 10. Единообразная передача данных

3.5. Объекты с подключением

Иногда объекту необходимо вызывать методы его клиентов. Технология объектов с подключением (Connectable Objects) обеспечивает более общий механизм обратной связи объекта с клиентом, чем предоставляемый IAdviseSink.

Чтобы обращаться к своему клиенту объект должен поддерживать один или несколько исходящих интерфейсов (outgoing interface). Поддержка исходящего интерфейса означает, что объект может работать с этим интерфейсом в качестве клиента.

Чтобы считаться объектом с подключением, объект должен поддерживать (как входящий) интерфейс IConnectionPointContainer. Через него клиенты объекта могут узнать, какие исходящие интерфейсы поддерживает этот объект. Каждый из этих интерфейсов представляется внутри объекта как отдельный объект точки связи (connection point object). Каждая точка связи отвечает только за один тип исходящего интерфейса и поддерживает (как входящий) интерфейс IConnectionPoint.

Клиент объекта с подключением, в свою очередь, должен реализовать те интерфейсы, которые для объекта с подключением является исходящим. Объекты в клиенте, которые реализуют эти интерфейсы, называются приемниками (sink).

Интерфейс IConnectionPointContainer имеет всего два специальных метода:

- FindConnectionPoint - позволяет клиенту узнать, поддерживает ли объект с подключением конкретный исходящий интерфейс. В качестве параметра передается IID, если интерфейс поддерживается, то возвращается указатель на интерфейс IConnectionPoint соответствующего объекта точки связи.*

- EnumConnectionPoint - позволяет клиенту получить список всех указателей на интерфейсы IConnectionPoint всех точек связи. Просматривая этот список, клиент может выяснить IID любого поддерживаемого объектом исходящего интерфейса с помощью метода интерфейса IConnectionPoint.

Интерфейс IConnectionPoint служит для установления и разрыва связи с объектом с подключением. В него входят методы:

- Advise - устанавливает связь, получает указатель на интерфейс, реализованный объектом-приемником, возвращает идентификатор соединения;

- Unadvise - разрывает связь;

- EnumConnection - возвращает список всех установленных связей;

- GetConnectionPointContainer - возвращает указатель на интерфейс

- IConnectionPointContainer объекта с подключением, которому принадлежит точка связи;

- GetConnectionlnterface - возвращает IID исходящего интерфейса, поддерживаемого данной точкой связи. Именно с помощью него клиент может, получив список указателей на интерфейсы IConnectionPoint от метода IConnectionPointContainer::EnumConnectionPoint, узнать, какие исходящие интерфейсы поддерживаются.

Таким образом, процесс установления связи следующий: клиент, имея указатель на интерфейс IConnectionPointContainer, получает указатель на интерфейс IConnectionPoint нужного объекта точки связи и устанавливает связь, вызывая его метод Advise, передавая ему в качестве параметра указатель на соответствующий интерфейс своего объекта- приемника. На этот интерфейс объект с подключением и будет посылать сообщения - вызывать его методы (рис. 11).

Рис. 11. Объекты с подключением

3.6. Составные OLE-документы

Составной документ включает в себя части, созданные различными приложениями. Технология OLE обеспечивает создание таких приложений. Исторически, именно из необходимости создания составных документов и развились все технологии, называемы в настоящий момент СОМ.

Технология составных OLE-документов использует много других СОМ- ориентированных технологий, включая структурированное хранилище, моникеры и единообразную передачу данных.

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

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

3.7. Управляющие элементы ActiveX

Управляющий элемент ActiveX - независимый программный компонент, выполняющий специфические задачи стандартным способом. Эти компоненты, не являясь независимыми приложениями, могут использоваться при разработке любых приложений. Такие элементы можно подключать к приложениям, создаваемым с помощью систем разработки Visual Basic, Visual C++, Delphi, Visual J++. Также их можно непосредственно вставлять в гипертекстовые HTML страницы или использовать в некоторых программах. Элементы управления ActiveX не могут реализовать свои функции без приложения-контейнера.

Элементы управления ActiveX обладают свойствами, методами и событиями.

События возникают внутри элемента управления, а обрабатываются вовне - подпрограммами контейнера.

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

Элементы управления ActiveX представляют собой внутризадачные СОМ-серверы, т.е. они являются dll-файлами, реализующими наборы СОМ-интерфейсов.

Для того, чтобы COM-объект мог рассматриваться как элемент управления ActiveX он должен:

- поддерживать IUnknown,

- обеспечивать саморегистрацию - т.е. занесения записи о себе в системный реестр.

Кроме этого, он может:

- отображать собственный пользовательский интерфейс;

- посылать сообщения контейнеру управляющих элементов;

- позволять контейнеру изменять значения своих свойств.

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

Для того, чтобы контейнер мог определить возможности и требования управляющего элемента используются категории компонентов (component categories), которые помещаются в системный реестр и задаются соответствующим GUID, называемым идентификатор категорий (category identifier - CATID). Категории компонентов могут использоваться для обозначения любого сочетания функциональных возможностей и требований к контейнеру.

Все СОМ-интерфейсы, поддерживаемые элементом управления и контейнером можно разделить на следующие группы:

- обеспечивающие пользовательский интерфейс;

- обеспечивающие выполнение методов - обычно интерфейс элемента управления IDispatch или дуальный интерфейс;

- обеспечивающие посылку элементом управления событий своему контейнеру;

- обеспечивающие работу со свойствами элемента управления (IPerstst* и др.).

3.8. Интерфейсы сервисов на основе СОМ

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

СУБД можно рассматривать как набор сервисов, которые она предоставляет другим программам. Эти сервисы можно рассматривать как СОМ-объекты. Аналогично можно организовать доступ к данным, хранящимся, например, в электронных таблицах.

Технология баз данных на основе COM (OLE Database или OLE DB) определяет стандартные объекты и интерфейсы СОМ для доступа к данным. Эта технология предоставляет всем клиентам универсальное средство доступа к данным, хранящимся в различной форме.

3.9. Определение стандартных интерфейсов с помощью СОМ

Microsoft финансирует программу разработки промышленных стандартов ннтрефейсов - OLE Industry Solutions (промышленные решения на основе OLE). В рамках этой программы группы финансовых компаний, организаций здравоохранения, поставщиков оборудования для торговых точек и др. определили стандартные интерфейсы компонентов в соответствующих областях.

3.10. СОМ и технологии Интернет

Компонентный подход находит различные применения в технологиях Microsoft для Интернет. Например, Internet Explorer, использует расширение технологии составных документов OLE - документы ActiveX. Сценарии ActiveX (ActiveX Scripting) - универсальный способ исполнения клиентами сценариев, написанных на любом языке. Технология Гиперсвязей ActiveX (ActiveX Hyperlinks), в основе которой лежат моникеры, обеспечивает создание гиперсвязей WWW не только между страницами HTML, но и между любыми типами документов.

Заключение

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

Библиография

1. Бокс Д. Сущность технологии СОМ. Библиотека программиста. / Д. Бокс. - СПб.: Питер, 2001. - 400 с.
2. Деннинг А. ActiveX для профессионалов / А. Деннинг. – СПб.: Питер, 2002. – 404 с.
3. Елманова Н. Delphi и технология COM. Мастер-класс / Н. Елманова, С. Трепалин, А. Тенцер. – СПб.: Питер, 2003. – 698 с.
4. Михайлов А.В. 1С: Предприятие 7.7/8.0: системное программирование / А.В. Михайлов. – СПб.: БХВ-Петербург, 2005. – 336 с.
5. Мюллер Д. Технология COM+ / Д. Мюллер. - СПб.: Питер, 2002. - 464с
6. Оберг Р.Д. Технология СОМ+. Основы и программирование / Р.Д. Оберг. – М.: Вильямс, 2000. – 480 с.
7. Роджерсон Д. Основы СОМ / Д. Роджерсон. – М.: Русская Редакция, 2000. – 228 с.
8. Трельсен Э. Модель СОМ и применение ATL 3.0 / Э. Трельсен. – СПб.: БХВ-Петербург, 2001. – 928 с.
9. Хармон Э. Разработка COM-приложений в среде Delphi / Э. Хармон. – М.: Вильямс, 2000. – 464 с.
10. Чеппел Д. Технологии ActiveX и OLE / Д. Чеппел. – М.: Русская Редакция, 1997. – 320 с.