Параллельное и распределенное программирование на С++
Шрифт:
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-служб.
Подробнее об объектных адаптерах
Помимо службы имен и объекта именованного контекста, сервер в программе 8.3 также использует переносимый объектный адаптер. Вспомните, что адаптер (см. рис. 8.6) действует как своего рода посредник между ORB-брокером и обслуживающим объектом, который в действительности выполняет работу CORBA-объекта. Мы можем сравнить этот обслуживающий объект с «наемным» писателем, который пишет книту от имени «подуставшей» знаменитости. С этой знаменитостью наперебой общаются журналисты, литературные агенты и юристы. Знаменитость удостаивается всех почестей, но реальную работу делает за него другой человек. CORBA-объект «публикует» интерфейс с внешним миром и играет роль «знаменитости» в CORBA-программе. Программа-клиент (или потребитель) взаимодействует с интерфейсом, который обеспечивает CORBA-объект, но реальную работу выполняет обслуживающий объект, играя роль «наемного» писателя. Обслуживающий объект имеет собственный
Таблица 8.4. Некоторые элементы, содержащиеся в хранилище реализац и й
Имя объекта Уникальный идентификатор для каждого объекта
Режим активации Разделяемый, неразделяемый, постоянный, биб-
лиотека permethod
Путь Имя или путь выполняемого файла
Список идентификаторов хранилища
ВОА-адаптер, чтобы приступить к выполнению объекта изготовителя (сервера), использует такие записи из хранилища реализаций, как режим активизации и путь. И хотя в ряде более простых примеров, приведенных в этой главе, используется ВОА-адаптер, мы рекоменлуем для серьезной CORBA-разработки применять РОА-адаптер. РОА-адаптер поддерживает:
• прозрачную активизацию объекта;
• транзитные объекты;
• не я вную активизацию обслуживаю щ их объектов;
• перманентные (постоянные) объекты за пределами сервера.
Возможно, наиболее важной функцией РОА-адаптера является взаимодействие собслуживающими объектами. CORBA-спецификация определяет обслуживающий объект следующим образом.
Обслуживающий объект — объект языка программирования, который реализует запросы к одному или нескольким объектам. Обслуживающие объекты в общем случае существуют в контексте процесса сервера. Запросы на получение объектных ссылок обслуживаются ORB-брокером, действующим в качестве связующего звена, и трансформируются в вызовы конкретных обслуживающих объектов. Во время своего жизненного цикла объект может быть связан с несколькими обслуживающими объектами.
Каждый обслуживающий объект должен иметь по крайней мере один POA-адаптер. Но возможны и другие конфигурации (рис. 8.10).
РОА-адаптерами управляют специальные объекты управления, или POA-менеджеры. CORBA-спецификация определяет РОА-менеджер таким образом:
РОА-менеджер — это объект, который инкапсулирует состояние обработки одного или нескольких РОА-адаптеров. С помощью РОА-менеджера разработчик может сделать запросы к соответствующим РОА-адаптерам с организацией очереди. Разработчик также может использовать РОА-менеджер для дезактивизации РОА-адаптеров.
Сервер в программе 8.3 служит простым примером использования объектов POA- адаптеров и РОА-менеджеров. Более подробное рассмотрение POA выходит за рамки нашей книги. За деталями обращайтесь к работе [20]. MICO-поставка также содержит ряд примеров использования мощных средств POA.
Рис.8.10. Возможные конфигурации отношений между РОА-агентами и обслуживающими объектами
Хранилища реализаций и интерфейсов