Библиотека Интернет Индустрии I2R.ru

Регалии

Начнем мы издалека -- с вещей, которые на самом деле никакого отношения к программам не имеют. А именно, с титулов, наград и регалий, которых программы (и их разработчики) удостаиваются. В мире большого коммерческого ПО титулованность -- один из самых важных, решающих факторов всех составляющих успеха. Не напрасно и не случайно Б. Гейтс объявил успех Windows XP в такой дерзкой форме: "Я очень счастлив, когда вижу такой уровень продаж, ведь отправка человека на Луну -- это ничто по сравнению с разработкой Windows XP". Эту фразу перепечатали тысячи изданий (и даже автор статьи не избежал подобной печальной участи), и вот уже сомнения, возмущения и предсказания аналитиков отошли на второй план. Проект KDE -- естественно, не корпорация Microsoft и представляет совершенно иной мир, но и в нем есть свои амбиции и титулы. Их полный перечень можно найти на сайте http://www.kde.org/, мы же обратим внимание на ключевую фразу, характеризующую цель проекта, которой "открывается" его сайт, и всего одну, но весьма весомую награду. Итак, главная цель и характеристика KDE, по словам разработчиков, гласит: "KDE -- это мощная, с Открытыми Исходными Текстами, графическая настольная среда для рабочей станции Unix". Ну а самая весомая награда -- "Программная инновация 1998/99 гг.", полученная проектом на выставке CeBIT.

Такое весьма странное начало вовсе не случайно -- ничего случайного не бывает. Раз уж KDE заявлена разработчиками как среда для "рабочей станции Unix" и раз столь уважаемая международная выставка, как CeBIT, удостоила проект такого титула, то руки можно считать развязанными. Что означает -- никаких "поблажек" при эксплуатации KDE 2.2.2 и никакой снисходительности автор проявлять не собирается, "ведь отправка человека на Луну -- это ничто по сравнению..." (здесь читатель может продолжить фразу сам).

Инновации и архитектура

Полученная проектом KDE в далеком по компьютерным меркам 1998 году награда CeBIT спонсировалась Ziff-Davis и присуждалась "не за коммерческий успех, а за креативность в дизайне продукта, исключительные решения специфических проблем или принципиально новые концепции". Одновременно с проектом KDE эти награды получили процессоры AMD семейства K6-2, видеоакселераторы NVidia Riva TNT и ATI Rage 128 и, наконец, Novell NetWare версии 5.

Что же принципиально инновационного было в проекте в те времена? Возможно, "привычный" дизайн, во многом схожий с оформлением "настольных" систем. Дизайном в мире рабочих станций Unix (вспомним цель и характеристику проекта) никто особенно не увлекался, классическая графическая оболочка CDE им, мягко говоря, не блещет, и симпатичный, с точки зрения не знакомого с ОС Unix человека, экран уже привлекает внимание. Но все-таки главной инновацией была архитектура системы, которая не столько интересна как застывшее явление, сколько крайне симтоматична в истории своего развития.

В одной из предыдущих статей мы уже обсуждали вопросы программной архитектуры, в другой -- бегло обсудили проблемы middleware -- основного связующего компонента, "клея", с помощью которого создаются большие программные системы. И если в предыдущих публикациях звучали больше рассуждения, то теперь настало время подкрепить их мнением практикующих разработчиков одного из самых ярких проектов в мире freeware: "Отказом от CORBA в пользу нашего собственного, оптимизированного под задачи middleware, мы смогли добиться большей гибкости, более тесной интеграции и высокой скорости как разработки, так и созданных программ". Все дело в том, что проект KDE в свое время использовал в качестве "клея" одну из реализаций де-факто стандартного механизма поддержки объектной архитектуры CORBA -- Mico. Надо сказать, что выбор именно Mico был весьма удачным -- это действительно очень неплохая реализация сложнейших стандартов CORBA, но сложность остается сложностью. И в случае с проектом KDE правило рационального программистского мышления сработало безукоризненно: если некоторая технология требует для своего использования N единиц времени на освоение и K -- на использование, а ее возможности реализуются собственной разработкой, требующей L единиц времени, и если L N + K, то собственная реализация -- рациональнее. Именно так разработчики KDE и поступили, создав два основных "клеящих" механизма, на которых строится вся система.

Первый механизм -- DCOP, "настольный коммуникационный протокол" (Desktop COmmunication Protocol), очень близок к описанной в недавней статье о программных шинах организации Software Bus (SB). Так же, как и выдуманная абстрактная программная шина, DCOP использует в качестве коммуникационного канала сокеты, правда, его конструкция максимально упрощена за счет "привязанности" к технологии X Window. Активное применение мощных сервисов последней (а X Window на деле -- куда более серьезная система, чем просто высокоуровневый драйвер видеокарты) -- ICE (Inter Client Communication, "межклиентское взаимодействие") -- позволило в кратчайшие сроки и с минимальными затратами создать крохотную, буквально в несколько сотен строк C/C++, реализацию весьма функциональной программной шины, расширяющей абстрактную модель SB возможностью обмена данными, преобразованными в последовательный поток (это в мире middleware часто именуется маршаллингом или сериализацией). Слово "настольный" в названии DCOP использовано очень метко -- "общение" с помощью SB DCOP возможно только в пределах одного компьютера. По большому счету, это даже не ограничение, а весьма продуманный ход, позволяющий повысить защищенность рабочих станций, на которых выполняется KDE.

Второй механизм также вполне "укладывается" в рамки рассмотренных прежде абстрактных моделей. Его назначение -- расширение возможностей "общения" между программами за жесткие границы одного компьютера, установленные DCOP. Для решения этой задачи разработчики KDE использовали очень симпатичные и простые идеи, положенные в основу системы поддержки распределенных вычислений XML-RPC ("XML -- удаленный вызов процедур"). Для поддержания XML-RPC в KDE применяется постоянно выполняемая программа-демон kxmlrpc, реализация которой подкупает смехотворными размерами и простотой. По сути, kxmlrpc -- это... не совсем обычный, но все же Web-сервер, транслирующий запросы, соответствующие спецификациям протокола XML-RPC, в сообщения программной шины DCOP. Выделение критичного к безопасности сервиса в отдельный демон, потенциальные возможности мониторинга всех обращений "из внешнего мира" к ресурсам компьютера и введения правил и политик управления "общением с внешним миром" -- это не все достоинства архитектурной идеи KDE. Простота протокола XML-RPC позволяет не просто писать клиентское ПО на любых языках программирования, но и быстро разрабатывать интерпретируемые "облатки" для созданных задолго до появления KDE программ, без низкоуровневой модификации интегрируя их в единое целое с новыми приложениями KDE. И наконец, XML-RPC позволяет практически полностью "отрывать" пользовательский интерфейс действительно сложных приложений (в первую очередь, научных и инженерных) от реализации собственно семантической части программы.

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

Но вернемся к архитектурным "инновациям" KDE. Настало время называть вещи своими именами, и потому слово инновация в предыдущем предложении закавычено. На самом деле, никаких особых инноваций во всем описанном выше нет -- все это в той или иной форме было задолго до появления самой первой версии KDE. С теми же проблемами "клея" столкнулись разработчики CDE, они использовали практически те же архитектурные решения (программная шина на основе механизмов ICE X Window и сокетов). XML-RPC -- красивая идея, породившая SOAP (Simple Object Access Protocol, "простой протокол доступа к объектам"), также не является изобретением команды KDE. И все-таки, если уж и раздавать "призы симпатий", то идеологи и разработчики KDE заслуживают, по мнению автора, самой важной награды: "За трезвое отношение к технологии и здравый смысл". К сожалению, таких призов никто не присуждает...

Оставшаяся часть "инноваций" в KDE также ничего неожиданного не преподносит. Если "склеивание" в пределах одного компьютера специально созданных компонентов осуществляется фактически программной шиной, "склеивание" внешних по отношению к компьютеру компонентов -- транслятором протокола XML-RPC в сообщения программной шины и, наконец, "вклеивание" классических приложений -- скриптовыми "облатками" XML-RPC, то на внутрикомпонентном уровне в KDE используется тривиальная слоистая (layered) архитектура с объектно-ориентированными "отклонениями". Библиотеки (слои) -- основа основ внутрикомпонентной модели KDE, с их помощью достигается и повторное использование кода, и стройная простая организация системы. "Каркас" (framework) библиотечной модели именуется KParts, и все приложения KDE являются "наполнениями" небольшого перечня "каркасных" моделей -- part ("часть", объединяющая пользовательский интерфейс и его функциональность, способная становиться частью другой part), plugin ("вставка", не обладающий свойством включения в part расширитель функциональности, возможно, с пользовательским интерфейсом), part manager ("управляющий частями", абстрактный механизм, отвечающий за компоновку parts в единое целое, запуск и остановку их выполнения и т. д.) и, наконец -- mainwindow ("главное окно" -- абстракция, собирающая воедино под управлением part manager множество необходимых parts, а также plugins).

Приложения

Инсталляция и надежность

Не подводя итогов