Проектирование объектно-ориентированного программного обеспечения — это процесс перевода требований к ПО в проект, в котором с помощью объектов моделируется каждый аспект разрабатываемой системы и выполняемой ею работы. Центральное место в этом проекте отводится структуре и иерархии коллекций объектов, а также их взаимоотношениям и взаимодействиям. Для поддержки понятия модели ПО в С++ используется ключевое слово class. Существует два базовых типа моделей. Первый тип модели — масштабированное представление некоторого процесса, концепции или идеи. Этот тип модели используется для анализа или экспериментирования. Например, класс применяется для разработки модели молекулы, т.е. с помощью концепции С++-класса можно смоделировать гипотетическую структуру некоторого химического процесса, происходящего в молекулах. Программным путем можно затем изучить поведение молекулы при внедрении новых групп атомов. Второй тип модели ПО — воспроизведение некоторой реальной задачи, процесса или идеи. Цель этой модели — заставить некоторую часть системы ПО или приложения функционировать подобно ее «прототипу». В этом случае ПО занимает место некоторого компонента или некоторого физического предмета в неавтоматизированной системе. Например, мы можем использовать концепцию класса для моделирования калькулятора. При корректном моделировании всех его характеристик и поведения можно создать экземпляр этого класса и использовать в качестве настоящего калькулятора. Программный калькулятор здесь будет играть роль реального калькулятора. Таким образом, смоделированный нами класс может служить в качестве виртуального лублера некоторого реального лица, места, предмета или идеи. Главное в программной модели — ухватить суть реального предмета.

Декомпозиция (decomposition) — это процесс разделения задачи и ее решения на ряд подзадач, коллекций объектов и принципов взаимоотношений между этими объектами. Аналогично инкапсуляция (encapsulation) — это моделирование характеристик, атрибутов и поведения некоторого лица, места, предмета или идеи с помощью С++-конструкции class. Такое моделирование (инкапсуляция) и декомпозиция являются частью этапа проектирования объектно-ориентированного ПО. Объектно-ориентированные приложения, которые содержат распределенные объекты, вносят в процесс проектирования дополнительный уровень сложности. С точки зрения «чистого» проектирования местоположение объектов в приложении не должно влиять на разработку атрибутов и характеристик этих объектов. Класс — это модель и, если местоположение не является частью этой модели, то даже самое «крайнее» расположение объектов (экземпляров этого класса) не должно иметь значение. Однако объекты существуют не в вакууме. Они взаимодействуют и обмениваются информацией с другими объектами. Если объекты (участники взаимодействия) расположены на разных компьютерах, и, возможно, даже в различных сетях, то оказывается, что фактор местоположения объектов необходимо с самого начала включать в процесс проектирования ПО. И хотя насчет того, на каком именно этапе проектирования следует рассматривать этот фактор, специалисты существенно расходятся во мнениях, тем не менее все единолушны в том, что его необходимо рассматривать. Дело в том, что обработка ошибок и исключений при взаимодействии объектов, расположенных в различных процессах или на различных компьютерах, отличается от обработки ошибок и исключений при взаимодействии объектов одного и того же процесса. Кроме того, связи и взаимодействия между объектами одного процесса реализуются совершенно не так, как при расположении объектов в различных процессах, которые могут выполняться на разных компьютерах. Это нужно иметь в виду еще на раннем этапе проектирования. В распределенном объектно-ориентированном приложении вся его работа делится между объектами и реализуется в виде функций-членов различных объектов. Объекты должны быть логически разделены согласно определенной модели декомпозиции работ (Work Breakdown Model — WBM). Они могут быть разделены согласно моделям типа «клиентс - сервер», «изготовитель-потребитель», равноправных узлов, «классной доски» или мультиагентной системы. Логическая структура каждой такой модели (с особенностями распределения объектов) показана на рис. 8.1.

Во всех моделях, показанных на рис. 8.1, предполагается, что объекты могут быть на одном и том же или на разных компьютерах (главное — они принадлежат разным процессам). Уже сам факт принадлежности рааличным процессам делает объекты распределенными . Все модели представляют рааличные подходы к распределению работы приложения между объектами.

 

Взаимодействие между распределенными объектами

Если объекты относятся к одному и тому же процессу, то в качестве средств межобъектно г о «общения» можно использовать механизм передачи параметров, вызовы обычных методов и использование г лобальных переменных. Если объекты принадлежат различным процессам, выполняемым на одном компьютере, то средствами ком м уникации между объекта м и м огут служить файлы, каналы, очереди c дисциплиной обслуживания «первы м пришел — первы м обслужен», разделяе м ал па м ять, буферы об м ена или пере м енные среды. Если же объекты «прописаны» на различных компьютерах, то в качестве средств связи придется использовать сокеты, вызовы удаленных процелур и дру г ие типы средств сетево г о про г раммирования. При это м мы должны поду м ать не только о то м, как булут общаться объекты в распределенном приложении, но и о том, посредство м че г о будет реализовано это об щ ение. Объектно- ориентированные приложения могут включать как простые типы данных, так и довольно сложные, а именно классы, определенные пользователем. Такие классы часто используются для связи между объектами. Поэтому связь между распределенными объектами будет обеспечиваться не только с помощью простых встроенных типов данных (например int, float или double), но и посредством классовых типов, определенных пользователем, без которых некоторые объекты не смогут выполнить свою работу. Кроме того, необходимо позаботиться о том, чтобы у одних объектов была возможность вызывать методы других объектов, расположенных в других адресных пространствах. Более того, необходимо прелусмотреть возможность для одного объекта «знать» о методах удаленных объектов. В то время как язык С++ поддерживает средства объектно-ориентированного программирования, в нем не предусмотрено никаких встроенных средств по обеспечению связи между распределенными объектами. Он не содержит никаких встроенных методов для локализации удаленных объектов и формирования к ним запросов.

Для реализации связи между распределенными объектами разработан ряд протоколов. Двумя наиболее важными из них являются IIOP (Internet Inter-ORB Protocol — протокол, определяющий передачу сообщений между сетевыми объектами по TCP/IP) и RMI (Remote Method Invocation — вызов удаленных методов). С помощью этих протоколов могут общаться объекты, расположенные практически в любом мести сети. В этой главе мы рассмотрим методы реализации распределенных объектно-ориентированных программ с использованием упомянутых протоколов и спецификации CORBA (Common Object Request BrokerArchitecture). Спецификация CORBA представляет собой промышленный стандарт для определения отношений, взаимодействий и связей между распределенными объектами. IIOP и GIOP — два основных протокола, с которыми работает спецификация CORBA. Эти протоколы хорошо согласуются с протоколом TCP/IP. CORBA — самый простой и наиболее гибкий способ добавления средств распределенного программирования в среду С++. Средства, предоставляемые спецификацией CORBA, реализуют поддержку двух основных моделей объектно-ориентированного параллелизма, которые мы используем в этой книге: «классная доска» и мультиагентные системы. Поскольку спецификация CORBA отражает принципы объектно-ориентированного программирования, с ее помощью можно реализовать приложения довольного широкого диапазона: от миниатюрных до очень больших. В этой книге мы используем MICO — открытую реализацию спецификации CORBA. MICO-реализация поддерживает основные CORBA-компоненты и службы. С++ взаимодействует с MICO посредством коллекции классов и библиотек классов. Спецификация CORBA поддерживает распределенное объектно-ориентированное моделирование на каждом его уровне.

 

Синхронизация взаимодействия локальных и удаленных объектов

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

 

Обработка ошибок и исключений в распределенной среде

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

 

Объекты, разделяющие одну область действия (видимости), могут взаимодействовать, получал доступ друг к другу по именам, псевдонимам или с помощью указателей. Объект доступен только в случае, если «видимо» его имя или указатель на него. Видимость имен объектов определяется областью действия. С++ рааличает четыре основ-ныхуровня областей действия:

• блока;

• функции;

• файла;

• класса.

Вспомните, что блок в С++ определяется фигурными скобками {}, поэтому присваивание значения Y переменной X в листинге 8.1 недопустимо, так как переменная Y видима только внутри блока. Функции main() неизвестно имя переменной Y за пределами блока, конец которого обозначен закрывающейся фигурной скобкой.

// Листинг 8.1. Простой пример области действия блока

int main(int argc, char argv[]) {

int X; int Z; {

int Y;

Z = Y; // Вполне правомочное присваивание.

//.. .

}

X = Y ; // Неверно, поскольку имя Y уже не определено.

}

Однако имя Y видимо для любого другого кода из того же блока, в котором определена переменная Y. Имя, объявляемое внутри функции или ее объявления, получает область видимости этой функции. В листинге 8.1 переменные X и Z видимы только для функции main (), и к ним нельзя получить доступ из других функций. Понятие области видимости файла относится к исходным файлам. Поскольку С++-программа может состоять из нескольких файлов, мы можем создавать объекты, которые видимы в одном файле и невидимы в другом. Имена, обладающие областью видимости файла, видимы, начиная с местоположения их объявления и заканчивая концом исходного файла. Имена с областью видимости файла не должны объявляться ни в одной из функций. Обычно их называют глобальными переменными. Имена, которые характеризуются областью видимости объекта, видимы для любой функции-члена, объявленной как часть этого объекта. Мы используем область видимости объекта в качестве первого уровня доступа к членам объекта. Закрытый, защищенный и открытый интерфейсы объекта определяют второй уровень. И хотя само имя объекта может быть видимым, закрытые и защищенные его члены тем не менее имеют ограниченный доступ. Область действия просто сообщает нам, видимо ли имя объекта. В нераспределенной программе область действия ассоциируется с единым адресным пространством. Два объекта в одном и том же адресном пространстве могут получать доступ друг к другу по имени или указателю и взаимодействовать, просто вызывал методы друг друга.

// Листинг 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-ссылки:

Рис. 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

4 #include

5 #include 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) этот объект используется как любой другой объект С++. И хотя существуют весьма значительные различия между вызовами локальных и удаленных объектов , объектно-ориентированное представление, тем не менее, поддерживается, и с точки зрения объектно-ориентированного программирования удаленные объекты ведут себя как локальные. Код, представленный в программе 8.1, является кодом клиентской части приложения (или кодом «потребителя»), поскольку в нем используются возможности объекта adding_machine. Поэтому теперь (для получения завершенного приложения калькулятора) нам нужен код «ответной части», который реализует объект adding_machine. Код этого второго компонента представлен в программе 8.2.

// Программа 8.2

1 #include

2 #include

3 #include «adding_machine_impl.h» 4

5 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 adding_machine_impl *AddingMachine =new adding_machine_impl;

13 CORBA::String_var Ref = Orb->object_to_string(AddingMachine);

14 ofstream Out(«adding_machine.objid»);

15 Out « Ref « endl;

16 Out.close() ;

17 Boa->impl_is_ready (CORBA: : ImplementationDef : :_nil () ) ;

18 Orb->run();

19 CORBA: :release(AddingMachine) ;

20 return(0);

21 } 22 23

Обратите внимание на то, что программа-«изготовитель» также должна инициализировать объект Orb (в строке 10). Это — одно из важных требований, предъявляемых к CORBA-ориентированным программам, поскольку каждая программа реализует взаимодействие с удаленными объектами с помощью ORB-брoкepa. Именно поэтому инициализация ORB-объекта— первое действие, которое должна выполнить CORBA-программа. В строке 12 объявляется реальный объект adding_machine . Это именно тот объект, с которым в действительности связывается программа 8.1. В строке 13 объектная ссылка на реальный объект adding_machine преобразуется в «строковую» форму, а затем записывается в обычный текстовый файл, чтобы ее можно было без труда прочитать. После того как IOR-ссылка записана в файл, объект Orb ожидает запроса. При каждом вызове одного из его методов этот объект выполняет соответствующее арифметическое действие (сложение или вычитание). Значение результата передается посредством вызова метода result() объекта adding_machine. Программы 8.1 и 8.2 демонстрируют базовую структуру, которую должны иметь CORBA-программы. Код, создающий объект adding_machine, начинается с объявления его CORBA-класса. Каждый CORBA-объект начинается как IDL-проект (Interface Definition Language — язык описания интерфейсов).

 

Язык описания интерфейсов (IDL):более «пристальный» взгляд на CORBA-объекты

Язык описания интерфейсов (IDL) — стандартный язык объектно-ориентированного проектирования, который используется для разработки классов, предназначенных для распределенного программирования. Он применяется для отображения интерфейса класса и отношений между классами, а также для определения прототипов функций-членов, типов параметров и типов значений, возвращаемых функциями. Одно из основных назначений языка IDL — отделить интерфейс класса от его реализации. Но дл я определени я самих функций-членов и членов данных IDL не используетс я. Язык IDL определ я ет только интерфейс функции. Основные ключевые слова IDL перечислены в табл. 8.1.

Ключевые слова, перечисленные в табл. 8.1, представл я ют собой зарезервированные слова, используемые в CORBA-программах. Помимо определени я интерфейса функций дл я класса, я зык IDL используетс я дл я определени я отношений между к л ассами. IDL под д ерживает:

• типы, определенные пользователем;

• последовательности, определенные пользователе м;

• типы массивов;

• рекурсивные типы;

• семантику исключений;

• модули (по аналогии с пространствами имен);

• единичное и множественное наследование;

• поразрядные арифметические операторы.

Приведем IDL-определение для класса adding_machine из листинга 8.2:

interface adding_machine{

void add(in unsigned long X);

void subtract(in unsigned long X);

long result();

}

Это определение начинается с ключевого слова CORBA interface. Обратите внимание на то, что данное объявление интерфейса класса adding_machine не включает ни одной переменной, которая бы могла хранить результат выполнения операций сложения и вычитания. Методы add () и subtract () принимают в качестве параметра одно значение типа unsigned long. Объявление типа параметра сопровождается ключевым словом CORBA in, который говорит о том, что данный параметр является входным (mput). Это объявление класса хранится в отдельном исходном файле adding_machine.idl. Исходные файлы, содержащие ГОЬюпределения, должны иметь . idl-расширения. Прежде чем такой файл можно будет использовать, его необходимо преобразовать к С++чЈюрмату. Это преобразование можно выполнить с помощью препроцессора или отдельной программы. Все CORBA-реализации включают IDL-компиляторы. Существуют IDL-компиляторы лля языков С, Smalltalk, С++, Java и др. IDL-компилятор преобразует ГОЬюпределения в код соответствующего языка. В данном случае IDL-компилятор преобразует объявление интерфейса в легитимный C++-код. В зависимости от конкретной CORBA-реализации IDL-компилятор вызывается с использованием синтаксиса, который будет подобен слелующему:

idl adding_machine.idl

При выполнении этой команды создается файл, содержащий С++-код. Поскольку наше IDL-определение хранится в файле adding_machine. idl, MICO IDL-компилятор создаст файл adding_machine. h, который будет содержать несколько каркасных C++-классов и CORBA-типов данных. Базовые IDL-типы данных приведены в табл. 8.2.

Таблица 8.2. Базовые IDL -т ипы дан н ых

IDL-типы данных

Диапазон

Размер

long

1

>

_2»-2' 5 -

1

> 16 бит

0-2 v - 1

> 32 бит

Даже после того как IDL-компилятор создаст из определения интерфейса С++-код, реализация методов интерфейсного класса остается все еще неопределенной. IDL-компилятор создает несколько С++-конструкций, которые предназначены для использования в качестве базовых классов. В листинге 8.3 показано два класса, сгенерированных MICO IDL-компилятором на основе файла adding_machine.idl .

// Листинг 8.3. Два класса, сгенерированные

// MICO IDL-компилятором из файла

// adding_machine.idl

class adding_machine : virtual public CORBA::Object{

public:

virtual ~adding_machine();

#ifdef HAVE_TYPEDEF_OVERLOAD

typedef adding_machine_ptr _ptr_type;

typedef adding_machine_var _var_type;

#endif

static adding_machine_ptr _narrow(CORBA::Object_ptr obj );

static adding_machine_ptr _narrow(CORBA::AbstractBase_ptr obj );

static adding_machine_ptr _duplicate(adding_machine_ptr _obj ){

CORBA::Object::_duplicate (_obj); return _obj;

}

static adding_machine_ptr _nil(){

return 0;

}

virtual void *_narrow_helper( const char *repoid );

static vector *_narrow_helpers;

static bool _narrow_helper2( CORBA::Object_ptr obj );

virtual void add( CORBA::ULong X ) = 0;

virtual void subtract( CORBA::ULong X ) = 0;

virtual CORBA::Long result() = 0;

protected:

adding_machine(){};

private:

adding_machine( const adding_machine& );

void operator=( const adding_machine& );

};

class adding_machine_stub : virtual public adding_machine{

public:

virtual ~adding_machine_stub();

void add( CORBA::ULong X );

void subtract( CORBA::ULong X ); CORBA::Long result();

private:

void operator=( const adding_machine_stub& );

};

Файл adding_machine.idl — это входные данные для компилятора, а файл adding_machine.h вместе с каркасны м и класса м и— результат его работы. Чтобы реализовать интерфейсы функций, объявленные в исходно м IDL-файле, разработчик использует наследование. Напри м ер, в листинге 8.4 представлен определенный пользователе м класс, который обеспечивает реализацию для одного из каркасных классов, созданных IDL-ко м пиляторо м.

// Листинг 8.4. Класс реализации структурных классов, // созданных IDL-компилятором

class adding_machine_impl : virtual public adding_machine_skel {

private:

CORBA::Long Result;

public:

adding_machine_impl (void){

Result = 0;

};

void add(CORBA::ULong X){

Result = Result + X;

};

void subtract(CORBA::ULong X){

Result = Result - X;

};

CORBA::Long result(void){

return(Result);

};

Один из каркасных файлов, созданных IDL-ко м пилятором из интерфейсного клас са adding_machine, называется adding_machine_skel. Обратите внимание на то, что при выведении новых классов IDL-компилятор берет имя из определения интерфейса. Наш класс adding_machine_impl обеспечивает реализацию интерфейса функций, объявленного с использованием языка IDL. Во-первых, в классе adding_machine_impl объявляется член данных Result. Во-вторых, здесь предлагается реализация методов add(), subtract () и result (). В то время как интерфейсный класс adding_machine включает объявление этих методов, класс adding_machine_impl обеспечивает их реализацию. Определяемый пользователем класс adding_machine_impl должен наследовать из базового класса множество функций, полезных для распределенного программирования. В этом и состоит основная схема работы, связанной с CORBA-программированием. Интерфейсный класс предназначен для представления используемых интерфейсов. Назначение IDL-компилятора ~ сгенерировать реальные каркасные С++-классы, исходя из определения интерфейса. Разработчик выводит класс из одного каркасных и обеспечивает реализацию методов, определенных в интерфейсном классе, и членов данных, которые должны использоваться для хранения атрибутов объекта. Итак, создание реальных С++-классов из IDL-определения представляет собой процесс, состоящий из трех действий.

1. Проектирование интерфейсов классов, отношений и иерархии с использование м языка IDL.

2. Использование IDL-ко м пилятора д ля генерирования реальных каркасных C++-классов на основе IDL-классов.

3. Использование наследования для создания пото м ков из одного из нескольких каркасных классов и реализация м етодов интерфейса, унаследованных от каркасных классов.

Мы рассмотрим этот процесс более детально ниже в этой главе. Но сначала познакомимся с базовой структурой программы потребителя.

 

Итак, из программ, представленных на рис. 8.4 и 8.5, видно, что д л я CORBA-при л ожения потребуются два ORB-объекта, объектный адаптер, метод передачи IOR-ссылки и по крайней мере один обслуживаю щ ий объект. Логическал структура CORBA-приложения показана на рис. 8.6.

После получения IOR-ссылки и приведения ее к соответствующему типу вызов удаленного метода в программе клиента (потребителя) подобен вызову обычного метода в любой С++-программе. В CORBA-примерах этой книги предполагается использование протокола IIOP (Internet Inter ORB Protocol). Поэтому ORB-брокеры (см. рис. 8.6) связываются с помощью протокола TCP/IP. IOR-ссылка должна содержать информацию о местоположении удаленного объекта, достаточную для реализации TCP/IP-связи. В качестве объектного адаптера обычно используется переносимый объектный адаптер. Но для некоторых программ (более старых и простых) можно использовать базовый объектный адаптер. Различие между этими двумя адаптерами мы рассмотрим ниже в этой главе. Каждое CORBA-приложение имеет один или несколько обслуживающих объектов, которые реализуют интерфейс, разработанный в IDL-классе. Простейшие программы потребителя и изготовителя, показанные на рис. 8.4 и 8.5, могут выполняться на одном компьютере в различных процессах или на различных компьютерах. Если эти программы выполняются на одном компьютере, файл adding_machine. ior должен быть доступен из обеих программ. Если они выполняются на различных компьютерах, этот файл должен быть послан клиентскому компьютеру по FTP-протоколу, электронной почте, HTTP-протоколу и т.д. Детали компиляции и выполнения этих программ описаны в разделах «Профиль программы 8.1» и «Профиль программы 8.2».

 

IDL-компилятор

IDL-компилятор представляет собой инструмент, предназначенный для перевода IDL-определений класса в С++-код. Этот код состоит из коллекции «каркасных» определений классов, перечислимых типов и шаблонных классов. Для CORBA-программ, приведенных в этой книге, в качестве IDL-компилятора используется MICO IDL-компилятор. В табл. 8.3 перечислены опции командной строки, которые чаще всего применяются при вызове этого IDL-компилятора.

Таблица 8.3. Самые распространенные опции командной строки, применяемые при вызове IDL-компилятора

• --boa  Генерирует «каркасные» конструкции, которые используют базовый объектный адаптер (basic object adapter — BOA). Эта опция испо л ьзуется по умо л чанию

• --no-boa  Отключает генерирование кода «каркасных» конструкций для BOA

• --poa  Генерирует «каркасные» конструкции, которые испо л ьзуют переносимый объектный адаптер (portable object adapter — POA)

• --no-poa  Отк л ючает генерирование кода «каркасных» конструкций для POA. Эта опция используетс я по умолчанию

• -- g en-included-defs Генерирует код, который был включен с по м о щ ью директив #include

• —version  Выводит версию спецификации MICO

• -D  Опреде ля ет макрос препроцессора. Эта опци я эквивалентна ключу -D у большинства UNIX С-компиляторов

• -I  Определяет путь поиска для директив #include. Эта опция эквивалентна к л ючу -I у бо л ьшинства UNIX С-компи ля торов

Ключи -boa и -poa (см. табл. 8.3) позволяют определить, на какой тип адаптера будут ориентированы создаваемые «каркасные» конструкции. Например, при выполнении слелующей команды

idl -poa -no-boa adding_machine.idl

будет получен файл adding_machine.h , который содержит «каркасные» конструкции для РОА-адаптера (portable object adapter), и будет отключено генерирование «каркасных» конструкций для ВОА-адаптера (basic object adapter).

При вводе команды idl -h будет сгенерирован полный список ключей IDL-компилятора. Если в поставке MICO надлежащим образом инсталлированы man-страницы, то ввод команды man idl обеспечит полное описание доступных IDL-ключей. Проектирование IDL-классов — первый шаг в CORBA-программировании. На слелующем этапе необходимо определить способ хранения и считывания IOR-ссылок на удаленные объекты.

 

Получение IOR-ссылки для удаленных объектов

ORB-класс содержит две функции-члена (string_to_object() и object_to_. string ()), которые можно использовать для преобразования IOR-объектов из строк в объекты типа Object_ptrs и обратно. Функция-член string_to_object() принимает параметр типа const char * и преобразует его в объект типа Object_ptr. Функция-член Object_to__string() принимает параметр типа Object_ptr и преобразует его в указатель типа char *. Эти методы являются составной частью интерфейса ORB-клаеса. Метод Object_to_string () используется для получения объектной IOR-ссылки строковой формы. IOR-ссылку, представленную в виде строки, можно передать программам клиентов (потребителей) различными способами, например:

• Электронная почта 

• Разделяемые файловые системы (NFS-оборудование)

• FTP-протокол 

• Встраивание в HTML-документы

• Java-аплеты/сервлеты

• Аргументы командной строки

• Разделяемая память 

• Традиционные средства межпроцесной связи (IPC), т.е. каналы, FIFO-очереди и пр.

• Переменные среды CGI-команды приема и отправки данных

Затем программа приема данных получает строковый вариант IOR-ссылки и использует функцию-член string_to_object () ORB-объектадля преобразования IOR-ссылки в CORBA-объект ptr. Этот CORBA-объект ptr затем «сужается» (т.е. приводится к соответствующему типу) и используется для инициализации локального объекта. В программах 8.1 и 8.2 для передачи IOR-ссылки между программой-потребителем и программой-изготовителем используются строковые формы объектов и файл. Строковую форму IOR-ссылок можно использовать для обеспечения очень гибкой связи с удаленными объектами, которые могут размещаться практически в любом месте Internet, intranet или extranet. Существует реализация MIWCO (Wireless Mico) — открытая реализация спецификации wCORBA , стандарт беспроводной спецификации CORBA, который можно использовать для улучшения мобиль-ности объектов. Эта беспроводнал спецификация позволяет реализовать связь посредством MIOR-ссылки (Mobile IOR). Она поддерживается для TCP-, UDP- и WAP WDP-механизмов передачи (Wireless Application Protocol Wireless Datagram Protocol). Мультиагентные и распределенные агентные системы также могут воспользоваться преимуществами стандартов IOR-ссылок. IOR- и MIOR-ссылки являются частью «строительных блоков» слелующего поколения объектно-ориентированных Web-служб. Важно отметить, что хотя строковые IOR-ссылки обеспечивают гибкость и переносимость, они не могут идеально подходить ко всем ситуациям и конфигурациям. Передача файла, который содержит IOR-ссылку, — не слишком приемлемое требование для многих систем. Трудно с точки зрения практичности требовать от приложений клиента и сервера разделять одну и ту же файловую систему или сеть. А с точки зрения безопасности строковый вариант IOR-ссылки вообще исключается как достойный рассмотрения. Если приложение типа «клиент-сервер» велико по объему и достаточно разнотипно, то требование разделения строковой формы IOR

 

Стандарт службы имен обеспечивает механизм преобразовани я имен в объектные ссылки. Автор запроса на IOR-ссылку предоставляет в службу имен имя, а она возвращает ему объектную ссылку, соответствующую этому имени.

Служба имен действует как разновидность телефонного справочника, в котором по имени и щ ется номер. Эта служба позволяет программам клиента (потребителя) находить по имени объектные ссылки. Эту службу можно использовать не только для получения IOR-ссылок, но и для других ресурсов приложения. Получение объектной ссылки по имени называется связыванием по имени (name binding). Коллекция вариантов связывания по имени соот н осится с объектом именного контекста (naming context). Чтобы проиллюстрировать понятие именного контекста, предположим, что у нас есть приложение, которое предназначено для планировани я маршрутов и состоит из большого количества различных объектов. Мы можем организовать группы объектов в соответствии с выполняемы м и и м и функция м и. Одни объекты относятся к группе файлового ввода-вывода данных, а другие — к группе безопас н ости. Наше приложение использует также объекты, которые имеют отношение к видам транспорта: поезд, автобус, автомобиль и велосипед. Каждое такое группирование образует некоторый контекст. Например, чтобы логически сгруппировать объекты, связанные с видами транспорта, можно создать контекст транспорта и связать с ним все виды транспорта. Такое группирование позволяет сформировать именной контекст. Сначала связываем наименование каждого вида транспорта с его IOR-ссылкой. Это и есть связывание по имени. Затем соотносим это связывание по имени с контекстом транспорта. Мы используем контексты для логической организации групп связанных объектов. Коллекция связанных именных контекстов образует именной граф (naming graph). Именные контексты представляются объектами. Поскольку именной контекст реализуется как объект, он может участвовать в связывании по имени подобно любому другом)' объекту. Это означает, что именной контекст может потенциально содержать другие именные контексты. Например, на рис. 8.7 показано несколько контекстов, включающих логическое представление нашего контекста транспорта.

Обратите внимание на то, что пос л едняя строка в контексте транспорта представляет собой имя airborne (возлушный вид транспорта). Для имени airborne существует еще один контекст, именуемый flying_machines (летательные аппараты). Контекст flying_machines содержит связи с неско л ькими объектами (на основе выполняемыхфункций). Контекст transportation (транспортные средства) вместе с контекстом flying_machines образуют именной граф. На рис. 8.7 обратите внимание на то, что последний объект в контексте flying_machines называется sonic (звуковые). Имя sonic связано с контекстом fast_flying_machines. Имя sonic имеет объектную ссылку 8888. Тем самым к именному графу добавляется еще один контекст. Это — пример именного контекста, содержащего другой именной контекст. Именной граф можно использовать для представления «многоплановой» структуры взаимосвязей в распределенном объектно-ориентированном приложении. Можно сказать, что именной граф фиксирует панораму распределенного приложения. Для мультиагентных систем именной граф можно использовать в качестве разновидности семантической сети (см. § 8.1). Несмотря на то что объекты могут быть разбросаны по различным аппаратным платформам, операционным системам, языкам программирования и географически отдаленным компьютерам, именной граф может представлять единую логическую структуру взаимоотношений и связей между объектами. На рис. 8.8 показано альтернативное представление именного графа, приведенного на рис. 8.7. Именные контексты этих двух рисунков совпадают, и в обоих случаях отчетливо отображены взаимоотношения между именными контекстами. На рис. 8.8 также показано, что существует путь от контекста transportation к контексту fast_flying_machines и обратно к контексту transportation.

Для обхода именного графа в процессе решения распределенной задачи применяются известные алгоритмы обхода графов. При этом различные пути обхода именного графа могут представлять различные решения задачи. Служба имен обеспечивает автора запроса доступом к именным контекстахм и именным графам. К именным контекстам доступ осуществляется через именные графы, а к связям — через именные контексты. Связывание обеспечивает прямое соответствие имени и объектной ссылки. Рассмотрим программу 8.3, в которой представлен простой вариант «изготовителя», создающего связывание по имени и соотносящего это связывание с некоторым именным контекстом.

// Программа 8.3

1 #include

2 #include

3 #include «permutation_impl.h»

4 #define MICO_CONF_IMR

5 #include

6 #include

7 #include

8 #include

9 #include 10

11

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

13 {

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

15 CORBA::Object_var PoaObj =Orb->resolve__initial_references(«RootPOA»);

16 PortableServer::POA_var Poa =PortableServer::POA::_narrow(PoaObj);

17 PortableServer::POAManager_var Mgr =Poa->the_POAManager();

18 inversion Server;

19 PortableServer: :ObjectId_var Oid =Poa->activate_object(&Server);

20 Mgr->activate () ;

21 permutation_ptr ObjectReference = Server.__this();

22 CORBA::Object_var NameService =Orb->resolve_initial_references («NameService»);

23 CosNaming: :NamingContext_var NamingContext =CosNaming::NamingContext::_narrow (NameService);

24 CosNaming: :Name name;

25 name.length (1) ;

26 name[0].id = CORBA::string_dup («Inflection»);

27 name[0].kind = CORBA::string_dup ("");

28 NamingContext->bind (name, ObjectReference);

29 Orb->run();

30 Poa->destroy(TRUE,TRUE);

31 return(0) ;

32 } 33 34

§ 8.1. Семантические сети

Семантическал сеть (semantic network) — это одна из са м ых старых и простых схе м представления зна н ий. В ос н ове се м а н тической сети лежит г рафическое изображение иерархических взаи м оот н ошений между объекта м и. На рис. 8.9 показа н а простая семантическая сеть, которая отображает зна н ия о тра н спортных средствах в цело м и о конкретных транспортных средствах в част н ости.

Овалы в семантической сети называются узлами, а линии — связями. Связи представляют существующие отношения между узлами. Узлы используются для представления объектов и фактов (или описателей). Некоторые связи являются дефинициональными, а другие могут быть вычислены. Связи можно использовать для отображения наследования или подчиненности. Узлы и связи вместе выражают некоторые порции знаний. Например, изучив семантическую сеть, представленную на рис. 8.9, мы понимаем, что F-15 — это транспортное средство, а также летательный аппарат, который имеет по крайней мере два крыла. Семантические сети используются для представления знаний, необходимых в ПО принятия решений.

 

Использование службы имен и создание именных контекстов

При выполнении строки 22 серверная про г рамма получает ссылку на службу имен

CORBA::Object_var NameService =Orb->resolve_initial_references(«NameService»);

Помимо получения объектных ссылок на хранилище реализаций (Implementation Repositoiy) и хранилище интерфейсов (Interface Repositoiy), метод ORB-объекта resolve_initial_references() используется д л я получени я ссылки на службу имен. Получив нужную ссылку, программа-сервер создает на ее основе именной контекст (см. строку 23):

CosNaming::NamingContext_var NamingContext =

CosNaming::NamingContext::_narrow(NameService);

При таком подходе мы получаем начальный именной контекст, который играет роль контекста, действующего по умолчанию. Обнаружив службу имен и создав начальный именной контекст, серверная программа может добавлять в контекст пары (связывания по имени) «имя/объектнал ссылка». Имена могут представлять собой объекты доменов или другие контексты. Чтобы добавить в контекст пару «имя/объектная ссылка», необходимо сначала создать имя. Имена реализуются в стандарте CORBA посредством структуры NameComponent.

struct NameComponent { //.. .

Istring_var id;

Istring_var kind;

}

В CORBA-реализации MICO структура NameComponent объявляется в файле CosNaming. h. Структура NameComponent содержит два атрибута: id и kind. Первый атрибут используется для хранения текста имени, а второй представляет собой идентификатор, который можно использовать для классификации объекта, например так.

//...

CosNaming::Name ObjectName;

ObjectName.length(1);

ObjectName.id = Corba::string_dup (" train») ;

ObjectName.kind=Corba::string_dup(«land_transportation»);

NamingContext->bind(ObjectName,ObjectReference) ;

//...

Здесь объяв л яется объект типа NameComponent. Атрибут id устанавливается равным значению «train», а атрибут kind— значению land_transportation. Очевидно, атрибут id до л жен быть описате л е м (дескриптором) объекта. Атрибут kind м ожно ис-пользовать для описания контекста или логической группы, к которой принадлежит этот объект. В данном случае он классифицирует поезд (train) как объект land_transportation (назе м ный вид транспорта). Метод bind () преобразует и м я объекта ObjectName в объектную ссылку ObjectReference и связывает ее с начальны м именным контексто м. И м я м ожет состоять из нескольких объектов типа NameComponent. Если имя состоит только из одного объекта типа NameComponent, оно называется простым, а если из нескольких — составным. Если имя составное, то атрибут kind можно использовать для описания отношения (этот метод рассматривается в главе 12). В программe 8.3 объект связывается с объектной ссылкой, которая соотносится с именованным контекстом. После связывания с именным контекстом объект клиента может получить доступ к контексту посредством службы имен. В программах 8.1 и 8.2 для связи (посре д ство м строковой IOR-ссылки ) между программами потребителя и изготовителя мы использовали файл. А для связи клиента и сервера (см. программу 8.3) используется служба имен.

Детали инсталляции и функционирования службы и м ен зависят от конкретной реализации. Среда MICO включает программу nsd, которая реализует COS-сов м ести м ую службу имен. Прежде чем служба имен будет доступной для программы-погребителя, необходимо залустить де м он micod и внести соответствующие элементы в хранилище реализаций. Чтобы узнать, как пользоваться програ мм а м и nsd, micod и imr, обратитесь к соответствую щ ей доку м е н тации и руководству по MICO (о н о содержит м ножество примеров использования программ imr, nsd, micod и ird). В листинге 8.5 приведен фрагмент из сценария, используемого для настройки сервера в программе 8.3, позволяющей сделать службу имен доступной для программы-потребителя.

// Листинг 8.5. Сценарий внесения записи в хранилище

// реализаций и запуска службы имен

//

micod -ORBIIOPAddr inet:hostname:portnumber —forward &

imr create NameService poa 'which nsd* IDL:omg.org/CosNaming/

NamingContext:1.0#NameService \

-ORBImplRepoAddr inet:hostname:portnumber \ -ORBNamingAddr inet:hostname:hostname:portnumberportnumber

imr create permutation persistent "'pwd'/permutation_server \ -ORBImplRepoAddr inet:hostname:portnumber \

-ORBNamingAddr inet:hostname:portnumber» IDL:permutation:1.0 \ -ORBImplRepoAddr inet:hostname:portnumber \ -ORBNamingAddr inet:hos tname:portnumber

imr activate permutation -ORBImplRepoAddr inet:hostname:portnumber \

-ORBNamingAddr inet:hostname:portnumber

Этот сценарий можно использовать в сочетании с кодом сервера, приведенным в программе 8.3. Приведенный здесь сценарий реально позволяет автоматически запустить программу-сервер permutation_server. Обратите вни м ание на то, что имена hostname и portnumber в программе 8.5 необходимо заменить реальным именем компьютера, на котором выполняется сервер, и номером порта соответственно.

 

Служба имен «потребитель-клиент»

Программа 8.3 связывает имя объекта с именным контекстом. Программа 8.4 содержит текст программы-потребителя, которая использует службу имен для доступа к связкам «объект-ссылка», которые были созданы в программе 8.3. Программа 8.3 генерирует перестановки любой строки символов, которую она получает. Для перестановки изменяется местоположение символов в строке. Например, эти строки

Objcte   JbOetc   tbOjec

Ojbect   JObetc

Ojbcet   JtObec

представ л яют собой перестановки строки Object. К л иент передает серверу строку и сервер генерирует N перестановок. Сервер связывает и м я «Inflection» с именным контекстом. Именно это имя программа-клиент должна задать, чтобы получить объектную ссылку из именного контекста.

// Программа 8.4

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

2 {

3

4 try{

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

6 object_reference Remote(«NameService»,Orb);

7 Remote.objectName(«Inflection»);

8 permutation_var Client =permutation::_narrow(Remote.objectReference());

9 char Value[1000];

strcpy(Value,«Common Object Request Broker»);

11 Client->original(Value);

12 int N;

12 for(N = 0;N < 15;N++)

14 {

15 cout « «Значение функции nextPermutation() "<< Client- >nextPermutation() « endl;

16 )

17 }

18 catch(CosNaming::NamingContext::NotFound_catch &exc) {

19 cerr << " Исключение: объект не обнаружен.» « endl;

20 }

21 catch(CosNaming::NamingContext::InvalidName_catch &exc) {

22 cerr << «Исключение: некорректное имя.» « endl;

23 }

24

25 return(0);

26 }

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

1. Получить ссылку на службу имен.

2. С помощью службы имен получить ссылку на соответствующий именной контекст.

3. С помощью именного контекста получить ссылку иа соответствующий объект.

Действие 1 реализуетс я путе м вызова м ето д а resolve_initial_references():

//.. .

CORBA::Object_var NameService;

NameService = Orb->resolve_initial_references

(«NameService»);

//...

Функция resolve_initial_references () возвратит объектную ссылку на службу имен. В действии 2 эта ссылка используетс я дл я получения объектной ссылки на именной контекст:

CosNaming: :NamingContext_var NameContext; NameContext = CosNaming::NamingContext::_narrow

(NameService);

В действии 3 значение объектной ссылки NameService «сужается», т.е. приводится к соответствую щ ему типу, в результате чего получаетс я объектнал ссылка на и м енной контекст NameContext. С по м ощью объекта NameContext програ мм а-потребитель может вызвать его м етод resolve(). Строки 24-27 из програ мм ы8.3 используютс я дл я построени я и м ени, которое и будет передано м етолу resolve ().

Name .length (1);

Name[Q].id = CORBA::string_dup («Inflection»); Name[C].kind = CORBA::string_dup (""); try {

ObjectReference = NameContext->resolve (Name);

}

Метод resolve() возвращает объектную ссылку, связанную с заданным именем объекта. В данном случае задано имя «Inflection». Обратите внимание на то, что такое же имя связывается с именным контекстом в программе8.3 (строка28). Если программа-потребитель имеет объектную ссылку, она может ее «сузить», а затем с ее помощью получить доступ к удаленному объекту. Процесс получения объектной ссылки на удаленный объект вполне тривиален, и поэтому имеет смысл его упростить путем инкапсуляции соответствующих компонентов в классе.

class object_reference{ //.. .

protected:

CORBA::Object_var NameService;

CosNaming::NamingContext_var NameContext;

CosNaming::Name Name;

CORBA::Object_var ObjectReference; public:

object_reference(char *Service,CORBA::ORB_var Orb);

CORBA::Object_var objectReference(void);

void objectName(char *FileName,CORBA::ORB_var Orb);

void objectName(char *OName); //. . . }

Про г рамма 8.4 использует преи м у щ ества просто г о каркасно г о к л асса obj ect_reference, который м ы создали с этой целью.

В про г ра мм е 8.4 (строка 6) обратите вни м ание на создание объекта Remote типа object_reference. В строке 8 этот объект используется для получения ссылки на удаленный объект с помощью следующего вызова м етода:

Remote.obj ectReference();

После этого программа-потребитель получает доступ к удаленному объекту. Класс object_reference обеспечивает выполнение некоторых необходимых действий и тем самым упрощает написание программы-потребителя. Ко н структор класса object_reference (о н вызывается в строке 6 программы 8.4) реализован следующим образом.

object_reference::object_reference(char *Service,

CORBA::ORB_var Orb)

{

NameService = Orb->resolve_initial_references (Service); NameContext = CosNaming::NamingContext::_narrow (

NameService);

}

Этот ко н структор получает ссылку на службу и м ен и создает объект к л асса NameContext. В строке 7 и м я это г о объекта передается м етолу objectName (). Затем для получения объектной ссылки, связанной с именем объекта, используется именной контекст. Метод objectName () реализован с л едую щ и м образо м.

void object_reference::objectName(char *OName) {

Name.length (1);

Name[0].id = CORBA::string_dup (OName); Name[0].kind = CORBA::string_dup ("");

try {

ObjectReference = NameContext->resolve (Name);

} catch(...) {

cerr « " Problem resolving Name " « endl; throw;

}

}

После вызова метода objectName() программа-потребитель получает доступ кссылке на удаленный объект. Теперь остается лишь вызвать метод objectReference() (это реализуется в строкев программы8.4). В методе objectName () основную часть работы выполняет функция resolve (). Программы 8.3 и 8.4 образуют простое распределенное приложение «клиент-сервер», которое для доступа к объектным ссылкам вместо строковой формы IOR-ссылок использует службу имен. В сетях intranet или Internet можно использовать оба подхода. Эти же варианты применяются в качестве опорных структурных компонентов в контексте новой модели Web-служб.