1. Ole 1.0

Технология OLE 1.0 была 16-битной и появилась где-то около 1991 года. Она позволяла программам обмениваться информацией на основе связи (linking) и внедрения (embedding). Как вы, наверное, знаете, некоторые при­ложения могут экспортировать визуальные объекты в другие приложения. Приложение-получатель либо внедряет объект в себя (копирует исходные данные), либо обращается к нему по ссылке (link), которая указывает на ис­точник данных. Классический образец данной технологии — это документ MS Word, содержащий внедренную таблицу MS Excel. OLE 1.0 основана не на СОМ, а на довольно громоздком протоколе DDE (Dynamic Data Exchange, динамический обмен данными). Аббревиатура OLE используется для обо­значения технологии связи и внедрения объектов (Object Linking and Em-bedding).

OLE 2.0

В 1993 году появилась 16-битная версия OLE 2.0 для Windows 3.x. Это был огромный технологический скачок для OLE, поскольку лежащий в ее основе протокол DDE стал постепенно заменяться на инфраструктуру на базе COM. С выпуском Windows NT 3.51 OLE 2.0 стало 32-битным. Главным дополнением к существующей 16-битной версии стала полная поддержка строк Unicode, а также модификация самой СОМ, которая начала действовать в соответствии с Microsoft-овской версией конструкции RFC (Remote Pro-сedure Call, удаленный вызов процедур), разработанной ранее Open Software Foundation (OSF, Фонд разработки открытого программного обеспечения).

Технология связи и внедрения объектов по-прежнему оставалась ядром OLE 2 0, но она была не единственной: OLE 2.0 содержала целый букет технологий на основе СОМ. Самым главным в OLE 2.0 стала расширяемая СОМ-архитектура. Поэтому мы никогда не увидим OLE 3.0. Вместо этого мы получаем все новые и новые технологии на базе СОМ. Сегодня OLE 1.0 и OLE 2.0 — это только этапы в истории развития СОМ.

2. ActiveX

ActiveX — это собирательное имя для всех технологий на основе СОМ. Ко­гда-то термином ActiveX называли только Web-специфичные СОМ-технологии, однако сегодня большинство компонентов СОМ имеет в своем на­звании ActiveX: элементы управления ActiveX, документы ActiveX, серверы ActiveX и т. д. Чтобы еще больше нас запутать, Microsoft иногда использует старый термин 'OLE' для названия совсем новых компонентов на базе СОМ, например, OLE DB (которая, если быть последовательными, должна бы называться ActiveX-DB). Мы будем часто встречать ActiveX на протяже­нии этой книги. А пока запомните, что все технологии ActiveX/OLE по­строены на протоколе СОМ.

3. Стандартные и пользовательские интерфейсы

СОМ — это интерфейсы. Единственный способ обмена информацией между клиентом и сервером в модели СОМ заключается в использовании интерфейсов. В предыдущей главе мы рассмотрели программирование на основе интерфейсов с точки зрения C++. Все приводимые там интерфейсы (IDraw, IShapeEdit и пр.) были разработаны с нуля и определяли функцио­нальные возможности, которые мог бы поддержать какой-нибудь (c3DRect, C3DRectEx) класс. Вы узнали, что классы C++ могут поддерживать пользова­тельские интерфейсы, применяя стандартное множественное наследование, ^а наши самодельные API позволили нам возвращать клиенту указатели интерфейсов. Мы определили интерфейс следующим образом:

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

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

1. СОМ — это объектно-ориентированная, основанная на интерфейсах программная архитектура;

2. СОМ — это набор функциональных возможностей, доступных во время выполнения приложения.

Изначально COM является архитектурой программирования. Когда разра­ботчики действуют в соответствии со спецификациями СОМ, то в результа­те получаются легко масштабируемые, переносимые и доступные бинарные объекты (исполняемые файлы). Например, все объекты СОМ могут быть доступны из разных языков и с разных (в т. ч. удаленных) рабочих мест. Кроме того, программисты имеют право выбора своего lingua franca для раз­работки самих объектов. Это позволяет не менять привычный язык при реа­лизации и использовании компонентов СОМ (конечно, если на этом не на­стаивает начальник).

Но СОМ — это не только технология программирования, но и набор сер­висных процедур для времени выполнения. СОМ предоставляет богатый API, называемый библиотекой СОМ. Многочисленные вспомогательные методы, функции и типы данных, определяемые библиотекой, создают окружение СОМ. В отличие от нашего API Rect, созданного в главе 2, библиотека СОМ работает с любым СОМ-совместимым объектом еди­ным (полиморфным) образом. В дополнение к библиотеке менеджер управления сервисом (Service Control Manager, SCM, произносится 'scum') и реестр системы обеспечивают сервис, доступный во время выполнения программы.

Преимущества COM:

COM-совместимые объекты обладают набором привлекательных характеристик.

Независимость COM от языка программирования

COM – это не язык программирования. На самом деле компоненты СОМ могут быть написаны на любом языке (C++, ATL, С, Visual Basic, Delphi, Java, Visual FoxPro, COBOL и пр. языки). Единственным требованием является поддержка языком генерации бинарной таблицы (vTable) объекта СОМ.

Не только разработчики могут создавать объекты СОМ на произвольном языке, но и сами объекты могут быть доступны из любого СОМ-совместимого языка. Например, ваш дружный коллектив программистов на С++ может пользоваться объектами, написанными на Java. Разработчики Web-приложений могут применять VBScript для доступа к СОМ-объектам, написанным на Delphi. Модель СОМ инкапсулирует все внутренние детали реализации объекта, включая и язык его написания. Пользователь СОМ объекта видит только хорошо прописанные интерфейсы, которые поддерживает объект.

"Прозрачность местонахождения" (Location Transparency)

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

• Процесс. В программировании Win32 процесс — это часть памяти, со­держащая выполняемое приложение и все необходимые системные ре­сурсы или внешние исполняемые файлы, требуемые приложением.

• Клиент. В модели СОМ клиент — это любой фрагмент кода, использую-ЭМ-объект. В предыдущих главах книги мы называли клиента ьзователем объекта". Начиная с данной главы, будем употреблять только термин "клиент".

• Сервер.В модели СОМ сервер — это пакет исполняемых файлов (DLL или ЕXE), содержащих любое количество объектов СОМ. Обычно один может быть домом для многих связанных СОМ-объектов, каждый горых может поддерживать любое количество интерфейсов.

Разница между клиентом и сервером может стать слегка размытой. Очень возможно (и часто происходит), что клиент использует сервер, который в свою очередь является клиентом другого сервера! Рассмотрим приложение, состоящее из клиента Visual Basic (VB), обращающегося к DLL на базе СОМ. Здесь сторона VB будет клиентом, a DLL играет роль сервера. Но что если этот DLL СОМ-сервер сам обращается к другой DLL на базе СОМ, чтобы выполнить требуемое задание? В этом случае пев вая DLL будет клиентом второй DLL,

Определив эти три ключевых понятия (процесс, клиент, сервер), мы теперь можем различать три возможных взаимосвязи между клиентом и сервером:

• связь внутри процесса (in-process);

• связь вне процесса (out-of-process);

• удаленная связь.

Связь внутри процесса (in-process)

Эта связь иногда сокращенно называется in-proc. In-proc серверы загружа­ются в ту же область памяти (процесс), что и клиент, которого они обслу­живают. Основным преимуществом связи внутри процесса является ско­рость. Клиенты получают функциональные возможности внутрипроцессного сервера так же быстро, как выполняются вызовы локальных функций, по­скольку клиент и объект общаются напрямую через указатели интерфейса. Недостатком in-proc-сервера является его низкая устойчивость по отноше­нию к ошибкам. Если в сервере есть ошибка, и эта ошибка проявляется то вылетает весь процесс вместе с клиентом. Другая потенциальная проблема таких серверов — они всегда принимают контекст безопасности клиента, в который они загружаются. Рис. 3.2 иллюстрирует связь внутри процесса.

Связь вне процесса (out-of-process)

Такая связь называется также локальной. Клиент и сервер находятся на од­ной физической машине, но загружены в разные области памяти (про­цессы), каждый со своим собственным контекстом безопасности. Одним из достоинств этой связи является высокий уровень устойчивости. Теперь, если в сервере возникает ошибка, приводящая к завершению серверного процес­са, клиент продолжает работу. Если он к тому же располагает эффективны­ми средствами обработки ошибок, то может жить спокойно.

Недостатком локального сервера является скорость: информация от одного процесса к другому должна быть запакована, передана и распакована на границе процессов. Хотя СОМ берет весь этот сервис на себя (используя технику под названием "универсальный маршалинг" — universal marshaling), тем не менее время потребляется. На рис. 3.3 представлена локальная связь между клиентом и сервером.

На рисунке используется упрощенный удаленный вызов процедуры (Lightweight Remote Procedure Call, LRPC) для передачи информации между компонентами СОМ на одной и той же машине, но в различных процессах. LRPC — это протокол связи, используемый во время выполнения програм­мы. При локальной связи клиент и сервер не коммутируют напрямую, а пе­редают данные между "заглушками" (stubs) и прокси-объектами (proxy -представитель). С точки зрения клиента, "представитель" является объектом СОМ и с ним можно обращаться так, как если бы он был расположен внутри процесса. Мы рассмотрим работу "заглушек" и прокси-объектов позже в главе 5 гт же просто отметьте, что они используются там, где установлена локал °^Ка связь клиент/сервер. ^ая

Удаленный сервер

Удаленный сервер физически расположен на другой машине по отношен к клиенту. Такая архитектура является основой приложений в масштаб предприятия, где пользовательский сервис, бизнес-правила и объекты дан ных могут быть расположены на многочисленных, объединенных в сет компьютерах. Удаленный сервер — это наиболее медленная из всех возмож­ных клиент-серверных связей, поскольку здесь мы должны не только "проводить" данные между заглушками и прокси, но и учитывать ширины полос пропускания и времена задержки (к сожалению, модель СОМ не мо­жет инкапсулировать вас от законов физики). Удаленная связь устанавлива­ется с помощью протокола распределенной модели COM (Distributed COM DCOM), который использует удаленный вызов процедур (Remote Procedure Call, RPC) для передачи информации между машинами. Интересно отметить, что удаленные (или локальные) объекты СОМ могут размещаться как на DLL, так и на ЕХЕ-серверах. DLL на основе СОМ мо­гут быть превращены в удаленные с помощью специальной утилиты с име­нем dlhost.exe (поставляется вместе с NT SP 2.0 и выше). ЕХЕ-серверы счи­тались до последнего времени стандартным типом удаленного сервера, и сейчас они по-прежнему представляют вполне приемлемое решение, осо­бенно для небольших LAN. онемся к прозрачности местонахождения. Это свойство модели

швливает, что код стороны клиента, используемый для доступа к

~ам сОМ-'объекта, не требует изменения в зависимости от физи-

сположения сервера. Заглушки и прокси обеспечивают достаточ-

^Гнкапсуляцию, поскольку клиент может работать с прокси-объектом

° "реальным объектом и оперировать с ним так, как если бы объект на-

я с ним в одном процессе. Аналогично, СОМ-объект сч ггает, что

^_ка _ это реальный клиент, оставляя код сервера без изменения.

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

Эти утилиты и расширения библиотеки обеспечивают гораздо более эффек­тивный подход по сравнению с тем, что мы имели до появления прозрачно­сти местонахождения. В то время разработчики должны были использовать различные (и не связанные между собой) API, чтобы переносить информа­цию между внутрипроцессными, локальным и удаленным серверами. При работе на основе модели СОМ вам не требуется писать отдельный код для доступа клиента к удаленным объектам, локальным объектам или объектам in-proc. Клиенты видят перед собой только интерфейсы, а прозрачность ме­стонахождения позволяет клиенту находиться в полном неведении относи­тельно точного места расположения сервера.

Модель СОМ — объектно-ориентированная

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

Полиморфизм. Вернемся к нашему рассмотрению программирования основе интерфейсов и вспомним, что концепция интерфейсов позвол ^Э любому числу объектов реализовать один и тот же интерфейс уникальньГ образом (см. лабораторную работу Shapes в главе 2). Таким образом, чеп интерфейс модель СОМ обеспечивает ad hoc полиморфизм.

Наследование. Если вы внимательно прочитали предыдущий абзац про по лиморфизм, то поняли, что модель СОМ не поддерживает классического наследования бинарных объектов. Другими словами, вы не можете сказать-"СОМ-объект А произведен от СОМ-объекта В”. А теперь внимание. Вы можете использовать наследование интерфейсов при создании объектов в сервере (например, caoRect использовал наследование интерфейсов, чтобы получить определения IDraw и ishapeEdit). Однако СОМ не позволяет пи­сать код вроде приводимого ниже:

//В модели СОМ это не допускается

// Предположим, BLOB — это новое ключевое слово,

// определяющее новый бинарный объект СОМ

BLOB MyServer.NewBlob.EXE : public MyOtherServer.01dB.lob.DLL

{…

};

Связь COM, OLE и ActiveX

Модель СОМ является краеугольным камнем всех технологий ActiveX и OLE. Возьмите любой из последних выпусков Microsoft Systems Journal и могу поспорить, вы найдете в нем как минимум одну статью, посвященную новому набору интерфейсов СОМ, услуг СОМ или еще какому-то аспекту СОМ. Спор я выиграю с гарантией, так как технологии СОМ буквально бомбардируют нас со всех сторон. Сегодня любое программное обеспечение, которым осчастливливают нас веселые ребята из Редмонта (город, где рас­положена штаб-квартира фирмы Microsoft -- Прим. пер.), поставляется в виде расширений СОМ, а не как API на базе С.

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

18

RMI (Remove Method Imocation)

является аналогом…

позволяет вызывать методы удаленного объекта, чтобы это реализовать необходимо:

1. описать интерфейс

interface ICount implement Remote

описываем методы, которые будут работать с внешним объектом

исключения

void set (int I)

int get();

2. объект, реализующий данный интерфейс и соответствующую функциональность

public int count;

void set (int, i){count=i;}

int get () {return count;}

Count c=newCount();

создали объект необходимо сообщить системе, что данный объект присутствует и можно с ним работать

проверка соответствия имени, с которым работают клиенты с самим объектом

имени Count2 на машинеhost(иногда эта часть может опускаться)

метод … в классе … Naming

Naming.b ind("// /host/Count2",C);

иногда необходимо запускать сервис на некотором порту

"// host:port/…/099

До момента присвоения имени необходимо установить менеджер безопасности, чтобы запустить реестр необходимо записать приложение rmiregistry, которое автоматически начинает прослушивать порт (по умолчанию 099).

Менеджер безопасности регламентирует: что, на каком этапе и куда передается.

ICount ic = (ICount)Naming.lookup

("// /host/Count2")

приведение типов

ic.set(5);

ic.get();

вызываем методы

19