Вставка и внедрение объектов


Теперь определим, что приложение – получатель собирается делать с полученными данными? Иногда можно их внедрить в свой объект целиком, не разбирая подробностей. Так в MS Word можно внедрить фрагмент документа MathCard, MSExcel и т.п. в виде рисунка. Недостаток этого способа в том, что при такой вставке с внедренным объектом уже ничего нельзя сделать (например, нельзя изменить формулы в MSExcel). То есть объект становится статичным! Точнее, он преобразован в такой формат, который предполагает возможность некоторых изменений (Вы можете растянуть рисунок по горизонтали), но это совершенно другие преобразования по сравнению с и возможностями исходного приложения. В нашем примере конечный формат – рисунок, а исходный – таблица MS Excel.

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

Фирма MS достаточно давно реализовала способ внедрения и связывания объектов – технологию OLE (object linking and embedding). В качестве временного хранилища переносимых объектов здесь используется буфер обмена.

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

Вспомним типы MIME – унифицированные типы данных, с которыми можно связывать интерпретирующие приложения. В Windows связь устанавливается через тип данного, в роли которого зачастую используется расширение имени файла. В результате, если Вы, например, из IE попытаетесь открыть файл с расширением .doc, то операционная система вызовет MS Word. Если расширение файла не зарегистрировано в системе, то Вы получите вопрос о требуемом приложении. В Netscape Navigator принято несколько другое решение: Вам будет предложено установить (или обновить) новое приложение.

Развитие этой технологии до OLE2 (или OLE Automation) привело к тому, что не только пользователь, но и программист смог из программы, работающей либо в приложении (скрипт), либо совершенно самостоятельной, получить доступ к функциональности OLE-сервера посредством обращения к COM-объектам. COM – Common Object Model это модель общих (то есть доступных извне) объектов. COM-объекты, реагирующие на действия пользователя, часто называют ActiveX.

OLE (связывание и внедрение объектов), OLE Automation.

Технология OLE (Object Linking and Embedding) или OLE-1 предполагает следующие возможности интеграции:

· перенос данных из одного приложения в другое через буфер обмена, с преобразованием исходного формата данных в формат приложения – приёмника (или в некоторый общеизвестный формат);

· вставка (внедрение) в приложение А объекта, порожденного приложением Б вместе со ссылкой на приложение – родитель (то есть Б), но без связи с исходным файлом данных;

· вставка (внедрение) в приложение А объекта, порожденного приложением Б вместе со ссылкой на приложение – родитель (то есть Б) и на исходный файл данных.

С целью создания OLE2 фирма Microsoft разработала и продолжает совершенствовать стандарт на описание объектов – COM. Современные информационные системы, основанные или совместимые с Windows, поддерживают разработанную фирмой Microsoft COM (component object model) – технологию. Расширение этой технологии для случая распределенных по сети объектов привело к созданию модели DCOM (Distributed COM).

Разработка COM-технологии стала возможной благодаря тому, что объектно-ориентированный подход превратился в стандарт для всех современных систем программирования. С появлением COM-технологии фирма Microsoft развила технологию OLE-1 до OLE-2. Технология OLE-2 дает возможность из программы на внутреннем языке (скрипт – языке), прикрепленной к документу приложения А, обратиться к объектам (их свойствам и методам) другого приложения – приложения Б.

Очевидно, что при таком способе интеграции приложение А получает весь спектр данных и методов их обработки, экспортируемый приложением Б. Заметим, что он может быть и весьма ограниченным и очень широким, по крайней мере, никого не должен удивлять факт отличия функциональности, предоставляемой по OLE, и функциональности, обеспечиваемой родительским приложением пользователю!

В отличие от прежнего способа связи между приложениями – протокола DDE – обмена сообщениями не стандартизованной формы, OLE-2 стал стандартным средством структуризации экспортируемых приложением данных и возможностей их обработки. Но остался по существу символьный формат обмена данными, а отсюда – низкая скорость доступа.

Поясним разные виды OLE.

Можно просто внедрять данные. В этом случае обычно данные преобразуются из одного формата в другой. Передача может осуществляться через некоторого посредника: буфер обмена, файл общедоступного формата (например, текстовый). Заметьте, что во втором случае, вообще говоря, данные преобразуются дважды: из формата приложения Б в текстовый файл, а затем из текстового файла в формат приложения А! С буфером обмена та же ситуация, т.к. в нем данные хранятся в некотором обобщенном формате. Потери при таком преобразовании практически неизбежны. Попробуйте перенести, например, оформленную цветами, шрифтами, границами, с объединенными ячейками и т.п. таблицу из MS Word в MS Excel, вы убедитесь в том, что потери достаточно существенны.

Второй недостаток – одна и та же информация хранится дважды, причем в двух видах, что ведет к лишней трате ресурсов. Изменение исходного фрагмента никак не отражается на файле со вставленным кусочком, то есть со временем возникает противоречивость данных! Еще важный недостаток этого метода – ограниченная возможность изменения вставленных данных, т.к. приложение А не обладает набором функций, реализованным в приложении Б. Так вы не можете в MS Word корректировать вставленный рисунок.

Можно вставить данные вместе с «кусочком» приложения. Эта операция OLE отличается от обычной операции копирования и вставки тем, что она передает приложению-клиенту и сведения об источнике. Это - название приложения-сервера, тип данных (страница, документ, …), имя, назначенное системой этим данным (если они не были извлечены из файла или не были сохранены в файле), название или координаты диапазона (если копируется только часть объекта), представление объекта в формате Windows Metafile (.WMF). Если объект не является рисунком, его представлением может быть значок того приложения, которое создало объект, для файловых объектов добавляются свойства.

При этом сохраняется возможность корректировать вставленные данные, используя «родное» приложение. Ограничение данного способа интегрирования состоит в требовании, чтобы оба приложения были установлены на компьютере. Возможны два варианта последнего метода интегрирования: а) связь устанавливается и с файлом-источником и с приложением-источником; б) связь устанавливается только с приложением-источником, а данные копируются. Очевидно, что во втором варианте изменения в файле-источнике не приведет к изменениям в файле-приёмнике.

Сравните внедрение объекта со связью с файлом-источником и без этой связи, ответив на следующие вопросы: 1) какой объем дисковой памяти требуется для хранения документов, 2) что происходит, если исходный файл (вставленный объект) изменен, 3) а если исходный файл переименован, удален, 4) как перенести документ со вставленным объектом на другой компьютер.

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

Классификация приложений по отношению к технологии OLE (COM).

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

Сервер СОМ (или OLE) обычно представляет собой исполняемый файл (или динамическую библиотеку DLL), содержащий, по крайней мере, один объект COM. Различают три типа серверов:

· внутренние серверы (in-process) являются динамическими библиотеками, подключенными к приложению клиенту и работающие с ним в одном адресном пространстве;

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

· удаленные серверы (remote) являются приложениями, функционирующими на другом по отношению к клиенту компьютере. Эти серверы поддерживают технологию DCOM.

Существует и другая классификация. В соответствии с ней если приложение является простым OLE-сервером (Server only Application), оно поставляет объектную модель, но не располагает встроенным языком обработки. Интеграция с таким приложением строится следующим образом: во втором приложении, которое является, как минимум, OLE-клиентом, на встроенном языке пишется программа, работающая с объектной моделью сервера. Сам простой сервер не может содержать никаких программ.

Приложение мини – сервер (Mimi server Application) – имеет OLE-объект, но может быть запущено только как часть приложения – клиента. Их называют и апплетами OLE и компонентами ActiveX.

Клиентом COM обычно называется приложение, из которого осуществляется доступ к объекту COM. Клиенты могут быть и динамическими библиотеками.

Приложение COM – клиент не имеет модели для своих данных, но может обращаться к приложениям-серверам с целью обработки их объектов. Приложения – контейнеры или приложения – клиенты (Container Application) – самостоятельное приложение, в которое можно внедрить или связать с ним объект OLE. Но приложение – контейнер не может создавать свои OLE – объекты. Иногда это – только язык, каким был, например, стандартный «сервер сценариев» в Windows. Следует заметить, что в настоящее время и у сервера сценариев есть объектная модель.

Если приложение является полным OLE-сервером (Full Server Application), то для описания данных оно предлагает объектную модель, а для работы со своими или внешними данными оно использует встроенный язык обработки, кроме того, это – самостоятельное приложение.