Чудес не бывает, и уроки прошлого применимы и сегодня
В июньском номере Queue за 2006 г. Мичи Хеннинг (Michi Henning) представил очень хорошую концентрированную историю CORBA и привел обсуждение того, как некоторые технические ограничения этой технологии способствовали ее краху. Хотя эти ограничения, несомненно, содействовали закату CORBA, имеется широко распространенное мнение, что основной причиной явилось доминирующее влияние Web-сервисов. Это мнение подкрепляется верой в то, что доминирующее положение Web-сервисов в области распределенного компьютинга свидетельствует о техническом превосходстве этой технологии над предшествовавшими ей технологиями, такими как CORBA и DCOM.
Проработав в области распределенных систем довольно много лет – начиная с того времени, когда построение распределенной системы в действительности означало упаковку бит в пакеты UDP с использованием любовно сделанного вручную кода на языке C, – я считаю это предположение безосновательным. Хуже того, оно свидетельствует о нежелании по достоинству оценивать те аспекты предшествующих систем, которые были хорошо продуманы и разработаны. Это является симптомом менталитета «серебряной пути», когда технология Web-сервисов рассматривается как радикальный отказ от прошлого, позволяющий окончательно устранить сложность разработки и построения распределенных систем.
На самом ли деле Web-сервисы отличаются от предшествующих систем? Одним из значительных преимуществ, приписываемых технологии Web-сервисов, является то, что она нацеливается на поддержку сервис-ориентированной архитектуры (Service Oriented Architectures, SOA). Близость этих понятий подчеркивает наличие слова «сервис» в названиях их обоих. «Ориентация на сервисы» часто противопоставляется стилю «мелкоструктурных» (fine-grain) распределенных объектов, который считается определяющей характеристикой систем, основанных на CORBA. Конечно, верно, что в CORBA обеспечивается распределенный доступ на уровне индивидуальных объектов. Однако следует заметить, что в CORBA также поддерживаются рекурсивно определяемые структуры данных, которые позволяют достаточно просто обмениваться сложными структурами данных, передаваемыми по значению.
В середине 1990-х я работал в составе группы, которая проектировала и разрабатывала основанную на CORBA систему, обеспечивающую с использованием этой возможности обмен информацией об управлении разработкой и сопровождением программного обеспечения. Мы спроектировали структуру данных CORBA, представляющую дерево узлов. У каждого узла имелось имя, значение и некоторые другие атрибуты. В нем также содержались дочерние узлы, каждый из которых обладал такой же структурой. Конечно, у листовых узлов потомки отсутствовали. Эту структуру было относительно просто представить на языке CORBA IDL с использованием конструкций struct, union и array. Любое дерево, состоящее из таких узлов, можно было легко передать посредством вызова метода в CORBA – подсистема поддержки времени выполнения производила сериализацию дерева и передавала его массовым образом получателю. Кроме того, такое дерево вообще не содержало ссылок на объекты и использовалось исключительно для обмена информацией по значению. Наконец, можно заметить, что структура и содержимое этого дерева не случайно напоминают DOM-представление XML-документа.
По моему мнению, этот пример демонстрирует, что хотя CORBA, безусловно, могла поддерживать мелкоструктурные объектные архитектуры, она никоим образом не навязывала применение этого стиля. Безусловно, простота реализации мелкоструктурной архитектуры могла соблазнять разработчиков, обладающих недостаточным опытом построения распределенных систем. Но это вовсе не означает, что мелкоструктурные объекты полностью бесполезны. При использовании мультипроцессорной системы, когда требования к пропускной способности и задержке существенно отличаются от соответствующих требований к приложению, распределенному в Internet, мелкоструктурные объекты могут обладать некоторой привлекательностью.
И в этом состоит суть проблемы. Когда мы создавали упоминавшуюся выше систему, мы могли выбрать подход с определением множества объектных интерфейсов и передачей между ними ссылок. Но мы знали, что к информации об управлении, в основном, будет требоваться массивный доступ, и это лишало всякого смысла передачу информации по кусочкам путем многократного вызова методов. Вместо того чтобы понадеяться на то, что эту нашу проблему каким-то образом решит CORBA, мы решили сами выбрать те элементы CORBA, которые обеспечивали требуемое нам поведение. Мы создали «сервис-ориентированное» решение, потому что это имело смысл.
Применение Web-сервисов не гарантирует построение хорошей распределенной системы, а использование CORBA не обязательно приводит к созданию плохой системы. Web-сервисы не могут волшебным образом предоставить системе возможность эффективно справиться с ограничениями пропускной способности и задержки. Эта технология не может устранить трудности, возникающие из-за частичных отказов и зависимостей в системах, которые могут становиться временно недоступными. К счастью, люди проектируют и создают распределенные системы на протяжении многих лет, часто используя технологии, подобные CORBA, DCOM, и более ранние технологии. Не надо думать, что вся эта работа вытесняется волшебством Web-сервисов, поскольку чудес на свете не бывает, а уроки прошлого применимы и сегодня.
Терри Коатта (Terry Coatta) является членом редакционного совета ACM Queue. Он работает менеджером по продукции компании Vitrium Systems Inc., которая производит программное обеспечение для отслеживания и контроля доступа к PDF-документам. В прошлом он занимал должности вице-президента по разработкам в компании Silicon Chalk, создававшей программное обеспечение реального времени для использования в высшей школе, и директором по разработке распределенных систем в Open Text Corporation. Он получил степень PhD в области компьютерных наук в University of British Columbia.
