Связь и Интернет 

Введение в разработку VisiBroker CORBA в среде JBuilder

CORBA-cервисы, представляют собой набор служб системного уровня, упакованных вместе с интерфейсами IDL. Их можно рассматривать как расширение функциональности ORB. Они используются для создания компонент, их именования и внедрения в среду.

Сервис именования (Naming service) служит для управления ссылками на CORBA-объекты и их хранения. Его осн.зад. - универсальным образом организовать соединение объектов друг с другом. Сервис имен оперирует с хранилищем объектных ссылок. Обращение к этому сервису выполняется для получения нужной объектной ссылки, идентифицируемой по читабельному имени объекта.

Сервис событий (Event service) обеспечивает поддержку асинхронного взаимодействия приложений.

Сервис хранения объектов (Persistence service) предоставляет набор универсальных интерфейсов для сохранения экземпляров объектов в долговременной памяти. Сервис разработан таким образом, что возможна его реализация на основе объектной базы данных.

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

Сервис взаимодействия (Relationship service) реализует логические связи между CORBA-объектами. Сервис определяет два дополнительных типа объектов: связь и роль. Роль представляет собой CORBA-объект, отражающий характер связи, а связь характеризует зависимости объектов прикладной области.

Сервис управления разделяемыми ресурсами (Concurrency control) service позволяет клиентам координировать свои действия при исп-нии разделяемых ресурсов. Управление разделяемыми ресурсами осущ-ся с пом. блокировок. Каждая блокировка ассоциируется с единственным ресурсом и единственным клиентом. Сервис определяет также несколько режимов блокировок, которые соответствуют различным способам доступа.

Сервис внешнего представления (Externalization service) формирует копию CORBA-объекта в виде некоторого внешнего представления - файла, элемента базы данных и т.д.

В адресном пространстве клиента функционирует специальный объект, называемый заглушкой (stub). Поучив запрос от клиента, он упаковывает параметры запроса в специальный формат и передает его серверу, а точнее скелету.Скелет (skeleton) - объект, работающий в адресном пространстве сервера. Получив запрос от клиента, он распаковывает его и передает серверу. Также скелет преобразует ответы сервера и передает их клиенту (заглушке).Создание CORBA приложения на Java начинается с написания интерфейса для удаленного объекта, используя язык описания интерфейсов (Interface Definition Language, IDL). Создадим файл test.idl

module testApp {

{ long count(in string msg); };

Серверная часть приложения.

Первое что мы делаем, создаем ORB. Затем создаем экземпляр класса удаленного объекта (testServant) и регистрируем его в ORB. Дальше вызываем специальную службу имен (NameService) и регистрируем в ней имя удаленного объекта, чтобы клиент смог его найти.После того как сервер обработает запрос от клиента и выполнит метод count он снова перейдет в состояние ожидания.

ORB orb = ORB.init(args, null);

testServant testRef = new testServant();

orb.connect(testRef);

org.omg.CORBA.Object objRef =orb.resolve_initial_references("NameService");

NamingContext ncRef = NamingContextHelper.narrow(objRef);

Код клиента. Основные шаги написания клиентского приложения: Создание и инициализация ORB Получение контекста службы имен Нахождение удаленного объекта Вызов метода count.

Третий пункт. Создается объект NameComponent. Вызывается метод resolve(NameComponent path), который отыскивает по имени удаленный объект (стандартный CORBA-объект). При помощи метода narrow(org.omg.CORBA.Object obj) класса testHelper (сгенерированного idltojava компилятором) получаем объектную ссылку на интерфейс test.

NameComponent nc = new NameComponent("test", "");

NameComponent path = {nc};

org.omg.CORBA.Object obj= ncRef.resolve(path);

test testRef=testHelper.narrow(obj);Теперь можно вызывать метод count

String msg = "try to count";

int count = testRef.count(msg);

24. ORB: понятие, назначение, основные функции. Принципы организации запросов в ORB. Использование стандарта IIOP.

Брокер объектных запросов - это объектная шина. Задачей брокера явл. предоставление механизма выполнения запроса объекта-клиента: поиск объекта, к кот. относится данный запрос, передача необх. данных, подготовка объекта к обработке. Брокер объектных запросов обеспечивает прозрачное взаимодействие клиентского и серверного приложений. Для разработчика вызов методов удаленных объектов не отличается от обычных локальных вызовов. ORB управляет взаимодействием объектов в распределенной сетевой среде. IIOP

IIOP (Internet Inter-ORB Protocol) - это специальный протокол взаимодействия между ORB.

IIOP определяет обмен сообщениями через TCP/IP-соединения. В посл.время протоколу IIOP уделяется все больше внимания со стороны крупнейших производителей ПО. IIOP становится признанным стандартом для вызова удаленных объектов в Интернет.

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

Клиент может запрашивать выполнение операций с помощью ORB несколькими способами. Вызов операций разделяемого объекта-сервера может быть статическим, через IDL-суррогат, или динамическим (Dynamic Invocation Interface). В случае статического вызова описания интерфейсов на IDL отображаются в программный код на языках С, С++, Smalltalk и др. При использовании динамического интерфейса запросы формируются специальным образом, без отображения интерфейса объекта в исходный код разрабатываемого приложения.


Похожая информация.


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

2. Задание к лабораторной работе

Разработать почтовый клиент и сервер. Клиент – оконное приложение, которое будет позволять отсылать и получать с сервера сообщения. Идентификация клиентов на сервере, протокол передачи сообщений – на усмотрение студентов.

Сервер может быть консольным приложением. Хранить сообщения можно в текстовом файле. Рекомендуется сделать сервер многопоточным.

Для взаимодействия клиента и сервера использовать технологию CORBA.

В качестве дополнения предлагается сервер или клиент реализовать не на Java.

3. Содержание отчета

Отчет должен содержать:

1. Постановку задачи, решаемой отлаженной программой.

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

3. Листинг программы с необходимыми комментариями.

4. Контрольные вопросы

1. Что такое CORBA?

2. Что такое IDL? Для чего он нужен?

3. Как осуществляется взаимодействие клиента и сервера в CORBA?

4. Как передаются данные между ними?

5. Для чего нужен сервер имен?

6. Как запускается CORBA‑сервер?

5. Литература

1. Кен Арнольд, Джеймс Гослинг, Дэвид Холмс. Язык программирования Java™.

2. Официальный сайт Java – http://java.sun.com/ (есть раздел на русском языке с учебником).

3. Java™ 2 SDK, Standard Edition Documentation – http://java.sun.com/products/jdk/1.5/index.html.

4. Джеймс Гослинг, Билл Джой, Гай Стил. Спецификация языка Java (The Java Language Specification – http://www.javasoft.com/docs/books/jls/). Перевод на русский язык – http://www.uni-vologda.ac.ru/java/jls/index.html

5. Официальный сайт проекта Eclipse – http://www.eclipse.org/.

6. Приложение 1. CORBA

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

Основу CORBA составляет объектный брокер запросов (Object Request Broker). ORB управляет взаимодействием объектов в распределенной сетевой среде. IIOP (Internet Inter-ORB Protocol) – это специальный протокол взаимодействия между ORB.

В адресном пространстве клиента функционирует специальный объект, называемый заглушкой (stub). Поучив запрос от клиента, он упаковывает параметры запроса в специальный формат и передает его серверу, а точнее скелету.

Скелет (skeleton) – объект, работающий в адресном пространстве сервера. Получив запрос от клиента, он распаковывает его и передает серверу. Также скелет преобразует ответы сервера и передает их клиенту (заглушке).

Для того чтобы написать любое приложение CORBA используя технологию Java, необходимо иметь две вещи – это установленный пакет JDK1.5 и компилятор idlj (…\jdk1.5.0\bin\idlj.exe). JDK предоставляет набор классов для работы с CORBA объектами, а idlj производит отображение языка IDL в Java.

6.1 Создание простейшего CORBA-приложения

6.1.1 Написание интерфейса

Создание CORBA приложения на Java начинается с написания интерфейса для удаленного объекта, используя язык описания интерфейсов (Interface Definition Language, IDL).

Создадим файл hello.idl

Module HelloApp{interface Hello{string sayHello();oneway void shutdown();};};

Данный интерфейс описывает лишь два метода shutdown и sayHello . Причем, нам не важно, что делают эти методы, главное мы определяем, что они есть и определяем какие у них входные и выходные параметры.

idlj – fall Hello.idl

В текущей директории появилась новая папка Hello App , в которой содержаться шесть java‑файлов. Каждый из них имеет свое назначение.

· HelloPOA.java java – абстрактный класс, который представляет собой ни что иное, как скелет сервера (skeleton) и обеспечивает функциональность сервера.

· _HelloStub.java – класс, реализующий заглушку (stub) клиента. Обеспечивает функциональность клиента.

· HelloHelper.java и HelloHolder.java – классы, предоставляющие вспомогательные функции для CORBA объектов.

· HelloOperations.java – класс, содержащий описание интерфейса hello на языке Java.

· Hello.java – класс – наследник HelloOperations, поддерживающий интерфейс org.omg.CORBA. Object.

6.1.2 Создание сервера

Теперь наша задача – написать класс, реализующий интерфейс hello . В нашем случае это будет HelloImpl . Обратите внимание, на то, что он является наследником класса HelloPOA . В HelloImpl реализованы методы, объявленные в Hello . idl .

Для упрощения задачи объявление методов можно взять из файла HelloOperations . java , сгенерированного jdlj .

Class HelloImpl extends HelloPOA {private ORB orb; public void setORB (ORB orb_val) {orb = orb_val;} // implement sayHello() methodpublic String sayHello() {return «\nHello world!!\n»;} // implement shutdown() methodpublic void shutdown() {orb.shutdown(false);}}

Следующим шагом будет создание собственно серверной части приложения. Это будет класс HelloServer.

В нем будет всего один метод – стандартная функция main.

Первое что мы делаем, создаем ORB. Затем создаем экземпляр класса удаленного объекта (HelloImpl) и регистрируем его в ORB. Дальше вызываем специальную службу имен (NameService) и регистрируем в ней имя удаленного объекта, чтобы клиент смог его найти.

Рассмотрим подробнее эти этапы.

1. Создание и инициализация ORB. Производится вызовом статического метода init класса ORB

2. Создание экземпляра класса удаленного объекта и регистрация его в ORB

helloImpl.setORB(orb);

3. Получение контекста имен (NamingContext)

org.omg.CORBA. Object objRef = orb.resolve_initial_references («NameService»);

В первой строчке мы получаем объектую ссылку на службу имен (NameService). Но фактически это обыкновенный CORBA‑объект и для того, чтобы использовать его как контекст имен (NamingContext), необходимо вызвать метод narrow класса NamingContextHelper , который как бы конкретизирует данный CORBA‑объект.

4. Регистрация имени удаленного объекта (HelloImpl)

String name = «Hello»;

ncRef.rebind (path, href);

Регистрация имени производится для того, чтобы клиент смог найти удаленный объект. Этой цели служит функция rebind (NameComponent nc, Object obj) интерфейса NamingContext.

5. Ожидание запросов от клиента

Теперь сервер готов к работе.

// HelloServer.javaimport HelloApp.*;import org.omg. CosNaming.*;import org.omg. CosNaming. NamingContextPackage.*;import org.omg.CORBA.*;import org.omg. PortableServer.*;import org.omg. PortableServer.POA;import java.util. Properties;class HelloImpl extends HelloPOA {private ORB orb;public void setORB (ORB orb_val) {orb = orb_val;} // implement sayHello() methodpublic String sayHello() {return «\nHello world!!\n»;} // implement shutdown() methodpublic void shutdown() {orb.shutdown(false);}}

public class HelloServer {

public static void main (String args) {

// create and initialize the ORB

ORB orb = ORB.init (args, null);

// get reference to rootpoa & activate the POAManager

POA rootpoa = POAHelper.narrow (orb.resolve_initial_references («RootPOA»));

rootpoa.the_POAManager().activate();

// create servant and register it with the ORB

HelloImpl helloImpl = new HelloImpl();

helloImpl.setORB(orb);

// get object reference from the servant

org.omg.CORBA. Object ref = rootpoa.servant_to_reference(helloImpl);

Hello href = HelloHelper.narrow(ref);

// get the root naming context

// NameService invokes the name service

org.omg.CORBA. Object objRef =

orb.resolve_initial_references («NameService»);

// Use NamingContextExt which is part of the Interoperable

// Naming Service (INS) specification.

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

// bind the Object Reference in Naming

String name = «Hello»;

NameComponent path = ncRef.to_name(name);

ncRef.rebind (path, href);

System.out.println («HelloServer ready and waiting…»);

// wait for invocations from clients

catch (Exception e) {

System.err.println («ERROR:» + e);

e.printStackTrace (System.out);

System.out.println («HelloServer Exiting…»);

6.1.3 Создание клиента

Перейдем к написанию кода для клиента.

Основные шаги написания клиентского приложения

1. Создание и инициализация ORB

2. Получение контекста службы имен (NamingContext)

3. Нахождение удаленного объекта

4. Вызов метода sayHello.

5. Вызов метода shutdown.

Как видно, первые два пункта совпадают с этапами создания серверного приложения, поэтому рассматривать их не будем.

Третий пункт реализуется тоже достаточно просто. Создается объект NameComponent. Вызывается метод resolve (NameComponent path), который отыскивает по имени удаленный объект (стандартный CORBA‑объект). При помощи метода narrow (org.omg.CORBA. Object obj) класса helloHelper (сгенерированного idlj компилятором) получаем объектную ссылку на интерфейс hello.

String name = «Hello»;

helloImpl = HelloHelper.narrow (ncRef.resolve_str(name));

Я знаю, что CORBA позволяет реализовать несколько объектов на разных языках программирования и даже работать на разных вычислительных узлах. Однако, требуется ли тогда два разных ORB, написанных на двух разных языках?

Пример: Узел A запускает приложение Java J1, а узел B запускает приложение C++ C1. Должен ли я получить "Java ORB" для узла A и "C++ ORB" для узла B или все/некоторые ORB взаимодействуют с приложениями, написанными на любом языке, на котором есть сопоставление IDL?

Я был бы особенно благодарен, если бы кто-нибудь мог связать меня с источником, прямо изложив это, как я хотел бы его привести. Самое близкое, что я нашел, это "способ, которым программист манипулирует структурой или объединением, делает удаленный вызов с использованием прокси или реализует интерфейс с классом servant, точно так же во всех продуктах CORBA C++, точно так же во всех Java CORBA и т.д. " . Это заставляет меня думать, что мне понадобятся два ORB, но недостаточно явных. В основном я хотел бы знать, могу ли я сказать, что "поскольку ORB написан в C++, программистам приложений также запрещено использовать C++".

благодаря

3 ответов

Не важно, на каком языке ORB реализован, важно, какие языковые привязки он предоставляет. Для языка L вам нужен орб, который предоставляет привязки для языка L. Часто орбы просто предоставляют привязку к языку, на котором они сами написаны, но также могут обеспечивать привязки для некоторых других языков.

Нет. Пункт CORBA состоит в том, что он полностью отделяет компоненты.

Очевидно, что ваши приложения должны использовать клиентские библиотеки, с которыми они могут взаимодействовать. Ваш ORB может устанавливать привязки только для одного языка, и в этом случае вам нужно найти другие привязки или найти способ взаимодействия с ними (например, если вы используете Python, вы все равно можете работать с библиотеками C++, если хотите).

Попробуйте использовать эту технологию.

Существует несколько подходов, которые можно использовать при реализации приложений CORBA, но суммируя их, да, инфраструктура ORB должна быть на том же языке, что и ваша реализация приложения.

Как в Java, так и в C++ компилятор IDL генерирует заглушки и скелеты, которые служат клеем между сетью и вашей программой. Вы предоставляете реализацию своих объектов CORBA, обычно наследуемых от генерируемого компилятором IDL класса (скелета). Скелет каким-то образом получает запрос от клиента, а затем вызывает вашу реализацию. То же самое происходит в обратном направлении на стороне клиента.

Затем и скелет, и заглушка используют механизмы, предоставляемые ORB, чтобы удаленно вызывать серверы и отвечать на ответы назад, даже включая установление сетевых подключений, если клиент и серверы находятся на разных машинах. Эта "магия" реализуется ORB и должна присутствовать в вашей программе в виде библиотеки, набора функций и т.д., Которые заглушка и скелет будут использовать для выполнения работы.

Таким образом, каждая программа должна иметь какое-то представление ORB для взаимодействия с другими клиентами и серверами CORBA на других машинах.

Однако с логической точки зрения ORB рассматривается как слой, который фактически и без проблем соединяет как клиентов, так и серверы, поэтому, даже если приложение C++ имеет некоторую реализацию ORB, написанную в C++, и реализацию Java иметь ORB, написанный на Java, посредством магии стандартных протоколов (GIOP, IIOP), они могут общаться друг с другом без проблем.

Александр Годин

Технология CORBA - это стандарт написания распределенных приложений, предложенный консорциумом OMG (Open Management Group). Создавая CORBA-объекты, мы можем,например, существенно уменьшить время решения задач, требующих выполнения большого объема вычислений. Это возможно благодаря размещению CORBA-объектов на разных машинах. Каждый удаленный объект решает определенную подзадачу, тем самым разгружает клиент от выполнения лишней работы.

Рассмотрим взаимодействие объектов в архитектуре CORBA

Рис.1 Взаимодействие объектов в архитектуре CORBA

Основу CORBA составляет объектный брокер запросов (Object Request Broker). ORB управляет взаимодействием объектов в распределенной сетевой среде. IIOP (Internet Inter-ORB Protocol) - это специальный протокол взаимодействия между ORB.

В адресном пространстве клиента функционирует специальный объект, называемый заглушкой (stub). Поучив запрос от клиента, он упаковывает параметры запроса в специальный формат и передает его серверу, а точнее скелету.

Скелет (skeleton) - объект, работающий в адресном пространстве сервера. Получив запрос от клиента, он распаковывает его и передает серверу. Также скелет преобразует ответы сервера и передает их клиенту (заглушке).

Для того, чтобы написать любое приложение CORBA используя технологию Java, необходимо иметь две вещи - это установленный пакет JDK1.2 и компилятор idltojava . JDK предоставляет набор классов для работы с CORBA объектами, а idltojava производит отображение языка IDL в Java.

Создание CORBA приложения на Java начинается с написания интерфейса для удаленного объекта, используя язык описания интерфейсов (Interface Definition Language, IDL).

Создадим файл test.idl module testApp { interface test { long count(in string msg); }; };

Данный интерфейс описывает лишь один метод count . Причем, нам не важно, что делает этот метод, главное мы определяем, что он есть, определяем какие у него входные и выходные параметры.

Воспользуемся компилятором idltojava.

Idltojava Hello.idl Примечание. Данный компилятор по умолчанию использует препроцессор языка С++, поэтому что бы не мучится с сообщением об ошибке имя команды или файла указано неправильно (в переменной окружения CPP должен быть прописан путь к нему) отключим его использование, установив флаги. idltojava -fno-cpp Hello.idl Результат работы данной программы можно представить в виде схемы.

Рис.2 Работа idltojava компилятора
В текущей директории появилась новая папка testApp , в которой содержатся пять java - файлов. Каждый из них имеет свое назначение.

_testImplBase.java - абстрактный класс, который представляет собой не что иное, как скелет сервера (skeleton) и обеспечивает функциональность сервера;

_testStub.java - класс, реализующий заглушку (stub) клиента. Обеспечивает функциональность клиента;

test.java - класс, содержащий описание интерфейса test на языке Java;

testHelper.java и testHolder.java - классы, предоставляющие вспомогательные функции для CORBA объектов.

Теперь наша задача - написать класс, реализующий интерфейс test . Такие классы должны называться так, чтобы в их имени было слово "Servant", в нашем случае это будет testServant .

Class testServant extends _testImplBase { public int count(String msg) { return msg.length(); } }

Обратите внимание, что этот класс унаследован от _testImplBase . Как видно, здесь реализован метод count, который в данном примере считает количество букв в принятом сообщении.

Теперь перейдем непосредственно к написанию серверной части приложения.

Первое что мы делаем, создаем ORB. Затем создаем экземпляр класса удаленного объекта (testServant) и регистрируем его в ORB. Дальше вызываем специальную службу имен (NameService) и регистрируем в ней имя удаленного объекта, чтобы клиент смог его найти (есть и другой способ нахождения удаленного объекта, но о нем чуть позже).

Рассмотрим подробнее эти этапы.

  1. Создание и инициализация ORB. Производится вызовом статического метода init класса ORB

    ORB orb = ORB.init();

  2. Создание экземпляра класса удаленного объекта и регистрация его в ORB

    testServant testRef = new testServant();

    orb.connect(testRef);

  3. Получение контекста имен (NamingContext)

    org.omg.CORBA.Object objRef =

    orb.resolve_initial_references("NameService");

    NamingContext ncRef = NamingContextHelper.narrow(objRef);

    в первой строчке мы получаем объектую ссылку на службу имен (NameService). Но фактически это обыкновенный CORBA-объект и для того, чтобы использовать его как контекст имен (NamingContext), необходимо вызвать метод narrow класса NamingContextHelper , который как бы конкретизирует данный CORBA-объект.

  4. Регистрация имени удаленного объекта (testServant)

    Как было сказано раньше регистрация имени производится для того чтобы клиент смог найти удаленный объект. Этой цели служит функция rebind(NameComponent nc, Object obj) интерфейса NamingContext .

    NameComponent nc = new NameComponent("test", ""); //первый параметр //указывает имя объекта, //второй нам использовать не обязательно NameComponent path = {nc}; ncRef.rebind(path, testRef);

  5. Ожидание запросов от клиента. java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait(); }

    После того как сервер обработает запрос от клиента и выполнит метод count он снова перейдет в состояние ожидания.

Теперь сервер готов к работе

Листинг 1. testServer.java

Import testApp.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; import java.lang.*; class testServant extends _testImplBase { public int count(String msg) { return msg.length(); } } public class testServer { public static void main(String args) { try { ORB orb = ORB.init(args, null); testServant testRef = new testServant(); orb.connect(testRef); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("test", ""); NameComponent path = {nc}; ncRef.rebind(path, testRef); java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait() } } catch (Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out); } } }

Обратите внимание на то, что все операции выполняемые над CORBA-объектами заключены в try-catch блок.

Перейдем к написанию кода для клиента.

Основные шаги написания клиентского приложения

  1. Создание и инициализация ORB
  2. Получение контекста службы имен (NamingContext )
  3. Нахождение удаленного объекта
  4. Вызов метода count .

Как видно, первые два пункта совпадают с этапами создания серверного приложения, поэтому рассматривать их не будем.

Третий пункт реализуется тоже достаточно просто. Создается объект NameComponent . Вызывается метод resolve(NameComponent path) , который отыскивает по имени удаленный объект (стандартный CORBA-объект). При помощи метода narrow(org.omg.CORBA.Object obj) класса testHelper (сгенерированного idltojava компилятором) получаем объектную ссылку на интерфейс test .

NameComponent nc = new NameComponent("test", ""); NameComponent path = {nc}; org.omg.CORBA.Object obj= ncRef.resolve(path); test testRef = testHelper.narrow(obj);

Теперь можно вызывать метод count

String msg = "try to count"; int count = testRef.count(msg);

Листинг 2. testClient.java

Import testApp.*; import org.omg.CosNaming.*; import org.omg.CORBA.*; import java.lang.*; public class testClient { public static void main(String args) { try { ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("test", ""); NameComponent path = {nc}; test testRef = testHelper.narrow(ncRef.resolve(path)); String msg = "try to count"; int count = testRef.count(msg); System.out.println ("number of chars in message is:" + count); } catch (Exception e) { System.out.println("ERROR: " + e) ; e.printStackTrace(System.out); } } }

Запуск приложения

  1. Запуск сервера имен (входит в поставку с JDK1.2). Это делается, чтобы мы смогли получить ссылку на службу имен tnameserv

    по умолчанию сервер запускается по порту 900. Это значение можно изменить, указав параметр запуска -ORBInitialPort, например

    Tnameserv -ORBInitialPort 1024

  2. Запуск сервера testServer java testServer -ORBInitialPort 1024 // указывается тот порт //по которому работает сервер имен
  3. Запуск клиента testClient java testClient -ORBInitialHost javas.stu.neva.ru -ORBInitialPort 1024

    параметр -ORBInitialHost указывает хост на котором работает testServer

после выполнения этого приложения, на консоль будет выведено

Number of chars in message is:12

Соединение с сервером без использования службы имен

Основная идея этого метода состоит в том, что сервер сохраняет экземпляр класса удаленного объекта (testServant ) в виде текстового файла в любом месте, доступном клиенту. Клиент загружает из файла данные (в объект String ) и преобразует специальными методами в объектную ссылку на удаленный объект.

Все это реализуется следующим образом

Удалим некоторую часть кода - это касается и клиента (testServer.java и testClient.java )

  1. Исключим из import библиотеки org.omg.CosNaming.*; org.omg.CosNaming.NamingContextPackage.*;
  2. Удалим код соответствующий п.3-п.4
Вместо удаленного кода вставим - для сервера: //преобразуем объект в строку String ior = orb.object_to_string(testRef); String filename = System.getProperty("user.home") + System.getProperty("file.separator")+"test_file"; //создаем файл test_file FileOutputStream fos = new FileOutputStream(filename); PrintStream ps = new PrintStream(fos); //записываем в него данные ps.print(ior); ps.close();

для клиента:

String filename = System.getProperty("user.home") + System.getProperty("file.separator")+"test_file"; //открываем файл FileInputStream fis = new FileInputStream(filename); DataInputStream dis = new DataInputStream(fis); //читаем данные String ior = dis.readLine(); //преобразуем в объект CORBA org.omg.CORBA.Object obj = orb.string_to_object(ior); //получаем ссылку на удаленный объект test testRef = testHelper.narrow(obj);

Скомпилируем приложения, запустим сервер и клиент аналогично тому, как мы делали это раньше (сервер имен запускать в данном случае не надо).

CORBA (Common Object Request Broker Architecture) - объектно-ориентированная технология создания распределенных приложений. Технология основана на использовании брокера объектных запросов (Object Request Broker, ORB) для прозрачной отправки и получения объектами запросов в распределенном окружении. Технология позволяет строить приложения из распределенных объектов, реализованных на различных языках программирования. Стандарт CORBA разработан Object Management Group (OMG) .

Архитектура CORBA

В данном разделе приводится краткий обзор CORBA в том виде, как ее описание дается в спецификации OMG версии 3.0. Требования этого документа могут в различной степени удовлетворяться фактическими реализациями брокеров объектных запросов . На Рис. 2.1 изображен запрос, посылаемый клиентом реализации объекта. Клиент - это сущность, которая хочет выполнить операцию с объектом, а Реализация - это совокупность кода и данных, которые в действительности реализуют объект.

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

Динамический интерфейс вызова и интерфейс заглушки имеет одинаковую семантику, так что получатель сообщения не может определить, как был послан запрос. ORB находит подходящий код реализации объекта, пересылает ему параметры и отдает управление через IDL скелетон или динамический скелетон (Рис. 2.4). Скелетоны специфичны для конкретного интерфейса и объектного адаптера. Во время выполнения запроса реализация может пользоваться некоторыми сервисами ORB через объектный адаптер. Когда запрос выполнен, управление и значения результата возвращаются клиенту.

Реализация объекта может выбрать, какой объектный адаптер использовать, в зависимости от того, в каких сервисах она нуждается. На Рис. 2.5 показано, как информация об интерфейсе и реализации становится доступной клиентам и реализациям объектов. Интерфейсы описываются на IDL или с помощью репозитория интерфейсов. Их описания используются для генерации клиентских заглушек и скелетонов для реализации.

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



Есть вопросы?

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Отправить