1.1 Место технологий РВС 1.2 Немного истории 1.3 Отрасли ИТ

1.1
Место технологий РВС ................................................................................................................................................... 4
1.2
Немного истории ............................................................................................................................................................... 4
1.3
Отрасли ИТ непосредственно относящиеся и близкие к РВС ...................................................................................... 6
1.4
Международные проекты распределенного поиска в массивах данных ...................................................................... 8
1.5
Процессы (уточняет понятие программная компонента, приложение) ..................................................................... 15
1.6
Сетевые ОС ...................................................................................................................................................................... 17
1.7
Необходимые сведения об уровнях сетевой архитектуры .......................................................................................... 19
2.1
Синхронный, односторонний и асинхронный (отложенный вызов) .......................................................................... 26
2.2
Основные понятия OOA ................................................................................................................................................. 28
2.2.1
Типы, наследование, объекты (адресация объектов), заявки, исключения ........................................................ 28
2.2.2
Объекты, имеющие состояние ............................................................................................................................ 29
2.2.3
Составные Типы данных ..................................................................................................................................... 29
2.2.4
Адресация объектов .............................................................................................................................................. 30
2.3
CORBA (Common Object Request Broker Arch.) ........................................................................................................... 31
2.3.1
Фазы жизненного цикла информационных технологий на примере CORBA ................................................... 31
2.3.2
Знакомство с IDL ..................................................................................................................................................... 34
2.3.3
Архитектура CORRBA ............................................................................................................................................ 34
2.4
Сравнение централизованных и децентрализованных РВС ........................................................................................ 39
2.5
«Прозрачность доступа» на примере проблемы Big- и Little-endian .......................................................................... 40
2.5.1
2.6
Подробнее об IDL. ................................................................................................................................................... 41
Объектная ссылка, устройство POA, протокол GIOP .................................................................................................. 45
2.6.1
IOR ............................................................................................................................................................................ 46
2.7
GIOP.................................................................................................................................................................................. 48
2.8
Репозиторий типов (Interface Repository) ...................................................................................................................... 60
2.9
Message Oriented M/w (Event / Notification Service) ..................................................................................................... 61
Типовые элементы распределенной системы ........................................................................................................................... 63
3.1
Big-endian и Little-endian.................................................................................................. Error! Bookmark not defined.
4.1
Проектирование интерфейсов на языке IDL. ................................................................................................................ 72
1.1.1.
Использование предкомпилятора IDL ................................................................................................................... 74
1.1.2.
Реализация серванта и клиентской части приложения на уровне исходных кодов .......................................... 79
1.1.3.
Компиляция исходных кодов ................................................................................................................................. 81
1
1 Тема 1. Введение и предварительная характеристика распределенных
вычислений
Этот курс имеет, в первую очередь, обзорный характер. Его основное назначение - сориентировать
слушателей в становящейся все более актуальной (в последнее десятилетие) тематике разработки и
практического использования различных технологий создания Распределенных Вычислительных
Систем (РВС). Часто еще говорят РИВС (… информационно-вычислительных …).
Вообще говоря, вычисления в любой любой ВС  Обработка и обмен данными.
Так складывается, что сотрудникам и руководителям информационных подразделений нужно уметь
ориентироваться в большом наборе современных систем сетевых вычислений (параллельных,
распределенных, пиринговых, Grid и т.п.)
Основное внимание уделяется не деталям отдельных технологий, а общим принципам их
использования и критериям выбора конкретной технологии для решения типовых проблем создания
распределенных информационно-вычислительных систем.
Моя цель - не научить программированию (НЕ КАК ДЕЛАТЬ), а рассказать о том, как ЭТО
МОЖНО СДЕЛАТЬ.
Говоря об общих принципах, я имею ввиду
 характерные области применения (варианты использования) РВС;
 общие принципы программной архитектуры РВС:
 общие правила организации взаимодействия элементов РВС.
 типовые элементы РВС, выполненных по существующим стандартам;
 характерные этапы жизненного цикла РВС
 проектирования
 программной реализации
 развертывания (установки и запуска).
Интуитивно понятно, что когда говорят об РВС, то имеют ввиду координированную работу
нескольких компьютерах, связанных сетью. Но это слишком общее определение. Оно касается ВСЕХ
сетевых технологий.
Например, вы включаете компьютер, подключенный к сети, и он не имеет фиксированного сетевого
(IP) адреса. Незаметно для вас, специальная программа DHCP client находит в сети специальный
2
DHCP сервер, который выдает вам временный IP-адрес, без которого нормальная работа в сети
невозможна. Означает ли это, что любой компьютер в сети является элементом РВС?
Или, когда вы ходите по Интернету ваш браузер (клиентская программа) периодически обращается к
WEB-серверам за очередной порцией HTML-разметки, чтобы отобразить текст и картинки в окне
браузера – является ли это примером работы распределенной системы. А когда
забираете/отправляете почту ? (Скорее нет.) А вот работа система обмена сообщениями ICQ – уже
больше похожа на РВС (это можно считать наиболее распространенным примером РВС).
Какими объективными причинами вызвана необходимость РВС.
 Желание полнее использовать вычислительные ресурсы уже фактически связанные сетью.
 Организационная и территориальная распределенность коллективов при совместной работе над
общей проблемой (в проектировании, в обработке данных экспериментов, при кооперативном
использовании своих ресурсов).
 Повышение надежности систем за счет «прозрачной» (незаметной для пользователей) замены
одних ресурсов другими однотипными (при отказах, при регламентных работах, и пр.)
 Расширение числа клиентской базы в результате предоставления возможностей удаленного
доступа к своим разработкам (дистанционное обучение, сетевые игры).
3
1.1
Место технологий РВС
«между» «интернетом» и «кластерами».
Web-интерфейс
(AJAX, Flex)
Измерение «привычность
конечному пользователю»
Технологии распределенныъ
вычислений
Кластеры и
параллельные
вычисления
Серверы
приложений
*nix консоль
Измерение близость к модели «клиент-сервер»
Ясно, что разговор об РВС был бы невозможен без возникновения компьютерных сетей.
1.2
Немного истории
37 лет назад два компьютера впервые обменялись данными в режиме онлайн.
2 сентября 1969 года студенты из Калифорнийского университета соединили два компьютера
пятиметровым кабелем и отправили по нему бессмысленный набор данных. Считается, что это была
первая передача информации по компьютерной сети. Именно из этого эксперимента спустя годы
4
появился современный интернет. First ARPANET IMP log - a record of the first message ever sent over
the ARPANET; it took place at 10:30PM on October 29, 1969. (wikipedia).
Через несколько месяцев к их "сети" подключились еще два узла. Первая передача информации по
этой сети между Калифорнийским и Стенфордским университетами произошла 21 ноября 1969
года. Это еще один, столь же условный, день рождения интернета.
Историки по сей день не могут решить, когда именно зародилась глобальная информационная сеть.
Некоторые считают, что историю интернета следует начинать с 1962 или даже с 1958 года, другие
называют 1969 год, третьи полагают, что интернет появился лишь в 1983 году. Верно одно - в эти
годы происходили события, существенно важные для истории интернета.
Самой первой датой, которую обычно указывают, является 1958 год. Именно тогда по указанию
президента США Дуайта Эйзенхауэра было создано агентство исследовательских проектов
Министерства обороны США (Advanced Research Projects Agency of the U.S. Department of
Defense, ARPA). ARPA была необычной организацией. В ней работало всего 150 человек.
Задача ученых заключалась в том, чтобы распределить между различными университетами и
лабораториями годовой бюджет организации, который составлял несколько миллиардов
долларов.
В 1972 году появилось первое приложение - электронная почта, автором которой стал Рей
Томплисон. Более чем на десять последующих лет электронная почта стала крупнейшим
сетевым приложением. Для своего времени она была исключительно мощным катализатором роста
всех видов потоков данных.
Термин "Internet" для обозначения сети был введен Винтоном Серфом в 1974 году.
Предложенная им идея объединения различных сетей в глобальную информационную
структуру - International Network, Интернет - основывалась на возможности существования
множества независимых сетей произвольной архитектуры. Ядром этого объединения должна
была стать ARPANET - пионерская сеть с пакетной коммуникацией
Для создания такого протокола была образована Международная сетевая рабочая группа, которую
возглавил Винтон Серф. В результате в 1975 году появился Протокол управления передачей
(Transmission Control Protocol - ТСР-протокол).
Настоящий расцвет интернета начался в 1992 году. Однако до поры до времени его ресурсы был
доступны при помощи программного обеспечения, ориентированного лишь на пересылку
файлов и неформатированного текста. В конце концов физикам Тиму Бернес-Ли и Роберту Кайо
5
это наскучило. Они решили разработаться инфраструктуру, позволяющую братьям-физикам по всей
Европе обмениваться результатами исследований через интернет в виде привычного для научных
работников отформатированного и иллюстрированного текста, включающего ссылки на другие
публикации.
Работая в качестве технического консультанта в Европейской лаборатории физики частиц в Женеве,
Бернерс-Ли написал программу Eniquire, которая стала прообразом будущей WWW (World Wide
Web, Всемирной паутины). Для воплощения в жизнь идеи форматированного текста Бернес-Ли
предложил концепцию языка HTML (Hyper Text Markup Language, язык разметки гипертекста),
позволившего создавать интернет-страницы.
В «популярном» общественном сознании Веб == Интернет. Более «продвинутые скажут,что Beб
== Серверы + броузеры + Гипертекст + почта + аська + ... (набор популярных программ)
Не собираюсь спорить.
Я просто предлагаю договориться между нами о терминах.
Интернет - программно-аппаратная среда обеспечивающая взаимодействие между
компьютерами. Интернет - коммуникационная среда ПРЕДНАЗНАЧЕННАЯ для обмена
данными между хостами (узлами).
Более точно, совокупность аппаратных устройств, служебного ПО поддерживающего
целостность системы (поддержка адресов, маршрутизация, передача данных между узлами и
устройствами),
а также прикладных программ конечных пользователей (браузеры, почтовые клиенты, и т.п.)
и разработчиков софта и контента (серверы, их поддержка и наполнение полезным
содержимым).
В этой вводной лекции уместно указать сложившееся сегменты (отрасли) ИТ имеющие
непосредственное отношение к теме РВС (что не означает, что все ЭТО есть РВС).
1.3
Отрасли ИТ непосредственно относящиеся и близкие к РВС
Исторически первые сетевые приложения
Собственно в те времена и возникло понятие Клиент-Серверной архитектуры, развитие которой
является одной из основных причин зарождения современной концепции РВС.
Тогда – 2-звенной затем 3-х звенной (three-tier mode) и в дальнейшем многозвенной (multi-tier
architecture)
6
Telnet (клиент – сервер )
FTP программа передачи файлов по сети (uploading/downloading)
Почта (почтовый клиент – SMTP Сервер и POP сервер)
Первые примитивные браузеры и Web-серверы (браузер – клиентское приложение
Современные суперкомпьютеры и кластеры
Многопроцессорные вычислительные комплексы (Parr. VM (Memory), MPI (CH)
Параллельные вычисления НЕ = РВ
Почтенное семейство WEB-технологий
Практически все современные широко используемые новостные сайты, почтовые сайты, e-магазины.
Зарождающийся на глазах «новый мир Google». Позднее – подробнее. А пока достаточносказать, что широко
известный термин Web-сервисы – одна из технологий РВС.
Системы обмена сообщениями
IMS (ICQ, Google Talk)
Пиринговые системы. Файлообменные сети.
Системы управления предприятием
Бухгалтерия, управление запасами (логистика), работа с клиентами, управление производством
Системы поддержки проектирования сложных технических систем
Когда необходимо организовать совместную работу групп специалистов разделенных территориально и
организационно. Это характерно для всех больших международных технических и научных проектов.
От создания Airbus (Франция, Германия, Италия, Голландия + Россия)
Проект МКС
Обработка больших массивов данных
Системы распределенного обучения
Grid
7
Google OS.
1.4 Международные проекты распределенного поиска в массивах данных
SETI (Search for Extra-Terrestrial Intelligence)
SETI@home is a highly successful distributed computing project that was launched by U.C. Berkeley in
May 1999, and is heavily sponsored by The Planetary Society. Any individual can become involved with
SETI research by downloading and running the SETI@home software package, which then runs signal
analysis on a "work unit" of data recorded from the central 2.5 MHz wide band of the SERENDIP IV
instrument. The results are then automatically reported back to UC Berkeley. Over 5 million computer
users in more than 200 countries have signed up for SETI@home and have collectively contributed over
19 миллиардов часов of computer processing time.
BOINC (Berkeley Open Infrastructure for Network Computing)
BOINC - унифицированная архитектура распределенной обработки больших массивов данных на
домашних компьютерах за счет использования «холостой» работы процессоров. Создана в University
of California, Berkeley.
Изначально – была разработана для SETI@home, но применяется but intended to be useful to fields
beyond SETI. This software platform is open in that it is free and open source software released under the
GNU Lesser General Public License. Currently BOINC is being developed by a team based at the University
of California, Berkeley led by David Anderson, the project director of SETI@home — a project which uses
this software. As a "quasi-supercomputing" platform BOINC has over 375,000 active computers
worldwide processing on average 374 TFLOPS as of August 8, 2006[1]
Например, используется для обработки данных астрономических наблюдений за быстро
вращающимися нейтронными звездами в попытках обнаружить гравитационные волны.
Great Internet Mersenne Prime Search (GIMPS)
Числа Мерсенна (http://ru.wikipedia.org/wiki/Числа_Мерсенна)
Mn = 2n – 1.
Основной интерес представляют числа Мерсенна
Числа носят имя французского математика Марена Мерсенна, жившего в начале XVII века.
8
Последовательность чисел Мерсенна начинается так:
1, 3, 7, 15, 31, 63, 127, 255, 511, 1023, ... (
Чаще - числами Мерсенна называют числа Mp с простыми индексами p. Эта
последовательность начинается так:
3, 7, 31, 127, 2047, 8191, 131071, 524287, 8388607
Свойства

Любой делитель числа Mp для простого p имеет вид 2pk + 1, где k — целое число. (Это прямое
следствие малой теоремы Ферма)

Эйлер доказал, что каждое чётное совершенное число имеет вид 2p - 1Mp, где число Мерсенна
Mp является простым.
Чи́сла Мерсенна получили известность в связи с эффективным критерием простоты ЛюкаЛемера, благодаря которому простые чи́сла Мерсенна давно удерживают лидерство как самые
больши́е известные простые чи́сла (см. ссылки).
Простые числа – важное «сырье» для современных алгоритмов шифрования и цифровой
подписи (RSA, Диффи-Хелмана и проч.)
Последовательность простых чисел Мерсенна и их показателей начинается так:
Mp: 3, 7, 31, 127, 8191, 131071, 524287, 2147483647, 2305843009213693951,
618970019642690137449562111, ..
p: 2, 3, 5, 7, 13, 17, 19, 31, 61, 89, ... (Последовательность A000043 из Энциклопедии
целочисленных последовательностей)
На данный момент самым большим (всего 43-им !!!) известным простым числом (найденным в
рамках проекта GIMPS) является число Мерсенна M30.402.457
= 230.402.457 − 1, найденное в
декабре 2005 го́да Всего известно 43 простых числа́ Мерсенна, причём порядковые номера с
уверенностью установлены только у первых 39-ти (т.е. – возможно что какие-то числа были
пропущены).
9
Распределенное суммирование
Рассмотрим задачу вычисления суммы N чисел {x1, x2, x3, …, xN} . На обычном «однопроцессорном»
компьютере эта задача требует выполнения N-1 операций сложения.
// x – определен выше как массив чисел float[] x; x.length = N
float res;
for (int i = 0, res = 0.; i < N; i++)
res += x[i];
N-1 операция, время - *(N-1)
Предположим, что в нашем распоряжении имеется достаточное количество «сумматоров», способных
выполнять операцию сложения двух чисел, и доступных для «удаленного» вызова таких операций.
Процедура вычисления суммы в таком случае может быть записана следующим образом
public static float DistrSum (float[] x, CalcOperations[] calcs) {
int N = x.length; // Number of summands
// ResHolder[] xHolder;
while (N > 1) {
int n;
// xHolder = new ResHolder[N/2];
for (n = 0; n < N/2; n++) { // храним промежуточные значения сумм в том
// же массиве
x[n] = calcs[n].add(x[2*n], x[2*n+1]);
// xHolder[n] = calcs[n].ami_add(x[2*n], x[2*n+1]); // асинхронный
вызов функции add
}
// Цикл синхронизации (требует асинхронного вызова команд калькулятора)
// for (n = 0; n < N/2; n++)
// x[n] = xHolder[n].getValue();
// Или
//int k = -1;
//while (k < N/2) {
// for (n = 0; n < N/2; n++)
// if (xHolder[n].poll()) {
//
x[n] = xHolder[n].getValue();
k++;
//}
//};
if ( 2*n < N) {// N – нечетное вида 2*n + 1
x[n] = x[N-1];
// x[n] = xHolder[N-1].getValue();
n++;
}
N = n;
}
return x[0];
}
10
// …
public interface CalcOperations
{
float add(int a, int b);
float sub(int a, int b);
float mult(int a, int b);
float div(int a, int b) throws DivisionByZero;
}
Пусть S(n) – трудоемкость для n элементов массива.
S(1) = 0;
S(2) = 1; (X1+X2)
S(3) = 2 ( (X1+X2) + X3).
S(4) = 3 ( (X1+X2) + (X3+X4))
…
S(n) <= S([n/2]) + 1
Кормен, Райвест, Штайн. Алгоритмы Построение и анализ.
S(N) оценивается как C*log2(N). Общее время ~ log2(N)**(1+t), где t – время передачи данных в долях от
времени выполнения одной операции.
Вопрос – почему имеет смысл группировать попарно, а не, скажем по-трое ?
11
Технические возможности, предлагаемые ИТ, оказали и продолжают оказывать огромное влияние на развитие
теории и «практики» вычислительных алгоритмов. Следующие два примера
Решение задачи Коши с помощью формулы Тейлора.
Бахвалов, Жидков, Кобельков. Численные Методы.
Будем рассматривать задачу Коши для системы ОДУ, в которой правая часть не зависит явно от времени:
x  f ( x) t  [t0  T ]
x(t0 )  x0
x
 x 2 , x(0)  1
t
12
Точное значение решения в момент времени
t
может быть представлено в виде ряда Тейлора (заметьте, что
речь идет о вычислении функции синтеза общего решения X(xo,t):
x0( s )
x( s 1) ( )
x0
2
s
x(t )  x0  x 0(t  t0 )  (t  t0 )  …
(t  t0 ) 
(t  t0 )( s1) 
2
s
( s  1)
где
x0( k )  x ( k ) (t0 )   (t0  t )
Выражения для вычисления производных, входящих в формулу (10), имеют вид:
x  f ( x )  (1) ( x )
 (1)
f
x
 x   f ( x )   (2) ( x )
x
x
…
x
(s)
 ( s 1)

 f ( x )  ( s ) ( x )
x
 1s

 x1
  s
s
 2

  x1
x 

  ns

 x1
Рекурсивное вычисление производных
1s
x2
 2s
x2
 ns
x2
1s 
…

xn 
 2s 
…

xn 


s
 n 
…

xn 
 1 ( x) …   s ( x)
осуществляется символьно, и полученные
символьные выражения хранятся для последующего использования, тем самым хранится информация о целом
пучке траекторий. Эти символьные выражения используются при решении следующих задач, которые могут
быть оформлены как отдельные вычислительные процедуры:
t x
 получение траектории, исходящей из точки ( 0 0 ). Для этого достаточно взять в качестве
коэффициентов разложения в формуле (10) значения
x0   1 ( x0 )…  s ( x0 )
.
13
 оценка близости двух различных траекторий;
 оценка точности полученного приближенного решения;
 оценка радиуса сходимости ряда.
Отметим, что существует большой класс задач, в которых символьное дифференцирование правых частей
выполняется достаточно просто (например, когда правые части являются многочленами n переменных или
дробно-рациональными функциями). Также отметим, что вычисления могут быть эффективно распараллелены
на 2-х уровнях:
 для каждого
xj  j  i
i  1 n производные компоненты xi могут вычисляться независимо от других
:
x
(s)
i
 вычисление
 is
x j
is 1
  
f j  s  2…

x
j 1
j
n
s
i
может вестись независимо для всех j  1 n
Решение системы ОДУ.
Для того, чтобы дать (более или менее) формальное определение мне понадобится ввести
некоторое количество базовых понятий, без чего провести классификацию всего
существующего зоопарка сетевых технологий – очень трудно.
Кто является элементом РВС компьютеры, подключенные к сети (хосты) или программы,
запущенные на хостах? Что такое программа (исполняемый файл, или нечто иное) ? Чем
распределенное приложение отличается от «обычной» монолитной программы, которые вы
привыкли запускать.
Например в книге «Конструирование распределенных объектов» Эммерих, (2002) дается следующее
определение: РВС состоит из компонентов, которые расположены на объединенных сетью хостах и
взаимодействуют по сети через унифицированное ППО таким образом, что все это внешне
выглядит единым вычислительным средством.
14
Здесь много непонятных слов. В дальнейшем будет дано разъяснение и приведено несколько иное
уточненное определение.
Компонент 1
Процесс
…
Компонент N
Процесс
Промежуточное (унифицированное) ПО
Сетевая ОС
(реализация стека сетевых протоколов)
Аппаратура H/W
Хост
Рис.1.
Понятие хоста (узла РВС)
В итоге РВС может быть представлена как совокупность таких пунктирных блоков, связанных сетью.
НАРИСОВАТЬ.
Остановимся пока на этой картинке и уточним несколько важных понятий, без чего трудно перейти к
уточнению этого определения. Кто такие эти сетевые ОС, что такое процессы, как они
взаимодействуют с OC, что такое стек сетевых протоколов…
1.5 Процессы (уточняет понятие программная компонента, приложение)
Например стандарт POSIX (Portable Operating System Interface for *niX) дает следующее определение
процесса. Процесс – это адресное пространство вместе с выполняемыми в нем потоками управления, а
также системными ресурсами, которые этим потокам требуются.
Современные многозадачные ОС, обеспечивают «одновременное» выполнение нескольких самых
разных процессов на одной машине.
Часто, для простоты, предлагается рассматривать процесс как абстракцию, характеризующую программу во
время выполнения. Это не совсем корректно. Понятие процесса характеризует некоторую совокупность
набора исполняющихся команд, ассоциированных с ним ресурсов (выделенная для исполнения память или
адресное пространство, стеки, используемые файлы и устройства ввода-вывода и т. д.) и текущего момента его
выполнения (значения регистров, программного счетчика, состояние стека и значения переменных),
находящуюся под управлением операционной системы.
Не существует взаимно-однозначного соответствия между процессами и программами, обрабатываемыми
вычислительными системами.
15
Как будет показано далее, в некоторых операционных системах для работы определенных программ может
организовываться более одного процесса или один и тот же процесс может исполнять последовательно
несколько различных программ. Более того, даже в случае обработки только одной программы в рамках
одного процесса нельзя считать, что процесс представляет собой просто динамическое описание кода
исполняемого файла, данных и выделенных для них ресурсов. Процесс находится под управлением
операционной системы, поэтому в нем может выполняться часть кода ее ядра (не находящегося в
исполняемом файле!), как в случаях, специально запланированных авторами программы (например, при
использовании системных вызовов), так и в непредусмотренных ситуациях (например, при обработке внешних
прерываний).
Процессы = ?? Компоненты, приложения. Когда программа запущена – синонимы.
Пока нет – компоненты, это набор файлов – результатов компиляции
W - *.exe, *.dll *nix – исп., *.so Java - *.class
Процессы рождаются и «умирают» по командам пользователей или OC. TaskManager в Windows; команда ps в
*nix.
Процессы могут быть многопоточными (multi-threaded), но и в этом случае существует некоторый главный
(порождающий) поток. Указать на пунктирный характер выполнения потоков (ограниченные аппаратные
ресурсы выделяются отдельным потокам отдельными интервалами времени). Управление выполнением
процессов и потоков – прерогатива ОС.
Современный GUI – кольца обработчиков событий, вызванных действиями пользователя и изменениями
состояния внутренних переменных процесса.
Для наших целей удобно представить следующую логическую структуру процесса в ходе его
выполнения (блоки, выделяемые процессу в оперативной памяти)
исполняемый код (возможна динамическая подгрузка фрагментов кода из DLL или SO)
куча (heap) – область памяти, где хранятся данные переменные;
стек – специальная область памяти, используемая при вызове процедур.
НАРИСОВАТЬ
16
1.6
Сетевые ОС
Современная ОС – жизненная среда обитания всех процессов запущенных на машине.
Рис.2. Слои программного обеспечения компьютерной системы
Операционная система как виртуальная машина (абстракция диска, файловой системы, памяти и пр.
аппаратных ресурсов)
Операционная система как менеджер ресурсов (управляет доступом приложений >> ресурсам)
Операционная система как защитник пользователей и программ (друг от друга).
Операционная система как постоянно функционирующее ядро. Это программа, постоянно
работающая на компьютере и взаимодействующая со всеми прикладными программами.
Можно выделить шесть основных функций, которые выполняли классические операционные
системы в процессе эволюции:
 Планирование заданий и использования процессора (обеспечение многозадачности).
 Обеспечение программ средствами коммуникации и синхронизации (обмен данными между
программами в пределах одного хоста).
 Управление памятью.
 Управление файловой системой.
 Управление вводом-выводом (включая отправку/получение данных из сети!) .
 Обеспечение безопасности
Если исключить архитектуру мэйнфреймов, то можно провести следующую (условную)
классификацию сетевых многозадачных OC.
17
Антимонопольный процесс против American Telephone and Telegraph (AT&T) в 1949 году запретил
AT&T продажей каких бы то ни было компьютерных решений, и рекомендовалось ограничиться
телефоном и телеграфом. Именно поэтому исследовательское подразделение AT&T, Bell Labs, с тех
пор прибыли само по себе не приносило: все создаваемые компьютерные технологии свободно
лицензировались всем желающим и созданная ею OC Unix (идейный прародитель всех современных
широко распространенных OC)
Многие из лицензиатов (в основном, конечно же, университеты) создавали слегка или сильно
модифицированные версии для собственных нужд.
Семейство *nix (AT&T + Sun
Linux
Windows
Microsystems)
Unix (~1970) (Belle Labs AT&T)
*nix – различные варианты
модификации открытого
исходного кода. (80–90 Unix
Wars)
*nix
80 – MS-DOS (НЕ
Начиная с 90-x
многозадачная, и очень слабо
сетевая
Sun OS (Solaris)
Win95 – фактически первая
Java !!!
более или менее полноценная
сетевая OC от MS .
Одной из "веток" стал разработанный в Беркли "берклиевский комплект ПО" (Berkeley Software Distribution,
BSD), по прежнему распространявшийся свободно и с исходниками. Возможно, именно этот факт повлиял на
DARPA при выборе - кому бы дать денег для разработки протокола TCP/IP. Дали. Разработали (4.2BSD, август
1983 года). Этот фактор (совместно со многими другими) повлиял на огромную популярность и быстрое
распространение BSD. Ну а Билл Джой, с которого начиналась эта версия Unix, тем временем создал
собственную фирму под названием "Солнышко" (Sun Microsystems). Сыгравшей огромную роль в развитии
концепции РВС
В начале 1980-х годов в результате очередного антимонопольного судебного процесса AT&T была
разделена на несколько подразделений, в результате чего у корпорации оказались развязаны руки (в
смысле получения прибыли от торговли компьютерами). И вновь - тяжело предположить, как бы
сложилась судьба Unix без этого события: с одной стороны, агрессивный маркетинг AT&T
способствовал быстрому и эффективному распространению ОС; с другой - новая стратегия
лицензирования (без исходного кода) положила начало разделению разработки Unix на
несколько разных независимых веток и многолетнему противостоянию этих веток (так
называемые unix wars). Это фактически и было причиной того, что Линус Торнвальд начал
18
разрабатывать собственную POSIX *nix систему . Параллельно MS захватила огромный рынок
настольных машин.
1.7 Необходимые сведения об уровнях сетевой архитектуры
http://www.intuit.ru/department/network/baslocnet/5/1.html
В сети производится множество операций, обеспечивающих передачу данных от компьютера к компьютеру.
Пользователя не интересует, как именно это происходит, ему необходим доступ к приложению или
компьютерному ресурсу, расположенному в другом компьютере сети. В действительности же вся
передаваемая информация проходит много этапов обработки, проходя через уровни архитектуры
сетевой ОС.
Прежде всего, она разбивается на блоки, каждый из которых снабжается управляющей информацией.
Полученные блоки оформляются в виде сетевых пакетов,
потом эти пакеты кодируются,
передаются с помощью электрических или световых сигналов по сети в соответствии с выбранным
методом доступа,
затем из принятых пакетов вновь восстанавливаются заключенные в них блоки данных, блоки
соединяются в данные, которые и становятся доступны другому приложению. Это, конечно, упрощенное
описание происходящих процессов.
Часть из указанных процедур реализуется только программно, другая часть – аппаратно, а какие-то операции
могут выполняться как программами, так и аппаратурой.
Место компонент РВС в модели ISO/OSI (Open System Interconnection), 1977
19
компоненты РВС
Приложения (Application)
Представления (Representation)
Сессии (Session)
Транспортный (Transport)
TCP (порты)
Сетевой
Между сетями
IP адреса (номер сети + хост в
сети)
192.168.0.0-254
Канальный
Между сетевыми картами в LAN
6-ByteMAC-адрес (Media
Access Control), NIC (Network
Interface Card)
Все кричат «по-очереди»
Физический
Провода межу устройствами
Логический
обмен
Приложение #1
Провода, оптика, частоты,
фазы и прочая физика
(фигуры Лиссажу на экране
осциллографа)
Приложение #2
Уровень представления
данных
Уровень представления
данных
Сеансовый уровень
Сеансовый уровень
Транспортный уровень
Транспортный уровень
Сетевой уровень
Сетевой уровень
Канальный уровень
Канальный уровень
Физический уровень
Физический уровень
Фактический обмен данными
Логическое «движение» данных
Рис.3.
Физический и логический обмен данными по сети
ARPAnet
20
BBN's proposal followed Roberts' plan closely; it called for the network to be composed of small computers
known as Interface Message Processors (more commonly known as IMPs). The IMPs at each site performed
store-and-forward packet switching functions, and were connected to each other using modems connected to
leased lines (initially running at 50 kbit/second). Host computers connected to the IMPs via custom bit-serial
interfaces to connect to ARPAnet (Advanced Research Projects Agency Network).
21
2 Удаленный вызов процедур
Взаимодействие фрагментов процесса (вызов функции)
Фрагменты исходного
Фрагменты
Исполняемый код загружен и начинает
кода программы
исполняемого кода
выполняться.
// С
процесса
…
На куче создаются экземпляры объекта Calc и
int x; int y; int res;
…// x = …; y = …
res = add(x, y)
Участок кода, откуда
переменных x, y, res.
вызывается функция.
«Клиентский»
участок кода
…
При вызове процедуры, переменные (или адреса
переменных помещаются на стек, и управление
передается на участок исп. кода, где реализована
процедура add.
int add( int a, int b) {
…
return a+b;
}
Участок кода, где
После выполнения процедуры – результат
функция
помещается по адресу res и управление
реализована.
возвращается «клиентскому» фрагменту
«Серверный»
участок кода
Оба участка в одном
процессе
Здесь важно то, что вызов процедуры (метода) обязательно сопровождается формированием
некоторой структуры данных (здесь – на стеке) и передаче этой структуры (или иной информации,
достаточной для ее обнаружения) другому фрагменту исполняемого кода.
Нарисовать
серверный/клиентский фрагменты процессов,
22
каркасы/представители процедуры (выполняют манипуляции с кучей/стеком «имитируя» локальный
вызов
маршаЛ(!)инг/демаршаЛ(!)инг
Указанные выше технологии различаются деталями и терминологией. Тем не менее, все они имеют много общего. В
этом разделе мы попытаемся указать набор типовых элементов, которые в той или иной форме присутствуют в любой
распределенной системе.
Основными понятиями здесь являются:

процесс (клиентский, серверный или смешанный);

сервис, каркас интерфейса, метод сервиса, доставленный вызов (в серверных процессах);

представитель интерфейса, вызов метода, предоставленный метод (в клиентских процессах);

связующее программное обеспечение (СПО), маршалинг, демаршалинг, а также службы СПО.
Процессом принято называть тот поток команд, который рассматривается операционной системой как отдельная
программа (или приложение) и выполняется в своем адресном пространстве. Эти процессы представляют собой среду, в
которой функционируют фрагменты распределенной системы. Сами процессы могут быть многопоточными, но это уже
зависит от деталей реализации (возможностей используемых языков программирования и операционных систем).
При этом возможны довольно сложные ситуации. Например, фрагменты распределенной системы могут быть
реализованы в форме Java-апплетов. В этом случае процессом будет являться тот экземпляр браузера (в комбинации с
Java-машиной - средой исполнения Java-классов апплета), который загрузил соответствующий HTML-документ.
Функциональность распределенной системы реализована в специальных фрагментах программного кода - сервисах, которые отвечают за выполнение четко определенного списка операций (методов). Описание этих операций содержится в
интерфейсах, которые представляют собой спецификации (списки аргументов с указанием типа передаваемых
параметров, типы возвращаемых значений), не зависящие от деталей реализации.
Процессы, в которых функционируют сервисы, принято называть серверными. Процессы, из которых идет
обращение к сервисам (вызовы методов), принято называть клиентскими. Однако, четкого разделения по этому признаку
не существует, т.к. могут существовать «смешанные» процессы, в которых наряду с функционированием собственных
сервисов предусмотрены обращения к сервисам других процессов. Учитывая это замечание, правильнее говорить о
клиентских и серверных фрагментах кода процессов в распределенной системе.
Архитектура процессов в распределенных системах представлена на рисунке
23
Северный фрагмент процесса №1
Клиентский фрагмент процесса №2
Фрагмент кода,
реализующий
процедуру
(метод)
Фрагмент кода,
вызывающий
удаленную
процедуру
Демаршалинг
Маршалинг
Представитель
процедуры
Каркас процедуры
ППО
ППО
Метод сервиса
Вызов метода сервиса
Доставленный вызов
Предоставленный метод
Рис.4. Ахитектура процессов в распределенных системах.
Вызов методов сервисов из клиентских фрагментов кода обеспечивается представителями интерфейсов. Это
специально оформленные участки клиентского кода, которые обеспечивают передачу параметров вызываемым методам
сервисов и возврат результатов таких вызовов, как если бы речь шла о клиентском вызове обычных методов в
классических (не распределенных) приложениях. Достигается это за счет того, что представители интерфейсов содержат
описание методов, спецификации которых абсолютно идентичны спецификациям соответствующих методов сервисов, и
это гарантирует корректный вызов. Важно подчеркнуть, что, несмотря на совпадение спецификаций, функциональности
этих двух категорий методов кардинально различаются: методы сервисов непосредственно обслуживают запросы
клиентов, в то время как методы представителей интерфейсов реализуют системные функции, связанные с доставкой
этих клиентских вызовов в другие процессы и возвратом результатов. Методы представителей интерфейсов далее
называются предоставленными методами.
Стандартизованный доступ к сервисам требует, чтобы серверные фрагменты кода включали в себя каркасы
интерфейсов. Основная задача каркасов - направить полученный вызов нужному методу сервиса. В серверных
фрагментах кода такой вызов происходит как обычный вызов внутренней процедуры. Однако, поскольку он является
отражением соответствующего вызова в клиентском процессе, мы будем называть его доставленным вызовом.
И, наконец, связующее ПО (middleware). Этот термин объединяет набор готовых программных компонентов,
отвечающих за удаленное взаимодействие процессов. Именно эти компоненты обеспечивают прозрачность сети,
передают вызовы между представителями интерфейсов и серверными фрагментами кода и возвращают результат
клиентским фрагментам кода.
Например, вызов предоставленного метода в клиентском процессе обрабатывается компонентами СПО и
преобразуется в форму, пригодную для передачи его по сети. Эта процедура называется маршалингом (marshaling)
вызова. Процессы взаимодействия с уровнем сетевых протоколов - также функция СПО. На стороне серверного процесса
соответствующие компоненты СПО принимают вызов, поступивший в форме пакета данных (указатель конкретного
сервиса, метода его интерфейса со списком значений аргументов), и преобразуют его в доставленный вызов метода
сервиса. Это преобразование, обратное маршалингу, называют демаршалингом.
24
Реализацией связующего ПО могут быть динамические библиотеки (*.DLL на платформах Microsoft, *.SO на
платформах Unix или Linux), исполняемые модули *.EXE, а также файлы Java-кода *.CLASS или *.JAR.
Функционирование СПО тоже происходит распределенным образом (см. 0). Фрагменты кода СПО подгружаются во
время запуска процессов, в которых функционируют фрагменты распределенной системы. Кроме того, часть СПО может
присутствовать в форме специальных служб, запущенных на серверах - узлах сетей различного уровня. При этом
функциональные возможности этих служб представлены специальными сервисами, реализующими стандартные
(описанные в спецификациях СПО) интерфейсы. Доступ к этим стандартным сервисам из клиентских фрагментов кода
происходит точно так же, как и к любым другим сервисам - через соответствующих представителей интерфейсов.
Клиентский фрагмент
процесса
Серверный фрагмент
процесса
Cлужбы СПО
Cлужбы СПО
Cлужбы СПО
Смешанный фрагмент
процесса
Рис.5. Основные элементы распределенной системы.
Таким образом, современные архитектуры распределенных систем обобщают традиционную клиент-серверную
схему сетевого взаимодействия в направлении, как принято говорить, многозвенных (multi-tire) систем, где разделение
клиентских и серверных частей имеет место не на уровне процессов, а на уровне отдельных фрагментов кода. При этом
место процессов-серверов занимают фрагменты кода, реализующие сервисы, а место процессов-клиентов - участки кода,
где происходят удаленные (через сеть) вызовы методов сервисов.
25
2.1 Синхронный, односторонний и асинхронный (отложенный вызов)
Процесс №1
Процесс №2
Клиентский
фрагмент кода
Серверный
фрагмент кода
Рис.6. Синхронный (блокирующий) вызов
Процесс №1
Процесс №2
Клиентский
фрагмент кода
Серверный
фрагмент кода
Рис.7. Односторонний вызов
26
Процесс №1
Процесс №2
Клиентский
фрагмент кода
Серверный
фрагмент кода
"Адрес" обратного
вызова (callback point)
Рис.8. Асинхронный (отложенный) вызов
Нужно сказать о двух модификациях асинхронного вызова:
 когда callback передает управление в указанное место клиентского процесса, как только будет
доставлен результат (часто так и назавают «модель callback»
 «модель Poller», когда клиентский процесс периодически опрашивает обертку Callback на
предмет – доставлен ли результат, и, когда это необходимо – использует для дальнейших
вычислений.
27
Лекция 5
Продолжение RPC (от удаленных процедур – к удаленным объектам)
2.2 Основные понятия OOA
2.2.1 Типы, наследование, объекты (адресация объектов), заявки, исключения
Все современные стандарты ППО, в той или иной мере, следуют принципам ООП.
(Нарисовать молекулу)
Черные кружочки - объекты или экземпляры типов.
Тип - набор методов, которые может выполнять объект этого типа.
Т.е. можно сказать, ТИП = ИНТЕРФЕЙС
Пример. Тип калькулятор (на некотором «абстрактном» языке описания интерфейсов)
Calc
{
add(float x, float y):float; // x + y
mult(float x, float y): float; // x * y
div(float x, float y): float; // x / y
}
CalcExt extends Calc {
sub(float x, float y): float // x - y
} - умеет делать все, что и Calc, и КТОМУ ЖЕ - вычитать.
Вызов метода - часто называют «заявкой»/объектный вызов или заявка. Обычно всегда - это структура типа:
{ссылка, содержимое}
При вызове метода могут возникнуть «ИСКЛЮЧЕНИЯ», например, для нашего Calc, такое исключение
возникнет, если второй аргумент y=0.
exception DivideByZero {};
Calc {
…
div(float x, float y): {float | DivideByZero} // либо результат, либо – исключение
}
28
Лекция 6
Продолжение описания общих требований к ООA.
2.2.2 Объекты, имеющие состояние
CalcPersist extends Calc {
setMem(float x): void; // Запомнить x в буфере объекта
getMem(): float;
clearMem(): void;
// Вернуть значение из буфера
// Очистить буфер
addMem(float x): void;
multMem(float x): void;
…
}
Работая с экземплярам такого типа следует помнить, что он имеет состояние, которое зависти от
предыстории вызванных на нем операций
2.2.3 Составные Типы данных
Использованный тип float относится к примитивным типам (int, double, string, …) поддержка таких типов
естественна. Однако всегда удобно иметь возможность определять и использовать составные сложные типы
данных. Например, для целей вычислений удобно использовать тип вектор, матрица и т.п.
type FloatVector {float}* // последовательность из нескольких float. Здесь я «пытаюсь» использовать нотацию
EBNF НЕ ПРИДИРАЙТЕСЬ
exception CheckDimensions {};
CalcVector extends CalcExt
{
scalarProduct(FloatVector x, FloatVector y) {float | CheckDimensions};
}
Более сложный пример. Объединение. Например, наш калькулятор умеет работать только с float. Но ведь есть
еще double, int. Чтобы не плодить методы удобно было бы задавать «объединение» типов, которое могло бы
принимать значение одного из указанного набора примитивных типов:
type Number {int | float | double | string} // Поскольку для строки не все операции можно корректно задать надо
бы предусмотреть исключение типа Unsupported
exception Unsupported{string message}
SuperCalc
{
add(Number x, Number y):Number; // x + y
29
mult(Number x, Number y): {Number | Unsupported }; // x * y
div(Number x, Number y): {Number | Unsupported}; // x / y
}
Таким образом от современных ППО можно требовать возможности определение различных типов данных и
типов объектов (интерфейсов, описание которых основано на описаниях типов)
И вот ВСЕ ЭТО нужно уметь делать на РАЗНЫХ ПЛАТФОРМАХ, и РАЗНЫХ ЯЗЫКАХ
2.2.4 Адресация объектов
Когда тип объекта задан, его нужно создать, затем уметь его обнаружить в сети: указать его ссылку.
Ссылка - это всегда, {
<сетевой адрес, для используемого транспорта, например хост, порт>,
доп. идентификатор объекта (т.к. несколько объектов могут обслуживаться одним портом),
тип объекта}
http://some.com:8080/someService (для WS)
corbaloc:iiop:some.com:30000/someObjKey (для CORBA)
30
2.3 CORBA (Common Object Request Broker Arch.)
CORBA (Common Object Request Broker Architecture) является спецификацией создания распределенных программных
систем, развиваемой консорциумом OMG (Object Management Group, www.omg.org ) - некоммерческой организацией,
включающей в период «расцвета» более 800 компаний. В настоящее время в списке – 438 компаний, из которых более
100 университетов. Многие известные крупные разработчики ПО «уровня предприятия» (SAP_AG, IONA, Prism
Technologies).
Лидерами OMG являются фирмы Oracle, IBM (сейчас – вышла), Sun Microsystems, IONA .
Цель OMG - достижение «быстрого роста технологии объектов» через развитие архитектуры управления объектами
OMА (Object Management Architecture). OMА является концептуальным базисом, на котором основаны спецификации
OMG.
OMG «продвигает» еще такие известные стандарты как UML язык проектирования ПО, MDA (Model Driven Arch)
поддержки всего жизненного цикла – от проектирования до реализации, развертывания и тестирования.
CORBA развивается как система открытых стандартов с 1989г. Первый итоговый доку-мент OMG был опубликован в
1991г. В 1992г. вышел его переработанный вариант, а в 1994г. появилась версия CORBA 2.0. В настоящее время
используется CORBA 2.3-5. Уже существует версия спецификации 3.0.
На основе CORBA развивается компонентная модель объектов CCM (CORBA Component Model). Целью этого проекта
является стандаризация процессов разработки распределенных систем на основе компонентной модели (контейнеры
объектов, серверы приложений, автоматическая склейка компонент «внутри» сервера приложений и т.п.). CCM
развивается в тесной связи с моделью EJB (Enterprise Java Beans) предлагаемой Sun Microsystems для разработки
распределенных приложений.
Активно развивается до сих пор.
2.3.1 Фазы жизненного цикла информационных технологий на примере CORBA
31
Популярность
(публикации и
обсуждения)
Практика (попытки)
использования
“Hype”
Внедрение
Появление
1990
Использование
1996-97,
CORBA 2.0
2000,
CORBA 2.4
2004,
CORBA 3.0
Время жизненного цикла технологии
Поддерживаемые языки программирования:
С, С++ (1998 Java (1997 - )
Smalltalk (1994 - )
ADA (первая версия 1995) подчеркивает важность CORBA для специалистов разработки «технического»
высокопроизводительного ПО
COBOL (1999 –
Lisp (1999 – ) CLORB a Common Lisp implementation of CORBA 2.6
Python (1999 –
XML, для типов данных.
“Авторы” CORBA
Несмотря на то, что, формально, спецификации CORBA являются результатом работы некоммерческого
консорциума OMG (Object Management Group), есть лица персонально «повязанные» с этой технологией.
Douglas Schmidt Автор многих базовых шаблонов (patterns) распределенного программирования.
Возглавляет коллектив центра Center for Distributed Object Computing (DOC), где уже более 10 лет
разрабатывается один из основных комплектов разработки CORBA (ACE TAO).
24 миллиона 1995-2006 команда ~10 человек (Boeing, Lockheed Martin, McDonnell Douglas, DARPA). Системы
реального времени в авионике, тренажерах, системы контроля за производственными процессами.
Steve Vinoski, IONA (крупный разработчик ППО, Orbix, ORBacus)
32
Michi Henning (родился в Германии) is Chief Scientist of ZeroC. From 1995 to 2002, he worked on CORBA as a
member of the Object Management Group's Architecture Board, and as an ORB implementer, consultant, and trainer.
He is the co-author of Advanced CORBA Programming with C++ and Distributed Programming with Ice.
33
2.3.2 Знакомство с IDL
В основе спецификации CORBA лежит язык IDL (Interface Definition Language), предназначенный для описания типов
данных и типов объектов (интерфейсов). Описания IDL – не зависят от языка программирования, на котором будет
реализована РС. Общее требование состоит в том, что для использования «удаленного объекта» вам должно быть
достаточно предоставленного IDL-описания типов, используемых этим объектом. Как это реализовано технически будет
рассказано позднее, а пока остановимся на ключевых понятиях языка.
Рассмотрим для примера IDL описание калькулятора
/* File DemoCalc.idl */
#pragma prefix "fivt.ru"
module dcs {
module demo {
interface SimpleCalc {
double add (in double a, in double b);
double sub (in double a, in double b);
double mult (in double a, in double b);
};
/* Комментарий
Пример наследования типа
*/
interface Calc : SimpleCalc {
exception DivisionByZero {
string reason;
};
double div (in double a, in double b) raises (DivisionByZero);
};
// Определение перечисления (Еще одна форма комментария)
enum NumberType {DT_LONG, DT_FLOAT};
union Number switch(NumberType) {
case DT_LONG: long longN;
case DT_FLOAT: float floatV;
};
interface SuperCalc {
Number add (in Number a, in Number b);
Number sub (in Number a, in Number b);
Number mult (in Number a, in Number b);
// Пример использования имени интерфейса/модуля (::) для ссылки на уже имеющийся тип данных.
Number div (in Number a, in Number b) raises (Calc::DivisionByZero);
};
typedef sequence<Number> NumberVector;
valuetype BoxedNumberVector sequence<Number>;
interface VectorCalc {
exception CheckDimensions {
string comment;
};
Number ScalarProduct (in NumberVector x, in NumberVector y) raises (CheckDimensions);
Number BoxScalarProduct (in BoxedNumberVector x, in BoxedNumberVector y) raises
(CheckDimensions);
};
};
};
//(Обратить внимание на то, что имя файла никак не связано с названиями модулей)
2.3.3 Архитектура CORRBA
Фактически стандарт CORBA представляет собой набор спецификаций, описывающих
IDL (Interface Definition Language)
Протоколы GIOP (IIOP), включая правила и формат упаковки данных, пердаваемых по сети.
Программная архитектура
Правила отображения на языки программирования (!)
Общие правила разработки (использование предкомпиляторов и структура готовых фрагментов исходного кода)
34
Спецификации стандартных служб (позже)
Программная архитектура многозначное понятие. Это и логическая структура программных модулей, находящихся в
отношении «основано-на», «состоит-из» и т.п., и описание API (Application Programming Interface). Различают
«абстрактную архитектуру» некоторой модели программирования, и «устройство» конкретной реализации.
Элементы приводимой ниже архитектуры CORBA находятся между собой в отношениях, аналогичных тем, что
используются при описании «семиуровневой модели»
Процесс, использующий
CORBA объект
Клиентский
фрагмент кода
Dynamic
Invocation
Interface
Static
IDL Stabs
Процесс, реализующий
CORBA объект
"Граница"
процессов
Реализация CORBA
объекта (сервант)
ORB Interface
DSI
IDL
Skeleton
Object
Adapter
Ядро ORB (Pseudo IDL)
Уровень универсального протокола GIOP (General Inter-Object Protocol)
Уровень специализированных протоколов
IIOP
CORBA
Уровень сетевых протоколов
SSLIOP ESIOP (Environment
Specific IOP)
SSL
Другие протоколы
TCP/IP
Интерфейсы ORB, универсальные для всех реализаций CORBA
Стабы и скелетоны, специфичные для каждого CORBA объекта
Реализации интерфейса Объектного Адаптера, зависящие от разработчиков ORB
Обычные вызовы методов, определяемые в прикладном коде
Доставленные вызовы из среды ORB
Рис.9. Основные элементы распределенной системы в технологии CORBA.
35
Существует большой выбор комплектов разработчика систем на базе CORBA от различных поставщиков и
ориентированных на разные языки программирования. Но везде присутствуют следующие необходимые элементы:

предкомпилятор языка IDL;

набор файлов на языке IDL, содержащих описание стандартных интерфейсов и служб (согласно стандартам
OMG);

набор готовых компонентов - реализация ядра ORB и некоторого подмножества стандартных служб CORBA (в
минимальной конфигурации - служба наименований и репозиторий интерфейсов).
1. Проектирование интерфейсов на языке IDL;
2. Использование предкомпилятора IDL;
3. Реализация серванта и клиентской части приложения на уровне исходных кодов
4. Компиляция исходных кодов
Для иллюстрации использования CORBA API приведем примеры операторов серверного и клиентского кодов, созданных
предкомпилятором для IDL описания DemoCalс.
36
Примеры файлов, созданных предкомпилятором “из” DemoCalc.idl (интерфейс Calc):
Имя файла (все с
расширением
.java)
Calc
Назначение
В каком
фрагменте кода
серв. клиент.
Базовый класс для объектов типа "сумматор".
package dcs.demo; // модули IDL
x
x
x
x
public interface Calc extends CalcOperations,
org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity
CalcOperations Абстрактный класс (в Java - типа interface) содержащий
отображение методов и атрибутов интерфейса на язык Java, но
без реализации.
CalcPOA
Фрагмент кода, содержащий скелетон интерфейса.
public abstract class SmartCalcPOA
extends
org.omg.PortableServer.Servant implements
org.omg.CORBA.portable.InvokeHandler,
dcs.demo.CalcOperations
_CalcStub
Фрагмент кода, содержащий представитель (стаб) интерфейса.
CalcHelper
Специальный вспомогательный класс, содержащий набор
методов, необходимых клиентской стороне (обычно - для
манипуляций с объектными ссылками)
x
x
x
x (в
основном
здесь)
Примеры «реализаций» клиентской и серверной частей приложения
// Клиентский код. File CalcClient.java
package dcs.demo;
import dcs.demo.CalcPackage.DivisionByZero;
public class CalcServer
{
static org.omg.CORBA.Object corbaObject = null;
public static void main(String[] args) {
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
// String reference = ….
org.omg.CORBA.Object corbaObject = orb.string_to_object(reference);
dcs.demo.Calc calc = CalcHelper.narrow(calcObject);
double res = calc.add(1.,2.);
try {
res = calc.div(10.,0.);
} catch(DivizionByZero ex)
{
System.out.println(“Не дели на ноль”);
}
}
}
37
// Серверные код. File CalcImpl.java
package dcs.demo;
import dcs.demo.CalcPackage.DivisionByZero;
public class CalcImpl extends CalcPOA { CalcImpl – «сервант»
public CalcImpl ()
{// Конструктор серванта
super();
};
public double add(double a, double b) { return a+b; }
public double div(double a, double b) throws DivisionByZero {
if (b < 1.E-08) {
DivisionByZero ex = new DivisionByZero("Denominator is too small");
throw ex;
}
return a/b;
}
// …….
}
// Серверный код. File CalcServer.java
package dcs.demo;
import dcs.demo.CalcPOA;
public class CalcServer
{
static org.omg.CORBA.ORB orb;
static NameComponent[] fullNameComponent;
static NamingContextExt root;
static org.omg.PortableServer.POA rootPOA = null;
static org.omg.CORBA.Object calcObject = null;
public static void main(String[] args) {
orb = org.omg.CORBA.ORB.init(args, null);
CalcImpl servant = null;
try {
rootPOA = org.omg.PortableServer.POAHelper.narrow(
orb.resolve_initial_references("RootPOA")
);
} catch (org.omg.CORBA.ORBPackage.InvalidName ex) {
Log.logout(ex);
System.exit(1);
} catch (org.omg.CORBA.BAD_PARAM ex) {
Log.logout(ex);
System.exit(1);
}
try { rootPOA.the_POAManager().activate(); }
catch(org.omg.PortableServer.POAManagerPackage.AdapterInactive ex) {
Log.logout(ex.getMessage()); System.exit(1);
}
/**
* Activate CORBA Object возможно – с присваиванием объектного ключа
*/
try {
servant = new CalcImpl();
rootPOA.activate_object(servant);
// activate_object_with_id(“MyCalcID”, servant);
} catch(org.omg.PortableServer.POAPackage.ServantAlreadyActive ex)
Log.logout(ex.getMessage());
System.exit(1);
}
catch(org.omg.PortableServer.POAPackage.WrongPolicy ex)
{
Log.logout(ex.getMessage());
System.exit(1);
}
} catch(org.omg.PortableServer.POAPackage.ServantAlreadyActive ex)
Log.logout(ex.getMessage());
System.exit(1);
}
catch(org.omg.PortableServer.POAPackage.WrongPolicy ex)
{
Log.logout(ex.getMessage());
System.exit(1);
}
{
{
// Публикация ссылки на объект register server with naming context
System.out.println(orb.object_to_string(servant._this_object());
try {
orb.run();
} catch (org.omg.CORBA.NO_IMPLEMENT ex) {
Log.logout(ex);
System.exit(1);
}
// …….
}
38
2.4 Сравнение централизованных и децентрализованных РВС
Централизованные
Распределенные
Содержат неавтономные компоненты (система
Содержат автономные компоненты (можно
имеет полный контроль над этими
выключить удаленный хост, или он сам сломается)
процессами/компонентами)
Однородная технология
Разнородные платформы (ОСы, языки)
Ресурсы разделяются между многими
Также не является определяющим признаком !
пользователями (возможно, но не обязательно)
Имеют один «центр управления» и
Несколько центров администрирования
администрирования
Прозрачность в распр. системах
Прозрачность
масштабируемости
Прозрачность
производительности
Прозрачность
миграции
Прозрачность
репликации
Прозрачность
доступа
Прозрачность
местонахождения
Прозрачность
отказов
Прозрачность
одновременного
выполнения
Рис.10. Требования «прозрачности» в РВС (Эммерих).
Стрелочки здесь означают «влияет-на». Например, «Прозрачность миграции» зависит от прозрачности
доступа и местонахождения, которые «влияют-на».
Все эти требования, фактически являются требованиями к соотв. ППО и его службам.
39
Вид прозрачности
Прозрачность доступа
Комментарий
Вызов объекта определенного типа не должен зависеть от:
реального места жительства объекта;
от ОС хоста;
от языка программирования, использованного при реализации.
Зависит ТОЛЬКО от типа (интерфейса) объекта
Программная компонента, где «живет» объект, может быть перенесена на другой
компьютер, без необходимости переделывать «клиентский участок» кода.
Решается: стандарт ссылок, стандарт описания интерфейсов (?DL),
использование универсального формата заявок.
Прозрачность
Объект может быть перенесен «незаметно» для других компонент РВС (отказал
местонахождения
хост обитания).
Решается: стандарт ссылок, служба регистрации (хранит ссылки по их
«описаниям»). Клиент обращается к службе за ссылкой, которая обновляется
при каждом запуске объекта.
Прозрачность миграции
- «» -
Прозрачность
Возможность создания новых «копий» реплик объекта, например для
репликации
обслуживания возросшего потока заявок
Решается: спец. средства для сохранения состояния и копирования объектов
(Persistence service). Добавить в CalcExt операцию
toMem(float x):void; // x -> mem
increment(float x): float // mem =+ x
getMem(): float // get mem value
Прозрачность
одновременного
Иллюзия «одновременного» выполнения заявок от различных клиентов.
Управления очередями заявок, Load Balancing Services. Нарисовать
выполнения
2.5 «Прозрачность доступа» на примере проблемы Big- и Little-endian
Память компьютера имеет байтовую организацию, а каждый байт имеет свой номер - адрес. Одного байта чаще всего
недостаточно для хранения какой-либо информации (например, тип short хранится в двух байтах, long – в четырех, double
– в восьми). Следовательно надо иметь возможность сохранять информацию в нескольких соседних байтах. Чтобы
расположить информацию в нескольких байтах, можно выбрать один из двух способов.
40
Номера байтов
0
1
2
3
число (2041302511) (выбрано просто о аналогии с
79
AB
CD
EF
последовательностью 89ABCDEF, но 8 – не подходит т.к. если 1й
первый бит – единица, то число отрицательное
Старший и младшие байты
адрес
…
хранимое
MSB
N
N+1
N+2
N+3
EF
CD
AB
79
значение
…
адрес
… N
хранимое
79
LSB
N+1
N+2
N+3
AB
CD
EF
…
значение
LSB
MSB
Тип представления Little-Endian
MSB
LSB
Тип представления Big-Endian
Рис.11. Big/Little Endians
Упомянуть о мониторах сетевой активности (Network Protocol Analyzer) Ethereal, Wireshark, позволяющих увидеть
Системы, на основе Intel-процессоров с архитектурой x86 используют тип Little-Endian. Системы на основе процессоров
Sun Sparc (и ОС Sun Solaris), Motorolla, различных RISC-процессоров; 64-разрядная архитектура IA-64 – используют
правило Big-Endian.
Это же правило применяется при чтении/записи числовых данных с использованием абстракций DataInput/DataOutput
(последовательных устройств ввода-вывода) виртуальной машиной Java.
Решение в протоколе GIOP: использовать специальный бит среди флагов заголовка сообщения 0 – Big-endian; 1 – Littleendian.The byte order for fragment messages must match the byte order of the initial message that the fragment
extends.
2.5.1 Подробнее об IDL.
Базовые (примитивные) типы
Целочисленные
short
-215 .. 215 - 1
long
-231 .. 231 - 1
long long -263 .. 263 - 1
unsigned short 0 .. 216 - 1
unsigned long 0 .. 232 - 1
unsigned long long 0 .. 264 - 1
Плавающие
OMG IDL floating-point types are float, double and long double. The float type represents IEEE single-precision floating
point numbers; the double type represents IEEE double-precision floating point numbers. The long double data type represents
an IEEE double-extended floating-point number, which has an exponent of at least 15 bits in length and a signed fraction of at
41
least 64 bits. See IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985, for a detailed
specification.
Символы
char 8 bit
wchar
(длина заранее не фиксирована, но, в первую очередь ориентирована на Unicode 16 bit)
Биты
boolean TRUE/FALSE
Октеты
octet 8 bit (удобен для пересылки произвольного содержания, т.к. CORBA гарантирует, что в содержимое НЕ будет
изменяться; так например удобно пересылать содержимое «двоичных» файлов (графика)).
Произвольный тип
any универсальный контейнер
interfrace DoAny {
any do(in Any)
}
Составные (пользовательские) и шаблонные типы
Структуры (struct), объединения (union), массивы переменной длины (sequence) и перечисления (enum)
typedef sequence<>
typedef string<10> myString;
typedef sequence<octet> binFile;
typedef sequence<octet,1000> binFile1000;
Структуры
struct Foo {
long myLong;
octet myOctet;
sequence<float> myFlatArray; (сказать о типе «массив фиксированной длины»)
};
Связанный список значений структур…
struct List {
Foo value;
sequence<List> next;
};
Описания интерфейсов
42
A
A
interface A { ... }
interface B: A { ... }
B
C
B
E
C
interface C: A { ... }
interface D: B, C { ... }
interface E: A, B { ... };
D
D
Переменная типа «интерфейс» может быть параметром
#include "DemoCalc.idl"
module dcs {
module demo {
interface Proxy2Calc {
double redirect(in Calc c, in string op, in double a, in double b);
/* in Object c – дало бы возможность передавать ссылку на любой CORBA-объект */
};
};
};
Семантика команды redirect состоит в том, чтобы перенаправить выполнение команды, указанной в виде строки
(значение параметра op) объекту, указанному в первом параметре. «Интерфейс-в-списке параметров» - всегда означает
передачу ссылки на объект !
Еще один пример.
#pragma prefix "fivt.ru"
module dcs {
module demo {
module file {
module io
{
exception IOException {
string mes;
};
exception FileNotFound {
string mes;
};
typedef sequence<octet> SeqOct;
typedef sequence<string> SeqStr;
struct File {
SeqOct content;
SeqStr path;
};
};
interface FileServer {
void put(in io::File f) raises (io::IOException);
io::SeqOct get(in io::SeqStr path) raises (io::IOException, io::FileNotFound);
void getInOut(in io::SeqStr path, out io::SeqOct content) raises (io::IOException,
io::FileNotFound);
};
};
};
};
Value Type
Можно передать ссылку на удаленный объект, можно передать структуру.
А можно ли передать объект «по-значению». Для этого в CORBA предусмотрен специальный
The basic notion is relatively simple. A value type is, in some sense, half way
between a “regular” IDL interface type and a struct. The use of a value type is a signal from the designer that some
additional properties (state) and implementation details be specified beyond that of an interface type. Specification of this
information puts some additional constraints on the implementation choices beyond that of interface types.
This is reflected in both the semantics specified herein, and in the language mappings.
An essential property of value types is that their implementations are always local.
That is, the explicit use of value type in a concrete programming language is always
guaranteed to use a local implementation, and will not require a remote call. They have no identity (their value is their identity)
and they are not “registered” with the ORB.
43
There are two kinds of value types, concrete (or stateful) value types, and abstract
(stateless) ones. As explained below the essential characteristics of both are the same.
The differences between them result from the differences in the way they are mapped
in the language mappings. In this specification the semantics of value types apply to
both kinds, unless specifically stated otherwise.
Concrete (stateful) values add to the expressive power of (IDL) structs by supporting:
• single derivation (from other value types)
• supports a single non-abstract interface
• arbitrary recursive value type definitions, with sharing semantics providing the
ability to define lists, trees, lattices and more generally arbitrary graphs using value
types.
• null value semantics
When an instance of such a type is passed as a parameter, the sending context marshals the state (data) and passes it to the
receiving context. The receiving context instantiates a new instance using the information in the GIOP request and unmarshals the
state. It is assumed that the receiving context has available to it an implementation that is consistent with the sender’s (i.e., only
needs the state information), or that it can
somehow download a usable implementation. Provision is made in the on-the-wire
format to support the carrying of an optional call back object (CodeBase) to the
sending context, which enables such downloading when it is appropriate.
It should be noted that it is possible to define a concrete value type with an empty state
as a degenerate case.
valuetype MyValueType
{
private long MyState;
private string MyName;
factory MyInit(in long l. in string n);
long getState();
string getName{}
}
interface OBVServer {
void putOBV(in MyValueType mv);
module demo {
module value {
valuetype boxedLong
long;
valuetype boxedString string;
valuetype Node {
public long id;
public Node next;
};
interface ValueServer {
string receive_long
(in boxedLong p1, in boxedLong p2);
string receive_string (in boxedString s1, in boxedString s2);
string receive_list
};
(in Node node);
};
};
44
Лекция 10
2.6 Объектная ссылка, устройство POA, протокол GIOP
Чтобы объяснить принципы адресации объектов CORBA. Нужно рассмотреть более подробно как устроен объектный
адаптер.
Важно, что в задачу POA входит обеспечить соответствие между зарегистрированными на нем объектами (которым
присвоено ID ) и реально существующими серверными объектами (сервантами)
Нарисовать иерархию POA и общую очередь заявок
Содержание объектной ссылки – адрес хоста + <rootPOA> + <subPOA> + … <ObjectKey>
Еще раз напомнить, что ORB API позволяет задавать осмысленные имена всем элементам этой цепочки
Policy[] policies = new Policy[3];
policies[0] =
root_poa.create_lifespan_policy(LifespanPolicyValue.PERSISTENT);//PERSISTENT);//
policies[1] =
root_poa.create_id_assignment_policy(IdAssignmentPolicyValue.USER_ID);//USER_ID);//
policies[2] =
root_poa.create_implicit_activation_policy( ImplicitActivationPolicyValue.NO_IMPLICIT_ACTIVATION );
POA poa = root_poa.create_POA( "CalcPOA", root_poa.the_POAManager(),
poa.the_POAManager().activate();
policies );
byte[] oid = "calc:1".getBytes();
CalcImpl servant = new CalcImpl();
poa.activate_object_with_id(oid, servant);
45
2.6.1 IOR
Важно, что стандарт CORBA использует язык IDL для описания всех структур используемых ORB,
протоколами GIOP The CORBA specification uses pseudo-IDL to define how an IOR encodes the
information required to send a request to the correct target object:
module IOP { // PIDL
typedef unsigned long ProfileId;
const ProfileId TAG_INTERNET_IOP = 0;
const ProfileId TAG_MULTIPLE_COMPONENTS = 1;
struct TaggedProfile {
ProfileId tag;
sequence<octet> profile_data;
};
struct IOR {
string type_id;
sequence<TaggedProfile> profiles;
};
typedef unsigned long ComponentId;
struct TaggedComponent {
ComponentId tag;
sequence<octet> component_data;
};
typedef sequence<TaggedComponent> MultipleComponentProfile;
};
At first glance, this is intimidating, but things are not quite as bad as they look. The main
data type in this IDL is struct IOR, which defines the basic encoding of an IOR as a
string followed by a sequence of profiles. The type_id string provides the interface
type of the IOR in the repository ID format we discuss in Section 4.19. The
profiles field is a sequence of protocol-specific profiles, usually one for each protocol
supported by the target object. For example, an IOR for an object that can be reached
either via IIOP or via DCE-CIOP has two elements in the profiles sequence. Figure
13.7 shows the main structure of an IOR.
Main structure of an IOR.
Interoperable Object Reference
46
IOR
String Length: 26
IOR::type_id: IDL:dcs/demo/Calc:1.0
Sequence Length: 1
Profile ID: TAG_INTERNET_IOP (0)
Sequence Length: 124
Endianess: Big Endian (0)
IIOP Major Version: 1
IIOP Minor Version: 2
String Length: 15
IIOP::Profile_host: 83.149.249.206
IIOP::Profile_port: 60004
Sequence Length: 34
Object Key: 726F6F742F4269446972504F415F5365727665722F426944...(“root/CalcPOA/calc:1”)
Sequence Length: 2
IIOP Component TAG: 0
Sequence Length: 8
component_data: ....JAC.
IIOP Component TAG: 1
Sequence Length: 28
component_data: ............................
Несколько профилей (для машины с двумя сетевыми интерфейсами)
>>ipconfig
Windows 2000 IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix .
IP Address. . . . . . . . . . . .
Subnet Mask . . . . . . . . . . .
Default Gateway . . . . . . . . .
:
: 10.10.64.15
: 255.255.255.192
: 10.10.64.1
PPP adapter Connection to Internet at Rapier24i-15Parkovay:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 212.5.76.66
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 212.5.76.66
================================================================
был запущен сервер (на TAO) со следующими параметрами:
... -ORBEndpoint iiop://10.10.64.15:50022, 212.5.76.66:50022
IOR объекта был зарегистрирован на сервисе именований, запущенном на dcs.
Дапм IOR (сгруженного с сервиса именований dcs):
IOR #1:
byteorder: little endian
type_id: IDL:iarnet/ResourceAgents/matlab/MxArrayFactory:1.0
Profile #1: iiop
iiop_version: 1.2
host: 10.10.64.15
port: 50022
object_key: (27)
20
1 15
0 82 83 84 98 "....RSTb"
117 166 68 131 64 10
0
1 "u.D.@..."
0
0
0
1
0
0
0
2 "........"
0
0
0
"..."
Component: TAG_ORB_TYPE = 0x54414f00
Native char codeset:
"ISO 8859-1:1987; Latin Alphabet No. 1"
Native wchar codeset:
"ISO/IEC 10646-1:1993; UTF-16, UCS Transformation Format 16-bit form"
Profile #2: iiop
iiop_version: 1.2
host: 212.5.76.66
port: 50022
object_key: (27)
20
1 15
0 82 83 84 98 "....RSTb"
117 166 68 131 64 10
0
1 "u.D.@..."
(Заметить, что ObjKey у разных профилей – один и тот же.)
0
0
0
1
0
0
0
2 "........"
0
0
0
"..."
Component: TAG_ORB_TYPE = 0x54414f00
Native char codeset:
"ISO 8859-1:1987; Latin Alphabet No. 1"
Native wchar codeset:
"ISO/IEC 10646-1:1993; UTF-16, UCS Transformation Format 16-bit form"
47
2.7 GIOP
Еще раз сказать о сниферах Ethereal Wireshark, где есть диссекторы протоколов GIOP, IIOP. «Лучше один раз увидеть»
General Inter-ORB Protocol
Magic number: GIOP
Version: 1.2
Flags: 0x01 (little-endian )
Message type: Request
Message size: 68
General Inter-ORB Protocol Request
Request id: 2
Response flags: SYNC_WITH_TARGET (3)
Reserved: 0 0 0
TargetAddress Discriminant: 0
KeyAddr (object key length): 29
KeyAddr (object key): ...0_RootPOA.CSPOA..demo:calc
Operation length: 4
Request operation: add
ServiceContextList
Sequence Length: 0
Stub data (8 bytes)
General Inter-ORB Protocol
Magic number: GIOP
Version: 1.2
Flags: 0x00 (big-endian )
Message type: Reply
Message size: 17
General Inter-ORB Protocol Reply
Request id: 2
Reply status: No Exception (0)
ServiceContextList
Sequence Length: 0
Stub data (5 bytes)
Синхронизация ответ-на-запрос посредством уникального ID (unsigned long)
GIOP Messages
Рассказывать подробно только про Request и Reply.
48
Заметить, что информация о кодировке big/little-endian передается в самом начале, во «флаговых»
битах 7-го байта GIOP Header. Длина сообщения, закодированная в последних 4-х байтах – уже
может быть закодирована разными способами.
Byte 7 is a flags byte. The least significant bit of the flags byte indicates whether the remainder of the
message is in big-endian or little-endian encoding: a value of 0 indicates big-endian. The second-least
significant bit indicates fragmentation. A value of 1 indicates that this message is a fragment with more
fragments to follow. A value of 0 indicates that this message is a complete message or is the last message in
a sequence of fragments.
Byte 8 indicates the message type. Its value is the ordinal value of one of the MsgType_1_1 enumerators.
The value 0 indicates a Request message. Bytes 9-12 are a 4-byte unsigned value that indicates the size of
the message (not counting the 12 header bytes). The value is encoded as big-endian or little-endian as
indicated by the least significant bit of the flags byte.
49
Request Message Format
request_id
This field is used by the client to associate the request with its response. The client sets the request_id to a
unique number when it sends the request. A Reply message also has a request_id field; when the server
sends the reply for a request, it returns the corresponding request_id to the client. In that way, the client can
have replies for more than one request outstanding at a time.
Упомянуть о важности ServiceContext, обещать привести пример с
BiDirGIOP.
response_expected
This field is a Boolean value that is set to true for a normal synchronous request, meaning that the client
requires a reply for the request. If the operation being invoked by the client is a oneway operation, the clientside run time can set this field to false (to indicate to the server that no reply is wanted) or to true to allow
the client to receive a system exception or a LOCATION_FORWARD reply (
operation
This field is a string that contains the name of the operation being invoked. If the client sends the request to
read or write an attribute, the operation name is_get_attribute_name or _set_attribute_name, respectively.
50
Reply Message Format
request_id
The request_id field returns the ID of the corresponding request to the client. The
client uses it to associate replies with requests. This allows the client to have several
replies outstanding simultaneously. The server need not send replies in the same order in
which it receives requests because some requests may take longer to complete than others.
reply_status
The reply_status field indicates the result of the request.
NO_EXCEPTION
This indicates that the request completed successfully.
USER_EXCEPTION
The request raised a user exception.
SYSTEM_EXCEPTION
The server-side ORB or the server-side application code raised a system exception.
LOCATION_FORWARD
This reply indicates that the request cannot be processed by this server, but the client
should try again at a different address.
Пример LOCATION_FORWARD
Каждый CORBA объект может быть пропингован, посредством специальной операции
_non_existent() – возвращает FALSE если объект «жив».
51
Ниже приводится пример обмена сообщениями GIOP когда клиентская сторона использует
«фиктивный» (на самом деле, - общеизвестный) адрес некоторой службы.
Нарисовать
Кл. <-> Серв.
-> Req id 4
<- Repl LOC._FORWARD id 4
->Req id 4
<- Reply No Exception id 4
Client -> _non_existent() ->Server
General Inter-ORB Protocol
Magic number: GIOP
Version: 1.0
Byte ordering: big-endian
Message type: Request
Message size: 60
General Inter-ORB Protocol Request
ServiceContextList
Sequence Length: 0
Request id: 4
Response expected: 1
Object Key length: 17
Object Key: 44656661756C745265706F7369746F7279 (DefaultRepository)
Operation length: 14
Request operation: _non_existent
Requesting Principal Length: 0
Server Reply
General Inter-ORB Protocol
Magic number: GIOP
Version: 1.0
Byte ordering: little-endian
Message type: Reply
Message size: 208
General Inter-ORB Protocol Reply
ServiceContextList
Sequence Length: 0
Request id: 4
Reply status: Location Forward (3)
IOR
String Length: 33
IOR::type_id: IDL:omg.org/CORBA/Repository:1.0
Sequence Length: 1
Profile ID: TAG_INTERNET_IOP (0)
Sequence Length: 144
Endianess: Little Endian (1)
IIOP Major Version: 1
IIOP Minor Version: 2
String Length: 15
IIOP::Profile_host: 83.149.249.206
IIOP::Profile_port: 30003
Sequence Length: 54
Object Key: ABACAB305F526F6F74504F4100496E746572666163655265...(RootPOA/RealImplementation… )
Sequence Length: 1
IIOP Component TAG: 1
Sequence Length: 44
component_data: ............ ...............................
Клиент повторяет запрос (с тем же ID) по указанному IOR. Причем Request ID – тот же 4.
GIOP использует CDR (Common data representation)
52
Strings and wide strings are encoded as an unsigned long (aligned on a 4-byte offset) that indicates the length of the string,
including its terminating NUL byte, followed by the bytes of the string, terminated by a NUL byte. For example, the string "Hello"
occupies 10 bytes. The first 4 bytes are an unsigned long with value 6, the next 5 bytes contain the characters Hello, and the final
byte contains an ASCII NUL byte. This means that an empty string occupies 5 bytes: 4 bytes containing a length of 1, followed by
a single NUL byte.
4 байта – длина строки unsigned long
‘H’ ‘e’ ‘l’ ‘l’ ‘o’
Заметьте, что в little/big-endian кодировке
содержание
NULL byte
Т.е. Hello занимает 4 + 5 + 1 = 10 байтов.
Аналогично хранятся sequence
Структуры
Structures are encoded as a sequence of structure members in the order in which they are defined in IDL.
Each structure member is aligned according to the rules in Table 13.1; padding bytes of undefined value
are inserted to maintain alignment. Consider the following structure:
struct CD {
char c;
double d;
};
This structure contains a character, which can occur anywhere in a byte stream, followed by a double value,
which must be aligned on an 8-byte boundary. Figure 13.1 shows how this structure would appear on the
wire, assuming it starts at the beginning of a byte stream.
1 байт – ‘c’
Заполнитель до 8 байтов
8 байт – на double (выровнено – по 8)
2-8
9-16
Заметьте, что если поменять местами описание полей в IDL – длина будет другой.
Общая длина Message Body может зависеть и от порядка декларации параметров операции
It is interesting to note that a structure of type CD does not always appear as a 16-byte value. Depending on
the other data that precedes the structure on the wire, the length of the structure may vary. For example,
consider the following operation, which accepts a string followed by a structure of type CD:
interface foo {
void op(in string s, in CD ds);
};
When a client marshals a request to invoke op, it sends all the in parameters end-to-end according to CDR
encoding rules. Assume for the moment that the parameters when sent inside the request begin at an 8-byte
offset and that the client sends the string "Hello" as the value of the parameter s. Figure 13.2 shows the
resulting encoding.
6 – длина «Hello»
Hello\0
‘c’
заполнитель
8 байт – на double (выровнено – по 8)
1-4
5-10
11
12-15
16-24
Теперь структура занимает меньше места (было – 16, теперь 14)
The encoding for the value "Hello" consumes 10 bytes: 4 bytes for the length and 6 bytes for the actual
string. The second parameter is the structure of type CD. Because the member c is of type char, it can be
53
aligned anywhere, so the value of c is encoded immediately following the string at byte offset 10. The d
member of the structure must be aligned on an 8-byte boundary, so c is followed by 5 bytes of padding,
followed by the 8 bytes required to hold the value of d
Пример использования GIOP ServiceContext в Bidirectional IIOP
As mentioned in Section 13.4, CORBA 2.3 added GIOP 1.2 and IIOP 1.2 to enable bidirectional
communication. This allows client and server to reverse roles without the need to open a separate connection
that may be blocked by a firewall. At the time of writing, the specification is undergoing changes, and
implementations are unlikely to appear before mid-1999, so we do not cover version 1.2 in detail in this
chapter. Here is a summary of the major changes.
GIOP 1.2 does not add new message types but adds extensions to most of the message headers and bodies.
These extensions support the additional information that must be exchanged for bidirectional
communication.
GIOP 1.2 adds a LOCATE_FORWARD_PERM reply status, which is intended to ease
object migration (see Section 14.5).
GIOP 1.2 tightens the alignment restrictions for a request body to make remarshaling after a
LOCATE_FORWARD reply more efficient.
IIOP 1.2 adds additional information to the service context to support bidirectional communication. It also
defines a policy that enables bidirectional communication only if both client and server agree to use it. This
policy allows administrators to disable bidirectional communication over insecure links and thereby prevent
clients from masquerading as someone else's call-back object. If bidirectional communication is disabled,
GIOP 1.2 uses a separate connection for callbacks.
Пример
module demo
{
module bidir
{
interface ClientCallback
{
void hello( in string message );
};
interface Server
{
void register_callback( in ClientCallback cc );
void callback_hello( in string message );
};
};
};
Сценарий для демонстрации BiDirGIOP.
Вначале – как это выглядит без использования BiDir
Процесс 1
Процесс 2
CallBack – сервер
Сервер-регистратор;
Клиент регистратора
Клиент CallBack
1. Передает IOR CB – серверу
регистратору
Принимает IOR и создает представителя CB
2.
Вызывает CB (вызов идет на тот порт, что слушает
POA 1)
54
Процесс 1
Процесс 2
CallBack – сервер
Сервер-регистратор;
Клиент регистратора
Клиент CallBack
1. Передает IOR CB – серверу регистратору
открыто сокетное соединение (H – host)
В BiDirServiceContext передает host:port,
S12={H1:SocketPort1;H2:POAPort2}
которые будут в IOR CallBack’ка
Принимает IOR и создает представителя CB. Сохраняет
открытым соединение H1:SocketP1
Записывает H1:POA_Port1 -> S12
2.
Вызывает CB, где указан адрес {H1:POAPort1}, но ORB
просматривает таблицу BiDir и использует для передачи данных
уже открытое соединение (вызов идет на порт SocketPort1)
General Inter-ORB Protocol
General Inter-ORB Protocol Request
Request id: 0
Response flags: SYNC_WITH_TARGET (3)
Reserved: 0 0 0
TargetAddress Discriminant: 0
KeyAddr (object key length): 34
KeyAddr (object key): root/BiDirPOA_Server/BiDirServerID
Operation length: 18
Request operation: register_callback
ServiceContextList
Sequence Length: 2
0000 0000 0000 0000 0000 0000 .... .... = VSCID: 0x00000000
.... .... .... .... .... .... 0000 0101 = SCID: 0x00000005
Service Context ID: BI_DIR_IIOP (5)
BI_DIR_IIOP
context_data: ............83.149.249.217...b (внутренний IP:60002)
struct ListenPoint {
//0f’8’’3’…’\NUL’00ea62 (BigEndian)
string host;
unsigned short port;
};
typedef sequence<ListenPoint> ListenPointList;
struct BiDirIIOPServiceContext {// BI_DIR_IIOP Service Context
ListenPointList listen_points;
};
Sequence Length: 12
Endianess: Big Endian (0)
0000 0000 0000 0000 0000 0000 .... .... = VSCID: 0x00000000
.... .... .... .... .... .... 0000 0001 = SCID: 0x00000001
Service Context ID: CodeSets (1)
CodeSets
char_data: 0x00010001
wchar_data: 0x00010109
Stub data (176 bytes) (передается IOR CallbackClient на хосте за NAT)
General Inter-ORB Protocol
General Inter-ORB Protocol Request
Request id: 2
Response flags: SYNC_WITH_TARGET (3)
Reserved: 0 0 0
TargetAddress Discriminant: 0
KeyAddr (object key length): 34
KeyAddr (object key): root/BiDirPOA_Server/BiDirServerID
Operation length: 15
Request operation: callback_hello
ServiceContextList
Sequence Length: 1
0000 0000 0000 0000 0000 0000 .... .... = VSCID: 0x00000000
.... .... .... .... .... .... 0000 0101 = SCID: 0x00000005
Service Context ID: BI_DIR_IIOP (5)
BI_DIR_IIOP
context_data: ............83.149.249.217...b
Stub data (18 bytes) (“Test string”)
55
Теперь «сервер» вызывает метод CallBack
General Inter-ORB Protocol
General Inter-ORB Protocol Request
Request id: 1
Response flags: SYNC_WITH_TARGET (3)
Reserved: 0 0 0
TargetAddress Discriminant: 0
KeyAddr (object key length): 34
KeyAddr (object key): root/BiDirPOA_Client/BiDirClientID
Operation length: 6
Request operation: hello
ServiceContextList
Sequence Length: 0
Stub data (18 bytes) (та же самая строка)
Прием BiDir IIOP есть пример решения задачи прозрачности местонахождения, т.к. основная часть кода (где реализован
прикладной сценарий) остается неизменной. Требуется лишь инициализировать транспорт ORB со специальными
опциями и политиками…
Не бог весть какой Бином Ньютона, однако это готовое решение.
CDR не предусматривает self-describing в самих данных.
Именно поэтому нужен IDL, стабы и скелетоны.
Для «полноценных» динамических вызовов нужна спец. служба ! Interface Repository
56
DII & DSI
module demo {
module dii {
interface server
{
void add(in long i, in long j, out long r );
};
};
};
На клиентской стороне
org.omg.CORBA.Object s = nc.resolve(name);
org.omg.CORBA.Request r_out = s._request("add");
r_out.add_in_arg().insert_long(3);
r_out.add_in_arg().insert_long(4);
org.omg.CORBA.Any out_arg = r_out.add_out_arg();
out_arg.type(orb.get_primitive_tc(org.omg.CORBA.TCKind.tk_long));
r_out.set_return_type(orb.get_primitive_tc(org.omg.CORBA.TCKind.tk_void));
r_out.invoke();
if (r_out.env().exception() != null) {
throw r_out.env().exception();
} else {
System.out.println("1: " + out_arg.extract_long());
}
На серверной
public void invoke(org.omg.CORBA.ServerRequest request) {
String op = request.operation();
if (op.equals("add")) {
57
package demo.events;
/**
* @authors Joerg v. Frantzius, Rainer Lischetzki, Gerald Brose 1997
*
* A simple demo for using the event channel as a push supplier of events.
*
*/
import
import
import
import
org.omg.CosEventChannelAdmin.*;
org.omg.CosEventComm.*;
org.omg.CosNaming.*;
org.omg.CORBA.Any;
class PushSupplierDemo extends PushSupplierPOA
{
public PushSupplierDemo( String[] args )
{
org.omg.CosEventChannelAdmin.EventChannel e = null;
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
try
{
org.omg.PortableServer.POA poa = org.omg.PortableServer.POAHelper.narrow
(orb.resolve_initial_references ("RootPOA"));
poa.the_POAManager().activate();
NamingContextExt nc = NamingContextExtHelper.narrow(
orb.resolve_initial_references("NameService"));
e = EventChannelHelper.narrow(nc.resolve(nc.to_name("eventchannel.example")));
}
catch(Exception ex)
{
ex.printStackTrace();
}
SupplierAdmin supplierAdmin = e.for_suppliers();
ProxyPushConsumer proxyPushConsumer = supplierAdmin.obtain_push_consumer();
try
{
proxyPushConsumer.connect_push_supplier( _this(orb) );
}
catch (org.omg.CosEventChannelAdmin.AlreadyConnected ex)
{
ex.printStackTrace();
}
for(int i=0; i < 30; i++)
{
try
{
Any any = orb.create_any();
any.insert_string("Test the channel!" + i);
System.out.println("Pushing event # " + (i) );
proxyPushConsumer.push( any );
}
catch(Disconnected d)
{
d.printStackTrace();
}
}
proxyPushConsumer.disconnect_push_consumer();
}
public void disconnect_push_supplier ()
{
System.out.println ("Supplier disconnected");
}
public static void main(String[] args)
{
PushSupplierDemo demo = new PushSupplierDemo( args );
}
}
package demo.events;
58
/**
* @authors Joerg v. Frantzius, Rainer Lischetzki, Gerald Brose 1997
* * A simple demo for using the event channel as a push consumer
* of events. This consumer unregisters and quits after receiving
* 5 events.
* */
import org.omg.CosEventChannelAdmin.*;
import org.omg.CosEventComm.*;
import org.omg.CosNaming.*;
public class PushConsumerDemo implements PushConsumerOperations
{
private short count = 0;
private ProxyPushSupplier myPps = null;
private int limit = 25;
static org.omg.CORBA.ORB orb = null;
public PushConsumerDemo( ProxyPushSupplier _pps ) {
myPps = _pps;
}
public void disconnect_push_consumer() {
System.out.println("Consumer disconnected.");
}
static public void main (String[] args) {
EventChannel ecs = null;
ConsumerAdmin ca = null;
PushConsumer pushConsumer = null;
ProxyPushSupplier pps = null;
try {
orb = org.omg.CORBA.ORB.init(args, null);
NamingContextExt nc =
NamingContextExtHelper.narrow(
orb.resolve_initial_references("NameService"));
ecs = EventChannelHelper.narrow(nc.resolve(
nc.to_name("eventchannel.example")));
}
catch(Exception e) {
e.printStackTrace();
}
ca = ecs.for_consumers();
pps = ca.obtain_push_supplier();
try {
org.omg.PortableServer.POA poa =org.omg.PortableServer.POAHelper.narrow(
orb.resolve_initial_references("RootPOA"));
poa.the_POAManager().activate();
PushConsumerPOATie pt = new PushConsumerPOATie( new PushConsumerDemo( pps ));
pt._this_object(orb);
pushConsumer = PushConsumerHelper.narrow(poa.servant_to_reference(pt) );
pps.connect_push_consumer( pushConsumer );
System.out.println("PushConsumerImpl registered.");
orb.run();
}
catch(Exception e) {
e.printStackTrace();
}
System.out.println("Quit.");
}
public synchronized void push(org.omg.CORBA.Any data)
throws org.omg.CosEventComm.Disconnected {
count++;
System.out.println("event " + count + " : " + data.extract_string());
if( count >= limit ) {
System.out.println("unregister");
myPps.disconnect_push_supplier();
// System.exit(0);
orb.shutdown(false);
}
}
}
59
2.8 Репозиторий типов (Interface Repository)
Фактически, представляет собой службу CORBA, т.е. специальный серверный процесс, позволяющий хранить
(пополнять, модифицировать) список типов данных и типов интерфейсов объектов РВС.
Рис.12. Пример отображения содержимого Репозитория Интерфейсов (IR браузер, т.н. Mao’s CORBA Brawser)
60
2.9 Message Oriented M/w (Event / Notification Service)
Начну с примера «распределенного» суммирования.
Распараллеливание работы удаленных вычислителей достигается за счет более совершенной архитектуры.
Рассмотрим задачу вычисления суммы N чисел {x1, x2, x3, …, xN} . На обычном «однопроцессорном»
компьютере эта задача требует выполнения N-1 операций сложения.
// x – определен выше как массив чисел float[] x; x.length = N
float res;
for (int i = 0, res = 0.; i < N; i++)
res += x[i];
Предположим, что в нашем распоряжении имеется достаточное количество «сумматоров», способных
выполнять операцию сложения двух чисел, и доступных для «удаленного» вызова таких операций.
Процедура вычисления суммы в таком случае может быть записана следующим образом
AMI вызов
Создание хранителя
CB
Хранитель
(Holder) для
каждого
вызова
public static float DistrSum (float[] x, CalcOperations[] calcs) {
int N = x.length; // Number of summands
ResHolder[] xHolder;
while (N > 1)
{
int n;
xHolder = new ResHolder[N/2];
for (n = 0; n < N/2; n++)
{ // храним промежуточные значения сумм в том же массиве
// x[n] = calcs[n].add(x[2*n], x[2*n+1]); // Неэффективный синхронный вызов
xHolder[n] = calcs[n].ami_add(x[2*n], x[2*n+1]); // асинхронный вызов функции add
}
// Цикл синхронизации (требует асинхронного вызова команд калькулятора)
for (n = 0; n < N/2; n++)
x[n] = xHolder[n].getValue(); // Блокирующий вызов, НО локально. Задержка <<
// Или
//int k = -1;
//while (k < N/2) {
// for (n = 0; n < N/2; n++)
// if (xHolder[n].poll()) {
//
x[n] = xHolder[n].getValue();
k++;
//}
//};
if ( 2*n < N)
{// N – нечетное вида 2*n + 1
// x[n] = x[N-1];
x[n]
= xHolder[N-1].getValue();
n++;
}
N = n;
}
return x[0];
}
// …
public interface CalcOperations
{
float add(int a, int b);
float sub(int a, int b);
float mult(int a, int b);
float div(int a, int b) throws DivisionByZero;
}
61
Распределенное суммирование
Рассмотрим задачу вычисления суммы N чисел {x1, x2, x3, …, xN} . На обычном «однопроцессорном»
компьютере эта задача требует выполнения N-1 операций сложения.
// x – определен выше как массив чисел float[] x; x.length = N
float res;
for (int i = 0, res = 0.; i < N; i++)
res += x[i];
Предположим, что в нашем распоряжении имеется достаточное количество «сумматоров», способных
выполнять операцию сложения двух чисел, и доступных для «удаленного» вызова таких операций.
Процедура вычисления суммы в таком случае может быть записана следующим образом
public static float DistrSum (float[] x, CalcOperations[] calcs) {
int N = x.length; // Number of summands
// ResHolder[] xHolder;
while (N > 1)
{
int n;
// xHolder = new ResHolder[N/2];
for (n = 0; n < N/2; n++)
{ // храним промежуточные значения сумм в том же массиве
x[n] = calcs[n].add(x[2*n], x[2*n+1]);
// xHolder[n] = calcs[n].ami_add(x[2*n], x[2*n+1]);
}
// Цикл синхронизации
// for (n = 0; n < N/2; n++)
// x[n] = xHolder[n].getValue();
// Или
//int k = -1;
//while (k < N/2) {
// for (n = 0; n < N/2; n++)
// if (xHolder[n].poll()) {
//
x[n] = xHolder[n].getValue();
k++;
//}
//};
if ( 2*n < N)
{// N – нечетное вида 2*n + 1
x[n] = x[N-1];
// x[n]
= xHolder[N-1].getValue();
n++;
}
N = n;
}
return x[0];
}
// …
public interface CalcOperations
{
float add(int a, int b);
float sub(int a, int b);
float mult(int a, int b);
float div(int a, int b) throws DivisionByZero;
}
Вернуться к определению (процессы, на хостах, соединенных сетью, ППО, компонентный подход к
проектированию, координированная обработка данных).
62
Общим для всех перечисленных архитектур является то, что они представляют собой абстрактную модель
распределенных вычислений, скрывающую особенности сетевого окружения от прикладных программ.
Для этих моделей характены:

компонентный подход к проектированию и реализации (программированию) системы, в основе которого лежит
объектная технология программирования и четкое разделение интерфейсов объектов (абстрактных наборов
связанных методов и свойств, не зависящих от выбора конкретного языка программирования) и их реализаций;

наличие специального связующего ПО (middleware), связывающего распределенные компоненты системы в
единое целое, что является обобщением классической «клиент-серверной» архитектуры;

интероперабельность, т.е. обеспечение взаимодействия компонентов, реализованных на разных языках
(например, C++ и Java) и функционирующих на различных платформах (Windows, Unix, Linux и т.д.), даже,
возможно, в неоднородных компьютерных сетях;

многоразовость, т.е. возможность использования готового программного компонента в разных приложениях без
необходимости внесения каких-либо изменений.
Типовые элементы распределенной системы
Завершая общее устройство РС.
Необходимо сказать о наличии стандартных служб ППО.
Кроме того, часть СПО может присутствовать в форме специальных служб, запущенных на серверах - узлах сетей
различного уровня. При этом функциональные возможности этих служб представлены специальными сервисами,
реализующими стандартные (описанные в спецификациях СПО) интерфейсы. Доступ к этим стандартным сервисам из
клиентских фрагментов кода происходит точно так же, как и к любым другим сервисам - через соответствующих
представителей интерфейсов.
63
RPCЛекция 2
Эволюция DCS
Лекция 2
Комментарии к рисунку
ONC
Open Network Computing [Sun]
XDR
eXternal Data Representation
XDR is an implementation of the presentation layer in the OSI model. XDR allows data to be wrapped in an
architecture independent matter so data can be transferred between heterogenous computer systems. Converting from
the local representation to XDR is called encoding. Converting from XDR to the local representation is called
decoding. XDR is implemented as a software library of functions that is portable between different operating systems
and is also independent of the transport layer. Sun RPC uses XDR.
XDR data types : { boolean, char, short, int, long, float, double, string,
enumeration, structure, union,
fixed length array, variable length array,
opaque data}
Процессы, RPC (удаленный вызов процедур)
Процесс – поток/единица выполнения набора команд под управлением OС. Процессы рождаются и «умирают»
по командам пользователей или OC. TaskManager в Windows; команда ps в *nix.
Процессы могут быть многопоточными (multi-threaded), но и в этом случае существует некоторый главный
(порождающий) поток. Современный GUI – кольца обработчиков событий, вызванных действиями
пользователя и изменениями состояния внутренних переменных процесса.
Процессы <> Компоненты. Когда программа запущена – синонимы. Пока нет – компоненты, это набор файлов
– результатов компиляции
W - *.exe, *.dll
64
*nix – исп., *.so
Java - *.class
65
Вызов процедуры (функции) внутри одного процесса (монолитное приложение)
Локальный вызов функции
Процесс #0
Процесс #1
Процесс #2
// Java
…
class Calc
Calc calc = new Calc();
Участок кода, откуда
// Calc calc = new Calc();
int x; int y; int res;
вызывается функция.
???
…// x = …; y = …
участок кода
int x; int y; int res;
…// x = …; y = …
…
// res = calc.add(x, y)
class Calc {
???
…
Участок кода, где
int add(int a, int b) {
функция
}
return a+b;
«Клиентский»
res = calc.add(x, y)
return a+b;
int add(int a, int b) {
}
реализована.
«Серверный»
участок кода
Оба участка в одном
процессе
Современное ППО решает эту проблему в условиях, когда:
процессы ## 1 и 2 выполняются на разных машинах, работающих под управлением разных ОС.
соотв. программные компоненты были реализованы на разных языках
66
Вернуться к определению (процессы, на хостах, соединенных сетью, ППО, компонентный подход к
проектированию, координированная обработка данных).
Общим для всех перечисленных архитектур является то, что они представляют собой абстрактную модель
распределенных вычислений, скрывающую особенности сетевого окружения от прикладных программ.
Для этих моделей характены:

компонентный подход к проектированию и реализации (программированию) системы, в основе которого лежит
объектная технология программирования и четкое разделение интерфейсов объектов (абстрактных наборов
связанных методов и свойств, не зависящих от выбора конкретного языка программирования) и их реализаций;

наличие специального связующего ПО (middleware), связывающего распределенные компоненты системы в
единое целое, что является обобщением классической «клиент-серверной» архитектуры;

интероперабельность, т.е. обеспечение взаимодействия компонентов, реализованных на разных языках
(например, C++ и Java) и функционирующих на различных платформах (Windows, Unix, Linux и т.д.), даже,
возможно, в неоднородных компьютерных сетях;

многоразовость, т.е. возможность использования готового программного компонента в разных приложениях без
необходимости внесения каких-либо изменений.
67
CORBA
CORBA (Common Object Request Broker Architecture) является спецификацией создания распределенных
программных систем, развиваемой консорциумом OMG (Object Management Group) - некоммерческой
организацией, включающей в настоящее время более 800 компа-ний. Лидерами OMG являются фирмы Oracle,
IBM, Sun. Цель OMG - достижение «быстрого роста технологии объектов» через развитие архитектуры
управления объектами OMА (Object Management Architecture). OMА является концептуальным базисом, на
котором основаны спецификации OMG.
CORBA развивается как система открытых стандартов с 1989г. Первый итоговый доку-мент OMG был
опубликован в 1991г. В 1992г. вышел его переработанный вариант, а в 1994г. появилась версия CORBA 2.0. В
настоящее время используется CORBA 2.3-5. Ожидается по-явление версии 3.0.
На основе CORBA развивается компонентная модель объектов CCM (CORBA Component Model). Целью этого
проекта является стандаризация процессов разработки распределенных систем, специализированных по
отраслевому признаку - системы управления производством, финансами и т.п.
Активно развивается до сих пор.
68
CORBA
CORBA (Common Object Request Broker Architecture) является спецификацией создания распределенных
программных систем, развиваемой консорциумом OMG (Object Management Group) - некоммерческой
организацией, включающей в настоящее время более 800 компа-ний. Лидерами OMG являются фирмы Oracle,
IBM, Sun. Цель OMG - достижение «быстрого роста технологии объектов» через развитие архитектуры
управления объектами OMА (Object Management Architecture). OMА является концептуальным базисом, на
котором основаны спецификации OMG.
CORBA развивается как система открытых стандартов с 1989г. Первый итоговый доку-мент OMG был
опубликован в 1991г. В 1992г. вышел его переработанный вариант, а в 1994г. появилась версия CORBA 2.0. В
настоящее время используется CORBA 2.3-5. Ожидается по-явление версии 3.0.
На основе CORBA развивается компонентная модель объектов CCM (CORBA Component Model). Целью этого
проекта является стандаризация процессов разработки распределенных систем, специализированных по
отраслевому признаку - системы управления производством, финансами и т.п.
Активно развивается до сих пор.
HLA
«Распределенная» революция в программировании началась в 80-е годы с проекта SIMNET (Simulation
Network) агентства ARPA (Advanced Research Project Agency) американского Министерства обороны. Проект
был нацелен на создание распределенных имитационных комплексов в военном деле.
Необходимость обеспечения надежных взаимодействий между удаленными компонентами таких систем
привела в 90-е годы к двум основным типам архитектуры распределенных имитационных моделей – ALSP
(Aggregate Level Simulation Protocol) и DIS (Distributed Inter-active Simulation).
ALSP предназначался для моделирования взаимодействий крупных воинских подразделений и не предполагал
использования реального времени.
В отличие от него DIS (ставший впоследствии стандартом IEEE 1278) ориентировался на имитацию
взаимодействий отдельных единиц боевой техники (Vehicle level) в реальном времени.
В 1996 году Министерство обороны США инициировало разработку новой высокоуровневой архитектуры
распределенного моделирования - HLA (High Level Architecture), обеспечившей интероперабельность
имитационных моделей всех уровней между собой и с системами C4I (Command, Control, Communications,
Computers, Intelligеnce), равно как поддержку многоразового использования компонент этих моделей.
Высокоуровневая архитектура HLA (High Level Architecture) для распределенного моделирования была
разработана в интересах и при финансовой поддержке Министерства обороны США в целях обеспечения
интероперабельности всех типов моделей и поддержки их многоразового использования.
Хотя создание HLA было проинициировано Министерством обороны США, с самого начала и до сих пор эта
архитектура является открытым стандартом, который развивается и поддерживается подразделением DMSO
(Defense Modeling & Simulation Office) Министерства Обороны США.
69
HLA быстро стала стандартом «де факто» для тренажеров и симуляторов в военных приложениях, что было
обусловлено жесткими требованиями совместимости с HLA тренажерами, разрабатываемыми и
используемыми Министерством обороны США. В настоящее время HLA находит все большее применение и в
гражданской сфере при разработке симуляторов и тренажеров для тренировки персонала сложных
технических систем в авиации, космонавтике, транспорте и т.п., становясь промышленным стандартом и в
этой области.
В сентябре 2000 года процесс создания HLA был отмечен важным событием: версия 1.3 была принята в
качестве стандарта IEEE 1516. Активно используется в промышленных симуляторах, MATLAB HLA Toolbox.
Процессы, иинтерфейсы, и проч потроха.
Cut&Paste как пример различных реализаций стандартизованного интерфейса ! Буфер обмена, как аналог
«ППО».
Рисунок «круг» (OS, ППО) как среда общения фрагментов одного процесса или нескольких процессов.
Java. Драматическая борьба того «как надо делать программные системы» с «как бы это побыстрее продать».
в 1988 году фирма Sun провозгласила: "Сеть - это компьютер". имелась в виду сеть, на которой работала
система Билла Джоя Network File System (NFS), включавшая в себя TCP/IP.
А 6 лет назад, в 1990 году, Билл Джой был известен, как один из величайших умов в программировании, но
постоянно проигрывающий Microsoft. На конференции PC Forum Эстер Дайсон в 1990 году он говорил, атакуя
Microsoft: "Мы добавляем все больше возможностей к старым системам и сложность растет
экспоненциально. У меня десять различных пакетов, и они взаимодействуют 10 х 10 различными
способами. Выскакивают всевозможные сюрпризы, а поскольку все эти пакеты не работают совместно,
мои возможности возрастают всего лишь аддитивно. У меня есть такая возможность и есть этакая, а в
комбинации они не работают. А я хочу видеть систему, где сложность возрастает линейно, а мощность экспоненциально". Гейтс набирал высоту, Билл Джой, похоже, уходил в тень и утрачивал влияние. В 1990
году Джой удалился в лесистые высоты Аспена в Колорадо, выполняя перспективные исследования для Sun.
Его разговоры о небольших программах и управляемых бытовых устройствах не имели, казалось, отношения к
работе компании.
Основная проблема в том, что массового (типичного) потребителя не интересуют проблемы массового
разработчика. Да и потребителей в тысячи раз больше. Поэтому «неправильно сделанный» (плохо
расширяемый, не переносимый, и т.д.) продукт, функциональность которого покрывает 90% потребностей
90% пользователей будет иметь успех. (Правило 80/20, 80% MS Office, используют 20% возможностей).
Тем не менее, Java указывает ВЕРНОЕ направление развития, что фактически подтвердила MS, переводя весь
свой зоопарк на .NET, и С#.
70
Немного подробнее о различных стандартах ППО.
CORBA, DCOM, EJB.
Web-сервисы. GRID-сервисы. .NET.
Жизненный цикл объектов.
Разработка
Проектирование (интерфейсов). Сравнить IDL и WSDL.
Принятие решения о выборе между статическими или динамическими режимами вызовов методов (на
клиентской стороне) и обработки вызовов на серверной стороне (универсальность<>производительности,
зависит от возможностей ППО).
Генерация стандартизованных стабов/скелетонов (исходных кодов на выбранных языках высокого уровня);
специальные средства (предкомпиляторы).
Реализация серверных фрагментов.
Регистрация типов интерфейсов
Функционирование
Серверная часть
Запуск «серверного» процесса (с черными кружочками).
Активация удаленных объектов и, возможно, регистрация их на специальной службе.
Обработка заявок.
Остановка, возможно, с сохранением состояния.
Клиентская часть.
Обеспечение клиентской программы «адресом» нужного ей объекта (объектная ссылка); в виде файла или
«имени» (идентификатора) на службе регистрации.
Вызов удаленного объекта.
71
3 Этапы разработки РВС (CORBA)
Существует большой выбор комплектов разработчика систем на базе CORBA от
различных поставщиков и ориентированных на разные языки программирования. Но
везде присутствуют следующие необходимые элементы:

предкомпилятор языка IDL;

набор файлов на языке IDL, содержащих описание стандартных интерфейсов и
служб (согласно стандартам OMG);

набор готовых компонентов - реализация ядра ORB и некоторого подмножества
стандартных служб CORBA (в минимальной конфигурации - служба
наименований и репозиторий интерфейсов).
5. Проектирование интерфейсов на языке IDL;
6. Использование предкомпилятора IDL;
7. Реализация серванта и клиентской части приложения на уровне исходных кодов
8. Компиляция исходных кодов
3.1 Проектирование интерфейсов на языке IDL.
Например, если мы хотим создать сервис, играющий роль сумматора, то описание
соответствующего интерфейса на языке IDL может выглядеть следующим образом:
72
module Our_System {
interface Summator {
attribute string name;
long getSum();
long addValue( in long increment );
};
};
Рис.13. Пример
описания интерфейса на языке IDL.
73
Интерфейс на Summator имеет один текстовый атрибут name, который мы будем
интерпретировать как «имя» объекта, и два метода:
1. getSum() - метод без параметров возвращающий текущее значение счетчика в
виде целого числа;
2. addValue( in long increment ) - метод с одним передаваемым (на это
указывает ключевой слово in ) целочисленным параметром (возможно отрицательным), который следует прибавить к текущему значению счетчика;
метод возвращает новое значение счетчика.
Следует сказать, что отличие атрибута от метода достаточно условно и, как мы
увидим, на уровне реализации практически ничем не отличается.
1.1.1. Использование предкомпилятора IDL
Обязательным элементом любого комплекта разработчика является специальная
программа, т.н. предкомпилятор с языка IDL.
Назначение этой утилиты - по имеющимся файлам IDL сгенерировать стандартные
фрагменты кода для стабов и скелетонов на соответствующем языке
программирования.
Например, если воспользоваться JavaIDL - простейшим комплектом разработки
CORBA приложений на языке Java, то следует отдать команду
idlj -fserver -fclient Sum.idl,
где Sum.idl - файл, содержащий текст, приведенный на Рис.13.
В результате будут созданы несколько файлов на языке Java, назначение которых
комментируется в следующей таблице:
74
В каком фрагменте кода
Имя файла (все с
расширением .java)
Summator
Назначение
понадобится
серверный клиентский
Базовый класс для
объектов типа
x
x
x
x
"сумматор".
SummatorOperations
Абстрактный класс (в Java
- типа interface)
содержащий отображение
методов и атрибутов
интерфейса на язык Java,
но без реализации.
_SummatorImplBase
Фрагмент кода,
содержащий скелетон
x
интерфейса.
_SummatorStub
Фрагмент кода,
содержащий
представитель (стаб)
x
интерфейса.
SummatorHelper
Специальный
вспомогательный класс,
содержащий набор
методов, необходимых
клиентской стороне
x
(обычно - для
манипуляций с
объектными ссылками)
Рис. 1.
Результат работы предкомпилятора JavaIDL
75
Чтобы понять каким образом произошло "языковое связывание" в
данном случае, приведем содержание файла
SummatorOperations.java:
76
SummatorOperations.java:
package Our_System;
public interface SummatorOperations
{
String name ();
void name (String newName);
int getSum ();
int addValue (int increment);
}
Рис. 2.
Пример отображения интерфейса IDL на язык Java.
Таким образом (см. Рис.13):

имя модуля превратилось в название пакета Java;

наличие атрибута name привело к появлению двух методов - для чтения
текущего значения атрибута (String name()) и для задания нового значения (void
name (String newName));

методы getSum и addValue превратились в "обычные" методы, причем IDL-тип
данных long преобразовался в тип int.
Предкомпилятор позаботился о том, чтобы установить правильные взаимосвязи
между всеми вышеперечисленными файлами, а также "подключил" стандартные
классы, реализующие ядро JavaIDL ORB и соответстветствующий Object Adapter.
Достаточно привести определения этих классов, присутствующие в каждом файле:
класс (интерфейс) CORBA-объекта Summator в файле Summator.java:
77
public interface Summator extends SummatorOperations,
org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity
класс _SummatorImplBase скелетона в файле _SummatorImplBase.java:
public abstract class _SummatorImplBase extends
org.omg.CORBA.portable.ObjectImpl implements
Our_System.Summator,
org.omg.CORBA.portable.InvokeHandler
класс _SummatorStub стаба в файле _SummatorStub.java:
public class _SummatorStub extends
org.omg.CORBA.portable.ObjectImpl implements
Our_System.Summator
78
1.1.2. Реализация серванта и клиентской части приложения на
уровне исходных кодов
Программист приступает к написанию серверной и клиентской программы,
используя в качестве готовых фрагментов кода перечисленные выше файлы.
Для реализации серванта можно создать класс SummatorServant, наследуя
готовый класс _SummatorImplBase:
public class SummatorServant extends _SummatorImplBase,
в котором придется определить поведение всех функций, объявленных в интерфейсе
SummatorOperations (см. Рис. 2).
Для создания экземпляра CORBA-объекта типа Summator, (а фактически - для
создания реализации CORBA-объекта) достаточно объявить переменную этого класса
(в языке Java это будет объектная ссылка) и воспользоваться оператором new для
создания экземпляра объекта заданного типа (стандартная схема создания экземпляров
объектов в Java):
Our_System.Summator theFirstCounter = new SummatorServant();
При необходимости можно создать несколько экземпляров таких объектов.
Мы пропустили несколько технических деталей: подключение к ядру ORB;
активация и подключение к Объектному Адаптеру; регистрация на нем созданного
объекта; "опубликование" его объектной ссылки, чтобы сделать объект доступным для
клиентских частей системы.
79
В клиентской программе, необходимо предусмотреть механизм получения
объектной ссылки на нужный экземпляр CORBA-объекта. Для этого удобнее всего
воспользоваться CORBA-службой Именований (Naming Service), о которой мы
поговорим позднее.
Когда объектная ссылка получена (в Java она является ссылкой на объект класса
org.omg.CORBA.Object), ее необходимо преобразовать к типу Summator. Для
этого и нужен класс SummatorHelper (см. Рис. 1). Соответствующие фрагменты
кода имеют вид:
org.omg.CORBA.Object ior; //ссылка на нетипизированный объект
// присваивание нужного значения ссылке ior
...
//Объявление переменной типа Summator и приведение ior
//к нужному типу при помощи специального метода narrow
//класса Helper
Our_System.Summator theProxyForTheFirstCounter =
Our_System.SummatorHelper.narrow (ior)
Рис.14. Простейший
пример фрагмента клиентского кода
Теперь можно использовать объект theProxyForTheFirstCounter для вызова
методов объекта theFirstCounter из серверной части кода.
80
1.1.3. Компиляция исходных кодов
На этом заключительном этапе необходимо откомпилировать
исходные тексты всех частей распределенного приложения, с
использованием результатов работы предкомпилятора (см. 1.1.1).
Результат компиляции естественно зависит от используемого языка.
Например, в при использовании Java, распределенное приложение будет
представлять собой набор файлов *.class (возможно - упакованных в
архивы *.jar). И для их запуска нужно использовать среду исполнения
Java. Если часть распределенного приложения представляет собой
Java-апплет, то для запуска понадобится браузер.
В случае использования языка C (C++) результатом работы этого этапа
будут либо исполняемые файлы *.exe, либо библиотеки динамической
компиляции *.dll (на платформе Microsoft) или *.so (на платформе
Unix, Linux).
81
Клиентский фрагмент
процесса
Серверный фрагмент
процесса
Cлужбы СПО
Cлужбы СПО
Cлужбы СПО
Смешанный фрагмент
процесса
Общий вид распределенной системы с использованием стандартных служб.
82
Стандартные службы CORBA
Название службы
Краткая характеристика
Наиболее распространенная служба, позволяющая давать имена
Naming Service (Служба
CORBA-объектам и создавать иерархическое доменное пространство
именования)
имен. Она предназначена для поиска объектов (получения объектной
ссылки) по их именам.
Одна из самых первых служб. Позволяет объектам "опубликовать"
сервисы, которые они предоставляют и зарегестрировать их в
Trading Object Service
(Объектный трейдер)
репозиторях этой службы. Предназначена для поиска объектов
(получения объектной ссылки), основываясь на опубликованных ими
сервисах.
Результат инициативы Sybase, IBM, SunSoft и Taligent - основных
Query Service (Сервис
разработчиков систем управления объектными базами данных. Позволяет
запросов)
находить объекты, удовлетворяющие определенным критериям.
Использует специальный язык запросов типа SQL.
Collections Service (Сервис
Позволяет управлять группами объектов, объединяя их в контейнеры:
контейнеров объектов)
очереди, списки, массивы, деревья и т.д.
Relationship Service
Позволяет устанавливать и управлять отношениями между объектами.
(Сервис сообщений)
Например, владения, содержания (включения), ссылки.
Помогает управлять созданием, копированием, перемещением и
Life Cycle Service (Сервис
жизненного цикла объекта)
удалением объектов. В случае связанных между собой объектов
использует интерфейсы Relationship Service.
Помогает синхронизировать время в распределенных системах.
Time Service (Сервис
Необходим в задачах "реального времени". Использует стандарт UTC
времени)
(Universal Time Coordinated) и совместим с существующим системами,
например, X/Open DCE Time Service
Представляет собой пример MOM (Message Oriented Middleware)
Event Service (Сервис
событий)
Позволяет организовать взаимодействие компонентов распределенной
системы посредством асинхронного обмена сообщениями.
Расширяет Event Service, добавляя новые возможности. Например,
Notification Service
(Расширенный сервис
событий)
поддержку "типизированных" событий, имеющих внутреннюю
структуру; фильтрацию рассылаемых сообщений и возможность
управлять этими фильтрами.
83
Название службы
Краткая характеристика
Позволяет множеству распределенных объектов взаимодействовать в
Object Transaction Service
(OTS) (Сервис объектных
транзакций)
рамках "неделимых транзакций", даже при наличии серьезных
аппаратных или программных сбоев. Чрезвычайно полезен для работы с
базами данных. Поддерживает "вложенные" транзакции.
Concurrency Service (Сервис
Позволяет объектам координировать обращения к совместно
контроля совместного
используемым ресурсам посредством механизма блокировок.
доступа)
Предназначена для сохранения и восстановления состояния объекта, в
Persistent Object Service
(Сервис долговременного
хранения)
ситуации временного отключения серверного процесса. Появился по
инициативе IBM и SunSoft. Существующие реализации тесно связаны с
реляционными базами данных.
Принцип работы напоминает механизм сериализации (serialization)
Externalization Service
(Сервис внешнего
представления)
объектов в языке Java, когда текущее состояние "бинарное" объекта
записывается в потоковый файл или, наоборот, восстанавливается из
файла.
Кроме этого, крупные фирмы-разработчики постоянно предлагают свои специализированные
службы, например Telecom Log Service.
Назначение всех этих служб - взять на себя выполнение многих важных типовых задач,
возникающих в процессе функционирования распределенных систем.
84
Event & Notification Services
Event Service
Event Channel
Consumer#1
ConsumerAdmin
Proxy Push
Supplier#1
Consumer#N
SupplierAdmin
Proxy Push
Consumer
Supplier
Proxy Push
Supplier#N
Направление передачи данных
Рис.15. Схема
работы CORBA Event Service
85
- The OrbZone - http://www.orbzone.org What is the difference between the CORBA Notification Service and the CORBA Event Service?
Posted By sylvia On 14th November 2005 @ 16:02 In Recent Articles | No Comments
The Notification Service can be considered to be a mature extension of the Event Service. The Event Service provided a model to
support decoupled communication, it was and is quite simplistic. It provides two models for supplying events, push and pull, and
the event data can either be typed or untyped. The event server itself provides no quality of service or persistence.
So what makes the Notification Service a more mature version of this?
The Notification Service could be looked upon as a much more powerful version of the Event Service. It keeps everything that the
Event Service has, but provides many additional and powerful features which enable you to implement sophisticated, intelligent
event-based communication.
As well as typed and untyped data events, there is also the new native "structured" event. This allows the transmission of a welldefined data structure in addition to the untyped Any. Due to the well-defined message structure extra information can be
associated with the event such as filtering and quality of service (QoS) details.
The Notification Service supports content based filtering on event data. Consumers can indicate what types of events they want to
receive by providing a filter constraint. Filter objects can be associated with each proxy and/or with the administration object.
Filtering is defined using an extension of the Trading constraint language.
The Notification Service introduces quality of service (QoS). This allows QoS to be assigned at different levels of granularity. For
example, QoS can be assigned on an event level using the structured event, or QoS can be assigned on a notification channel basis.
QoS properties such as reliability and priority can be used to indicate the delivery characteristics of events.
Notification channel persistence can be obtained using the EventReliability and ConnectionReliability QoS. If these properties are
set to persistent then the Notification channel will store all event information and all connection information. On a restart, the
channel will use this information to restore itself to its previous consistent state.
Consumers can use the mapping filter to assign priorities to events. Depending on the QoS OrderPolicy this may affect the order in
which events are delivered to the consumer.
Using the NotifyPublish interface it is possible to prevent unwanted events being put on the network. Suppliers can determine
what types of events are being listened on. If no consumers are interested in receiving a particular event type then the supplier will
not send the event to notification channel. New consumers can also use the NotifyPublish interface to find out which types of
events are currently available.
From The OrbZone: http://www.orbzone.org URL to article: http://www.orbzone.org/?p=85
86
Структура "сообщения" Notification Service
Фильтры в Notification Service
87
Получение ссылки через Implementation Repository (Orbacus)
Автоматический запуск серверных процессов посредством
88
Implementation Repository (Orbacus)
"Домены" серверов IMR
Каждый IMR управляет своим доменом "хостов"
Web-сервисы
89
Пример архитектуры одной из систем на основе Web-сервисов (WASP Architecture)
90
Oracle snaps up Collaxa
By Martin LaMonica
Oracle on Tuesday (~June 29, 2004) announced the acquisition of Collaxa and plans to incorporate the company's business
process automation software into Oracle's Java server software line.
Privately held Collaxa, which was founded in 2000, sells a business process management "engine," or software that collects
data from different applications to complete a particular business process, such as handling insurance claims. Collaxa was one
of the first companies to build its product around the Business Process Execution Language (BPEL), a Web services
specification under development. BPEL is designed to be an XML-based industry standard for business process management.
Thomas Kurian, Oracle's senior vice president for Oracle Application Server and application development tools, is expected to
announce the Collaxa deal at a keynote speech Tuesday afternoon at the JavaOne conference in San Francisco. Kurian also
plans to say that Oracle will release MacOS X versions of its Oracle Application Server 10G and JDeveloper Java
programming tools this fall.
Oracle has already renamed the Collaxa software Oracle BPEL Process Manager and has made it available for download for
free evaluation. It can be purchased as an add-on option to Oracle Application Server Enterprise Edition for $10,000 or as a
standalone product for $30,000. The BPEL Process Manager software can run on any Java 2 Enterprise Edition (J2EE)
application server.
The field of business process management has drawn increasing attention from large companies, such as Microsoft, IBM,
Oracle and BEA Systems, as well as dozens of specialized start-up companies.
Analysts say process workflow tools that use Web services are a central component to creating a service-oriented architecture,
a modular system design for exhanging data between systems cost-effectively and reusing software components across many
applications.
Oracle said the software will fill out its Java server line and provide tools for more rapidly building applications that automate
business processes.
"Oracle made this acquisition to complete our services oriented architecture and integration technology stack," said Cheng.
"We already have the infrastructure from our core application server based on Java. This adds a piece for orchestrating Web
services."
On top of running business process workflow applications, the BPEL Process Manager software provides so-called business
activity monitoring tools to report on the progress of a process that is under way. The software also includes "adapters" that
transport data between packaged applications, such as SAP's R/3 and Siebel, Oracle said.
91
Лекция ##
Web-сервисы и связанные с этим тенденции развития технологий РВС
До сих пор обсуждались CORBA, COM – являющиеся развитием ОО модели программирования
Та группа технологий, что обычно подразумевается под термином WS, основана на другой модели
программирования.
SOA - Service Oriented Architecture. Я считаю термин «сервис» неудачным, поскольку он требует
доп. разъяснений (ООП – содержит разъяснение «в себе», если, конечно, быть знакомым с
современными языками ОО программирования).
Лучше говорить – о модели программирования, основанной на обмене структурами данных
(часто еще называют «документами»). Заметьте, что RPC, очевидно будет частным случаем,
такой модели:
вызов – отправка структуры данных RequestMesage, получение результата – также прием
сообщения RequestResponse. В то же время, речь не идет о MOM (MOM)
• SOA Service Oriented Architecture
• UDDI Universal Definition, Discovery and Integration
(of Web Services)
• W3C World Wide Web Consortium
• WS Web Service
• WSDL Web Service Description Language
• WS-I Web Services Interoperability organization
• WSID Web Services Interoperability Demonstration
• XML Extensible Markup Language
• XSLT XML Stylesheet Language (Transform)
Чтобы не рассуждать абстрактно, я хочу рассмотреть стремительно развивающуюся (буквально за
последние год-два) технологию AJAX (Asynch. JavaScript API for XML).
Google Map, Mail, ???
Нарисовать примерную архитектуру AJAX:
источник данных в формате XML
асинхронные обращения к источнику (XmlHttpRequest)
преобразование (XML-parsers, XSLT) и кэширование преобразованных данных,
GUI и «локальное» использование полученных данных
Обмен документами XML, в том числе асинхронный, поверх сложившейся транспортной
сетевой инфраструктуры.
WS часто заменяют гораздо более узким понятием SOAP
92
Идея SOAP – зачем использовать спец. протоколы GIOP/IIOP если весь мир покрыт средой
HTTP/SMTP/POP/FTP.
SOAP ~ XML-RPC ~ XML + HTTP POST
Напомнить HTTP POST, XML сообщение в кач-ве «полезной нагрузки».
93
Simple Object Access Protocol (SOAP) – основанный на XML протокол, предназначенный для обмена информацией в
распределенных системах. SOAP устанавливает стандарт взаимодействия клиент-сервер и регламентирует, как
должен осуществляться вызов, передаваться параметры и возвращаемые значения. Для представления любой
информации, передаваемой от клиента к серверу и наоборот, используется XML.
ПРИМЕЧАНИЕ
SOAP не накладывает ограничений на используемый транспорт. Для передачи сообщений могут использоваться
любые протоколы и продукты, например, протоколы HTTP, HTTPS, SMTP. Данные могут передаваться через
Microsoft Message Queueing, IBM MQ Series и т.д. Однако чаще всего используется протокол HTTP. Microsoft SOAP
Toolkit включает в себя только поддержку HTTP.
WSDL
94
Замечание насчет binding style rpc|document (в выданном мною примере WSDL этот элемент отсутствует)
В распределенных системах SOAP используется для обеспечения взаимодействия разных уровней. На сегодняшний
день существует множество технологий и протоколов, позволяющих без труда соединять элементы распределенных
систем между собой. Одна из наиболее известных технологий – DCOM, позволяющая эффективно осуществлять RPCвызовы, передавать и принимать данные, распределять нагрузку между несколькими back-end серверами. Однако у
систем, построенных на DCOM, есть очень важный недостаток, затрудняющий взаимодействие уровня представления
и уровня бизнес-логики через Internet. Хотя DCOM-приложения могут использовать TCP/IP для передачи вызовов
RPC, большинство современных сетевых экранов будут запрещать передачу таких пакетов из соображений
безопасности. Конечно, с помощью утилиты DCOMCNFG можно настроить DCOM на использование любого порта в
диапазоне от 1024 до 65535. Но при изменении настроек одного из промежуточных файрволлов DCOM может
перестать работать. Можно сказать, что DCOM является доминирующей технологией для обмена информацией и
передачи вызовов в пределах корпоративной локальной сети, но при выходе за ее пределы DCOM приносит большое
количество хлопот, связанных с настройкой портов, файрволлов и т.д.
ПРИМЕЧАНИЕ
95
Чтобы расширить сферу применения DCOM, Microsoft выпустила COM Internet Services (CIS). CIS использует
специальный “туннельный” TCP-протокол, позволяющий DCOM-приложениям осуществлять RPC-вызовы через
порт 80. На стороне сервера находится ISAPI-расширение, перехватывающее запросы, идущие на порт 80, и
перенаправляющее их дальше для обработки с помощью обычного RPC. Особенностью CIS является то, что только
начальное “рукопожатие” клиента с сервером происходит в соответствии с протоколом HTTP, остальной трафик
не является HTTP (сделано это, видимо, из соображений эффективности). Поэтому, несмотря на использование 80го порта, CIS не устраняет проблему сетевых экранов, которые могут запретить передачу “подозрительных”
пакетов.
Альтернативой DCOM при построении распределенных систем может служить использование Web-интерфейса на
основе ASP. В таких системах от клиента ничего не требуется, кроме наличия браузера, способного соединиться с
корпоративным Web-сервером. Для передачи запроса от клиента к серверу можно применить, например, метод POST
для HTML-формы, а обработка запроса будет происходить уже на серверной стороне. Несмотря на популярность
такого подхода, у него есть недостатки – состав передаваемой информации, а главное, способ ее передачи в методе
POST специфичны для конкретного приложения. А если на уровне представления необходим полноценный
пользовательский интерфейс Windows-приложения, не миновать проблем.
Как в этом случае может быть построено взаимодействие клиента с сервером? И, наконец, как быть, если необходимо
обеспечить поддержку не только HTTP, но, например, SMTP или MSMQ (для асинхронного взаимодействия)? Эти
задачи можно решить следующим образом:
* Преобразовать вызов в текстовое представление с сохранением информации обо всех параметрах и их значениях.
* Передать текст на сервер по HTTP, SMTP и т.д.
* Интерпретировать текстовое сообщение на сервере и осуществить вызов некоторого метода.
* Преобразовать out-параметры или информацию об ошибке, возвращаемые методом, в текстовое представление.
* Передать текст клиенту по HTTP, SMTP и т.д.
* Интерпретировать результат.
Реализуя описанный сценарий, можно спроектировать свой собственный формат передачи параметров и информации
о вызове, или использовать SOAP, тем самым снижая затраты на разработку, документирование и сопровождение
системы.
Необходимо упомянуть о еще одном достоинстве протокола SOAP – он нейтрален к платформе, т.е. не накладывает
ограничений на платформы, которые используются клиентом и сервером. Запрос клиента, работающего под
управлением Windows 98, может быть обработан сервером под управлением Unix.
Наконец, Веб-сервисы !!!
96
Web Services Protocol Stack
The following sections aim at more detailed descriptions of the protocols shown in 0 and explained in its role
above.
XML messaging using SOAP
1.
In Figure 4, at (1) a service requestor’s application creates a SOAP message. This SOAP
message is the request that invokes the Web service operation provided by the service provider. The XML
97
document in the body of the message can be a SOAP RPC request or a document-centric message as
indicated in the service description. The service requestor presents this message together with the network
address of the service provider to the SOAP infrastructure (for example, a SOAP client runtime). The SOAP
client runtime interacts with an underlying network protocol (for example HTTP) to send the SOAP message
out over the network.
At (2) the network infrastructure delivers the message to the service provider’s SOAP
2.
runtime (for example a SOAP server). The SOAP server routes the request message to the service provider's
Web service. The SOAP runtime is responsible for converting the XML message into programming
language-specific objects if required by the application. This conversion is governed by the encoding
schemes found within the message.
3.
The Web service is responsible for processing the request message and formulating a
response. The response is also a SOAP message. At (3) the response SOAP message is presented to the
SOAP runtime with the service requestor as the destination. In the case of synchronous request/response over
HTTP, the underlying request/response nature of the networking protocol is used to implement the
request/response nature of the messaging. The SOAP runtime sends the SOAP message response to the
service requestor over the network.
4.
At (4) the response message is received by the networking infrastructure on the service
requestor’s node. The message is routed through the SOAP infrastructure; potentially converting the XML
message into objects in a target programming language. The response message is then presented to the
application.
Network Layer
The base layer of the Web Services stack is the network. This layer can be implemented using any number of existing network
protocols such as SMTP, FTP, HTTP, RMI, IIOP or others. Despite a wide choice of network protocols that can be used, most
Web Service applications rely on HTTP. HTTP is widely deployed and is very likely the ideal choice for Internet based
applications. For applications with limited audience for example within an Intranet or specific requirements including security,
performance and reliability other protocols could be a better choice.
One of the major advantages of the Web Service architecture is that the service developers do not need to care about this
underlying network protocol, as it is completely transparent to the upper layers.
HTTP (Hypertext Transfer Protocol)
Запрос GET может содержать данные, передаваемые клиентом серверу. они передаются непосредственно через URL
адрес по CGI протоколу. Так например для входа в чат браузер может передавать серверу следующий запрос:
GET http://chat.ru/?login=Basil&pass=Pupkin HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword,
application/vnd.ms-powerpoint, */*
Accept-Language: ru
Cookie: yandexuid=2464977781018373381
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
Host: yandex.ru
Referer: narod.ru
Proxy-Connection: Keep-Alive
Кака мы видим строка запроса содержит логин и пароль пользователя, переданые через строку URL. Такой тип
передачи данных серверу удобен, однако имеет ограничения на объем. Слишком большие массивы данных передавать
98
через URL нельзя. Для таких целей существует другой тип зпросов: запрос POST. Запрос POST очень похож на GET, с
той лишь разницей что данные в запросе POST передаются отдельно от самого собственно заголовка запроса. Так
приведенный выше пример в варианте POST имеет вид:
POST http://chat.ru/ HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword,
application/vnd.ms-powerpoint, */*
Accept-Language: ru
Cookie: yandexuid=2464977781018373381
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
Host: yandex.ru
Referer: narod.ru
Proxy-Connection: Keep-Alive
login=Basil&pass=Pupkin
Поэтому для SOAP используется POST форма HTTP запросов, позволяющая не перемешивать URL и содержание
сообщения.
The HTTP header consists of plain text. The payload is of the type specified in the Content-Type section of the
header. In the example the payload is also of the format plain text. A potential answer must start with a return code
indicating the type of result and optionally additional information.
200 OK
Content-Type: text/plain
Content-Length: 11
Hello you !
HTTP Success Response
As shown in 0 a potential Response of the server in case of success could be organized. A response contains also a
header and optionally a content body. A Response starts with a status code indicating the type of response and a
descriptive text for this kind of answer. Other examples for HTTP responses are shown in 0 and 0.
400 Bad Request
Content-Length: 0
HTTP Error Response
307 Temporarily Moved
Location:
http://123.123.123.11/bar
Content-Length: 0
HTTP Redirect Response
XML Protocol Layer (SOAP)
This layer is responsible for the transport of method calls, its parameters and also the results of operations. This layer is in most
implementations of a Web Service stack realised using the Simple Object Access Protocol (SOAP). The SOAP Protocol is
99
expressed using XML and defines within its specification also how SOAP messages are supposed to be transported using
HTTP and SMTP. Other mappings will be defined in the future.
SOAP offers different kind of communication types between service requestor and service provider. Beside a synchronous or
asynchronous request/response oriented client server relation publish/subscribe models, one-way messaging (with no response)
and notification (push-style response) are possible.
One-Way
Client
<input>
Server
Request-Response
<input>
Client
Server
<output>
Solicit-Response
<output>
Client
Server
<input>
Notification
Client
<output>
Server
SOAP Communication Types
A SOAP message is built from several logical components. The Object Endpoint ID uniquely identifies the destination of the
request. The interface and method identifier describe the method that should be called. The Extension Headers are headers of
the SOAP message and the Parameter DATA is the Body of the SOAP message. In 0 the mapping from logical components to
a SOAP message transported via HTTP is shown.
100
POST/objectURI HTTP/1.1
Object Endpoint ID
SOAP Method Name
Interface Identifier
SOAP:Envelope
Method Identifier
SOAP:Header («тип» сообщения)
Extension Headers
Header 1
Parameter Data
SOAP:Body («полезная нагрузка»
сообщения)
Call Element
Logical Components of a SOAP message
Как это выглядит изнутри (пример echoFloatArray)
Исходный Java код метода:
public float[] echoFloatArray(float[] inputFloatArray) throws java.rmi.RemoteException {
return inputFloatArray;
}
Благодаря использованию вспомогательных средств пакетов разработки WS, формирование SOAP вызовов и
декодирование результатов происходит скрытым от программиста образом.
Если запустить какой-нибудь TCP sniffer, то можно увидеть чем на самом деле обмениваются клиенты и WS.
101
Вызов метода
POST /axis/servlet/AxisServlet HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.0
Host: vvv
Cache-Control: no-cache
Pragma: no-cache
Connection: Keep-Alive (чтобы не тратить время на установление соединений при
следующих вызовах)
SOAPAction: http://soapinterop.org/ (опциональное значение, может быть «»)
Content-Length: 656
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:echoFloatArray
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="http://soapinterop.org/">
<inputFloatArray xsi:type="soapenc:Array" soapenc:arrayType="xsd:float[2]"
xmlns:ns2="http://soapinterop.org/xsd"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<item>3.7</item>
<item>7.0</item>
</inputFloatArray>
</ns1:echoFloatArray>
</soapenv:Body>
</soapenv:Envelope>
102
Возврат результата
HTTP/1.0 200 OK
Content-Type: text/xml; charset=utf-8
Set-Cookie: 5
Set-Cookie2: 5
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:echoFloatArrayResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="http://soapinterop.org/">
<return xsi:type="soapenc:Array" soapenc:arrayType="xsd:float[2]"
xmlns:ns2="http://soapinterop.org/xsd"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<item>3.7</item>
<item>7.0</item>
</return>
</ns1:echoFloatArrayResponse>
</soapenv:Body>
</soapenv:Envelope>
Можно сказать, что WS обобщают обычные средства HTTP (метод POST) на случай сколь угодно сложных SOAP
запросов.
Средства разработки и доки:
XMLSpy,
NetBeans IDE, Sun ONE
Eclipse (XML Buddy)
The concept of WS container (HTTP server)
Средой обитания WS является WEB-server. Обычно, для НЕ MS реализаций таковым является Apache TomCat,
снабженный всевозможными утилитами для манипуляций с WSDL и WSDD файлами.
Для MS WS – IIS (Visual Studio.NET)
Однако существуют и специальные «легкие» реализации AxisServer, gSOAP. Играющие роль аналогичную CORBA
Object Adaptor.
CELL
http://en.wikipedia.org/wiki/CELL
103
Cell is a microprocessor architecture jointly developed by a Sony, Toshiba, and IBM alliance known as STI. The architectural
design and first implementation were carried out at the STI Design Center over a four-year period beginning March 2001 on a
budget reported by IBM as approaching $400 million.
Cell is a shorthand for Cell Broadband Engine Architecture, commonly abbreviated CBEA in full or Cell BE in part. Cell
combines a general-purpose POWER-architecture core of modest performance with streamlined coprocessing elements which
greatly accelerate multimedia and vector processing applications, as well as many other forms of dedicated computation.
104