В сетях OLE

Если настольные системы у вас от Microsoft, то локальной сетью станет, вероятно, OLE/COM. И, несмотря на все старания конкурентов, это может случиться весьма скоро.

Возможно, наиболее неотразимый довод в пользу того, что компоненты - это будущее сетевого прикладного программного обеспечения, состоит в том, что так думает Билл Гейтс. OpenDoc и единая архитектура посредника объектных запросов (Common Object Request Broker Architecture, CORBA) рабочей группы по управлению объектами (Object Management Group, OMG) достигли впечатляющих результатов в разработке компонентной архитектуры; язык Java компании Sun Microsystems вводит компоненты в мир World Wide Web. Однако сегодня наиболее широко используемой компонентной архитектурой является технология связывания и внедрения объектов (Object LInking and Embedding, OLE) и базовый транспортный механизм (Common Object Model, COM) компании Microsoft.

Практически каждый имел возможность ознакомиться с OLE самолично (чего нельзя сказать ни об OpenDoc, ни о Java), так как эта технология является частью среды Windows. OLE позволяет вставить электронную таблицу в текстовый документ, буксировать объекты из одного приложения в другое, редактировать различные типы данных в одном и том же приложении при помощи родных для них инструментов. Эти функции уже стали привычными в настольных системах под Windows.

Журнал "LAN Magazine/Русское издание" рассматривал OpenDoc и его базовую объектную шину CORBA (см. статью "Глубины OpenDoc" в апрельском номере). Очевидно, CORBA представляет собой попытку полностью революционизировать способ построения программного обеспечения. Тем не менее благодаря усилиям OMG CORBA пользуется на удивление широкой поддержкой в отрасли.

Статью "Java под парами" (см. июньский номер "LAN Magazine/Русское издание") мы посвятили языку Java и его естественной интеграции с программами просмотра Web. Появление этой новой технологии вызвано реально существующей потребностью в безопасном распространении небольших исполняемых программных кусков по Internet и в пределах корпоративной сети. Однако если взглянуть на OLE с точки зрения перехода к архитектуре распределенной сети, то мы увидим, что это единственная распределенная компонентная технология с выходом на массовый рынок.

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

В соответствии с планами Microsoft следующим шагом должен был стать выпуск в мае бета-версии Network OLE (также называемой Distributed COM или DCOM). Однако это означает, что Microsoft отстает на целый год от Apple и OpenDoc для Macintosh.

Какова вероятность, что Network OLE удастся ликвидировать этот разрыв? Думается, достаточно большая - по двум весьма прозаическим причинам. Во-первых, у Microsoft есть деньги и желание. Во-вторых, с технической точки зрения, подход Microsoft вполне добротен, хоть и не отличается особой элегантностью.

ОБОРОНА OLE

Каковы бы ни были шансы OLE на успех, хулители всегда найдутся. Критики подвергается практически каждый предпринимаемый Microsoft шаг, особенно это касается соперничества с CORBA/OpenDoc. В результате почти все, что Microsoft говорит о распространении компонентов в сети, выглядит как оправдание. Поэтому ребята из Редмонда на эту тему говорят весьма неохотно и сквозь зубы.

Например, Крэг Брокшмидт в своей энциклопедической книге "Inside OLE" ("OLE изнутри", 2-е издание, Microsoft Press, 1995) провозглашает: "OLE нацелена на интеграцию бинарных компонент, а значит, в отличие от объектно-ориентированных решений других поставщиков, занимается совершенно иным кругом проблем".

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

Понятие "ложно объектно-ориентированные" расшифровывается от противного примерно так: "Компоненты заслуживают такого названия только тогда, когда вновь создаваемые компоненты наследуют свойства от своих предшественников, причем свойства эти могут быть затем изменены".

Позиция Microsoft состоит в том, что объектная ориентация отнюдь не однозначна. Со стороны это выглядит так, будто Билл Гейтс за неимением света провозглашает таковым тьму. Однако все не так просто. Microsoft настаивает, что возможность герметизировать (slap a wrapper) обычный код и заставить его вести себя как объект (вне зависимости от объектной ориентированности кода) вовсе на так уж плоха. Плюс к тому, разделив функции между интерфейсами, вы можете выборочно менять реализацию интерфейса. Во всех смыслах это то же самое, что и замещение метода. В другом месте Брокшмидт пишет: "Наследование необходимо для полиморфизма и многократности использования, ни для чего другого оно не нужно".

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

Однако множественное наследование выдумали не для красного словца. Множественное наследование означает возможность включения отдельных компонентов, в результате появляется нечто такое, что создатели исходных компонентов не могли даже предвидеть.

Microsoft утверждает, что множественное наследование имеет смысл только на уровне языка программирования, а не на уровне бинарных компонентов. Однако это скорее пускание дыма, чем обоснованное заявление.

МОРСКОЙ БОЙ

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

До OLE интеграция отдельных приложений состояла в обеспечении обмена данными между приложениями в пределах настольной системы. Решение было весьма простым: динамический обмен данными (DDE). Эта методика по-прежнему широко используется в настольных системах под Windows. Однако DDE позволяет приложениям только обмениваться данными и ограниченным набором команд, но не позволяет вставлять данные, подготовленные и отформатированные в одном документе, "как есть", в другое приложение.

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

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

По словам Джона Слитца, вице-президента IBM по маркетингу объектных технологий, OLE - хорошее средство для доступа к коду в настольной системе. "Если мне нужно средство передвижения по дачному поселку, то я вряд ли найду что-либо лучше велосипеда, но если я поеду в город, то велосипед здесь точно не подойдет", - говорит он. По Слитцу, разница между технологией, с самого начала задумывавшейся как распределенная, и добавлением сетевых возможностей к OLE, как "между хорошо продуманной прикладной средой и DLL".

Джеф Алгер, старший менеджер по маркетингу продуктов для корпоративного разработчика в Microsoft, не согласен с этим: "С коммерческой точки зрения, реализация вначале в локальной системе была хорошим решением. Труд работников стал более производительным, таким образом, компании смогли быстро получить отдачу от сделанных вложений. Так что такая последовательность реализации - это удачное коммерческое, экономически эффективное решение".

По словам того же Алгера, Microsoft вовсе не испытывала нехватку талантов в области сетевых решений при закладке фундамента для COM: "Эта модель изобретена вовсе не теми, кто работал над Microsoft Office. С первого дня COM разрабатывалась с учетом развертывания в распределенной сети. Я не буду утверждать, что мы предвидели все детали и тонкости, но те, кто ей занимался, были далеко не профанами в распределенных вычислениях". Убедительно?

ПРЫЖОК ИЗ ОКНА

Другое пугало, от которого Microsoft рада бы избавиться, да пока не может, это то, что OLE превосходна для среды Windows, но никаким боком не подходит для остального (гетерогенного) мира. Поэтому Microsoft разработала программу под названием Windows Interface Source Environment (WISE) и заключила соглашение с Software AG (Германия).

Software AG входит в десятку крупнейших в мире программистских компаний и имеет свыше 5000 корпоративных клиентов по всему миру. Цель альянса Microsoft и Software AG - распространение компонентной технологии OLE на все основные варианты Unix, IBM MVS, OS/400 и ряд других операционных систем для серверов и мэйнфреймов. Первые реализации появятся не ранее следующего года, а полностью программу намечено завершить в 1998 году. Что касается WISE, комплекты разработчика программного обеспечения поставляются, но OLE ни один из них не поддерживает.

Так что же остается делать небольшой рабочей группе с цепочкой дружелюбных компьютеров Macintosh, как не использовать OpenDoc?

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

ДОСТАВКА ТОВАРА

В OLE запросы от одного компонента к интерфейсу другого осуществляются при помощи архитектуры COM (см. Рис.1). С помощью COM компоненты OLE могут общаться друг с другом через предварительно описанные интерфейсы. Каждый интерфейс - это группа родственных функций, он обычно предопределен в спецификации OLE (хотя то, как данная реализация функций интерфейса выполнена, отдается полностью на откуп разработчику интерфейса).

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

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

Теперь о проблеме нахождения объектов. COM предоставляет каждому объекту уникальный идентификатор, называемый идентификатором класса (CLSID). Идентификатор класса - ключ к королевству OLE, так как, независимо от того, где в сети находится объект, сервисы объекта можно получить, только зная длинное (16-байтное) число объекта. В частности, COM имеет диспетчера сервисов (Service Control Manager, SCM, сокращение произносится как "скам"), отыскивающего и устанавливающего класс объекта по заданному идентификатору класса. Поиск диспетчер производит в Windows Registry. Если на вашем компьютере установлены Windows 95, то можете заглянуть туда при помощи утилиты REGEDIT. Идентификаторы классов OLE находятся в разделе реестра HKEYS_CLASSES_ROOT.

МЕСТОНАХОЖДЕНИЕ, МЕСТОНАХОЖДЕНИЕ, И ЕЩЕ РАЗ МЕСТОНАХОЖДЕНИЕ

Сервер может выполняться внутри процесса (in-process), локально или удаленно (см. Таблицу 1). Выполнение внутри процесса - это базовый сценарий, к которому мы все привыкли: запрос интерфейса OLE удовлетворяется DLL, выполняющейся внутри того же процесса и адресного пространства, что и вызывающая программа. В сугубо аппаратных терминах интерфейс находит адрес процедуры DLL и сбрасывает указатель команд ЦПУ, перемещая его из вызывающей программы прямо на этот адрес без какого-либо переключения между существующими на текущий момент процессами ЦПУ.

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

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

Удаленные вызовы представляют собой расширения локальных сценариев. В этом случае COM (на самом деле DCOM) создает межсетевое соединение с SCM в удаленной системе и сортирует необходимые данные по сети. Удаленная сортировка опирается на среду распределенных вычислений (Distributed Computing Environment, DCE) Фонда открытого программного обеспечения (OSF), особенно в части удаленного вызова процедур. (О возможностях Visual Basic по обеспечению удаленной автоматизации для доступа к серверам OLE см. врезку "OLE без задержки".)

ЦЕЛОСТНОСТЬ ИНТЕРФЕЙСА

Несмотря на SCM и сортировку, святость власти интерфейса остается неприкосновенной. Необходимо, однако, заметить - и это замечание убийственно для приложений, - что интерфейсы, о которых мы здесь говорим, являются определенно 100-процентно статичными на всем протяжении жизни программного компонента. Мы спросили у Алджера из Microsoft: "Как долго он живет?".

"Жизненный цикл программного обеспечения на удивление долог, - ответил Алджер. - От пяти до десяти лет". Иными словами, это тот промежуток времени, в течение которого большинство компонентов должно поддерживать любой данный интерфейс, разработанный Microsoft.

Новые добавляемые компоненты должны работать со старыми интерфейсами. В случае изменения старых интерфейсов новые компоненты будут работать и с обновлениями. Если компоненты OLE смогут реально работать - даже с совершенно новыми программными расширениями и типами данных - в течение 5-10 лет, то OLE ознаменует начало новой эры многократного использования программного обеспечения.

ОБЪЕКТ ЖЕЛАНИЯ

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

Даже с учетом того, что результаты оказались в целом далеки от ожидаемых, эти "прорывы" привели к серьезным сдвигам в отрасли. Возьмем, например, переход к проектированию сверху донизу, который изменил полностью структуру и синтаксис языков программирования. Или то, что большинство популярных сред разработки теперь используют графические средства. Сегодня неграфические инструменты язык с трудом поворачивается называть "средой", и дело не в том, что разработчики перестали запускать процесс компиляции из командной строки, а в том, что все большее число их отказывается от этого старомодного способа.

В серии из трех статей мы рассмотрели три технологии - OpenDoc, Java и OLE. Думается, что именно они окажут наибольшее влияние на компьютерную отрасль. Тенденция перехода к программным компонентам в виде объектов и к распределенным сетям продолжает нарастать, поэтому вполне вероятно, что все три подхода к распространению компонентов по сети обретут свою нишу на рынке. CORBA и OpenDoc найдут себе место на предприятиях, переходящих от суперкомпьютерных транзакционных к клиент-серверным системам, а Java ждет широкое признание прежде всего в Internet. Network OLE будет доминировать в небольших компаниях и рабочих группах.

ТАБЛИЦА 1 - СОЕДИНЕНИЯ OLE НА ПАЛЬЦАХ

---

VISUAL BASIC ОСУЩЕСТВЛЯЕТ УДАЛЕННУЮ АВТОМАТИЗАЦИЮ

OLE без задержки

Корпоративная версия среды программирования Visual Basic появилась задолго до Network OLE. Среду можно использовать для создания некоторых видов сценариев распределенных вычислений. Технология удаленной автоматизации Visual Basic 4.0 делает выполняющеся вне процесса серверы OLE (т.е. независимые, выполняемые модули) доступными по сети.

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

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

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

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

Аналогично распределенной модели COM (DCOM) удаленная автоматизация заменяет исходные доверенного и заглушку OLE (используемые для выхода за границы процесса в пределах локальной среды) на модули, создающие канал удаленного вызова процедуры через сеть. Заглушка OLE на удаленной машине получает вызовы через диспетчера автоматизации, в обязанности которого входит распаковка удаленных вызовов. Диспетчер использует отдельную нить для каждого приходящего запроса, поэтому он вполне пригоден для обработки множества запросов от многочисленных распределенных клиентов.

Удаленная автоматизация работает с основными транспортными механизмами: TCP/IP, NetBEUI, IPX и Named Pipes. Защита бывает двух типов: во-первых, контроль прав доступа пользователя к тому или иному серверу; во-вторых, проверка пакетов данных на различных уровнях защиты.