Параллельное и распределенное программирование на С++

Хьюз Камерон

// Листинг 8.2. Использование объектов, которые вызывают

// методы других объектов из того же

// адресного пространства

//.. .

some_object А; another_object В;

dynamic_object *C;

C = new dynamic_object;

//...

B.doSomething(A.doSomething );

A.doSomething(B.doSomething );

C->doMore (A.doSomething ) ;

//...

В листинге 8.2 объекты А и В находятся в одной области видимости, т.е. объект В видим для объекта А, а объект А видим для объекта В. Объект А может вызывать функции-члены объекта В, и наоборот. А что можно сказать об областях види м ости, если два объекта находятся на различных компьютерах? Что происходит, когда объект В создается другой программой и «получает прописку» совершенно в другом адресном пространстве? Как объект А узнает о существовании объекта В и как (что особенно важно) объект А узнает имя и интерфейс объекта В? Каким образом объект А сможет вызывать функции-члены, принадлежащие объекту В, если В — часть другой программы?

В листинге 8.2 объекты А и В создаются во время компиляции, а объект С — во время выполнения. Все они являются частями одной и той же программы, обладают одной областью видимости, а их адреса принадлежат адресному пространству одного и того же процесса. Чтобы процесс мог выполнить инструкцию, ему нужно знать ее адрес. При компиляции программы, представленной в листинге 8.2, адреса объектов А и В хранятся в выполняемом файле. Сле д овательно, процесс, который выполняет программу из листинга 8.2, будет знать местоположение объектов А и В. Адрес объекту С присваивается во время выполнени я программы, т.е. его точный адрес станет известен только тог д а, когда будет вызвана функция new . Однако указатель на объект С бу д ет содержать адрес в пределах того же пространства, в котором размещаются объекты А и В, и, следовательно, процесс для получения доступа к объекту С воспользуется этим указателем. Таким образом, доступ к каждому объекту осуществляется на основе доступа к их адресам (прямого или косвенного). Имя переменной объекта — это просто псевдоним для его адреса. Если имя объекта попадает в рамки нашей области видимости, то мы можем получить к нему доступ. Проблема в том, как связать удаленный объект с нашей локальной областью видимости. Для того чтобы получить доступ к объекту D, который находится в другом адресном пространстве, нам необходим некоторый способ ввода адреса удаленного объекта в наш выполняющийся процесс, т.е. нужно научиться связывать удаленный объект с нашей локальной областью видимости. Нам требуется видимое имя, которое бы служило псевдонимом для адреса в другом процессе, причем этот процесс может выполняться даже на другом компьютере. В некоторых случалх этот самый «другой» компьютер может быть подключен к другой сети! Было бы весьма удобно запросить удаленный объект с помощью некоторого согласованного описания и получить ссылку для адреса удаленного объекта. Имея ссылку, мы могли бы взаимодействовать с этим объектом из нашей локальной области действия. Именно для таких нужд распределенного программирования и можно использовать CORBA-реализацию.

. IOR-доступ к удаленным объектам

Объектнал ссылка специального типа IOR (Interoperable Object Reference) — это стандартный формат объектной ссылки для распределенных объектов. Каждый CORBA-объект имеет IOR-ссылку. IOR-ссылка — это дескриптор, который уникально идентифицирует объект. В то время как обычный указатель содержит простой машинный адрес для объекта, IOR-ссылка может содержать номер порта, имя хоста (имя компьютера в сети), объектный ключ и пр. В С++ для доступа к динамически создаваемым объектам используется указатель. Указатель содержит информацию о том, где в памяти компьютера расположен объект. При разыменовании указателя на объект используется полученный адрес для доступа к членам этого объекта. Однако процесс разыменования указателя на объект (с целью получения доступа к нему) требует больших усилий, когда этот объект находится в другом адресном пространстве и, возможно, на другом компьютере. Указатель в этом случае должен содержать достаточно информации, чтобы сообщить точное местоположение объекта. Если объект расположен в другой сети, указатель должен содержать (прямо или косвенно) сетевой адрес, сетевой протокол, имя хоста, адрес порта, объектный ключ и физический адрес. Стандартнал IOR-ссылка действует как разновидность распределенного указателя на удаленный объект. Набор компонентов, содержащихся в IOR-ссылке под протоколом IIOP, показан на рис. 8.2.

Пон я тие переносимой (portable) объектной ссылки — это важный этап на пути к достижению распределенной обработки данных. Оно позволяет использовать локальные ссылки на удаленные объекты практически везде (в Internet или intranet) и имеет важные последствия для мультиагентных систем, в которых агентам приходится перемещаться между системами и по всему пространству Internet. Стандарт IOR создает основу для мобильных объектов и распределенных агентов. После того как ваша программа получит доступ к IOR-ссылке объекта, можно использовать брокер объектных запросов (Object Request Broker — ORB) для взаимодействия с удаленным объектом посредством вызова методов, механизма передачи параметров, возврата значений и т.п.

Логические компоненты IOR-ссылки:

Хост

Порт

Объектный ключ

Другие компоненты

Идентифицирует Internet-хост

Содержит но

м

ер порта TCP/IP, в которо

м

целевой объект при-ни

м

ает запросы

Значение,которое однозначно преобразуется в конкретный объект

Дополнительнал инфор

м

ация, которую

м

ожно использовать при обращениях, напри

м

ер для безопасности

Рис. 8.2. Набор компонентов, содержащихся в IOR-ссылке подпротоколом IIOP

Брокеры объектных запросов (ORB)

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

точно так же он устраняет необходимость в программировании каналов и очередей с FIFO-дисциплиной между процессами, выполняющимися на одном компьютере. Он берет на себя немалый объем сетевого программирования, без которого не обойтись при создании распределенных программ. Более того, он стирает различия между операционными системами, языками программирования и аппаратными средствами. При программировании локальных объектов программисту больше не нужно беспокоиться о том, на каком языке реализованы удаленные объекты, на какой платформе они выполняются и к какой сети они «приписаны»: Internet или локальной intranet. ORB-брокер использует IOR-ссылки, чтобы упростить взаимодействие между компьютерами, сетями и объектами. Обратите внимание на то, что IOR-ссылка (см. рис. 8.2) содержит информацию, которая может быть использована для TCP/IP-соединений. Мы представили лишь частичное описание IOR-компонентов, поскольку IOR-дескриптор должен быть «черным ящиком» для разработчика. ORB-брокер использует IOR-ссылки, чтобы найти объект назначения. Обнаружив объект, ORB-брокер активизирует его и передает аргументы, необходимые для вызова этого объекта. ORB-брокер ожидает завершения обслуживания запроса и возвращает вызывающему объекгу ожидаемую информацию или исключение, если вызов метода оказался неудачным. Упрощенная последовательность действий, выполняемых ORB-брокером от имени локального объекта, показана на рис. 8.3.

Действия, перечисленные на рис. 8.3, представляютупро щ енную схему того, что делает ORB-брокер, взаимодействуя с удаленным объектом. Эти действия практически незаметны для локального объекта. Локальный объект вызывает один из методов удаленного объекта, а ORB-брокер делает «свою работу» от имени локального объекта. ORB-брокер выполняет большой объем обработки, заключенный всего лишь в нескольких строках кода. Обычно распределенное объектно-ориенти-рованное приложение состоит по крайней мере из двух программ. Каждая программа имеет один или несколько объектов, которые взаимодействуют друг с другом, «пересекая» адресные пространства. Характер взаимодействия объектов определяется отношениями «клиент-сервер», «изготовитель-потребитель» или базируется на принципе равноправия (модель равноправных узлов). Следовательно, если у нас есть две программы, то одна будет действовать как клиент, а другая — как сервер, или одна — как изготовитель, а другая — как потребитель, либо обе они будут равноправными. В программе 8.1 реализован потребитель, который вызывает простой удаленный объект калькулятора. На примере этой программы демонстрируется, как можно получить доступ к удаленному объекгу, а также как инициализируется и используется ORB-брокер.

УПРОЩЕННАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ ДЕЙСТВИЙ ORB-БРОКЕРА ПРИ ВЫЗОВЕ МЕТОДА УДАЛЕННОГО ОБЪЕКТА _

1. Найти удаленный объект. _

2. Активизировать модуль, содержа щ ий искомый объект, если таковой е щ е не активизирован. _

3. Передать аргументы удаленному объекту. _

4. Ожидать ответа после вызова метода удаленного объекта. _

5. Вернугьлокальномуобъекту информацию или исключение, если вызовудаленного метода оказался неуспешным. _

Рис. 8.3. Упрощенная последовательность действий, выполняемых ORB-брокером от имени локального объекта

// Программа 8.1

1 using namespace std;

2 #include «adding_machine_impl.h»

3 #include <iostream>

4 #include <fstream>

5 #include <string> 6

7

8 int main(int argc, char *argv[])

9 {

10 CORBA::ORB_var Orb = CORBA::ORB_init(argc, argv, «mico-local-orb»);

11 CORBA::BOA_var Boa = Orb->BOA_init(argc,argv,«mico-local-boa»);

12 ifstream In(«adding_machine.objid»);

13 string Ref;

14 if('In.eof){

15 In » Ref;

16 }

17 In.close;

18 CORBA::Object_var Obj = Orb->string_to_object(Ref.data);

19 adding_machine_var Machine =adding_machine::_narrow(Obj);

20 Machine->add(700);

21 Machine->subtract(250);

22 cout << «Результат равен " « Machine->result« endl;

23 return(0);

24 }

25

26

При выполнении строки 10 ORB-брокер инициализируетс я. Строка 15 обеспечивает считывание из файла IOR-ссылки на объект adding_machine. Одно из прекрасных свойств IOR-ссылки состоит в том, что ее можно хранить как простую строку и передавать другим программам. Передачу IOR-ссылки проще всего реализовать с помощью аргументов командной строки, переменных среды или файлов. IOR-ссылку можно отправить по электронной почте или с помощью протокола передачи файлов (File Transfer Protocol — FTP). IOR-ссылки совместно используют файловые системы, и их можно загружать с Web-страниц. Если некоторая программа имеет IOR-ссылку на удаленный объект, то для доступа к нему можно использовать ORB-брокер. Другие методы связи между объектами с помощью IOR-ссылок будут рассмотрены ниже в этой главе. Но для начала вполне достаточно использования файловых систем. Итак, в программе 8.1 IOR-ссылка была получена путем преобразования объектной ссылки в «строковую» форму (с использованием ORB-брокера удаленного калькулятора) и записана в файл. При выполнении строки 18 локальный объект Orb преобразует «строковую» IOR-ссылку обратно в объектную. В строке 19 эта объектнал ссылка используется для реализации объекта adding_machine. Обратите внимание на то, что при вызове методов этого объекта adding_machine выполняется соответствующий код удаленного калькулятора (см. строки 20, 21 и 22).

Machine->add(700) ;

Machine->subtract(250) ;

cout « «Результат равен " « Machine->result « endl;

И хотя вызовы этих методов сделаны в нашей локальной области види м ости, они относятся к выполняемому колу в другом адресном пространстве (в данном случае — даже к другому компьютеру). Для разработчика местоположение объекта Machine как будто перестает иметь значение. После создания (в строке 19) этот объект используется как любой другой объект С++. И хотя существуют весьма значительные различия между вызовами локальных и удаленных объектов ^[15], объектно-ориентированное представление, тем не менее, поддерживается, и с точки зрения объектно-ориентированного программирования удаленные объекты ведут себя как локальные. Код, представленный в программе 8.1, является кодом клиентской части приложения (или кодом «потребителя»), поскольку в нем используются возможности объекта adding_machine. Поэтому теперь (для получения завершенного приложения калькулятора) нам нужен код «ответной части», который реализует объект adding_machine. Код этого второго компонента представлен в программе 8.2.