Здесь мы рассмотрим нынешнее состояние CORBA. В конце концов, вы покупаете продукт, а не стандарт. CORBA хороша ровно настолько, насколько хороша ее реализация. Далее, мы расскажем вам о том, что на сегодня в CORBA обстоит хорошо, что плохо, что вызывает тревогу. Эти выводы базируются на опыте совместного использования CORBA и Java. Мы завершим попыткой ответить на два ключевых вопроса: Можно использовать CORBA и Java сегодня для создания нового поколения клиент-серверных систем на базе Web? На самом ли деле эта технология созрела для выхода на ведущие позиции для создания наиболее важных приложений?
CORBA ORB; ХОРОШО. ПЛОХО. ТРЕВОЖНО
В этом разделе мы выскажем наше мнение, опираясь на опыт создания 3-хзвенных систем с использованием CORBA и Java. В сущности весь этот раздел представляет собой «уголок оратора».
CORBA ORB: Что Хорошо
Мы не хотели бы превращать этот раздел в панегирик на тему того, как прекрасна CORBA. Вместо этого, мы просто приведем десять наиболее важных достоинств, исходя из собственного опыта написания программ. Вот эти достоинства, без соблюдения какой-либо определенной градации:
Надежная основа создания распределенных объектов. Объектные ссылки CORBA представляют из себя очень мощное средство. Она сопоставлена с интерфейсом объекта, который является набором логически связанных операций, выполняемых над объектом. Сравните это поведение с RPC, который предоставляет указатель только на один метод. Более того, вы можете при определении интерфейсов использовать множественное наследование. Наконец, объекты CORBA полиморфны, один и тот же вызов интерпретируется по-разному в зависимости от типа объекта, который этот вызов получает. Конечно же, RPC не поддерживает ни наследование, ни полиморфизм, ни состояние отдельных объектов. Вьюод: объектные ссылки CORBA позволяют работать с хирургической точностью; они позволяют обратиться к нужным методам нужного объекта. Уникальные объектные ссылки обеспечивают наиболее эффективный способ доступа к удаленным сервисам в «межгалактических» сетях.
Callbacks: Мы всегда имели возможность очень эффективно использовать callback-объекты для управления клиентом со стороны сервера. Их можно использовать даже для создания клиентских приложения (или аплетов), которые автоматически получают данные, состояния и инструкции от своих серверов.
Прекрасная интеграция CORBA и Java. Мы были приятно поражены, как хорошо CORBA интегрируется с Java. Интерфейсы CORBA самым естественным образом отображаются в классы Java. Кроме того, Netscape/Visigemc Caffeine позволяет убрать все барьеры между CORBA и Java-программой. Нам также очень понравилось, как естественно некоторые Java-ORB используют потоки (threads) приложения-сервера, написанного на Java. Это показывает прекрасный уровень совместимости между средствами активации объектов CORBA и потоками Java. В такой среде мониторы транзакций будут просто способны творить чудеса. Очень высокая производительность Java ORB. Наши испытания показали, что ORB,, написанный на «чистой» Java, вполне способен защитить свои позиции перед более «закаленными» C++- конкурентами. В этом очень большую помощь оказывают ЛТ-компиляторы3.
Взаимодействие с C++-объектами. Вы были восхищены, насколько «гладко» происходит взаимодействие Java- и C++-объектов через ПОР. Это открывает перед объектами Java возможность обращаться к существующим корпоративным приложениям (и наоборот). Реальная независимость от языков программирования и операционных систем выводит Java/CORBA на ведущие роли в мире Internet.
Динамический поиск и «самоанализ» (introspection). CORBA-объекты могут почти все рассказать о себе сами. Динамические средства поиска, включая Trader Service, DII и Репозитарии Интерфейсов, обеспечивает надежную основу для поиска и вызова сервисов в «межгалактических» сетях. Все это позволяет создавать очень надежные гибкие системы.
Основа для построения современных 3-хзвенных клиент-серверных систем. Объекты CORBA идеально подходят для роли объектов-северов в 3-хзвенных и многозвенных системах. Прозрачная работа в локальном и удаленном вариантах. CORBA ОRB способен работать как в локальных настольных системах, так и взаимодействовать с любыми другими ORB, где бы они не находились. ORB может обслуживать вызовы объектов в пределах одного приложения, между различными приложениями на одном компьютере и между различными компьютерами, работающими под управлением различных операционных систем. Все эти детали совершенно не интересуют ваши объекты.
Универсальная инфраструктура «сервер-сервер». CORBA предоставляет развитую инфраструктуру «объект-объект», которая способна обеспечивать инкапсуляцию данных, полученных из различных источников. В дополнение к этому, вы можете использовать CORBA IDL для инкапсуляции целых существующих систем и «присоединения» их к ORB. Наконец, вы можете создать пул объектов-серверов. Каждый такой пул может управляться отдельным менеджером объектов (instance manager), который осведомлен о специфике объектов и способен обеспечить соответствующую среду выполнения. Эти менеджеры объектов на самом деле выполняют функции монитора транзакций для объектов. Они должны уметь управлять состоянием объекта в контексте транзакций, а так же обеспечивать распределение нагрузки между серверами и эффективную систему активации объектов. Объектные мониторы транзакций могут использовать магистраль CORBA для координации компонентов серверов и обеспечения устойчивости к отказам. В дополнение ко всему этому, TP Monitors могут взаимодействовать со встроенным в ПОР Сервисом Транзакций для координации транзакций при участии в них различных компонентов и контроля их состояния. Эта магистраль между серверами прекрасно подходит для межкомпонентного взаимодействия. Вы можете использовать эту возможность, например, для реализации отношения «подписка-опубликование» (publist subscribe), организации рабочих потоков (workflow) или создания целевого объединения взаимодействующих объектов.
Открытый стандарт. CORBA не контролируется каким-то одним производителем. Следовательно, вы всегда имеете возможность выбрать тот ORB, который вам подходит более всего. Наконец, CORBA не привязана к какой-либо одной платформе; она работает под управлением всех наиболее распространенных операционных систем на самых различных аппаратных платформах. Свобода выбора - это прекрасно! Открытость - чрезвычайно важное требование для «межгалактического» middleware.
CORBA ORB: Что Плохо
Где сервисы CORBA? Нам необходим полный набор их реализации на Java.
Где MOM? MOM — это аббревиатура для Message-Oriented Middleware (Сервера, ориентированные на использование сообщений). Этот сервис создает асинхронные очереди сообщений на стороне как клиента, так и сервера. Этот механизм позволяет приложениям клиента и сервера работать независимо друг от друга, в разное время и с разной скоростью. ORB должен поддерживать MOM для взаимодействия с клиентами, местоположение которых часто меняется, а также для повышения функциональности при работе в гетерогенных средах. Нам очень пригодилась бы возможность передачи объектов по значению; кроме того, очереди сообщений подходят для передачи агентов CORBA/Java.
В наш список полезных, но отсутствующих возможностей можно было бы поместить и другие существенные вещи. К примеру, мы хотели бы иметь расширения CORBA IDL на семантическом уровне. Для этого компоненты нуждаются в антологиях для построения вами собственных словарей. Хорошим примером такой технологии является Project X фирмы Apple.
CORBA ORB: Что Вызывает Беспокойство
После пяти лет «созревания» большинство вопросов, вызывающие беспокойство, были сняты. Осталось не так уж много проблем в ORB. В тяжелые старые времена, для того, чтобы нарушить нормальное функционирование ORB, достаточно было допустить «утечку» памяти где-то в сети. Сейчас «повалить» ORB намного сложнее, особенно при работе с Java. Что вызывает наибольшую тревогу при изучении ORB? Это серверная платформа, которая требует от пользователя реализации слишком многих элементов инфраструктуры. Это приводит к тому, что нам приходится заново создавать инфраструктуру вместо того, чтобы заниматься разработкой приложений. Мы думаем, что проблема возникла потому, что производители ORB не слишком задумывались о требованиях предъявляемых к серверной части системы. Нельзя просто сваливать свои проблемы на пользователей. Многие из первый пользователей CORBA тратили огромное количество времени и энергии для того, чтобы обеспечить масштабируемость серверов. Да, ORB действительно хороши, но кто-то должен обеспечить функциональность и масштабируемость серверов.
Вот наши «вечные» вопросы к поставщикам ORB:
Как вы обеспечите масштабируемость серверов? У нас все еще нет ORB, который был бы в состоянии поддерживать миллионы объектов-серверов вместе с их состоянием.
Где распределение нагрузки между серверами? Мы все еще ищем ORB который мог бы распределить нагрузку на сервер между несколькими процессорами. ORB должны иметь возможность предварительного создания объектов и копирования их состояний.
Где устойчивость к сбоям? Мы все еще не имеем ORB, который выполнял бы автоматическое переключение на копию объекта-сервера ра при возникновении проблем.
Справедливости ради надо отметить, что у конкурирующих технологий дела обстоят не лучше. DCOM все еще в ужасной форме; может быть, дело поправвит Viper. На сегодня единственной альтернативой для ORB являются процедура ориентированные мониторы транзакций. ObjectBroker фирмы Digital был использован с приложением, обслуживающим 10000 клиентов и 750000 вызовов методов в день. Источник: Gushing Group, Distributed Object Technology at Wells Faigo.
Другими словами, когда будет обеспечено взаимодействие серверной части ORB с мониторами транзакций, ODBMS и RDBMS? Поставщики ORB - это просто создатели middleware для решения коммуникационных задач, и они не имеют дело с обсуждаемыми проблемами. В самом деле, вы же не покупаете программные оболочки, ориентированные на разработку определенного класса приложений, у фирм, занимающихся реализацией протокола TCP/IP.
Кто же возьмется за решение поставленных задач? . Впрочем, есть основания считать, что разработчики мониторов транзакций наконец то приняли вызов .
МОНИТОРЫ ТРАНЗАКЦИЙ И ORB
Мониторы транзакций - прямые конкуренты распределенных объектных систем в борьбе за то, чтобы стать базовой платформой для создания и обслуживания 3 хзвенных клиент серверных приложений. Поэтому нет ничего удивительного, что возможности Брокеров Объектных Запросов ORB, таких, как CORBA и DCOM, внимательно изучаются и учитываются при разработке следующего поколения ТР Мониторов. Фактически, некоторый их основных поставщиков Мониторов Транзакций близки к реализации нового поколения систем, построенных "поверх" ORB. Мы знаем о трех крупных проектах создания базирующихся на ORB Мониторов Транзакций: Business Object Server Solution (BOSS) IBM, базирующийся на Tuxedo фирмы ВЕА Systems и Viper Microsoft. Разумеется, Viper может обслуживать только объекты DCOM. Чем могут быть ТР Мониторы полезны для ORB? В "чистых" реализациях CORBA или DCOM объекты могут существовать где угодно и когда угодно. Под управлением же ТР Мониторов поведение объектов становится более предсказуемым. Например, ТР Монитор может выполнить предварительное создание объекта, управлять его жизненным циклом и обеспечить идентификацию дна уровне транзакций. ТР Мониторы не любят неожиданных действий. Они предпочитают быть в курсе всех вопросов, касающихся программных сред. Наоборот, "чистые" объекты по своей природе тяготеют к анархии. Сочетание объектов и ТР Мониторов способно породить очень интересные конструкции.
Что могут сделать ORB для ТР Мониторов? ORB предоставляют стандартную транзакционную среду для управления объектами. ORB будут (или уже) встроены в наиболее распространенные операционные ситемы NT, OS/2 Waip, Windows95/98 и Macintosh. Кроме того, ОRB свободно распространяются в составе некоторых браузеров, тем самым ыступая в качестве основы для распределенных объектных систем, базирующихся на Java. На первое время, производителям ТР Мониторов не потребуется создавать свое middleware для управления транзакциями-как CORBA, так и DCOM содержат собственные сервера транзакий. Еще лучше то, что ТР Мониторы будут способны работать на стороне как клиента, так и сервера. Наконец, инфраструктура распределенных объектов сделает доступным для Мониторов Сервисы CORBA, включая использование метаданных, динамические вызовы, хранение объектов, отношения, события, фабрики компонентов, поиск по именам, лицензирование, безопасность и многое другое. В противном случае производителям ТР Мониторов пришлось бы все это создавать самим.
Объектный подход позволит упростить создание и управление сложными моделями транзакций такими, как вложенные транзакции и длительные транзакции (или рабочие потоки, "workflows"). Мониторы станут средой управления очень "разумными" компонентами. Если TP Мониторы и ORB договорятся играть по общим правилам, они смогут буквально творить чудеса. ТР Мониторы станут координаторами распределенных объектов в Internet и intranet. Вместо того, чтобы управлять методами классов, они будут управлять Java Beans, Oracle Cartridges, CORBA Business Objects и Vipenzed ActiveX'ми. Мониторы транзакций будут отвечать за предварительное создание компонентов, управление их состоянием и координацию поведения объектов в сетях. ТР Мониторы обеспечат широкий спектр важнейших сервисов, включая управление длинными транзакциями и транзакционными рабочими потоками, распределение нагрузки, управление транзакционными очередями, обеспечение устойчивости к сбоям и управление жизненным циклом объектов. ТР Мониторы помогут ORB выйти на уровень инструмента для создания наиболее ответственных приложений. В свою очередь, ORB откроют ТР Мониторам доступ к базовым технологиям создания клиент серверных систем в роли Дирижера Object Web.
Этикет OLTP: Пять Заповелей
Онлайновые Системы Управления Транзакциями (Online Transaction Processing, OLTP) имеют 30 летние традиции выжимание максимума возможного из доступных системных ресурсов для повышения производительности. Вот кто настоящий мастер в деле обеспечения масштабируемости. Большинство из наиболее известных в мире клиент серверных систем следуют правилам OLTP. Обычно вопросы синхронизации берут на себя Мониторы Транзакций. Для того, чтобы комфортно чувствовать себя в OLTP системе, ваше приложения должно твердо следовать следующим заповедям:
Не занимайте системные ресурсы на слишком большое время. Никогда не следует "заглатывать" любые виды системных ресурсов, включая соединения с базами данных, блокировки, коммуникационные сессии, дескрипторы файлов и объекты серверы. Клиент не должен фиксировать состояние на сервере в течение долгого времени.
Для фиксации завершения выполняемых действий используйте транзакции. Вы должны использовать транзакции для того, чтобы все остальные знали, когда завершен процесс внесения изменений. Мониторы транзакций, SQL БД и ODBMS используют границы транзакций для управления и освобождения используемых вами системных ресурсов. Транзакции также используются для синхронизации действий OLTP объектов на серверах. Наконец, транзакции .обеспечивают соответствие требованиям ACID, используемым для ликвидации последствий некорректных действий например, с помощью менеджера ресурсов.
Следует стремится к повторному использованию ресурсов в интересах различных клиентов. Сервера должны предварительно создавать пул ресурсов и выделять их клиентам по их требованию. Когда клиент завершает действия (или просто освобождает ресурс), сервер должен вернуть его в пул, чтобы ресурс был доступен другому клиенту. Ресурсов сервера всегда недостаточно: они должны использоваться в разделяемом режиме.
Сделал свое дело, и уходи". Пэт Хелланд (Pat Holland) архитектор Viper из Microsoft - называет это "тактикой хирургического воздействия". Сервер должен предоставить независимые небольшие сервисы для выполнения одной задачи. Клиент должен "войти", выполнить необходимые действия и тут же "выйти".
Имейте дело с большим количеством маленьких вещей. Обычно это означает, что ваша программа должны быть выполнена в "компонентном" стиле. ТР Мониторы первыми потребовали соблюдения определенной дисциплины со стороны серверных компонентов. Тем не менее, обычно такие компоненты имеют "процедурную", а не объектную, архитектуру. ORB и новое поколение Мониторов Транзакций IBM BOSS, Microsoft Viper и ВЕА Systems ObjectWare предназначены для "дирижирования" объектами серверами.
Эти пять исключительно простых правил являются тем ядром, которые архитекторы OLTP систем успешно использовали для создания нескольких чрезвычайно сложных распределенных систем. Большинство из этих правил применимы также и к объектам CORBA на серверах.
Готова Ли CORBA Играть Ведущую Роль В Архитектуре Клиент Сервер?
Перед тем как закончить разговор о нынешнем состоянии CORBA, мы хотели бы высказать свои соображения по этой проблеме. Во первых, CORBA вернула интерес к клиент серверным системам. Сейчас удачное время для того, чтобы быть программистом. Во вторых, эта история не имеет завершения. Object Web только "пошел на взлет". Двумя базовыми технологиями для Object Web являются CORBA и Java. Тем не менее, только CORBA и Java недостаточно.
Значит ли это, что еще не наступило время CORBA и Java? Конечно же, нет! Главное впечатление, которое должно у вас возникнуть - что вы можете и должны начать работу с ними прямо сейчас. Даже в своем нынешнем виде, CORBA/Java предоставляют наилучшую на сегодня платформу для создания Web ориентированных клиент серверных приложений.
Кроме того, объектам CORBA/Java суждена долгая жизнь, так что вам не придется без конца переписывать ранее созданный код. Концепция распределенных объектов только набирает силу. Ваши приложения должны быть совместимы с новыми версиями используемых средств. В этом великое достоинство унифицированного стандартного подхода.
Каков цикл развития CORBA? Его вид очень типичен для новых клиент серверных технологий. В первые годы упор делался на расширение функциональности. "Mission critical" характеристики появились позднее. CORBA только становится инструментом для создания наиболее ответственных и сложных приложений. Производители ORB получают огромное количество откликов от их измученных и нетерпеливых пользователей. Вследствие этого, они повысили качество и надежность ORB. Мы надеемся, что в будущем ORB станут такими же продвинутыми и надежными, как ТР Мониторы сегодня. Используйте а ваших первых клиент серверных CORBA приложениях только объекты серверы, не имеющие состояния. Ими гораздо проще управлять, и не возникает никаких проблем, связанных с масштабируемостью. К использованию объектов с состоянием после появления Объектных Мониторов Транзакций и доступных ODBMS. Поверьте нам, эта та часть инфраструктуры приложения, которую не следует создавать самому.
назад | содержание | далее