Тестовый центр PC Week Labs считает CORBA самой современной технологией, но за DCOM стоит сила Microsoft
Сообщаю хорошую новость. Интеграторам платформ, разработчикам приложений и менеджерам рабочих групп (уже в ближайшее время) не придется выбирать между удобством DCOM (модель распределенных составных объектов) и мощью поддерживаемого многими производителями стандарта CORBA (общая архитектура посредника запросов к объектам), поскольку вскоре появятся возможности их совместной работы, что позволит приложениям использовать достоинства обоих подходов.
Но есть и плохие новости. Так, обе технологии требуют от разработчика глубокого их понимания. Кроме того, чтобы сохранить привычный для традиционных приложений уровень производительности и богатство интерактивных возможностей и одновременно предоставить разработчикам гибкость компонентного ПО и “запас прочности”, необходимый для распределенной среды приложений, компаниям придется использовать как CORBA, так и DCOM.
DCOM иногда называют “COM с удлиненным проводом”. Она позволяет приложениям в настольных системах работать с удаленными компонентами через разнообразные виды сетевых соединений, опираясь на привычные интерфейсы прикладного программирования COM API, которые разработчики уже применяют в компонентных приложениях для Windows.
COM API произрастают из технологии OLE корпорации Microsoft, и их генеалогию можно проследить от конца до самого начала - выхода еще весьма сырой технологии Dynamic Data Exchange (динамический обмен данными), впервые предоставившей разработчикам нечто похожее на открытый стандарт программируемого взаимодействия приложений под управлением Windows.
Привычность COM, однако, имеет и теневые стороны. Действительно, простые задачи в локальной среде легко решаются с помощью COM, и переход к сетевому распределенному взаимодействию на базе DCOM тоже не труден, но это вовсе не означает, что использование DCOM всегда предпочтительнее применения более сложной технологии CORBA. Взобраться на дерево, конечно, проще, чем построить и запустить ракету, но искать дерево повыше для путешествия на Луну вряд ли разумно.
Слабость модели DCOM заключается в том, что для приложений, построенных на ее базе, сеть выглядит, как локальная среда. В некоторой степени структура DCOM аналогична структуре ПК, предполагающей наличие одного пользователя - центра управления системой - и локального пула памяти - единственного централизованного ресурса, подлежащего разделению. Эти предположения перестают работать или же требуют поддержки дополнительных слоев ПО, как только DCOM вторгается в область более далеких соединений небезупречной надежности, и множества конкурирующих в борьбе за ресурсы приложений.
DCOM создает и уничтожает объекты динамически; каждый объект является набором указателей на интерфейсы, предоставляемые им другим объектам. Если от объекта ничего не зависит, он исчезает. Но до тех пор, пока это не так, он должен оставаться активным.
В CORBA применен другой подход. В нем объекты связаны с некоторыми сущностями, жизнь которых продолжается даже тогда, когда объекта нет в памяти. Центральная задача ORB (посредник запросов к объектам) - предоставить объектам доступ к услугам друг друга, скрывая при этом все аспекты их расположения и состояния. Если некоторый CORBA-объект обращается к услугам другого, то дело ORB определить, где этот другой объект расположен, и активизировать его в случае необходимости, причем незаметно для запрашивающего объекта.
Жизненно важно осознать практические трудности, проистекающие из подхода, реализованного в DCOM. Если у DCOM-сервера есть активные клиенты, он должен оставаться в памяти даже в те периоды времени, когда этим клиентам внимания не требуется. В CORBA сервер может удалить сам себя из памяти, чтобы освободить ресурсы другим задачам, поскольку через ORB любые объекты-клиенты могут обратиться к этому серверу, как только им это понадобится.
Если сетевое соединение с DCOM-клиентом пропадает, то сервер может заключить, что клиент больше не существует, и “самоуничтожиться”. При восстановлении соединения объекту-клиенту придется обнаруживать и решать эту проблему самостоятельно. Такие “осиротевшие” объекты должны быть снабжены логикой обработки ошибок, которую лучше было бы реализовать и оттестировать однажды, в рамках ORB, нежели раз за разом изобретать заново.
На некоторые из архитектурных изъянов DCOM, возможно, будет обращено внимание при создании COM третьего поколения. Ожидается, что в COM 3 войдет среда периода выполнения, повышающая надежность работы системы при помощи Java-подобных средств обработки ошибок.
Роль Microsoft на рынке столь велика, что имеется мощный финансовый стимул найти решение, сколь бы неэлегантным оно ни было, и сделать-таки конфетку из того, что есть сейчас. Если этого не совершит Microsoft, пробелы будут восполнены другими компаниями.
Относительно DCOM, как и о всякой другой программной технологии, почти невозможно уверенно сказать, что она не сможет обеспечить какую-либо определенную возможность. Всегда можно добавить дополнительные слои ПО (хотя обычно за счет потери доли производительности, простоты и надежности). Как бы то ни было, DCOM обладает по крайней мере одним достоинством - эта модель контролируется единой компанией с богатой историей доведения продуктов до ума в их третьих версиях.
Ответные удары CORBA
Аргументация в пользу CORBA основана на том неявном предположении, что разные ORB могут взаимодействовать, реализуя свои достоинства в рамках гетерогенных сетей. Однако опыт прошедших лет показывает, что надеяться на это вряд ли стоит. DCOM - это продукт, а CORBA - всего лишь спецификация, и различий между конкурирующими реализациями CORBA было достаточно для того, чтобы воздвигнуть серьезные барьеры на пути ее практического применения.
В последнее время совместимость версий ORB существенно улучшилась. Это связано с появлением явных лидеров на рынке, например фирмы Visigenic Software. Лицензии на ее ORB купили Netscape Communications, Oracle и Novell, с основными производителями (включая IBM, Netscape, Oracle и фирму Sun Microsystems) она заключила также соглашения о поддержке и взаимной совместимости ORB. Десятки миллионов Web-клиентов Netscape, использующих Visigenic ORB, придадут CORBA импульс, вполне сравнимый по мощности с энергией “приливной волны”, - тактикой, обычно применяемой Microsoft при продвижении своих продуктов.
Перспективы развития многоплатформных компонентов тесно связаны с вопросом создания многоплатформных ORB. DCOM от Microsoft представляет собой средство обслуживания компонентов ActiveX, которые обычно содержат “родной” код, специфичный для одной платформы, например Windows на X86-ПК. CORBA же “подружилась” с технологией Java фирмы Sun и моделью компонентов JavaBeans. В ней появилась поддержка переносимых модулей в байт-коде, исполняемых на реализованной для локальной платформы виртуальной машине Java.
Закончив период заигрывания со специфическим для Java подходом, называемым Remote Method Invocation (удаленный вызов методов), Sun и другие адепты Java теперь делают выбор в пользу CORBA как Java-решения для сетевого взаимодействия компонентов. Библиотека Java-классов фирмы Sun, JOE (Java Objects Everywhere - Java-объекты повсюду) позволяет Java-программистам использовать механизмы CORBA с тем же самым удобством (за счет инкапсуляции механизмов в классах), которое Java предоставляет при работе с другими службами, например Internet-соединениями.
Компоненты JavaBeans, взаимодействующие друг с другом в гетерогенных сетях на основе надежных стандартов CORBA и выполняющиеся на любом процессоре, поддерживающем интерпретатор виртуальной машины Java, предоставляют промышленным разработчикам просто потрясающую гибкость.
Эти перспективы гораздо заманчивее тех, которые сулит встречное предложение Microsoft, основанное на многоплатформной поддержке DCOM. Microsoft всего лишь обещает, что компоненты на разных платформах смогут вызывать друг друга через единообразные (но ненадежные) протоколы DCOM.
Тем не менее степень присутствия Microsoft на компьютерном рынке и широкая поддержка DCOM в инструментах разработки, выпускаемых сторонними фирмами, гарантируют, что на ИТ-профессионалов в промышленности будет оказано сильное давление, склоняющее их к сохранению верности модели DCOM при масштабировании ими вверх приложений уровня подразделений. В то же время приверженцам CORBA придется ответить на вызов, доказав на деле взаимную совместимость своих продуктов. Им также придется продемонстрировать, что теоретическая мощь CORBA способна воплотиться в жизнь, и сделать это прежде, чем Microsoft укрепит DCOM настолько, что эта технология сможет серьезно соперничать с CORBA в качестве крупномасштабного решения.
Питер Коффи (PC Week Labs)
