41. Предпосылки возникновения COM

Технология СОМ является одной из базовых технологий Windows и для того, чтобы понять ее назначение, необходимо рассмотреть основные предпосылки ее возникновения. Если попытаться кратко сформулировать ее цель – то это способ взаимодействия клиентских приложений и серверов или предоставление сервисов одним приложением другому. Таким образом, главной предпосылкой возникновения СОМ является именно взаимодействие приложений.

Проблема взаимодействия приложений Windows имеет две стороны: взаимодействие на одном компьютере и в сети Intranet или Internet. Взаимодействие приложений, размещенных на удаленных компьютерах, обеспечивается технологией DCOM (Distributed COM – распределенная модель компонентных объектов), а также и технологией COM+. COM+ является следующим эволюционным шагом в развитии технологии СОМ. Технология COM+ не только включает в себя технологии COM и DCOM, но и имеет свои специфические особенности, облегчающие программирование взаимодействующих приложений Windows в рамках одного компьютера или в сети.

Чтобы яснее представить себе проблему взаимодействия приложений Windows, надо вспомнить следующее. Каждый процесс в 32-разрядной Windows имеет свое адресное пространство размером в 4Гб и, по этой причине, один процесс не имеет никакой возможности (и хорошо!) получить доступ к данным или функциям другого процесса, так как любой адрес в процессе ссылается на свое адресное пространство.

В логической и хронологической последовательности взаимодействие приложений Windows реализовалось с использованием следующих технологий:

1 Dynamic Link Libraries (DLL) – динамически подключаемые библиотеки.

2 Open DataBase Connectivity (ODBC) – открытый интерфейс доступа к базам данных, встроенный в Windows и Windows NT.

3 Dynamic Data Exchange (DDE) – динамический обмен данными.

4 Object Linking and Embedding (OLE1.0) – внедрение и связывание объектов.

5 OLE2.0 – OLE на базе COM.

6 Distributed COM (DCOM) – распределенная модель компонентных объектов.

7 COM+ – новейшая технология COM.

Ну хорошо, скажете Вы, а зачем вообще приложениям необходимо взаимодействовать друг с другом? Если некоторому приложению необходимо, допустим, использовать электронные таблицы Excel, то почему бы ему не подключить соответствующую библиотеку DLL? Естественно, можно, и это уже было первым подходом к решению обсуждаемой проблемы. Однако, такой подход имеет свои недостатки, главным из которых является проблема сопровождения и модификации ПП. Если разрабатывалась новая версия какой-либо функции DLL, то перестают работать приложения, которые используют старую версию библиотеки. Если новую версию функции снабдить новым именем, то необходимо разрабатывать новую документацию и включать в библиотеку обе версии функции. Несложно себе представить, в какой конгломерат превратится библиотека в течение весьма небольшого промежутка времени и насколько сложно будет ориентироваться в многочисленных версиях функций!

Главную идею технологии ODBC можно проиллюстрировать все на той же Excel. Так как это приложение должно быть способно считывать данные из БД различных форматов, необходимо или разрабатывать различные версии Excel для каждой из БД (Excel для Access, Excel для Oracle и т.д.) или заблаговременно подключать все необходимые библиотеки к Excel. Microsoft выбрала другой путь, создав промежуточный программный слой, который определяет стандартный интерфейс для приложений. На уровне вызовов этот интерфейс использует язык SQL, а реализация взаимодействия с БД обеспечивается драйверами, поставляемые в форме DLL. Таким образом, ODBC располагается между приложением и источниками данных различных форматов.

Технологию динамического обмена данными DDE можно рассматривать как попытку стандартизации обмена данными между приложениями. Вся идеология Windows основана на обработке сообщений (messages) и любые приложения могут обмениваться друг с другом сообщениями, используя общую очередь сообщений. Проблема, однако, состоит в том, что каждое из приложений должно знать протокол обмена данными, т.е. формат сообщений, и собственно сообщения Windows не позволяют передавать сравнительно большие объемы данных. Технология DDE как раз и предложила такой стандартный протокол, реализованный во многих приложениях. Главными недостатками DDE является сложность программирования, ненадежность и то обстоятельство, что приложения должны знать формат передаваемых данных.

Технологию внедрения и связывания объектов[1] OLE1.0 фирма Microsoft представила в 1991г. как попытку реализации объектно-ориентированного механизма взаимодействия приложений. Главной идеей OLE является концепция составного документа, который может содержать объекты других приложений.

До OLE приложения могли обмениваться статическими снимками данных через буфер обмена Windows. Однако редактирование таких данных должно выполняться тем приложением, которое их породило, а после редактирования они вновь должны быть вставлены в другой документ. Если изменяются исходные данные, то, очевидно, должны изменяться данные и в составном документе. Однако, системный буфер обмена не имеет никаких средств поддержания таких связей. Более того, проблемы возникают и при перемещении исходных данных в новое место.

Внедренный с помощью OLE1.0 объект содержит статические данные (рисунок) и данные, необходимые для его редактирования. Для редактирования объекта пользователю приложения-контейнера необходимо щелкнуть по объекту, вследствие чего в отдельном окне запускается исходное приложение, породившее эти данные. По окончании редактирования пользователь может сохранить данные и эти данные будут обновлены и в приложении-контейнере.

Недостатками технологии OLE1.0 являются:

1 Так как базовым механизмом OLE1.0 является DDE, который по своей природе асинхронен, то после вызова любой функции возврат управления происходит немедленно и требуется ожидать, в цикле, завершения требуемой операции.

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

3 Связи OLE1.0 легко разрываются при перемещении файлов.

4 Пользователю неудобно редактировать данные в отдельном окне.