Сом и технологии Интернета

Интернет и стиль доступа к данным, обеспечиваемый WWW, обрушились на берега информатики, как цунами. Microsoft не первая осознала влияние, которое может оказать эта волна, но не замедлила с ответом. Не удивительно, что большинство новых технологий Microsoft в данной области созданы с использованием СОМ. Уже говорилось, что ActiveX своим названием обязана встрече СОМ и Интернета, хотя теперь оно и распространилось на многие другие технологии на основе СОМ.

Компонентный подход СОМ находит различные применения в технологиях Microsoft для Интернета и WWW. Например, средство просмотра WWW фирмы Microsoft — Проводник по Интернету (Internet Explorer) — активно использует расширение технологии составных документов OLE — Документы ActiveX(ActiveX Documents). Благодаря этому расширению, пользователь может просматривать информацию разного типа в дополнение к обычным страницам HTML (Hypertext Markup Language — Язык разметки гипертекста). Технология управляющих элементов ActiveX была расширена, чтобы код и данные управляющих элементов могли при необходимости загружаться с сервера WWW и исполняться внутри средства просмотра.Сценарии ActiveX (ActiveX Scripting) — универсальный способ исполнения клиентами сценариев, написанных на любом языке, тогда как технологияГиперсвязей ActiveX(ActiveX Hyper-links), в основе которой лежат моникеры, обеспечивает создание гиперсвязей в стиле WWW на только между страницами HTML, но и между любыми типами документов.

Перспективы ActiveX и ole

Итак, OLE - это набор стандартов для связи и внедрения объектов при создании компонентов программного обеспечения. Одним из стандартов OLE является спецификация модели составного объекта (или COM), основа для бинарных соединений между компонентами.

Начав скромно, как способ создания составных документов, СОМ развилась в фундаментальную основу прикладного и системного программного обеспечения. СОМ получила такое широкое применение потому, что определяемая ею архитектура предоставления сервисов — привлекательное решение массы проблем. Учитывая ее универсальность и очевидные преимущества, описанные здесь применения СОМ, по всей вероятности, только начало. Хотя общая марка, под которой выступают технологии на основе СОМ, с течением времени изменялась от OLE к ActiveX, с чисто технической точки зрения, это не имеет значения. Дело не в названии, а в тех преимуществах СОМ и ее приложений, что продолжают повсеместно проявляться во всей этой части мира информатики.

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

С чего начинается COM?

С чего начинается COM… Вопрос достойный того, чтобы над ним хорошо подумать. Наверное,COMвсе-таки начинается с механизма взаимодействия объектов. Словом, читателю придётся выдержать ещё немного философии.

Объект - это абстракция прямо отражающаяся в окружающей реальности. У любой сущности видимого мира есть состояние и поведение. В computer sciencesсостояние описывается данными, а поведение - процедурами. Объединив оба понятия в одну сущность получим объект - классика, начиная уже со времен Страуструпа! Является теоремой, но сейчас доказывать уже не нужно - любая программа может быть сконструирована как совокупность взаимодействующих объектов. Вот и посмотрим, как бы могли между собой взаимодействовать части такой единой программы. Соответствующая конфигурация показана на рис. 1:

 

Рис.1 Конфигурация модуля, сконструированного в ООП

Здесь имеется два взаимодействующих объекта CиSкоторые располагаются в одном исполняемом модуле, а модуль, в свою очередь, располагается в среде операционной системы. Расположение в одном модуле позволяет «по рождению» знать друг о друге все, что знал о них компилятор. Также, здесь и ниже под термином «взаимодействиеСиS» мы имеем в виду, чтоCполучил ссылку наSи вызывает его метод.

Разделим модуль, изображённый на рис.1 на два модуля, так чтобы в каждом оказалось по одному объекту. Этим мы разорвем их взаимодействие, но не уничтожим способность объектов взаимодействовать друг с другом - ведь сами-то объекты не изменились. Сделать это можно, если один из объектов поместить в DLL, а второй оставить вEXE. Получим конфигурацию, изображённую на рис. 2:

 

Рис. 2 Конфигурация разделенных модулей

Рассмотрим возможный сценарий такого взаимодействия. Сразу оговоримся - сценарий «загрузки DLLпо требованию» здесь невозможен - модульMCничего не знает о модулеMS. Это мы их наименовали так только для нашего рассмотрения. Очевидно так же, что модульMC- загружен в память и выполняется, а иначе как бы объектCмог проявлять свои желания?

Итак, объект Cимеет твёрдое намерение взаимодействовать с объектомS, а объектS- такого желания совершенно не испытывает и ведет себя пассивно: разыщут - исполнит. Более того, вообще говоря,Си вовсе неизвестно - есть ли «в живых» этот самый объектS. Пока они оба «жили» в одном модуле этой проблемы не было вовсе - и адресное пространство было одно и ссылки на объект из «своего» модуля создавались еще компилятором. А сейчас… сейчас объектСзнает только, что где-то в природе должен существовать объектSи хочет его достать.

Что должен делать объект C? Что он вообще может сделать? Разумно предположить, что первое обращение последует отCк операционной системе - «я знаю, что в твоих недрах есть объектS, прошу выдать мне ссылку на него». Система в таком случае должна как-то вести учёт своего «объектного поголовья» и иметь средства отличать одни объекты от других. Без этой способности запросы такого рода не выполнить. Адрес, как характеристика объекта, здесь неприменим - адрес памяти известен только для заведомо существующих объектов, аCдаже про существованиеSничего не знает. Кроме того, система должна также знать, что объектS«живет» именно в модулеMS, а этот модуль - располагается во вполне определенном каталоге файловой системы. О том, какие модули составляют процесс, система знает и так.

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

Как «сделать объект S» система, конечно, могла бы знать. Но - сколько модулей, столько и мнений, и - все их помнить? Поэтому система не будет пытаться что-то сделать сама, а совершенно стандартным образом запросит модульMS- «выдать ссылку на объектS». Тут появляется уже некоторая возможность волюнтаризма со стороны модуляMS- система-то просила у него только ссылку. Как получается эта ссылка - создает ли модуль новый объектSвсякий раз, как его запрашивают, имеет ли он объектSодин на всех и всем выдает одну и ту же ссылку - дело модуляMS, а не системы.

Модуль MS«проворачивается» - он «делает объектS» в памяти, получает его адрес и возвращает этот адрес системе - «получите, что просили». Система же, зная, от кого поступил запрос, возвращает адрес тому, кто вызывал - объектуC. Поскольку объектыCиSраньше жили в одном модуле, то, как вызывать методы объектаSобъектCзнает! А ссылку он получил… Взаимодействие - состоялось.

Обратим внимание вот на что - в этом, нестрого изложенном сценарии взаимодействия, точно обозначены механизмы и понятия, необходимые, чтобы объекты, заведомо всё знающие о взаимодействии друг с другом могли «друг друга повстречать». Более того, эти механизмы и нужны только лишь для того, чтобы можно было «обеспечить встречу» - как взаимодействовать объекты и сами знают. И вот эту инфраструктуру мы изучим подробнее, ведь «вызов метода по ссылке на объект» - совершенно стандартная возможность, предоставляемая любым языком программирования.