Глубины OpenDoc

OpenDoc - один из основных стандартов для распределенных программных компонентов в сети. Давайте заглянем, что скрывается за этой вывеской.

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

Называйте как угодно (программки, распределенные объекты или программные компоненты), но суть остается - эти небольшие фрагменты кода обладают определенным интеллектом, заботятся о себе сами и комбинируются друг с другом. Однако, чем все это обернется - покажет будущее. Не стоит удивляться, если последствия окажутся куда более радикальными, чем последствия повсеместного распространения Internet. И не только потому, что объектные компоненты будут распространяться по сети, но и потому, что они будут взаимодействовать между собой по сети прозрачным образом.

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

OpenDoc от Object Management Group, язык Java от Sun Microsystems и Network OLE от Microsoft - именно эти три распределенные объектные технологии могут оказать самое непосредственное влияние на вашу сеть в нынешнем году. Если вы хотите знать заранее, кто из них одержит победу, то тут мы ничем помочь не можем. Отметим только, что все крупные игроки на рынке разделились между этими тремя лагерями.

Если считать, что победитель возьмет все, то события тогда могут развиваться по одному из сценариев; первый - Гейтс берет все; второй - информационная супермагистраль "прокатывается" поверх всех; третий - открытые стандарты добиваются успеха на благо обычного человека.

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

ЧЕСТНАЯ ИГРА

Для чистоты эксперимента мы решили начать с OpenDoc. Объясняется это тем, что OpenDoc представляет собой технологию на базе открытых стандартов, поддерживаемую крупнейшими в программистской отрасли группами по стандартизации; она создавалась "с нуля" специально для прозрачного распространения по сети взаимодействующих объектов.

Помимо своих практических возможностей OpenDoc является учебным решением и поэтому служит основой в изучении вопросов, связанных, например, с распределенной объектной технологией (см. врезку "Объекты в двух словах").

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

Чтобы заставить работать все модули вместе, необходимо придумать способ сделать модульные куски надежными и управляемыми (они не должны выходить из строя при распространении по сети) и определить твердый набор базовых правил, которым модули будут следовать при работе друг с другом. А чтобы базовые правила работали, все куски должны играть в соответствии с одним и тем же кодексом. Иными словами, старый вопрос о том, кто должен устанавливать стандарты - комитет или указ, вновь становится актуальным.

Как следует из названия, OpenDoc - это определяемый комитетом открытый стандарт взаимодействия компонентов. За OpenDoc стоит Open Management Group, консорциум из более чем 500 поставщиков в сфере объектной технологии. Группа существует с 1989 года.

OMG определила единую архитектуру программы-брокера объектных запросов (Common Object Request Broker Architecture - CORBA). CORBA - это открытый стандарт для технологии следующего поколения, вокруг которого объединились все ключевые игроки в отрасли. Все, кроме одного. Как мы увидим в следующей статье, у Microsoft свои идеи на этот счет.

СУДЬЯ ПО ИМЕНИ ORB

Важной концепцией, таящейся в акрониме CORBA, является брокер объектных запросов (Object Request Broker - ORB). Брокер определяет правила взаимодействия объектных компонентов друг с другом, с программистов, создающих компоненты, снимает всякого рода ответственность за разработку и, что более важно, позволяет смешивать компоненты, не прибегая к заказному программированию.

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

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

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

CORBA имеет два отдельных хранилища: хранилище интерфейсов, описывающее методы и способы их вызова, и хранилище реализации, содержащее след всех объектов во время выполнения и информацию о том, что они в этот момент делают. Данные из хранилища реализации чрезвычайно важны, так как сеть предполагается прозрачной для всех компонентов брокера.

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

CORBA поддерживает множественное наследование, и в качестве таковой является схемой распространения компонентов с хорошей академической родословной. До сих пор, однако, не ясно, по силам ли чисто объектно-ориентированным реализациям программных компонентов занять рыночную нишу целиком. Java - это объектно-ориентированный язык программирования, но он перестает быть таковым при распространении программок на Java по World Wide Web. Несмотря на теоретические недостатки, Java пользуется повышенным вниманием со стороны сообщества Internet. Ясно одно - сильной стороной и OpenDoc, и Java является способность перемещать компонентное программное обеспечение по сетевой "Вселенной" просто и эффективно. Будьте уверены - у Microsoft есть свои идеи и на этот счет.

Осталось только заметить, что CORBA - стандарт, а не реализация. На рынке уже существует множество совместимых с CORBA брокеров объектных запросов. Наибольшим же влиянием, скорее всего, будет пользоваться реализация IBM под названием Модель системных объектов (System Object Model). SOM, один из первых брокеров, совместимых с CORBA, выполняется на платформах OS/2, AIX, Windows и Macintosh. (Заметим, однако, что о равных возможностях выполнения OpenDoc на всех этих платформах говорить не приходится, поскольку SOM представляет собой просто базовый протокол передачи сообщений между объектами.)

Неоспоримое достоинство SOM заключено в том, что технология его доказала свою жизнеспособность, по крайней мере, в качестве механизма координации объектов в рамках единого адресного пространства. SOM была той инфраструктурой, на которой с 1992 года строилась OS/2 Workplace Shell.

МЕТОД MICROSOFT

В разговоре о Network OLE мы еще вернемся к Брокеру объектных запросов Microsoft, а пока только заметим, что с CORBA он определенно не совместим. Называемый Моделью компонентных объектов (Component Object Model), он вызван к жизни необходимостью взаимодействия различных частей программного обеспечения Microsoft и, как таковой, ведет свое происхождение от DDE (динамического обмена данными).

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

Сторонники OpenDoc считают, что объекты OLE могут рассматриваться как части OpenDoc, а части OpenDoc, в свою очередь, выступают в роли объектов OLE. Несмотря на взаимодействие, отношения между двумя лагерями весьма напряженные. Джон Слитц, вице-президент IBM по маркетингу объектных технологий, говорит, что это конфликт идей по поводу того, каким должен быть мир распределенных вычислений - настольно- или системно-центрическим.

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

Процветание Microsoft, считает Слитц, пришлось на то время, когда быстрая разработка даже слабоструктурированного программного обеспечения приводила к успеху на рынке настольных систем. "Уверен, миру крупных распределенных сетей не обойтись без специальных методологий. Я иногда просыпаюсь ночью с мыслью, что "быстрота и натиск" отодвигают научный подход на второй план. Честно говоря, сетевая модель - еще тот фрукт. Если вы хотите, чтобы компьютер взаимодействовал со всем, что есть в сети, то придется играть по другим правилам".

УСТРАНЕНИЕ ПРОБЛЕМ

Базовые правила, которым совместимые с CORBA объекты должны следовать, являются частью ORB. Однако объекты могут достичь высокой степени интеграции только тогда, когда они включены в единую, определяющую возможные типы взаимодействия, структуру, уровнем выше брокера. Это чисто прагматический вопрос; если несколько компонентов способны оказывать влияние на экран вашего компьютера, то хотелось бы быть уверенным в том, что экран не превратится в неудобопонятную мешанину, а компоненты будут подчиняться правилам. Вопрос решается посредством создания "структур", внутри которых могут сосуществовать совместимые со структурой компоненты.

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

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

Думается, мы не погрешим против истины, если будем говорить о документе как о некоем "контейнере"; одному разделу документа приписываются инструменты текстового процессора, другому - электронной таблицы. Можно также приписать части документа инструменты базы данных по подготовке отчетов, и если мы работаем с распределенными компонентами, то этот раздел документа способен контролировать объект, находящийся на другом компьютере вне зависимости от того, где тот расположен - в том же здании или в другой стране.

OPENDOC ОТКРЫТ ДЛЯ ВСЕХ

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

Ответственность за создание и сопровождение OpenDoc была возложена на специально организованную для этого компанию Component Integration Labs (больше известную, как CI Labs).

Как структура OpenDoc имеет четыре основные обязанности (см. Рис. 2 ):

РЕАЛЬНЫЙ МИР

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

OpenDoc предстоит стать значимой частью стратегии нескольких крупных игроков. По мнению Скотта Блэка, менеджера по разработкам для OpenDoc в Apple, об этом свидетельствует хотя бы та сумма денег, которую Apple собирается выделить на финансирование разработок для OpenDoc: "В части системного программного обеспечения Copland (операционная система Apple следующего поколения) - проект номер 1. В то же время OpenDoc - проект номер 2".

OpenDoc 1.0 для Macintosh появился в прошлом году. Свыше 300 поставщиков заявили о своих планах по выпуску продуктов для OpenDoc. Если говорить о возможностях OpenDoc на Macintosh, то, по словам Блэка, OpenDoc "позволяет забыть о том, что вы работаете в локальной сети: вы получаете материалы из любой точки сети без каких бы то ни было проблем". Если по ходу дела подключаются дополнительные приложения, то "вы получаете хранилище функций с возможностью буксировать базовые компоненты и писать сценарии для их объединения, и в результате имеете взаимодействующие части".

"Эти компоненты являются небольшими кусками компактного кода. По сети распространяется не более 5 Кбайт кода приложения в расчете на часть, - продолжает Блэк и в качестве конкретного примера приводит технологию CyberDog (Apple не пришла к окончательному решению по поводу названия во время написания статьи). - CyberDog представляет набор частей OpenDoc, выполняющих такие функции Internet, как просмотр Web, и позволяет внедрять в документ соединение с Internet любого типа".

Код CyberDog можно считать вполне законченным, во всяком случае настолько, насколько это позволительно сказать, когда речь идет о разработке для Internet. Альфа-версия CyberDog была представлена на MacWorld в начале года.

Конечно, большинства настольных компьютеров Macintosh не составляют. Но IBM планирует выпустить OpenDoc к концу этого года. Версии для OS/2 и AIX были выпущены компанией в 1995 году.

Вы спросите, почему версия для Windows выпускается позже всех остальных? Ответ прост - когда что-либо делается "гуртом", т.е., в данном случае консорциумом, то трудностей не миновать. Обуреваемая множеством проблем, Novell отказалась от OpenDoc в середине 1995 года. IBM "подобрала" OpenDoc там, где его оставила Novell, надеясь обогнать Microsoft, пока та не выпустила на рынок Network OLE. Это будет долгая гонка, и победит тот, кто лучше впишется в поворот.

АЛЬТЕРНАТИВА

Не хотелось бы делать окончательный вывод, но если вы собираетесь использовать компоненты в гетерогенной сетевой среде, то предпочтение надо отдать не OLE, а OpenDoc. Если даже вы находитесь в среде Microsoft, расширения OLE Control Extensions (OCX) могут быть включены в среду OpenDoc. На чем основывается наше заключение? Во-первых, уже сейчас видно, что даже на начальной стадии модель SOM будет более надежна, так как она является открытым стандартом и, следовательно, поощряет конкуренцию. Во-вторых, нет никакой разумной причины отказываться от созидательных возможностей, проистекающих от множественного наследования.

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

ЧТО СТОИТ ЗА ТЕРМИНАМИ

Объект как он есть

Если на подробное объяснение объектной технологии потребуется несколько параграфов, то все основные понятия, касающиеся распределенных в сети объектов, можно описать в нескольких словах.

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

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

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

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