Цели и задачи технологии СОМ

Основы технологии СОМ

СОМ (Component Object Model — модель многокомпонентных объектов) — одна из базовых технологий Windows. Более того, все новые технологии Windows (Shell, Scripting, HTML и т. и.) реализуют свои прикладные программные интерфейсы (Application Program Interface, API) именно в виде СОМ-интерфейсов. Таким образом, в настоящее время профессиональное программирование требует понимания модели СОМ и умения с ней работать.

Ниже рассмотрим основные понятия СОМ и особенности их поддержки в Delphi.

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

На первый взгляд, задача экспорта объектов решается достаточно просто, по крайней мере, когда в качестве другого модуля используется динамически загружаемая библиотека (Dynamic Link Library, DLL). В этом случае оба модуля содержатся в одном и том же адресном пространстве. Казалось бы, достаточно создать в DLL объект, а его методы вызвать из основного приложения — и задача решена. Чтобы понять, что это не так, рассмотрим небольшой пример. Определим метод IsFont в приложении:

procedure IsFont(O:TObject);

begin

if O is TFont then

ShowMessage('Font');

else

ShowMessage('Not font');

end;

procedure Tform1.Button1Click(Sender: TObject);

begin

IsFont(Font);

end;

Вызовем этот метод из приложения. В качестве параметра метода IsFont используем свойство Font формы. Как и ожидалось, появится сообщение, что объект является шрифтом.

Теперь создадим динамически загружаемую библиотеку, поместим в нее функцию IsFont и объявим ее экспортируемой:

library Fontlib;

uses

SysUtils,

Dialogs,

Graphics,

Classes;

procedure IsFont(O:TObject);

begin

if O is TFont then

ShowMessage('Font');

else

ShowMessage('Not font');

end;

exports

IsFont name 'IsFont';

begin

end;

Пусть функция IsFont вызывается из библиотеки при щелчке на кнопке Button2 в вызывающем приложении:

procedure IsF(O:TObject); external 'FontLib.dll' name 'IsFont';

procedure TForm1.Button2Click(Sender: TObject);

begin

IsF(Font);

end;

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

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

procedure IsF(О:TObject); external 'FontLib.dll' name 'IsFont;

Эта строка определяет имя функции IsFont и список ее параметров О:TObject, поэтому программисту, использующему эту библиотеку, потребуется документация — список функций со списком их формальных параметров. Их реализация «вручную» с большой вероятностью приведет к ошибкам. Для исправления ошибок потребуется время, причем без всякой гарантии, что все ошибки будут обнаружены. Хотелось бы, чтобы сам модуль мог информировать среду разработки о том, какие методы ей доступны и каковы списки их формальных параметров.

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

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

Очередная проблема возникает при передаче двоичных данных от одного приложения к другому. Многие языки программирования имеют разное внутреннее представление переменных (например, строки, логические значения), и при получении данных от заранее неизвестного приложения их интерпретация подчас невозможна.

Можно выделить и другие проблемы, которые встречаются при традиционном программировании, например:

· поиск установленной копии приложения, реализующего требуемые сервисы, и корректная его инициализация;

· обеспечение корректной работы приложения-сервера одновременно с несколькими клиентами;

· управление памятью, выгрузка из памяти приложения-сервера, когда необходимость в нем отпадет и, наоборот, предотвращение несвоевременной выгрузки.

Все эти п

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

Дата добавления: 2014-01-05