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

Назовем технологии, позволяющие осуществлять распределенную обработку в гетерогенных системах: это архитектура брокера общих объектных запросов (Common Object Request Broker Architecture, CORBA) и протокол Internet Inter-ORB Protocol (IIOP). CORBA полностью определяет архитектуру, необходимую для обмена информацией между распределенными объектами. К числу ее спецификаций относятся IIOP и множество других технологий. IIOP самый важный компонент CORBA, потому что его основная функция организация взаимодействия распределенных объектов в гетерогенной среде. Вместе CORBA и IIOP характеризуют многообразие средств промежуточного уровня, которые станут стимулом для пересмотра подходов к созданию прикладных программ в сетевых средах разработчиками всего мира.

CORBA и IIOP не исключительные варианты решения, обеспечивающего распределенную обработку. Существует и конкурирующая архитектура, разработанная корпорацией Microsoft, объектная модель распределенной обработки (Distributed Computing Object Model, DCOM), в основном представленная брокером объектных запросов (Object Request Broker, ORB), который входит в состав Windows NT 4.0 и будет включен в следующую редакцию Windows.

CORBA детище консорциума Object Management Group (OMG), в составе которого более 700 компаний из самых различных отраслей промышленности. Цель этой организации состоит в том, чтобы определять базовые структуры для разработки приложений с использованием объектно-ориентированных методов. OMG выпускает спецификации, позволяющие стандартизировать обработку распределенных объектов, а не прикладные программы, и такая ориентация на разработку идей, а не программ принесла группе большой успех.

Самый удачный результат деятельности OMG впервые реализованная в 1991 г. CORBA. CORBA описывает стандартную архитектуру для обмена информацией между распределенными объектами, благодаря которой компоненты прикладных программ могут связываться друг с другом, независимо от их местоположения в вычислительной сети. Более того, поскольку CORBA определяет стандартный интерфейс между объектами, операционная система, в которой работает объект, и язык, на котором он составлен, не имеют значения. Если объект удовлетворяет требованиям CORBA, он способен обмениваться информацией с другими распределенными объектами.

Появившийся в декабре 1994 г. как составная часть спецификации CORBA 2.0 протокол IIOP еще одна удача OMG. До того как был подготовлен протокол IIOP, спецификация CORBA определяла способ взаимодействия только для распределенных объектов, созданных одним производителем. При подготовке объектов приходилось рассчитывать лишь на конкретную реализацию архитектуры. Благодаря IIOP вторая спецификация CORBA стала окончательным решением для взаимодействия объектов, которое не привязано ни к какой конкретной платформе или реализации.

С применением CORBA вы создадите системы масштаба предприятия (корпоративные системы), в которых объекты распределены по вычислительной сети. В корпоративных системах основные объекты для обслуживания файлов, необходимые прикладной программе, могут храниться на сервере Windows NT. Эти объекты вы составите, например, на языке Си++. На большом компьютере можно разместить первичные функции ядра системы скажем, используя объекты, запрограммированные на языке Кобол. Любой настольный компьютер, работающий под управлением Windows 95, пригоден для хранения внешних интерфейсов, использующих объекты, созданные средствами Visual Basic. И все эти объекты могут обмениваться информацией, а посредником при передаче запросов служит CORBA.

Фирмы Netscape Communications Corp. и Sun Microsystems избрали CORBA и IIOP в качестве основы для следующего поколения своих программ. Sun применяет CORBA и IIOP для реализации гетерогенных вызовов удаленных процедур в языке программирования Java 1.1, причем без этих технологий в копоративных сетях не было бы платформы Java (Java Platform). Более того, в API Enterprise JavaBeans будут применяться CORBA и IIOP, чтобы обеспечить возможность создания масштабируемых прикладных программ для деловой сферы (бизнес-приложения) с многократно используемыми серверными компонентами.

Для огранизации вызовов удаленных процедур в языке Java пригодна и технология DCOM. Необходимые для этого специальные программные процедуры имеются в Visual J++. Но модель DCOM рассчитана только на платформы Windows NT 4.0 и Windows 95 (с помощью расширений Internet Explorer), т. е. DCOM не годится для обмена информацией с другими операционными системами. Microsoft сообщает, что в будущем технология DCOM будет перенесена на другие платформы.

По протоколу IIOP осуществляется взаимодействие открытой сетевой среды (Open Network Environment, ONE) фирмы Netscape с корпоративными системами. Кроме того, с помощью IIOP программисты могут подключать программы, подготовленные на языках Java, JavaScript и Си или Си++, к системам масштаба предприятия. В программе Netscape Navigator протокол IIOP реализуется в рамках механизма LiveConnect и предназначен для обмена информацией между апплетами, внешними модулями и сценариями.

Ядро CORBA брокер (посредник) объектных запросов (ORB). Это что-то вроде магистрали для объектов. Основная задача ORB оказывать посреднические услуги при обмене запросами между объектами. Хотя ORB "обитает" в среде клиентсервер, объекты, с которыми он работает, выполняют функции либо клиентов, либо серверов, в зависимости от обстоятельств. Если объект принимает и обрабатывает запрос, то он играет роль сервера. Если он отправляет запрос, то выступает в роли клиента.

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

При обработке этих запросов для ORB не имеет значения ни язык программирования, ни операционная система или платформа. Механизм, обеспечивающий "прозрачность" обработки запросов, называется языком определения интерфейса (Interface Definition Language, IDL). Этот язык применяется для объявления границ и интерфейсов объекта. Во многом подобно независимому арбитру, IDL нейтрален и не зависит от объектов и ORB, тем не менее он связывает поставщиков служб распределенных объектов с их клиентами. Всякому, кто знаком с DCOM, наверное, известно, что в модели DCOM используется IDL. Но IDL DCOM несовместим с CORBA и работает иначе, чем IDL CORBA. В CORBA предусматривается множественное наследование, а ее IDL-средствам наследование необходимо для инкапсуляции объектов. Это существенно облегчает многократное использование блоков программ. В DCOM механизм множественного наследования не реализован. Поэтому вы должны подготовить и объединить все интерфейсы, прежде чем к ним обратится клиент.

Язык IDL хорош тем, что позволяет кратко описать API, сохранив при этом свободу определить методы на любом языке программирования, который обеспечивает связывание с CORBA. К таким языкам относятся Ада, Кобол, Си, Си++, Smalltalk и Java. У некоторых поставщиков имеются собственные средства согласования с CORBA для Visual Basic и Фортрана.

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

Для подлинной независимости IDL в CORBA используется репозиторий (хранилище) интерфейсов, предназначенный для хранения сигнатур методов, принадлежащих объектам, с тем чтобы эти сигнатуры можно было динамически извлекать и обновлять во время исполнения программы. Благодаря этому все объекты в корпоративной системе могут получить информацию об интерфейсах других объектов, методах, принадлежащих этим интерфейсам, и параметрах, необходимых для обращения к ним. (В DCOM тоже предусмотрены службы реестра и поиска, позволяющие клиентам получить информацию об интерфейсах компонента, а также о параметрах, необходимых для вызова конкретного метода.)

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

Как технология, которая обеспечивает базовые структуры для взаимодействия разнородных объектов, CORBA достигла замечательных успехов, и это при том, что она представляет собой только часть еще более крупной архитектуры управления объектами (Object Management Architecture, OMA), состоящей из следующих компонентов:

Как мы уже упоминали, брокер объектных запросов управляет обменом запросами между объектами. Но как все остальные кусочки этой мозаики складываются воедино? Давайте рассмотрим службы, средства и объекты CORBA.

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

Имеется 16 объектных служб, в том числе:

Благодаря тому что службы объектов CORBA решают широкий спектр задач, разработчики могут концентрировать внимание на подготовке объектов, не заботясь о службах системного уровня. Разработав класс для своего объекта, вы затем расширите его функциональные возможности с помощью служб объектов. Добиться этого вам помогут механизмы деления на подклассы (subclassing) и множественного наследования. Например, после создания класса Widget вы можете вывести из него подкласс aWidget, который унаследует от службы Persistence устойчивость. Кроме того, вы обеспечите передачу уведомлений о наступлении событий, безопасность и выполнение запросов, применяя механизм наследования к этим функциям соответствующих служб.

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

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

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

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

Реальные объекты, образующие ядро совместимой с CORBA прикладной программы, называются бизнес-объектами. Бизнес-объект это способ описания понятий, не зависящих от прикладной программы, типа покупатель, заказ или платеж. Для подготовки прикладной программы вам будет необходим набор бизнес-объектов.

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

Для управления сложной прикладной программой с распределенными бизнес-объектами у последних есть информация только о том, какие сервисные функции выполняют другие объекты, но не о том, как эти функции реализуются на самом деле. Благодаря бизнес-объектам мы избавлены от сложностей реализации внутренней обработки, поскольку можем сконцентрировать внимание на интерфейсах.

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

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

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

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

Если вы с помощью CORBA интегрировали унаследованные программы с процессами клиента и сервера, у вас есть все составляющие многоуровневой модели клиентсервер. Один уровень это визуальные объекты, например интерфейсы, размещаемые на клиентских ПК. Другой уровень объекты сервера, предусматривающие бизнес-функции. Еще один уровень составляют унаследованные прикладные программы, например СУБД на большой ЭВМ.

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