Цели и задачи технологии сом

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

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

Однако, здесь возникают ряд проблем:

• Программисту, использующему эту библиотеку, потребуется докумен­тация — список методов со списком их формальных параметров. Их реализация «вручную» неизбежно приведет к ошибкам. Для исправления ошибок потребу­ется время, и при этом нет никакой гарантии, что все ошибки будут обнаружены. Хотелось бы, чтобы сам объект мог информировать среду разработки о том, ка­кие методы ему доступны и каковы списки их формальных параметров;

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

• Еще одна проблема возникает при обращении к объекту, созданному другим приложением. В этом случае указатель на объект в памяти, созданный в одном приложении, является недействительным для другого приложения. Если пере­дать указатель из одного приложения в другое (это можно сделать, скопировав его в буфер обмена или используя метод PostMessage), другое приложение будет обращаться совсем не к тем ячейкам оперативной памяти компьютера, в которых реально находятся данные. В лучшем случае сразу же произойдет исключение, в худшем — при попытке записи данных — будет разрушено ядро Windows. Эту проблему можно представить более глобально, если рассматривать возможность создания объекта на одном из компьютеров, а использования его через сеть на другом.

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

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

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

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

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

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

Дальнейшее развитие СОМ

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

• автоматическая обработка подсчета ссылок;

• СОМ - объекты можно будет инспектировать во время выполнения.

Технологии в современном мире развиваются непостижимо быстро. Сначала ни у кого не было настольных компьютеров, в 80-х почти все обзавелись машинами под управлением MS-DOS, и, наконец, к середине 90-х компьютеры под управлением Microsoft Windows заполонили мир. И, по-видимому, технологии сделают один виток. В конце 90-х Web-сайты разрабатывались вручную, с использованием «простого» языка HTML (Hypertext Markup Language), CGI (Common Gate Interface), DLL-библиотек ISAPI (Internet Server Application Programming Interface), Java и ASP-страниц (Active Server Pages). В июле 2000 г. Microsoft возвестила о намерении заменить все это технологией .NET.

Сейчас Microsoft вовсю работает над .NET. Пару лет назад для создания сайта нужно было лишь установить сервер, приобрести IP-адрес и «выложить» на сайт какую-то информацию. После этого сайт становился доступен всем — достаточно было знать URL-адрес. Коммерческие предприятия использовали Web для размещения данных, которые могли пригодиться клиентам. Web-среда также оказалась ценным исследовательским инструментом и средством распространения информации.

В ИТ-мире ближайшего будущего Web будет играть первую скрипку. Однако ситуация изменится: до этого содержимое Web-сайтов предназначалось пользователям, теперь же с этой информацией будут работать другие компьютеры. То есть доступ к содержимому Web-сайтов станет возможен из программ — благодаря Web-сервисам. Согласно концепциям .NET ответственность за организацию многофункционального пользовательского интерфейса возлагается на сервер.

В условиях эйфории относительно Web-сервисов и пользовательских интерфейсов, поддерживаемых сервером, может показаться, что автономные приложения и клиентские сценарии — прерогатива таких средств, как библиотека MFC. (Microsoft Foundation Class Library), — окажутся за бортом истории. Однако вряд ли исчезнет потребность в полнофункциональном пользовательском интерфей­се. Многие полагали, что «персоналки» и распределенные технологии естествен­ным путем вытеснят мейнфреймы и миникомпьютеры, а оказалось, что ПК и рас­пределенные вычисления лишь дополнили общую картину ИТ-мира. Принципы Web-сервисов в .NET и поддерживаемые сервером многофункциональные пользо­вательские интерфейсы стали еще одним вариантом, доступным разработчикам. Полнофункциональные пользовательские интерфейсы никуда не уйдут из боль­шинства приложений, которые прекрасно уживутся с другими приложениями с другого типа интерфейсами (в том числе поддерживаемыми сервером Web-интер­фейсы).

MFC — зрелый, хорошо изученный инструмент, обеспеченный обширной под­держкой сторонних компаний. Какое-то время эта библиотека останется одним из самых производительных способов создания полнофункциональных автоном­ных приложений.

А что будет с СОМ? Эта технология позволила решить массу проблем органи­зации распределенных вычислений, но у нее есть ряд серьезных недостатков, как правило, связанных с поддержкой версий и информации о типах. Работа .NET ос­нована на общеязыковой среде исполнения, или CLR (Common Language Runtime). Она берет на себя функции СОМ по обеспечению совместимости. И .NET и CLR-среда будут рассмотрены во второй части курса.

СОМ и CLR-среда основаны на различных компонентных архитектурах, и все же Microsoft позаботилась о механизмах «мирного сосуществования» этих техно­логий. Обычно удается без проблем обеспечить совместимость СОМ и CLR. Ма­ловероятно, что в мире .NET вы станете использовать СОМ в качестве компонен­тной архитектуры, однако вряд ли откажетесь от ATL (Active Template Library) Server — высокопроизводительного инструмента создания Web-сайтов.