Geum.ru

Лекция 1 Введение в современные технологии программирования

Вид материалаЛекция

Содержание


Цели и задачи технологии СОМ
Дальнейшее развитие СОМ
1.3. Базовые понятие СОМ-технологии
Подобный материал:
1   2   3   4

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


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

1.3. Базовые понятие СОМ-технологии

Все технологии OLE и ActiveX, которые будут рассматриваться, построены на основании, обеспеченном СОМ. Итак, что же такое СОМ? Чтобы ответить на этот вопрос, зададимся сначала другим: “Каким образом одна часть программного обеспечения должна получать доступ к сервисам, предоставляемым другой частью?” На сегодняшний день ответ зависит от того, что представляют эти части. Рассмотрим следующий рисунок (рис.1.1). Приложения, например, скомпонованные с библиотекой, могут пользоваться ее сервисами, вызывая функции из этой библиотеки. Приложение также может использовать сервисы другого приложения, являющегося совершенно отдельным процессом. В этом случае два таких локальных процесса взаимодействуют посредством некого механизма связи, который обычно требует определения протокола между этим приложениями (набор сообщений, позволяющих одному приложению выдавать запросы, а другому соответствующим образом отвечать на них). Еще пример - приложение, использующее сервисы операционной системы. Здесь приложение обычно выполняет системные вызовы, обрабатываемые операционной системой. Наконец, приложению. могут понадобиться сервисы, предоставляемые программным обеспечением, выполняемым на другой машине, доступ к которой осуществляется по сети. Получать доступ к таким сервисам можно многими способами, такими как, обмен сообщениями с удаленным приложением или вызовы удаленных процедур.

В принципе проблема одна: одна часть программного обеспечения должна получить доступ к сервису, предоставляемому другой частью. Но в каждом отдельном случае механизм доступа разный: вызовы локальных функций, передача сообщений средствами связи между процессорами, системные вызовы (которые с точки зрения программиста выглядят практически так же, как и вызовы функций) или какая-то разновидность сетевых коммуникаций. Зачем все это? Не проще ли определить один общий способ доступа ко всем видам программных сервисов независимо от способа их реализации?




Рис.1.1. В отсутствии СОМ для доступа к сервисам, предоставляемых библиотеками, локальными процессами, операционной системой или удаленными процессами применяются разные механизмы.

Этим и занимается СОМ. Она предоставляет стандартный механизм, с помощью которого одна часть программного обеспечения предоставляет свои сервисы другой и который работает во всех описанных выше случаях. Смысл ее заключается в том, чтобы применить объектный подход не на уровне одного приложения и классов, а на уровне нескольких приложений, в том числе приложений, расположенных на удаленном компьютере. Общая архитектура сервисов в библиотеках, приложениях, системном и сетевом программном обеспечении позволяет СОМ (Component Object Model - Модель многокомпонентных объектов) изменить подход к созданию программ.