- •107 Методические указания «Программное обеспечение сетей эвм. Часть 4. Версия 2. Развитие схемы «клиент-сервер» в com и corba»
- •Введение
- •1.1. Необходимость использования компонент
- •1.2. Методы встраивания компонентов
- •1.3. Основы com
- •1.4. Типы компонентов
- •1.5. Размещение управляющих элементов при помощи cWnd
- •1.6. Использование директивы #import
- •1.7. Компоновка тестовой программы
- •1.7.1 О компонентах
- •1.7.2 Регистрация компонентов
- •1.7.3 Импортирование библиотеки типов
- •1.7.4 Определение членов cDemoClientView
- •1.7.5 Создание компонентов
- •1.7.6 Создание точек взаимодействия
- •1.7.7 Синхронизация параметров
- •1.7.8 Обработка событий от компонентов
- •1.7.9 Очистка
- •1.7.10 Шаблонный код
- •1.9. Индивидуальные задания на работу
- •2.1. Проект. Основные принципы
- •2.2. Как создать компонент
- •Шаг 2: Создание компонента:
- •2.3. Значения по умолчанию
- •2.5. Индивидуальные задания на работу
- •3.1. Cоздание сервера com
- •3.2. Использование com-объектов
- •3.3. Индивидуальные задания на работу
- •Лабораторная работа № 4. Использование atl
- •4.1 Создание dcom-сервера с использованием atl
- •4.1.1 Введение в atl
- •4.1.2 Что такое atl?
- •4.1.3 Разделение труда
- •4.1.4 Создание хранилища компонентов с помощью atl Com AppWizard
- •4.1.5 Вставка кода заглушки/прокси-объекта.
- •4.1.7 Atl com-карта
- •4.1.9 Класс cComModule
- •4.1.10 Язык скриптов реестра в atl
- •4.1.11 Распределенная com (dcom)
- •4.1.12 Dcom и службы nt
- •4.1.13 Структура службы nt
- •4.1.14 Основанный на службах nt сервер сом
- •4.1.15 Создание проекта при помощи atl
- •4.1.16 Добавление функциональных средств
- •4.1.17 Функция CacheQuotes (dcomServiceXdcomService.Cpp)
- •4.1.18 Функция GetQuote (dcomServiceXdcomService.Cpp)
- •4.2 Создание dcom сервера
- •4.3 Создание dcom клиента
- •4.4 Индивидуальные задания на работу
- •Лабораторная работа № 5. Разработка corba приложений
- •5.1. Конфигурирование
- •5.2. Порядок действий
- •5.3. Объектно-ориентированный анализ и моделирование
- •5.4. Описание и трансляция объектов
- •5.5. Создание сервера
- •5.6. Создание клиента
- •5.7. Отладка объектов
- •5.8. Индивидуальные задания на работу
- •Лабораторная работа № 6. Адаптер роа
- •6.1. Архитектура poa
- •6.2. Политики poa
- •Политика обработки запросов
- •6.3. Создание серверов на основе poa
- •6.4. Индивидуальные задания на работу
- •Лабораторная работа № 7. Прикладная задача связи
- •7.1. Постановка задачи
- •7.1.1. Сотовая станция
- •7.1.2. Телефоны
- •7.1.3. Система
- •7.2. Функционирование системы
- •7.3. Индивидуальные задания на работу
- •Лабораторная работа № 8. Работа по умолчанию
- •8.1. Сервер с сервантом по умолчанию
- •8.2. Индивидуальные задания на работу
- •Лабораторная работа № 9. Создание менеджеров сервантов
- •9.1. Менеджеры сервантов
- •ServantActivator
- •ServantLocator
- •9.2. И снова практика
- •9.3. Индивидуальные задания на работу
- •Лабораторная работа № 10. Сервис именования
- •10.1. Сервис для именования (Naming Service)
- •10.2. Индивидуальные задания на работу
4.4 Индивидуальные задания на работу
4.4.1. Индивидуальное задание для каждого студента.РазработатьDCOM-сервер, используя встроенные средства библиотекиATL, который:
обеспечивает выполнение простейших математических операций;
обрабатывает запросы от клиента для заданной преподавателем простой арифметической функции с пятью операндами и четырьмя операциями, например, "(a+b)*(c–(d/e))";
предоставляет возможность получения статистики о выполненных запросах.
4.4.2.Индивидуальное задание для каждого студента. Разработать на любом языке программированиятестовый клиент,обладающийминимальным интерфейсом, который задается преподавателем, и имеющий возможность работать в двух режимах:
реальном(пользователь составляет запрос и отправляет его на сервер);
эмуляции потока запросов (клиент генерирует заданное количество запросов с определенными временными интервалами между ними).
В любой момент времени клиент может послать запрос серверу на получение статистики о выполненных математических запросах.
Лабораторная работа № 5. Разработка corba приложений
Что нужно, чтобы приступить к созданию приложений на основе CORBA? В принципе не так уж и много: прежде всего научиться описывать объекты, используя язык IDL.
Для начала следует установить инструментарий: будет использоваться VisiBroker 3.3 for Java и VisiBroker 3.3 for C++. Данные пакеты можно получить с Web-сервера компании Inprise в виде версий дистрибутива. Кроме того, VisiBroker входит в достаточно распространенные Enterprise-редакции пакетов JBuilder, C++Builder и Delphi корпорации Borland/Inprise. Еще один плюс в пользу выбора именно этих пакетов: существуют версии для множества операционных систем, включая Linux.
Установка VisiBroker происходит автоматически, поэтому, скорее всего, проблем не возникнет. Пакет прописывает необходимые ключи реестра Windows, а также модифицирует файл сервисов и переменные среды. Важно лишь помнить, что переменная PATH должна указывать на подкаталог bin основного каталога, где установлен VisiBroker.
5.1. Конфигурирование
Прежде чем заниматься настройкой VisiBroker, следует познакомиться с термином «виртуальный домен» и с тем, как его понимают разработчики CORBA-систем. Виртуальный домен — это один или несколько компьютеров, логически объединенных для выполнения некоторой задачи. Виртуальным домен называют потому, что для сетевого администратора его нет, а существует он лишь за счет каких-то установленных пользователями правил. К примеру, в VisiBroker это некий выделенный порт. Так что виртуальный домен можно считать маленькой подсетью внутри основной сети.
Когда разработка ведется не на одном компьютере, а в сети, могут потребоваться дополнительные настройки. Следует обратить внимание на две переменных среды:
OSAGENT_PORT (по умолчанию равна 14000) служит для настройки виртуальных доменов в рамках локальной сети;
VBROKER_ADM — системный каталог; обычно это подкаталог adm внутри основного каталога, где установлен VisiBroker; служит для хранения важной информации репозитария интерфейсов, демона активизации объектов и Smart Agent, а также является основным местом хранения конфигурационных файлов.
Настройка этих переменных вручную нужна лишь в UNIX, так как в Windows эти значения хранятся в системном реестре в виде ключей и могут быть изменены в любой момент с помощью утилиты vregedit, поставляемой с VisiBroker.
Значение OSAGENT_PORT важно, когда необходимо изолировать компьютеры, подключенные к одной и той же локальной сети. Кроме того, изменив OSAGENT_ PORT, можно разделить уже работающие на серверах объекты и их неотлаженные версии, «живущие» где-нибудь на компьютере разработчика. Если этого не сделать, то при запросе объекта приложению-клиенту может быть возвращена ссылка на еще «сырой» экземпляр объекта, которая случайно «подвернулась под руку» административной утилите Smart Agent. Напротив, если в локальной сети стандартным является порт 14000, а при разработке новых версий CORBA-объектов переменная OSAGENT_PORT настроена на 14500, можно быть спокойным— приложения не «зацепят» объекты в основном домене, а последние не заберутся в виртуальный домен. Это равносильно тому, что переключенарацияна канал, недоступный другим.
Следующий тонкий момент — организация взаимодействия частей CORBA-приложений, находящихся в разных локальных сетях, но связанных друг с другом (для крупных фирм сети со сложной топологией — не редкость). В VisiBroker по умолчанию поиск объектов и балансировку нагрузки выполняют запущенные в сетях экземпляры утилиты Smart Agent. Поэтому, для того чтобы они могли беспрепятственно связываться друг с другом, в каталоге, заданном переменной среды VBROKER_ADM, должен быть файл с именем agentaddr. Внутри него на каждой строчке будет помещаться одно имя или IP-адрес компьютера, на котором запущен другой экземпляр Smart Agent. Редактируя этот список, можно формировать топологию связей объектов. Изменить имя и место файла agentaddr легко, если настроить переменную среды OSAGENT_ADDR_FILE. Всеготовок работе с CORBA.