Обращение к удаленным объектам. Привязка клиента к объекту. Статическое и динамическое удаленное обращение к методам. Передача параметров. DCE, RMI.

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

Передача параметров удаленной процедуре – достаточно сложная задача.

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

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

 

Тема 13. Распределенная система объектов CORBA.

Введение.

В 1989 г. HP, Sun, Americal Airlines< Canon и др. производители и потребители программных продуктов объединились в группу OMG (Object Management Group), которая поставила цель: созж\дание технологии, позволяющей объединить программные приложения, выполняющиеся на различных программных и аппаратных платформах, взаимодействующие по различным протоколам, написанные на различных языках, используемые в различных частях мира. Результатом деятельности OMG стал набор спецификаций, а не готовый продукт. Требования:

- Объединяются приложения как новые, так и наследуемые;

- Эти приложения могут выполняться на различных операционных платформах;

- Стандарты не стоят ничего (их может получить и использовать любой желающий).

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

В объектной модели COM предполагается, что поиском сервера объекта и самого объекта занимается операционная система компьютера клиента. В случае, если объект не расположен на компьютере клиента, требуются дополнительные действия, например, организация сеанса связи с удаленным компьютером – сервером объекта. Доступ к удаленным объектам осуществляется с помощью технологии DCOM. Но остается неизменным то, что ОС клиента должна знать о местонахождении объекта. Кроме того, если компьютер – сервер не запущен, то запустить его невозможно. Такая технология несколько статична. Для удаленных объектов характерно частая смена их местоположения.

Технология CORBA пытается устранить недостатки DCOM. CORBA (Common Object Request Broker Architecture) – это стандарт построения приложений с распределенными объектами. Разработала этот стандарт группа нескольких фирм, объединившихся в отраслевой комитет OMG (Object Management Group). CORBA реализована на многих аппаратных платформах, поэтому она позволяет общаться даже приложениям, работающим на компьютерах под руководством разных операционных систем!

Архитектура системы.

Перечень основных компонент системы.

Прикладные объекты		Службы вертикального уровня		Службы горизонтального уровня		Службы общего назначения
ORB

Брокер запросов

Схема расположения компонент системы на компьютерах.

Структура связей CORBA.

В технологии CORBA предполагается, что в сети работают клиентские и серверные приложения. На одном компьютере могут быть установлены и приложения – клиенты и приложения – серверы. Сервер поставляет один или несколько объектов. Клиенты и серверы общаются не непосредственно, а через Smart Agent сетевого агента, которому известно местоположение всех объектов. Более того, приложение – клиент не знает даже, где находится сетевой агент, то есть агент тоже может перемещаться по сети!

Как это организовано разберем, пользуясь картинкой. Не уменьшая общности, покажем на картинке все службы CORBA, считая, что на компьютере К запущено только клиентское приложение, на компьютере С – только серверное, а на компьютере А – сетевой агент.

 

Компьютер К		Компьютер А		Компьютер С
ORB		Smart Agent		BOA
Клиент 3 4 Stub		Implementation Repository		Сервер   Sceleton

В среде CORBA на одном из компьютеров должна функционировать специальная программа Smart Agent, осуществляющая взаимодействие брокеров (с клиентских компьютеров). Эта служба при помощи Implementation Repository хранит информацию обо всех запущенных серверах.

На каждом компьютере с серверными приложениями должна быть запущена служба BOA. Если запускается сервер, он обращается к этой службе (1), сообщая о себе. Служба BOA (2) связывается со службой Implementation Repository и передает ей информацию о сервере.

К клиентскому приложению присоединяется специальная программа – заглушка. На каждом компьютере с клиентскими приложениями устанавливается служба ORB (Object Request Broker) – объектный брокер запросов. Когда клиентское приложение обращается к серверу, заглушка перехватывает такое обращение (3), преобразует в транспортный формат и помещает в буфер (4). При первом обращении к серверу брокер ORB компьютера клиента находит в сетевом окружении работающий экземпляр сетевого агента Smart Agent (5) и через него (6) получает информацию о сервере, передает ее заглушке. Далее заглушка передает сообщение серверу. На стороне сервера запрос получает специальный объект, называемый скелетом scelet (7). Он преобразует запрос из транспортной формы в обычный вид и передает его серверу. Ответ сервера передается скелету, тот, преобразовав ответ в транспортный формат, передает в буфер заглушки, она, в свою очередь, передает ответ клиенту. Эти передачи стрелками не изображены, чтобы не запутывать картину.

Остается добавить, что в качестве транспортного протокола CORBA использует протокол UDP. Вспомните, что это – протокол из стека протоколов TCP/IP, не гарантирующий доставку. В этом случае за корректность передаваемых данных отвечают программы, организующие общение по сети. С целью организовать общение компьютеров для CORBA следует соответствующим образом настроить одинаковые сетевые порты компьютеров.

В конце отметим, что технология CORBA поддерживается в операционной системе Windows. Вы можете написать на языке C++ Builder приложения, соответствующие данной технологии.