Главная » Delphi » Разработка приложений COM

0

Основы COM

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

COM: Модель  компонентных объектов

Модель компонентных  объектов (COM —  Component Object  Model) представляет со бой основу технологий ActiveX и OLE. COM определяет стандарты интерфейсов API и бинарные стандарты для связи объектов, не зависящих от языка программирования или платформы (теоретически). Объекты COM подобны известным уже объектам VCL, за исключением того,  что они содержат специализированные методы  и свойства, а не по ля данных.

Объект COM имеет  один  или несколько интерфейсов (interface), которые, по сути, представляют собой  таблицы функций,  связанных с этим  объектом. Методы  интер фейса  можно  вызывать аналогично методам  любого  объекта Delphi. Более  подробно интерфейсы описаны в этой настоящей далее.Используемые объекты компонентов могут быть реализованы в любом файле .exe или  .dll. При  этом  реализация объекта остается для  пользователя объекта совер шенно  прозрачной благодаря предлагаемому COM сервису,  называемому маршалингом (marshalling). Механизм маршалинга COM берет на себя всю организацию взаимного вызова  функций  между независимыми процессами и даже  различными компьютера ми, вследствие чего  становится возможным использование 32 разрядных объектов в

16 разрядных приложениях, а также  доступ к объекту,  расположенному на компьюте ре А, из приложения, запущенного на компьютере Б. Такое  межкомпьютерное взаи модействие  называется  распределенной   моделью компонентных   объектов   (Distributed COM, или DCOM).  Более  подробное описание механизма этого  взаимодействия при ведено  в настоящей главе далее.

COM, ActiveX или OLE?

“Так в чем же различие между COM, ActiveX и OLE?” — вот один из наиболее частых (и обоснованных) вопросов, которые задают разработчики при знакомстве с этими  тех нологиями. Резонность такого  вопроса объясняется еще  и тем,  что  создатель данных технологий, корпорация Microsoft, не прилагает особых  усилий,  чтобы  разъяснить их суть. Как уже упоминалось, COM —  это  стандарты интерфейсов API и бинарные стан дарты, которые служат основой для построения всех остальных технологий данного се мейства. В 1995 году аббревиатура OLE была общим  термином, использовавшимся для описания целого  набора технологий, основанных на архитектуре COM. Тогда  термин “OLE” применялся только  для тех технологий, которые непосредственно имели  дело со связыванием и внедрением, а именно: использование контейнеров и серверов, активи зация  по месту вставки  или внедрения, технология “перетащить и опустить”  (drag and drop), слияние меню. В 1996 году Microsoft начинает агрессивную маркетинговую кампа нию по внедрению в язык  разработчиков термина ActiveX. Последний становится все объемлющим и используется для описания технологий, отличных от OLE, но основан ных на применении COM. Технология ActiveX включает в себя  автоматизацию (ранее называвшуюся  OLE автоматизацией),  элементы  управления,  документы,  контейнеры, сценарии и некоторые технологии Internet. Поскольку началась неразбериха, вызван ная стремлением использовать термин “ActiveX” для описания всех “домашних  любим цев”, корпорация Microsoft слегка “дала задний  ход” и сейчас  иногда  называет все техно логии, отличные от OLE, но основанные на модели  компонентных объектов, просто и незатейливо — COM ориентированные технологии (COM based technologies).

В компьютерной индустрии критический взгляд на творчество этой  корпорации по лучил   свое   выражение  в  следующей   фразе:  мы   говорим  “OLE” —    подразумеваем “замедление работы и увеличение размера приложений”. В результате для маркетинго вых решений корпорации Microsoft потребовалась новая  терминология, предназначен ная для новых  интерфейсов API, которые были  положены в основу  будущих операци онных систем и технологий Internet. Еще один забавный факт: Microsoft просит называть OLE не Object Linking and Embedding, а просто О Ле

Терминология

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

Экземпляр объекта COM обычно называют просто объектом, а тип,  который иденти фицирует такой  объект, —  компонентным классом (component class, или  coclass).  Поэтому для создания экземпляра некоторого объекта COM необходим идентификатор класса COM (CLSID).

Часть  данных, которая совместно используется  несколькими приложениями, на зывается объектом OLE (OLE object). Приложения, способные вмещать  в себя объекты OLE,  называются контейнерами OLE (OLE  container), а приложения,  способные со держать собственные данные  в контейнерах OLE, — OLE серверами (OLE server).

Документ, в который входит  один  или  более  объектов OLE,  обычно называют со ставным  документом (compound  document).  Хотя   объекты  OLE  могут  находиться внутри  других документов, полноценные приложения, с которыми можно  работать в контексте другого документа, называют документами ActiveX (ActiveX document).

Как следует  из названия технологии, объект OLE может  быть  связан (linked) или внедрен (embedded) в составной документ.  Связанные объекты сохраняются в отдель ном файле на диске.  Благодаря средствам связывания объектов несколько контейне ров — или даже приложение сервер — могут быть  связаны с одним  и тем же объектом OLE, расположенным на диске.  Если одно  из приложений модифицирует связанный объект, внесенные изменения распространяется на все приложения, связанные с данным  объектом. Внедренные объекты хранятся непосредственно в приложениях, являющихся контейнерами OLE.  Только  контейнерное приложение будет способно осуществлять редактирование  внедренного  объекта OLE.  Внедрение не  позволяет другим  приложениям  осуществлять доступ  к импортированным данным  (а  следова тельно, модифицировать или разрушать их),  но это  существенно усложняет управле ние данными, помещенными в контейнер.

Еще один аспект  ActiveX, речь  о котором пойдет в настоящей главе далее, называется автоматизацией (automation). Это средство позволяет приложениям (называемым контроллерами автоматизации —  automation controller) управлять объектами, ассоцииро ванными с другими приложениями или динамическими библиотеками (именуемыми серве ром автоматизации — automation server).  Автоматизация позволяет управлять объектами в другом приложении и, наоборот, — предоставлять функциональные элементы своего при ложения другим приложениям.

Достоинства ActiveX

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

Технология  ActiveX  прекрасно  вписывается  в  традицию  Delphi  многократно  ис

пользовать программный  код,  созданный ранее. Не  нужно  заново писать   код  дляуправления конкретным типом  данных, если уже существует работоспособное при ложение OLE сервера. Какой  бы сложной ни показалась технология OLE, она все же лучше других альтернативных решений.

Не  секрет, что  корпорация Microsoft инвестировала значительные средства в тех нологию ActiveX, и теперь разработчики Windows 95/98, Windows NT/2000 и после дующих операционных систем  данной серии вынуждены ближе  познакомиться с тех нологией ActiveX, чтобы  использовать все ее преимущества в своих приложениях. Причем, нравится это  кому то  или  нет,  но  модель  COM  следует  воспринимать как объективную реальность и постараться сделать  ее удобным помощником в разработке своих приложений.

OLE 1 против OLE 2

Одно из основных различий между объектами OLE, ассоциированными с 16 разрядными серверами OLE 1 и OLE 2, заключается в способе их активизации. Когда активизируется объект, созданный для сервера OLE 1, запускается и получает  фокус ввода приложение сервер, а объект OLE появляется в нем в готовом для редактирова ния  виде. Когда активизируется объект OLE 2, приложение сервер OLE 2 становится активным неявно, “внутри” приложения контейнера. Это называется активизацией по месту вставки (in place activation), или визуальным редактированием (visual editing).

При   активизации  объекта  OLE 2  меню   и  панели  инструментов   приложения сервера заменяются или сливаются с соответствующими элементами приложения клиента, а часть  окна  приложения клиента, по сути, становится окном  приложения сервера. Этот  процесс демонстрируется на конкретном примере, приведенном в на стоящей главе далее.

Структурированное хранилище

Стандарт OLE 2 определяет схему хранения информации на диске,  известную как структурированное хранилище (structured storage). Данная схема предполагает реализа цию на файловом уровне  тех функций, которые в среде  DOS обеспечивались на уров не диска. Структурированное хранилище представляет собой  один  физический файл на диске,  внутреннее строение которого подобно каталогу  DOS, и состоит из множе ства других хранилищ (эквивалентных подкаталогам) и потоков (эквивалентных фай лам DOS).  Иногда структурированные хранилища называют составными файлами (compound files).

Единообразная передача данных

В OLE 2 реализована концепция объекта данных (data  object), который является ба зовым  объектом, используемым для обмена  данными с соблюдением некоторых пра вил единообразной передачи информации. Принципы единообразной  передачи  данных (UDT —   Uniform  Data   Transfer)  определяют  передачу   данных   через  буфер обмена (clipboard) и реализованы в механизмах “перетащить и опустить”,  DDE и OLE. Объек ты данных предоставляют большие возможности описания типов  содержащихся в них данных, по сравнению с теми,  что имелись прежде. На практике недостатки прежних объектов выражались в ограничениях, свойственных существовавшим ранее средст вам передачи данных.  Фактически технология UDT предназначена для замены  техно логии  DDE. В процессе работы объект данных  может  учитывать значения собствен ных свойств, таких как размер, цвет и даже тип устройства, в котором он отображает ся. Попробуйте ка реализовать вышесказанное в буфере  обмена  Windows!

Потоковые модели

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

•  Однопоточная (single). Весь сервер COM выполняется в одном потоке.

•  Раздельная  (apartment).   Иначе  эту   модель   называют  однопоточно раздельной (STA —  Single Threaded Apartment).  Каждый  объект COM  выполняется в кон тексте  собственного потока, а несколько экземпляров объекта COM одинаково го типа  могут выполняться в отдельных потоках. В результате любые  данные, используемые совместно всеми  экземплярами объектов (например глобальные переменные), должны  быть  при  необходимости защищены объектами синхро низации потоков.

•  Свободная  (free). Иначе эту  модель  называют многопоточно раздельной  (MTA — Multithreading Apartment). Клиент может  вызвать метод объекта в любом пото ке и в любое время.  В этом случае объект COM должен  защищать даже свои соб ственные данные  (а не только  глобальные) от одновременного доступа  из не скольких потоков.

•  Обе модели. Поддерживаются обе потоковые модели (“раздельная” и “свободная”).

Следует  иметь  в виду, что  выбор  желаемой потоковой модели  в диалоговом окне мастера не гарантирует, что объект COM будет защищен надлежащим образом в соот ветствии с выбранной потоковой моделью.  Для поддержки определенной потоковой модели  необходимо написать код, гарантирующий, что сервер COM будет работать с выбранной моделью  правильно. При  этом практически всегда нужно использовать объекты синхронизации потоков для защиты доступа к глобальным данным  или  дан ным  экземпляров в объектах COM.  Более подробная информация о синхронизации потоков приведена в главе 5, “Создание многопоточных приложений”.

COM+

Корпорация Microsoft реализовала свое  самое  значительное за последнее время  об новление технологии COM в виде составной части  версии Windows 2000, которую  и на звала COM+. Цель выпуска стандарта COM+ состоит в упрощении процесса разработки приложений COM  на основе интеграции нескольких технологий сателлитов, из кото рых  самыми   значительными  являются  сервер транзакций   Microsoft (MTS —   MicrosoftTransaction Server) (более  подробная информация по этой теме приведена в настоящей главе далее) и очередь сообщений Microsoft (MSMQ — Microsoft Message Queue). Интеграция этих технологий со стандартными динамическими средствами COM+ означает, что все разработчики COM+ смогут воспользоваться преимуществами таких  средств, как управ ление  транзакциями,  поддержка безопасности, удаленное администрирование,  обслу живание очереди компонентов, а также  сервис, связанный с публикацией и подпиской на события. Поскольку модель COM+ состоит в основном из имеющихся в наличии час тей, то это означает полную обратную совместимость, в результате которой все сущест вующие приложения COM и MTS автоматически становятся приложениями COM+. Бо лее подробная информация о технологиях COM+ и MTS приведена в главе 18, “Транзакционные методы разработки с применением COM+ и MTS”.

Источник: Тейксейра, Стив, Пачеко, Ксавье.   Borland Delphi 6. Руководство разработчика. : Пер.  с англ. — М. : Издательский дом “Вильямс”, 2002. —  1120 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии