Опубликован: 10.10.2010 | Доступ: свободный | Студентов: 3217 / 301 | Оценка: 4.14 / 3.32 | Длительность: 13:16:00
ISBN: 978-5-9963-0444-8
Специальности: Системный архитектор
Лекция 6:

Использование CORBA

< Лекция 5 || Лекция 6: 123456 || Лекция 7 >

Последовательность действий

Реализация распределенной системы - это нетривиальная задача. Для реализации распределенной системы с использованием Java и CORBA необходимы следующие шаги:

  1. выполнить анализ и проектирование на основе моделирования предметной области, моделирования системы и декомпозиции системы на ряд подсистем;
  2. создать IDL -описание путем спецификации API распределенных подсистем и спецификации структур данных, которые передаются через границы системы;
  3. реализовать сервант, используя файлы, сгенерированные IDL -компилятором;
  4. реализовать клиент, используя файлы заглушек, сгенерированные IDL -компилятором;
  5. принять решение о методе распространения объектных ссылок сервантов (обычно это делается с помощью сервиса именования, но не обязательно);
  6. запустить реализацию серванта;
  7. запустить клиент.

После определения подсистем нужно решить, каким из них придать форму распределенных сервисов. Если предположить, что структура всех подсистем реализует функциональность распределенных совместно используемых сервисов, то перевод таких подсистем на платформу CORBA существенно упрощается. В любом случае, открытый API такого сервиса будет доступен клиентам. Для объектно-ориентированного подхода обычно интерфейс, описываемый в IDL, может являться некоторым подмножеством всех реализуемых сервером функций. И даже после реализации сервера (мы используем Java в качестве языка программирования) разработчиков продолжает волновать вопрос о том, сколько дополнительных функций (административных, связанных с защитой и т.д.) предоставить серверу.

Если существуют структуры данных, которые сервер должен возвращать клиенту (или принимать от него), то описание и определение этих структур данных должно присутствовать в IDL -файле. Модель CORBA предоставляет возможность процедурным языкам программирования описывать конструкции в "псевдообъектном" стиле. Две конструкции CORBA поддерживают этот механизм: struct и valuetype. Клиент и сервер передают IDL -структуры ( struct ) туда и обратно в качестве обычных данных. Стандартная оптимизация включает в себя отправку этих данных непосредственно клиенту, чтобы освободить сервер от избыточных запросов. Конструкция valuetype является IDL -описанием некоторой сущности, включающей и данные, и методы. Конструкция struct состоит только из данных (конструкция struct, скомпилированная в Java -код, определяет открытые атрибуты), тогда как valuetype инкапсулирует данные, и добавляет логику, необходимую для создания объекта, простого или сложного, какой требуется.

После объявления API сервера в виде IDL -файла единственное, чего не достает, - это собственно реализация сервера. Компилятор IDL анализирует IDL -файл и генерирует соответствующие файлы на целевом языке. После того как созданы вспомогательные файлы, разработчик может писать код реализации; до этого момента единственное, что было сделано разработчиком, - это объявлены интерфейс, атрибуты и данные, необходимые серверу для обработки запросов. Сначала разработчик может реализовать фиктивный сервер, который просто возвращает текстовые данные, чтобы другой разработчик мог написать клиент (или, возможно, текстовый клиент) для тестирования обращений к серверу. Более типичный пример - сервер, который является оболочкой унаследованного приложения, но скрывает это от клиентов.

Допустим, что объявленное API сервера находится в IDL -файле и IDL -компилятор скомпилировал этот файл. Теперь клиент может использовать сгенерированные для клиента файлы, необходимые ему для взаимодействия с сервером. Клиенту нужны только файлы, сгенерированные IDL -компилятором, чтобы обеспечить прозрачное сетевое взаимодействие. Можно создать локальную версию сервера (вместо того, чтобы задействовать объектную ссылку CORBA, можно просто выполнить операцию new ServerImpl()) и отправлять сообщения напрямую, но такой сервер уже не будет распределенным объектом, он будет работать в адресном пространстве клиента, утрачивая преимущества слабой связи между компонентами системы, имевшимися первоначально, благодаря использованию интегрирующего кода, размещенного в сгенерированных файлах.

Первый пример

Данный пример реализует решение задачи про сеть столовых, использующую в своей работе с клиентами пластиковые карты.

Интерфейс сервера BillingService включает четыре метода: addNewCard (добавляет новую карту), addMoney (добавляет денежные средства на карту), subMoney (снимает денежные средства с карты), getCardBalance (показывает текущий баланс карты).

Файл BillingService.idl

В примере 6.1 приведено IDL -описание сервера BillingService.

CORBA не является предписанием реализации, поэтому IDL -описание формально программным кодом не является. Ключевое слово module связывает данное имя непосредственно с пакетом Java. Вложенные имена module, соединенные вместе, дают полное имя пакета. Имя module в примере 6.1 - BillingServiceModule.

Фигурные скобки в строках 4 и 13 обозначают границы области действия блока. В IDL точка с запятой всегда завершает блок (включая объявление module ). Java, C, C++ являются языками с блочной структурой и используют похожий синтаксис, но в них блок не рассматривается как строка, требующая для завершения точки с запятой. Отсутствие точки с запятой в IDL является синтаксической ошибкой.

1  // BillingService.idl
2  // IDL-описание BillingService
3  module    BillingServiceModule 4{
5  interface BillingService 6{
7  //определение CORBA-совместимого сервиса
8  void addNewCard(in string personName, in string card);
9  void addMoney(in string card, in double money);
10  void subMoney(in string card, in double money);
11  double getCardBalance(in string card);
12  };
13  };
Листинг 6.1. IDL-описание сервера BillingService

Строки 5-12 являются объявлением интерфейса сервера BillingService. Указанный сервер представляет собой производный класс (конкретную реализацию) интерфейса BillingService. Отсутствие привязки к клиенту является сознательным, допускается произвольная реализация сервера.

Строки 8-11 осуществляют объявление методов/функций/сообщений. Все, что объявляется на IDL, является public,поэтому в IDL -интерфейсах отсутствуют специальные ключевые слова для public, private, protected (хотя у метатипов component и valuetype есть ключевые слова public и private).

Следующим шагом в реализации нашего приложения будет генерация из IDL -определения вспомогательных классов. В самом деле, то, что написано в IDL -файле, очень напоминает определение интерфейса java или абстрактного класса C++. Вполне естественно, что созданы инструменты, автоматически генерирующие соответствующие конструкции на базовом языке. Кроме того, мы говорили о том, что базовые типы IDL должны транслироваться в соответствующие типы целевой системы программирования. И опять же, такого рода трансляция может осуществляться автоматически, соответствующим образом сгенерированным кодом.

Компиляция файла idl

Компиляция файла BillingService.idl компилятором Java-IDL idlj,входящим в состав пакета jdk фирмы Sun, осуществляется так:

idlj -td c:\src -pkgPrefix BillingServiceModule com.asw.corba.ex1 
   -fall BillingService.idl

Позднее мы рассмотрим утилиту Java idlj и ее параметры командной строки. По умолчанию утилита idlj для каждого определенного в idl модуля создает пакет java, а для элементов модуля создает набор java -классов, включенных в этот пакет.

< Лекция 5 || Лекция 6: 123456 || Лекция 7 >
Алмаз Мурзабеков
Алмаз Мурзабеков
Прохожу курс "Построение распределенных систем на Java" в третьей лекции где описывается TCPServer вылетает эта ошибка
"Connection cannot be resolved to a type"


Java version 1.7.0_05