Здесь мы начинаем наше детальное исследование CORBA с образа вызовов статических методов. Для многих из нас статические выводы - это все, что нам нужно от ORB. Это один из основных принципов, который мы должны знать. Вплоть до сегодняшнего дня все ORB выполняли основную работу с помощью статических вызовов. Конечно, мы прошли через три поколения ORB, совершенствуя этот процесс. Создаваемый вами клиентский код для выполнения статических выводов обладает высокой степенью переносимости между ORB разных производителей. Вы пишете клиентский код, используя язык высокого уровня по своему выбору, а затем предоставляете ORB всю грязную работу по доставке этих вызовов серверу.
Если вы пришли из мира клиент/сервер, то на первый взгляд статический вызов похож на RPC. Если же вы пришли из мира Java, C++ или Smalltalk, то статический вызов для вас будет похож на вызов любого обычного метода, за исключением того, что это удаленный вызов. В идеале вы не должны чувствовать разницу между вызовами локальных объектов и удаленных. ORB обеспечивает такое связывание для различных языков, которое является полностью прозрачным. Однако, на практике семантика распределенных объектов может все же некоторым образом проявитя. Например, сначала необходимо получить ссылку на объект CORBA, а уж затем можно воспользоваться вызовом его методов. Однако, ссыли на такой объект - это как раз то, что делает CORBA более мощной чем RPC или обычные объекты языка программирования. И вот почему.
Ссылка на объект или объектная ссылка (object reference) CORBA - это веский довод в переговорах (по установлению связи), распределенных сервисов. Она указывает на интерфейс объекта, т.е. набор определенных методов, которые управляют отдельным объектом. Более того, вы можете компоновать интерфейсы CORBA с помощью множественного наследования (multiple - inheritance). В дополнение к этому, объекты CORBA полиморфны — поведение одного и того же вызова зависит от типа объекта, который его получает (и обрабатывает). Естественно, RPC не поддерживает наследование, полиморфизм или уникальность состояний объектов. Смысл состоит в том, что объектная ссылка CORBA обеспечивает точность скальпеля - она позволяет вам вызывать целую группу методов конкретного объекта. Уникальные объектные ссылки предоставляют наиболее эффективный метод обращения к удаленным сервисам в межгалактической сети.
Сравнение статических и динамических методов
На рис.8 показаны два типа вызовов клиент/сервер, поддерживаемые CORBA ORB: статические и динамические. В обоих случаях клиент подготавливает запрос по объектной ссылке(т.е., по идентификатору объекта), и вызывает необходимый метод. Сервер не может распознать различие между статическим и динамическим вызовом.
рис. 8. Статистические и динамические вызовы методов CORBA
Клиенты видят объектные интерфейсы через перспективу языкового отображения (language mapping), или связывания (binding), которое переводит ORB на программный уровень. Клиентские программы должны работать без каких-либо изменений исходного текста ORB, что обеспечивается языковым связыванием. Они должны быть способны вызвать экземпляр любого объекта, который реализует заданный интерфейс. Реализация объекта, его объектный адаптер, и ORB, используемый для доступа к объекту, полностью прозрачны как для статических, так и для динамических вызовов.
Статический Интерфейс генерируется в форме стабов непосредственно компилятором IDL. Программы уже на этапе компиляции знают характеристики операций, которые им необходимо вызывать. Связывание интерфейса статических стабов производится на этапе компиляции и обеспечивает следующие преимущества перед динамическими вызовами:
В противоположность этому, динамические вызовы предоставляют более гибкую среду. Они позволяют добавлять в систему новые классы без изменений кода клиента. Они очень полезны для инструментальных средств, которые во время выполнения пытаются определить предоставляемые сервисы. С помощью динамического API вы можете создавать код общего вида. Тем не менее, большинство приложений не требуют такой гибкости и выиграют от реализации со статическими стабами.
Что находится внутри обьектной ссылки (Object Reference)
Ссылка на объект предоставляет необходимую вам информацию, уникально определяющую объект в распределенной системе, и является уникальным именем или идентификатором (обратите внимание, особенно те из вас, кто активно работает с серверами баз данных, что уникальный идентификатор далеко не всегда является числом; его структура может быть достаточно сложна; это применимо и к CORBA object reference). Реализация объектной ссылки не определена спецификациями CORBA, что подразумевает зависимость от реализации системы. Два CORBA-совместимых ORB могут иметь различные представления объектных ссылок. Кроме того, в настоящее время CORBA определяет Переносимые или Интероперабельные Объектные Ссылки (Interoperable Object References — IOR), которые обязаны использовать производители для передачи объектных ссылок между различными ORВ. Как же управлять переносимостью программы клиент/сервер в такой среде? Используйте языковое связывание, чтобы изолировать программы от реального представления объектных ссылок.
Все ORB должны обеспечивать одинаковое языковое связывание для объектных ссылок (обычно трактуются как объекты) в конкретных языках программирования. Это означает, что переносимость обеспечивает язык, он же позволяет вам ссылаться на объекты вашей программы выполняемые на различных ORB. Что произойдет, если ваша программа обращается к объектным ссылкам на двух различных ORB? Согласно CORBA, ваша программа будет работать корректно. На производителей возлагается разрешение всех конфликтов (с помощью использования IOR), которые могут возникнуть в программном коде клиентов.
Как клиентские программы получают объектные ссылки? Обычно их получают из каталогов или вызовов других объектов, на которые уже есть ссылки. Вы можете преобразовать объектную ссылку в строку с именем и сохранить ее в файле. Такая строка может храниться или передаваться еще кому-нибудь, а затем может быть восстановлена в объектную ссылку брокером ORB, который обработает эту строку. CORBA определяет две интерфейсные функции ORB (object_to_string\string_to_object) для облегчения хранения, обмена и получения объектных ссылок. Клиентские программы могут использовать эти функции для получения строки с именем и преобразования ее в объектную ссылку и наоборот.
Наконец, интерфейс ORB определяет некоторые операции, которые можно выполнить для любой объектной ссылки. Эти операции реализованы брокером ORB непосредственно над объектными ссылками. Что означает, что они не передаются реализации самого объекта. Вы можете вызвать метод ORB get_interface для любой объектной ссылки, чтобы получить объект Репозитария Интерфейсов (Interface Repository), гдe представлена информация о типе и метаданных искомого объекта. Вы можете вызвать метод ORB get_implementation для любой объектной сылки, чтобы получить объект Репозитария Реализаций (Implementation repository), в котором описана реализация искомого объекта. Вы можете вызвать метод ORB is_nil для любой объектной ссылки, чтобы определить, существует ли объект.
Статические вызовы CORBA: от IDL до интерфейсных стабов
Давайте пройдем по очереди все шаги для создания ваших серверных классов, интерфейсных стабов для них, сохранения определений серверных классов в Репозитарии Интерфейсов, активации объектов в реальном времени и записи их представления в Репозитарии Реализаций.
Определите объектные классы, используя Язык Определения Интерфейсов (IDL). IDL представляет собой средство указания того, как объекты представляются своим потенциальным клиентам, какие операции допустимы и как они будут вызываться. IDL определяет типы объектов, их атрибуты, экспортируемые методы и их параметры.
Пропустите IDL-файл через прекомпилятор выбранного языка. Типичный CORBA-совместимый прекомпилятор обрабатывает IDL-файлы и создает скелетоны для реализации серверных классов на соответствующем языке программирования.
Добавьте к скелетонам код реализации. Вы должны обеспечить код, реализующий как таковую функциональность методов, заложенную в скелетонах. Другими словами, создайте свои серверные классы.
Откомпилируйте полученный код. CORBA-совместимый компилятор обычно генерирует, по крайней мере, три типа выходных файлов: 1)файлы импорта для описания объектов Репозитария Интерфейсов; 2) клиентские стабы для определенных с помощью IDL методов стабы вызываются клиентской программой, которой необходим статический доступ к IDL-определенным сервисам через ORB; и 3) серверные скелетоны, которые вызывают методы на сервере - их также называют up-call интерфейсами . Вы должны обеспечить код реализации серверных классов. Автоматическая генерация стабов освобождает разработчиков от написания их вручную, а также делает приложения независимыми от частных реализаций ORB.
Свяжите определения класса с Репозитарием Интерфейсов (Interface Repository). Обычно используется соответствующая утилита для связывания (или загрузки, если вам так больше нравится) IDL-информации с Репозитарием Интерфейсов. К этой информации программы обращаются во время выполнения.
Зарегистрируйте выполняемые объекты в Репозитарии Реализации (Implementation Repository). Объектный Адаптер (Object Adapter) заносит в Репозитарии Реализаций объектную ссылку и тип любого объекта, создаваемого с его (адаптера) помощью на сервере. Репозитарий Реализаций также знает, какие классы объектов поддерживаются конкретным сервером. ORB использует эту информацию для определения местонахождения (локализации) активных объектов или для запроса на активизацию объектов на данном сервере.
Создайте экземпляры объектов на сервере. При старте серверный Объектный Адаптер может создавать экземпляры серверных объектов, которые обслуживают вызовы методов удаленными клиентами. Такие объекты реального времени представляют собой экземпляры серверных классов. CORBA определяет различные стратегии Объектных Адаптеров, которые используются для создания и управления объектами реального временив( run-time ) (подробнее об этом далее).
Семь шагов, которые мы только что кратко обрисовали, являются типичными для большинства реализаций CORBA. Естественно, допускаются отклонения. Например, исходный код IDL не обязательно должен быть доступен, если интерфейсная информация уже представлена в форме стабов или в Репозитарии Интерфейсов. Вы не обязаны реализвывать серверные объекты как классы, если они инкапсулированы посредством стабов IDL. Отделение интерфейса от реализации позволяет вам использовать существующие унаследованные системы в среде ORB.
Рассказанное здесь было кратким и приятным. Вызовы статических методов, в самом деле, достаточно просты. Большая часть работы за вас делается брокером ORB. С помощью IDL вы должны описать интерфейсы, которые сервер экспортирует для своих клиентов. Однако, даже эта работа может быть упрощена, если позволить компилятору непосредственно генерировать IDL из определений классов. Например, Netscape/Iprise Caffeine автоматически генерирует стабы и скелетоны CORBA с помощью обработки байт-кода Java, кроме того, он может генерировать также CORBA IDL.
Последней оставшейся головной болью для статических вызовов CORBA является управление стабами. Помните, клиент должен располагать и стабом и объектной ссылкой, прежде чем он сможет вызывать методы серверного объекта. Легко передать объектную ссылку, но как нам получить стаб для клиента ? Обычно, это часть клиентского кода. Однако Java упрощает загрузку стабов в виде байт-кода Java. Новые стандарты связывания CORBA для Java даже определяют формат переносимых (portable) стабов , что позволяет им работать с разными ORB. Например, вы можете загрузить с сервера Orbix-сгенерированный стаб, а затем использовать его для статического вызова методов на клиенте с помощью VisiBroker. Да, статическая CORBA становится очень динамичной.
назад | содержание | далее
