Обзор CORBA

Технология COM - отличная технология... от других

Итак, " технология COM ". Аббревиатура COM расшифровывается просто, это - Component Object Model - компонентная объектная модель. Иногда говорят и " модель COM ". Сутью данной технологии является то,что программы строятся из компонент, которые состоят из объектов. Само по себе это обстоятельство не является последней новостью в области программостроения - модульная архитектура и объектно-ориентированный подход к построению программ давно являются признанными стандартами de facto. Новостью является то, что является этими компонентами и объектами - ими является непосредственно исполняемый двоичный код. Да-да, не " включаемые исходные тексты " компилируемые совместно с проектом, не " библиотеки стандартных программ ", присоединяемые линкером, а непосредственно исполняемые файлы, которые никак не надо "связывать" со своим проектом - их достаточно зарегистрировать в операционной системе и они будут доступны любой программе исполняющейся на данной машине. Т.е. их использование в своей программе производится " без использования операций сборки модуля ".

Это ли новость? Такая технология называется "динамическая загрузка", она давно известна и её преимущества очевидны. А модули, которые позволяют загружать себя таким образом, называются DLL. И в системе, именуемой Microsoft Windows такая технология известна от самого её рождения... А DLL и есть тот самый "двоичный исполняемый модуль", который может быть присоединен к программе лишь на стадии её выполнения.

Выходит, если весь проект распределить по нескольким динамическим библиотекам, то получатся "двоичные компоненты"?

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

Другое отличие COM, уже от привычных объектов в стиле объектно-ориентированного программирования (ООП), состоит в том, что объекты ООП известны только компилятору. Это - абстракции, в которых мыслит программист и которые компилятор превращает в двоичные структуры " данные + код ". Объекты ООП существующие в разных единицах компиляции и, тем более, помещенные в разные двоичные модули, ничего не могут друг о друге "знать" просто потому, что их там нет и никогда не было. Не случайно заголовочные файлы, содержащие описания всех объектов проекта, подаются на вход именно компилятора - потом они уже никому не нужны. Объекты же COM - действительно существуют в двоичном виде как объекты. И в таком качестве известны всем, кто испытывает в них нужду.

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

Надеюсь, что в прошлый раз, хорошо ли, плохо ли, но ответ на вопрос "в чём суть COM -технологии" был сформулирован. Сегодня мы рассмотрим некоторые хорошие детали COM подробнее. Итак, в прошлый раз утверждалось - COM -объект, это объект, который доступен так же, как и "локальный" объект данного проекта, хотя, фактически, он не располагается в данном проекте, а есть уже готовый двоичный исполняемый ресурс. И в предыдущей же статье утверждалось, что он может располагаться где угодно. Там же говорилось, что это - некая DLL. Суровая правда состоит в том, что объект COM может располагаться действительно где угодно. И DLL - не единственная форма его существования. COM -объект может жить и внутри EXE -модуля, который может исполняться независимо (параллельно!) от модуля, который использует этот объект, и даже - этот самый модуль может исполняться совсем на другом компьютере! Вы где-нибудь видели подобное? И зачем это нужно?

Начнем с ответа на второй вопрос. Зачем это нужно и, если нужно, насколько это важно? Представьте себе ситуацию - у вас есть хороший, славный, удачный алгоритм. Скажем, сортировка или "вычисление средней температуры по больничной палате". Вообще говоря, этот алгоритм появился не как самостоятельная сущность, а в процессе разработки какой-то большой программы мониторинга этой средней температуры. Заказ был именно на неё, и работать эта программа должна была на компьютере дежурной медсестры. Только вот в процессе работы над этой программой выяснилось, что существует и значительно реже используемая и совсем не первоочередная задача подсчёта всевозможнейшей статистики, которая, может быть, будет отдана вам на реализацию позднее. А может быть - и не будет отдана. Во всяком случае, такую возможность вы видите, и при подсчёте этой самой статистики вы будете использовать тот же алгоритм. Ваши возможные действия? Оформить библиотечной процедурой? Дело хорошее, но в расчёте той статистики используются не только ваша программа, но и программы других разработчиков. И они - мыслят так же. Сколько отдельных библиотек они создадут? Сколько при этом образуется независимых "единиц поддержки"? И как будет жить тот, кто в этих условиях будет писать статистику? Вот если бы у вас была возможность объявить свою, находящуюся не в библиотеке, а прямо в исполняемом модуле, процедуру доступной для вызова из другого исполняемого модуля, то вы бы убили сразу двух зайцев: 1) вам не нужно поддерживать два файла вместо одного; 2) вам не нужно как-то специально тестировать вашу библиотеку. Есть еще и третье обстоятельство - эту процедуру из вашего модуля "не выковырять", и, если у вас есть какие-то алгоритмы, составляющие ваше know how, то вам не нужно их помещать в значительно более беззащитную объектную библиотеку, которая, к тому же, может распространяться отдельно от вашего модуля. И - отдельно от вашего гордого имени тоже.

Вместо всего этого кошмара вы просто объявляете COM -объект, находящийся внутри вашего исполняемого модуля. Объявляете как его вызвать - и всё. Более того, если компьютер статистика соединен с компьютером медсестры сетью, то - то статистику даже не нужно иметь ваш модуль на своей машине - он сможет его запустить (и получить доступ к функциональности вашего COM -объекта) на машине медсестры со своей машины. Если вы с уважением относитесь к авторскому праву, то знаете, что программы не продаются (ввиду очевидной глупости такого подхода), а лицензируются для использования. Платить приходится, фактически, по числу процессоров, которые могут исполнять программу. Запуск на машине медсестры не нарушает лицензионного соглашения, а запуск второй копии на машине статистика - нарушает его. Эта особенность программы становится выгодной, если программа, содержащая не часто используемую функцию, стоит дорого. Конечно, для вас обстоятельство, понуждающее клиента купить вашу программу еще раз, - выгодно. Но, подумайте, были бы вы в том же лагере, если бы уже вы писали бы ту же статистику с использованием функций из чужих программ?

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

В этом - пожалуй, самое большое преимущество COM. Вы знаете, что практически никогда не встречается случай, когда бы ваша программа в момент ее окончания была бы именно тем, что вы представляли себе, когда начинали ее писать. Изменения технического задания, переделки во внутренней конструкции, изменение требований заказчика - да мало ли что может произойти, почему вдруг вашей программе понадобилось стать другой. Если вы работаете над большим проектом, то в какой-то момент времени это становится проклятием - вы не можете изменить что-то без того, чтобы не "поплыло" что-то другое. Если же ваш проект делается как "грамотный COM ", то фактически, вы разбиваете его на много согласованно работающих, но самостоятельных частей. Причем - несущественно, работают ли эти части на одной машине или на нескольких... Конечно, и здесь не все так просто, но переконфигурирование безусловно проще переписывания и последующего полнообъёмного тестирования. Что делает COM очень удобной архитектурной платформой для проектов, масштаб которых заранее не очень понятен и впоследствии может измениться.

Кроме того, поскольку сопрягаются двоичные объекты, - не все ли равно на каком языке эти объекты написаны?! Кроссплатформенная совместимость - бич Божий, кроме обмена примитивными типами и вызова примитивных процедур, как правило, двинуться не удается - не знает компилятор Pascal или Visual Basic как вызывать класс из модуля, написанного на C++. А что такое COM -объект - все они прекрасно знают. Более того, пользователи VB могут с удовлетворением отметить, что все идентификаторы, которые они с любовью разделяют в тексте точками, обозначая цепочечную ссылку, фактически являются COM -объектами. Т.е. для того, чтобы в обиход VB ввести "свой" объект его нужно сделать COM -объектом. И - всё.

Прочитав это читатель вправе засомневаться - так хорошо в одном месте не бывает. И будет прав - помимо таких больших достоинств технология COM имеет и немалые недостатки. О которых - в следующий раз.

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

Ну просто не может быть, чтобы в такой бочке мёда не было хотя бы маленькой ложки дёгтя! И дёготь действительно есть...

Во-первых, технология COM - сложная технология. Сложная как в концепции, так и в реализации. Она - намного сложнее, чем технология С++, реализуемая компилятором. Эта сложность не должна пугать - к настоящему времени разработано достаточное количество инструментов и средств разработки, которые позволяют "легко писать" и "легко использовать" COM -компоненты. Но эта сложность есть. На её преодоление тратятся ресурсы компьютера во время выполнения, а слабо понимающий концепции COM программист, несмотря на все эти редакторы, не сможет создать что-то приемлемо работающее, большее, чем примитивный пример. К счастью, это стандартная проблема - умение программировать есть не умение писать код, а только умение мыслить соответствующими категориями и конструкциями. И на VB можно написать плохо работающую программу, хотя на C++ сделать это значительно легче:). Никакая технология не в состоянии предложить приемлемого решения этой проблемы - технические средства могут только избавить от рутины, но не от необходимости думать и понимать.

Во-вторых, технология COM - замкнутая технология. Её решения применимы пока только на платформе Microsoft. Нельзя сказать, что другие платформы не предлагают ничего подобного, но это - другие, несовместимые на двоичном уровне с COM технологии.

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

В-четвертых... давайте остановимся на этом. Всякое решение имеет область своего определения, вне пределов которой его использование становится попыткой воспользоваться ластами на заснеженном склоне. Технология COM - не исключение. С использованием этой технологии можно решить немало задач уровня настольного приложения или уровня локальной сети на платформе Microsoft. Это получается очень удобно и практично - все решения Microsoft так или иначе эту технологию поддерживают, поэтому появляется возможность их интеграции в собственное изделие. Но на платформе COM нельзя решить всех задач.

Для читателя, который бы хотел сам сравнить преимущества и недостатки технологий COM и CORBA ниже я привожу две ссылки (фактически, в Сети можно найти их значительно больше). Следует знать, что принципиально эти технологии сравнимы очень относительно, поскольку ориентированы на решение задач совершенно разного уровня и, если можно так выразиться, ориентированы на решение задач с разных концов. Я хочу напомнить - " COM или CORBA?" это такая же "религиозная война", как " C или Pascal?" или " NT или Unix?"

CORBA (расшифровывается как Common Object Request Broker) это технология, которая позволяет рассматривать компоненты распределенной системы как объекты, отвечающие некоторым определенным интерфейсам. Эта технология дает возможность единым образом конструировать эти интерфейс при помощи специального декларативного языка IDL (Interface Definition Language). При этом интерфейс и его описание не зависит от используемого языка программирования, операционной системы или архитектуры процессора. Таким образом, один объект может быть написан на C++, другой --- на Java, и эта два объекта могут успешно друг с другом взаимодействовать и при этом не заботиться о формате данных (например, представления целых чисел или символов).

Эта возможность очень удобна для программистов, потому что используя такой подход можно конструировать взаимодействие между распределенными объектами при помощи тех же средств, которые применяются для описания взаимосвязей обычных объектов в пределах одной программы на одном компьютере. Популярные CASE-средства, такие как Rational Rose, WithClasses или Together, позволяют создавать UML-схемы и экспортировать их в описания интерфейсов IDL.

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

Под названием "реализация CORBA", по сути, понимается как раз наличие конкретного ORB и средств для общения с ним. Кроме того, в реализацию CORBA входят дополнительные утилиты, такие как транслятор интерфейса, написанного на IDL, в код, который будет обеспечивать поддержку сетевых средств CORBA в конкретном языке программирования (например, Java или C++). Таким образом, один ORB обеспечивает средства для общения объектов, написанных при помощи средств, с ним поставляемым.

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

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

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

interface Random { // return non-negative long // integer in the interval [0, 2^31) long lrand48(); // return signed long integer // in the interval [-2^31, 2^31) long mrand48();};

Это реальный интерфейс демонстрационного объекта, доступный по адресу random.org. Объект идентифицируется строкой

IOR:000000000000000f49444c3a52616e646f6d3a312e3000000000000100000000000000500001000000000016706c616e7874792e6473672e63732e7463642e69650006220000002c3a5c706c616e7874792e6473672e63732e7463642e69653a52616e646f6d3a303a3a49523a52616e646f6d00

и позволяет получить случайное число. Смотря на эти данные, пользователь объекта ничего не знает о том, как устроен генератор случайных чисел, на каком языке программирования он написан и где находится. Но после некоторых предварительных действий в своей программе (инициализация ORB) он может использовать этот генератор случайных чисел как обычный объект, который написан на используемом языке программирования:

for(int i = 0; i < 10; i++) printf("%li ", obj->lrand48();

Вообще говоря, клиент может вообще сначала не знать интерфейса объекта, который пытается использовать. Средствами ORB можно узнать этот интерфейс во время выполнения (без IDL) и сгенерировать запрос к объекту на основе его интерфейса.

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

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

В последние 2-3 года резко возрос интерес к так называемым распределенным системам. Под распределенными системами обычно понимают программные комплексы, составные части которых функционируют на разных компьютерах в сети. Эти части взаимодействуют друг с другом, используя ту или иную технологию различного уровня - от непосредственного использования сокетов TCP/IP до технологий с высоким уровнем абстракции, таких, как RMI или CORBA.

Рост популярности распределенных систем вызван существенным ужесточением требований, предъявляемых заказчиком к современным программным продуктам. Пожалуй, важнейшими из этих требований являются следующие:

• Обеспечение масштабируемости систем, т.е. способности эффективно обслуживать как малое, так и очень большое количество клиентов одновременно.
• Надежность создаваемых приложений. Программный комплекс должен быть устойчив не только к ошибкам пользователей (это определяется главным образом качеством клиентских приложений), но и к сбоям в системе коммуникаций. Надежность подразумевает использование транзакций, т.е. гарантированного перехода системы в процессе функционирования из одного устойчивого и достоверного состояния в другое.
• Возможность непрерывной работы в течение длительного времени (так называемый режим 24x7, т.е. режим круглосуточной работы в течение недель и месяцев).
• Высокий уровень безопасности системы, под которой понимается не только контроль доступности тех или иных ресурсов системы и защищенность информации на всех этапах функционирования, но и отслеживание выполняемых действий с высокой степенью достоверности.
• Высокая скорость разработки приложений и простота их сопровождения и модификации с использованием программистов средней квалификации.

Оказалось, что обеспечить соответствие этим требованиям, используя традиционные технологии - а именно, двухзвенные системы “клиент-сервер”, в которых в качестве серверов выступают системы управления базами данных, почти невозможно.

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

Данный обзор содержит сравнительный анализ двух наиболее популярных и комплексных систем создания распределенных приложений, а именно, CORBA консорциума OMG и COM (DCOM, COM+) фирмы Microsoft. Этот обзор предназначен главным образом для менеджеров проектов, руководителей информационных служб и др., т.е. для тех, кому приходится принимать ответственные, “стратегические” решения. Вследствие этого, в нем будут отсутствовать чисто технические аспекты обоих технологий, которые интересны только для разработчиков.

Кроме того, при написании обзора не ставилась задача сделать окончательный вывод типа “... таким образом, CORBA (COM), бесспорно, лучше, чем COM (CORBA)”. Связано это не с модной в наше время “политкорректностью” или отсутствием у автора своей точки зрения по этому вопросу. Дело даже не в том, что существуют определенные трудности с формализацией такого сравнения - я мог бы представить результаты сравнительных анализов, в которых используются численные оценки (баллы), выставленные экспертами, весовые коэффициенты и прочее, что придает отчету серьезный и весомый вид. Дело в том, что COM и CORBA можно сравнивать только с учетом определенных допущений. Отказ от таких допущений легко позволяет получить какой угодно результат. Вот эти допущения:

• CORBA, в отличие от COM’а, является концепцией, а не ее реализацией. Когда мы говорим “COM”, то понимаем под этим скорее набор конкретных средств - элементов операционной системы, библиотек, утилит и т.п., являющихся составной частью того, что называется Microsoft Windows. Под термином “CORBA” понимается именно сложная и развитая концепция, сформулированная на уровне специального языка описаний - IDL. Реализации же этой концепции могут сильно отличаться друг от друга по различным критериям, наиболее важным в том или другом случае. Inprise/Corel VisiBroker и Application Server, BEA WebLogic, Iona Orbix, Oracle Application Server и “картриджи” Oracle, IBM BOSS - все эти продукты используют те или иные возможности CORBA. Технология Sun Enterpise JavaBeans создана поверх CORBA и использует такие ее возможности, как удаленный вызов объектов, службу имен, управление транзакциями. Реализация EJB фирмы Inprise связано с CORBA еще более тесным образом. Мы будем сравнивать COM и CORBA именно как концепции создания распределенных систем, а не как ту или иную их реализацию.
• При работе с реальным проектом необходимо учитывать область применения той или иной технологии. COM (как цельное и комплексное решение) способен функционировать только под Windows NT/Windows2000. Рассуждения о переносе COM на другие операционные системы в настоящий момент носят скорее рекламный характер. Ни компонентная модель COM (т.е. ActiveX), ни монитор транзакций (Microsoft Transaction Server, MTS) не способны работать нигде, кроме Windows, и сама Microsoft не проявляет никакой активности в этом напрвлении (вопросами переноса тех или иных элементов COM на другие платформы занимается консорциум Open Group). CORBA является многоплатформенным решением просто по определению.
• Помимо чисто технологических аспектов, при принятии решения необходимо оценить затраты на закупку необходимого программного обеспечения, его сопровождения и обучение персонала. COM (в отличие от CORBA) официально является бесплатной технологией. Вы получаете все необходимое, просто приобретя, например, Windows NT Server. (Кстати, сам факт конкуренции дорогостоящей технологии с “аналогичной”, но бесплатной, многое говорит об их технических возможностях).
• Наличие готовых серверов приложений, пригодных для решения вашей задачи. Если Вы можете решить свои проблемы, используя функциональность Microsoft Office, то ничего лучше COM вы, естественно, не найдете.

Таким образом, главной задачей настоящего обзора является попытка помочь руководителю того или иного уровня принять квалифицированное решение в каждом конкретном случае. Поскольку и CORBA, и COM позиционируются соответственно OMG и Microsoft как универсальные технологии создания распределенных систем, мы будем оценивать и сравнивать их именно с этой точки зрения. Предполагается, что для проекта используется платформа Windows (в противном случае нечего рассматривать COM) и имеется достаточно средств для закупки основных стандартных частей той или иной реализации (иначе обсуждение CORBA теряет смысл).

Концептуальный фундамент технологии

Дата добавления: 2013-12-12