\caption{Параметры настройки программы \code{ParaLab} для сортировки массива данных}
\caption{Параметры настройки программы \code{ParaLab} для сортировки массива данных}
@ -43,11 +46,11 @@
\hline
\hline
Размер массива данных & Время выполнения (мкс) & Из них на передачу данных (мкс) & Время в отчёте \code{ParaLab}\\ [0.5ex]
Размер массива данных & Время выполнения (мкс) & Из них на передачу данных (мкс) & Время в отчёте \code{ParaLab}\\ [0.5ex]
\hline\hline
\hline\hline
1000 & 274,4514 & 270,96 & 365,27 \\
$1000$&$274,4514$&$270,96$&$365,27$\\
1500 & 396,4165 & 390,96 & 527,49 \\
$1500$&$396,4165$&$390,96$&$527,49$\\
2000 & 518,4429 & 510,96 & 689,76 \\
$2000$&$518,4429$&$510,96$&$689,76$\\
2500 & 640,5148 & 630,96 & 852,08 \\
$2500$&$640,5148$&$630,96$&$852,08$\\
3000 & 762,6231 & 750,96 & 1014,4 \\
$3000$&$762,6231$&$750,96$&$1014,4$\\
\hline
\hline
\end{tabular}
\end{tabular}
\caption{Результаты сортировки массива данных методом пузырьковой сортировки.}
\caption{Результаты сортировки массива данных методом пузырьковой сортировки.}
@ -98,7 +101,7 @@
\label{table:multiplytask}
\label{table:multiplytask}
\end{table}
\end{table}
Настройка программы \code{ParaLab} для данного задания приводит к ошибке, связанной с тем, что ни один из алгоритмов умножения матриц не может быть реализован на топологии типа - Гиперкуб. Сообщения об ошибке представлено на рисунке \hyperref[pic:multiplyerror]{\ref{pic:multiplyerror}}.
Настройка программы \code{ParaLab} для данного задания приводит к ошибке, связанной с тем, что ни один из алгоритмов умножения матриц не может быть реализован на топологии типа -- Гиперкуб. Сообщения об ошибке представлено на рисунке \hyperref[pic:multiplyerror]{\ref{pic:multiplyerror}}.
\begin{figure}[H]
\begin{figure}[H]
\centering
\centering
@ -107,7 +110,7 @@
\label{pic:multiplyerror}
\label{pic:multiplyerror}
\end{figure}
\end{figure}
Так как топология сети \textbf{Гиперкуб} не подходит для выполнения задачи, были исследованные остальные доступные топологии на предмет выполняемости условий задачи. Топология \textbf{Линейка} аналогично топологии \textbf{Гиперкуб} не может быть использована для выполнения задачи. Топологии \textbf{Кольцо} и \textbf{Полный граф} хотя и могут быть использованы, однако поддерживают только метод решения –\textbf{Ленточный алгоритм}, что недостаточно для решения задачи. Топология \textbf{Решетка} позволяет провести эксперименты для всех методов решения и была выбрана вместо топологии указанной в задаче.
Так как топология сети \textbf{Гиперкуб} не подходит для выполнения задачи, были исследованные остальные доступные топологии на предмет выполняемости условий задачи. Топология \textbf{Линейка} аналогично топологии \textbf{Гиперкуб} не может быть использована для выполнения задачи. Топологии \textbf{Кольцо} и \textbf{Полный граф} хотя и могут быть использованы, однако поддерживают только метод решения --\textbf{Ленточный алгоритм}, что недостаточно для решения задачи. Топология \textbf{Решетка} позволяет провести эксперименты для всех методов решения и была выбрана вместо топологии указанной в задаче.
Результаты выполнения задания представлены в таблице \hyperref[table:multiplylent]{\ref{table:multiplylent}}, а график временной зависимости времени сортировки от размера массива на рисунке \hyperref[pic:multiplydiagram]{\ref{pic:multiplydiagram}}.
Результаты выполнения задания представлены в таблице \hyperref[table:multiplylent]{\ref{table:multiplylent}}, а график временной зависимости времени сортировки от размера массива на рисунке \hyperref[pic:multiplydiagram]{\ref{pic:multiplydiagram}}.
@ -254,19 +257,19 @@
\subsection{Описание алгоритма сортировки, в соответствии с вариантом, использованным в работе}
\subsection{Описание алгоритма сортировки, в соответствии с вариантом, использованным в работе}
\textbf{Пузырьковая сортировка}. Алгоритм пузырьковой сортировки в прямом виде достаточно сложен для распараллеливания – сравнение пар значений упорядочиваемого набора данных происходит строго последовательно. В связи с этим для параллельного применения используется не сам этот алгоритм, аего модификация, известная в литературе как метод чёт-нечётной перестановки (odd-even transposition). Суть модификации состоит в том, что в алгоритм сортировки вводятся два разных правила выполнения итераций метода – в зависимости от чётности или нечётности номера итерации сортировки для обработки выбираются элементы с чётными или нечётными индексами соответственно, сравнение выделяемых значений всегда осуществляется с их правыми соседними элементами. Т.е., на всех нечётных итерациях сравниваются пары
\textbf{Пузырьковая сортировка}. Алгоритм пузырьковой сортировки в прямом виде достаточно сложен для распараллеливания – сравнение пар значений упорядочиваемого набора данных происходит строго последовательно. В связи с этим для параллельного применения используется не сам этот алгоритм, аего модификация, известная в литературе как метод чёт-нечётной перестановки (odd-even transposition). Суть модификации состоит в том, что в алгоритм сортировки вводятся два разных правила выполнения итераций метода – в зависимости от чётности или нечётности номера итерации сортировки для обработки выбираются элементы с чётными или нечётными индексами соответственно, сравнение выделяемых значений всегда осуществляется с их правыми соседними элементами. Т.е., на всех нечётных итерациях сравниваются пары
\[
$$
(a_1, a_2), (a_3, a_4), ..., (a_{n–1}, a_n)
(a_1, a_2), (a_3, a_4), ..., (a_{n-1}, a_n)
\]
$$
на четных итерациях обрабатываются элементы
на чётных итерациях обрабатываются элементы
\[
$$
(a_2, a_3), (a_4, a_5), ..., (a_{n–2}, a_{n–1})
(a_2, a_3), (a_4, a_5), ..., (a_{n-2}, a_{n-1})
\]
$$
После N-кратного повторения подобных итераций сортировки исходный набор данных оказывается упорядоченным.
После N-кратного повторения подобных итераций сортировки исходный набор данных оказывается упорядоченным.
Получение параллельного варианта для метода чет-нечетной перестановки уже не представляет каких-либо затруднений – сравнение пар значений на итерациях сортировки любого типа являются независимыми и могут быть выполнены параллельно.
Получение параллельного варианта для метода чет-нечетной перестановки уже не представляет каких-либо затруднений -- сравнение пар значений на итерациях сортировки любого типа являются независимыми и могут быть выполнены параллельно.
\subsection{В чем состоит основное различие сортировки Шелла от пузырьковой сортировки?}
\subsection{В чем состоит основное различие сортировки Шелла от пузырьковой сортировки?}
Основное различие состоит в том, что на первых итерациях алгоритма Шелла происходит сравнение пар элементов, которые в исходном наборе данных находятся далеко друг от друга (для упорядочивания таких пар в пузырьковой сортировке может понадобиться достаточно большое количество итераций).
Основное различие состоит в том, что на первых итерациях алгоритма Шелла происходит сравнение пар элементов, которые в исходном наборе данных находятся далеко друг от друга (для упорядочивания таких пар в пузырьковой сортировке может понадобиться достаточно большое количество итераций).
@ -281,9 +284,9 @@
При блочном представлении данных параллельная вычислительная схема матричного умножения в наиболее простом виде может быть построена, если топология вычислительной сети имеет вид прямоугольной решетки (если реальная топология сети имеет иной вид, например, гиперкуб, как это было необходимо согласно варианта, представление сети в виде решетки можно обеспечить на логическом уровне). Основные положения параллельных методов для блочно представленных матриц состоят в следующем:
При блочном представлении данных параллельная вычислительная схема матричного умножения в наиболее простом виде может быть построена, если топология вычислительной сети имеет вид прямоугольной решетки (если реальная топология сети имеет иной вид, например, гиперкуб, как это было необходимо согласно варианта, представление сети в виде решетки можно обеспечить на логическом уровне). Основные положения параллельных методов для блочно представленных матриц состоят в следующем:
\begin{enumerate}
\begin{enumerate}
\item каждый из процессоров решетки отвечает за вычисление одного блока матрицы C;
\item каждый из процессоров решетки отвечает за вычисление одного блока матрицы C;
\item в ходе вычислений на каждом из процессоров располагается по одному блоку исходных матриц A и В;
\item в ходе вычислений на каждом из процессоров располагается по одному блоку исходных матриц A и B;
\item при выполнении итераций алгоритмов блоки матрицы А последовательно сдвигаются вдоль строк процессорной решетки, а блоки матрицы B — вдоль столбцов решетки;
\item при выполнении итераций алгоритмов блоки матрицы A последовательно сдвигаются вдоль строк процессорной решетки, а блоки матрицы B — вдоль столбцов решетки;
\item в результате вычислений на каждом из процессоров получается блок матрицы С, при этом общее количество итераций алгоритма равно числу процессоров.
\item в результате вычислений на каждом из процессоров получается блок матрицы C, при этом общее количество итераций алгоритма равно числу процессоров.
\end{enumerate}
\end{enumerate}
\subsection{Какие варианты топологии сети возможно использовать для пузырьковой сортировки массива?}
\subsection{Какие варианты топологии сети возможно использовать для пузырьковой сортировки массива?}
@ -299,11 +302,11 @@
\subsection{Перечислите топологии сети, их особенности. Какая сеть обладает наибольшей связанностью рабочих станций при одном и том же количестве станций?}
\subsection{Перечислите топологии сети, их особенности. Какая сеть обладает наибольшей связанностью рабочих станций при одном и том же количестве станций?}
Основные используемые топологии сети следующие:
Основные используемые топологии сети следующие:
\begin{enumerate}
\begin{enumerate}
\item полный граф (completely-connected graph или clique) – система, в которой между любой парой процессоров существует прямая линия связи; как результат, данная топология обеспечивает минимальные затраты при передаче данных, однако является сложно реализуемой при большом количестве процессоров;
\item полный граф (completely-connected graph или clique) -- система, в которой между любой парой процессоров существует прямая линия связи; как результат, данная топология обеспечивает минимальные затраты при передаче данных, однако является сложно реализуемой при большом количестве процессоров;
\item линейка (linear array или farm) – система, в которой каждый процессор имеет линии связи только с двумя соседними (с предыдущим и последующим) процессорами; такая схема является, с одной стороны, просто реализуемой, с другой стороны, соответствует структуре передачи данных при решении многих вычислительных задач (например, при организации конвейерных вычислений);
\item линейка (linear array или farm) -- система, в которой каждый процессор имеет линии связи только с двумя соседними (с предыдущим и последующим) процессорами; такая схема является, с одной стороны, просто реализуемой, с другой стороны, соответствует структуре передачи данных при решении многих вычислительных задач (например, при организации конвейерных вычислений);
\item кольцо (ring) – данная топология получается из линейки процессоров соединением первого и последнего процессоров линейки;
\item кольцо (ring) -- данная топология получается из линейки процессоров соединением первого и последнего процессоров линейки;
\item решетка (mesh) – система, в которой граф линий связи образует прямоугольную двумерную сетку; подобная топология может быть достаточно просто реализована и, кроме того, может эффективно использоваться при параллельном выполнении многих численных алгоритмов (например, при реализации методов блочного умножения матриц);
\item решетка (mesh) -- система, в которой граф линий связи образует прямоугольную двумерную сетку; подобная топология может быть достаточно просто реализована и, кроме того, может эффективно использоваться при параллельном выполнении многих численных алгоритмов (например, при реализации методов блочного умножения матриц);
\item гиперкуб (hypercube) – данная топология представляет частный случай структуры N-мерной решетки, когда по каждой размерности сетки имеется только два процессора. Так гиперкуб содержит 2N процессоров при размерности N.
\item гиперкуб (hypercube) -- данная топология представляет частный случай структуры N-мерной решетки, когда по каждой размерности сетки имеется только два процессора. Так гиперкуб содержит 2N процессоров при размерности N.
\end{enumerate}
\end{enumerate}
Полный граф обладает наибольшей связанностью при одном и том же количестве процессоров.
Полный граф обладает наибольшей связанностью при одном и том же количестве процессоров.
@ -34,7 +37,7 @@ newScaredTimes содержит число шагов, в течении кот
комбинируйте их для создания великолепной оценочной функции.
комбинируйте их для создания великолепной оценочной функции.
\end{verbatim}
\end{verbatim}
Улучшенный код рефлексивного агента представлен в листинге \hyperref[lst:betterReflex]{\ref{lst:betterReflex}}. Результаты выполнения тестов, запушенных командой \code{python autograder.py –q –q1 –no-graphics} представлен в выводе \hyperref[fig:result1]{\ref{fig:result1}}.
Улучшенный код рефлексивного агента представлен в листинге \hyperref[lst:betterReflex]{\ref{lst:betterReflex}}. Результаты выполнения тестов, запушенных командой \code{python autograder.py -q -q1 -no-graphics} представлен в выводе \hyperref[fig:result1]{\ref{fig:result1}}.
\begin{lstlisting}[language=Python, caption=Улучшенный код агента, style=PyCodeStyle, label={lst:betterReflex}]
\begin{lstlisting}[language=Python, caption=Улучшенный код агента, style=PyCodeStyle, label={lst:betterReflex}]
В рамках персонального задания было необходимо улучшить алгоритм альфа-бета отсечения (вариант 11(2)). Улучшенный код алгоритма представлен в листинге \hyperref[lst:alphaBeta]{\ref{lst:alphaBeta}}. Результаты выполнения тестов алгоритма, запушенных командой \code{python autograder.py –q –q2 –no-graphics} представлен в выводе \hyperref[fig:result2]{\ref{fig:result2}}.
В рамках персонального задания было необходимо улучшить алгоритм альфа-бета отсечения (вариант 11(2)). Улучшенный код алгоритма представлен в листинге \hyperref[lst:alphaBeta]{\ref{lst:alphaBeta}}. Результаты выполнения тестов алгоритма, запушенных командой \code{python autograder.py -q -q2 -no-graphics} представлен в выводе \hyperref[fig:result2]{\ref{fig:result2}}.
@ -238,6 +241,6 @@ to follow your instructor's guidelines to receive credit on your project.
Оценочная функция позволяет достаточно быстро и точно, в выбранной метрике, указать оценку вероятности победы конкретного игрока для конкретного расположения фигур, не опираясь на то, каким образом игроки к этому состоянию пришли. Алгоритм альфа-бета отсечения является модификацией алгоритма минимакса, однако, в отличие от него, анализ некоторых ходов может быть не выполнен, то есть, прекратиться досрочно.
Оценочная функция позволяет достаточно быстро и точно, в выбранной метрике, указать оценку вероятности победы конкретного игрока для конкретного расположения фигур, не опираясь на то, каким образом игроки к этому состоянию пришли. Алгоритм альфа-бета отсечения является модификацией алгоритма минимакса, однако, в отличие от него, анализ некоторых ходов может быть не выполнен, то есть, прекратиться досрочно.
Агенты позволяют использовать существующее программное обеспечение, в контексте выполнения работы им являлась игра Pacman, для достижения своих целей – победы. Алгоритмы их работы являются эвристическими и не гарантируют победу, а лишь позволяют с заданной быстротой и точностью достичь поставленной цели - анализ текущей ситуации и выбор лучшего выхода из неё.
Агенты позволяют использовать существующее программное обеспечение, в контексте выполнения работы им являлась игра Pacman, для достижения своих целей -- победы. Алгоритмы их работы являются эвристическими и не гарантируют победу, а лишь позволяют с заданной быстротой и точностью достичь поставленной цели -- анализ текущей ситуации и выбор лучшего выхода из неё.
В ходе выполнения работы была реализованная задача создания распределенной системы, где вся логика обработки данных предоставляется серверу, тогда как работа с данными происходит на клиенте.
В ходе выполнения работы была реализованная задача создания распределенной системы, где вся логика обработки данных предоставляется серверу, тогда как работа с данными происходит на клиенте.
Для реализации задачи был использован протокол удаленных вызовов процедур JSON-RPC. Протокол использует JSON для кодирования сообщений. Протокол был использован исходя из рекомендаций к заданию и имеет следующий особенности:
Для реализации задачи был использован протокол удаленных вызовов процедур JSON-RPC. Протокол использует JSON для кодирования сообщений. Протокол был использован исходя из рекомендаций к заданию и имеет следующий особенности:
распределённая информационная система - это такая информационная система, в которой информация и её обработка распределены между несколькими устройствами. То есть это набор независимых устройств, которые пользователю предоставляются как единое целое. Может быть распределена как аппаратная, так и программная часть. В первую очередь это распределённое программное обеспечение. Основная общая модель - это клиент-сервер. Клиент выдаёт запросы и получает от сервера ответы. Взаимодействие может быть двух видов:
распределённая информационная система - это такая информационная система, в которой информация и её обработка распределены между несколькими устройствами. То есть это набор независимых устройств, которые пользователю предоставляются как единое целое. Может быть распределена как аппаратная, так и программная часть. В первую очередь это распределённое программное обеспечение. Основная общая модель -- это клиент-сервер. Клиент выдаёт запросы и получает от сервера ответы. Взаимодействие может быть двух видов:
\begin{itemize}
\begin{itemize}
\item синхронное - клиент даёт запрос и только после получения ответа продолжает работу.
\item синхронное -- клиент даёт запрос и только после получения ответа продолжает работу.
\begin{frm}
\begin{figure}
\def\svgwidth{70mm}
\centering
\input{pics/01-dis-00-sync.pdf_tex}
\fontsize{12}{1}\selectfont
\label{pic:clientsync}
\includesvg[scale=1.01]{pics/01-dis-00-sync.svg}
\end{frm}
\caption{}
\label{pic:clientsync}
\end{figure}
Клиент запраживает службу у Сервера и ожидает ответа от сервера, полностью бездействуя
Клиент запраживает службу у Сервера и ожидает ответа от сервера, полностью бездействуя
\item асинхронное - клиент не блокируется.
\item асинхронное -- клиент не блокируется.
\begin{frm}
\begin{figure}
\def\svgwidth{70mm}
\centering
\input{pics/01-dis-00-async.pdf_tex}
\fontsize{12}{1}\selectfont
\label{pic:clientasync}
\includesvg[scale=1.01]{pics/01-dis-00-async.svg}
\end{frm}
\caption{}
\label{pic:clientasync}
\end{figure}
Клиент запраживает службу у Сервера и возвращает управление себе, работает без ожидания. Когда приходит ответ от Сервера, клиент посылает сигнал подтверждения получения ответа.
Клиент запраживает службу у Сервера и возвращает управление себе, работает без ожидания. Когда приходит ответ от Сервера, клиент посылает сигнал подтверждения получения ответа.
\end{itemize}
\end{itemize}
@ -59,7 +65,7 @@
\end{itemize}
\end{itemize}
Типы клиент-серверных архитектур
Типы клиент-серверных архитектур
\begin{enumerate}
\begin{enumerate}
\item одноярусные: все три слоя (логических уровня) находятся в одном ярусе - то есть одно устройство. Презентационный слой - это терминал, а логика и ресурсы это приложение;
\item одноярусные: все три слоя (логических уровня) находятся в одном ярусе -- то есть одно устройство. Презентационный слой -- это терминал, а логика и ресурсы это приложение;
\item двухярусные: обычно, отображение отделяется от обработки;
\item двухярусные: обычно, отображение отделяется от обработки;
\item трёхярусные: презентационный слой на клиенте, слой прикладной логики на среднем ярусе и слой управления ресурсами отделяется на третье устройство;
\item трёхярусные: презентационный слой на клиенте, слой прикладной логики на среднем ярусе и слой управления ресурсами отделяется на третье устройство;
\item многоярусные: обычно прикладной слой уже делается на разном железе. Или примером такой архитектуры может служить объединение неоднородных систем в одну.
\item многоярусные: обычно прикладной слой уже делается на разном железе. Или примером такой архитектуры может служить объединение неоднородных систем в одну.
\item слой управления ресурсами (организовывает доступ к данным, RES) включает в себя не только просто ресурсы, но и другие двух- и трёхъярусные модели.
\item слой управления ресурсами (организовывает доступ к данным, RES) включает в себя не только просто ресурсы, но и другие двух- и трёхъярусные модели.
Программная компонента - это единица программного обеспечения, исполняемая на одном компьютере в пределах одного процесса и представляющая некий набор сервисов или служб, которые используются через её внешний интерфейс другими компонентами, выполняемыми как на этом же компьютере, так и на удалённом. Распределённая информационная система - это набор взаимодействующих программных компонент, выполняемых на одном или нескольких связанных компьютерах и выглядящих с точки зрения пользователя как единое целое. Распределение должно быть скрыто от пользователя, то есть пользователь должен представлять, что система это единое целое. Такое сокрытие называется "прозрачность".
Программная компонента -- это единица программного обеспечения, исполняемая на одном компьютере в пределах одного процесса и представляющая некий набор сервисов или служб, которые используются через её внешний интерфейс другими компонентами, выполняемыми как на этом же компьютере, так и на удалённом. Распределённая информационная система - это набор взаимодействующих программных компонент, выполняемых на одном или нескольких связанных компьютерах и выглядящих с точки зрения пользователя как единое целое. Распределение должно быть скрыто от пользователя, то есть пользователь должен представлять, что система это единое целое. Такое сокрытие называется \textbf{прозрачность}.
Основные характеристики распределённых информационных систем
Основные характеристики распределённых информационных систем
\begin{enumerate}
\begin{enumerate}
@ -165,13 +172,13 @@
\subsection{Концепции программных решений}
\subsection{Концепции программных решений}
Именно программное решение более явно отличает распределение системы. Распределённые системы в этом плане похожи на обычные операционные системы: есть менеджер ресурсов, который помогает пользователям и аппаратным составляющим совместно использовать процессоры, память, сеть и другие периферийные устройства, и работать с системой, как с распределённой. Именно программно скрывает распределённость от пользователя. Операционные системы для распределённых систем можно разделить на категории:
Именно программное решение более явно отличает распределение системы. Распределённые системы в этом плане похожи на обычные операционные системы: есть менеджер ресурсов, который помогает пользователям и аппаратным составляющим совместно использовать процессоры, память, сеть и другие периферийные устройства, и работать с системой, как с распределённой. Именно программно скрывает распределённость от пользователя. Операционные системы для распределённых систем можно разделить на категории:
\begin{itemize}
\begin{itemize}
\item\textbf{слабо связанные:} операционная система воспринимается как набор независимых операционных систем. Подвид - сетевые операционные системы. Для них не требуется прямой доступ к аппаратному обеспечению. Не требуют, чтобы аппаратное обеспечение на котором они функционируют было однородным и управлялось как единая система. Абстрагирует от аппаратных решений. Но одной только сетевой операционной системы недостаточно для создания распределённой системы, необходимы также компоненты, которые поддерживают прозрачность распределения. За такие компоненты отвечает промежуточный уровень распределённой системы:
\item\textbf{слабо связанные:} операционная система воспринимается как набор независимых операционных систем. Подвид -- сетевые операционные системы. Для них не требуется прямой доступ к аппаратному обеспечению. Не требуют, чтобы аппаратное обеспечение на котором они функционируют было однородным и управлялось как единая система. Абстрагирует от аппаратных решений. Но одной только сетевой операционной системы недостаточно для создания распределённой системы, необходимы также компоненты, которые поддерживают прозрачность распределения. За такие компоненты отвечает промежуточный уровень распределённой системы:
\includegraphics[width=8cm]{01-dis-00-spo.png}
\includegraphics[width=8cm]{01-dis-00-spo.png}
\item\textbf{сильно связанные:} операционная система старается работать с одним глобальным представлением ресурсов, которыми она управляет. Обычно используется именно такая связанность для управления распределёнными системами.
\item\textbf{сильно связанные:} операционная система старается работать с одним глобальным представлением ресурсов, которыми она управляет. Обычно используется именно такая связанность для управления распределёнными системами.
\end{itemize}
\end{itemize}
\subsection{Програмное обеспечение промежуточного уровня}
\subsection{Програмное обеспечение промежуточного уровня}
Распределённые операционные системы не предназначены для управления набором независимых компонент, а сетевые операционные системы не дают одной согласованной системы. Поэтому нужны системы, которые объединяют плюсы сетевых операционных систем (масштабируемость, открытость, итд), и плюсы распределённых систем (прозрачность, относительная простота использования). Программное обеспечение промежуточного уровня скрывает неоднородность, например. Отдельными узлами всё также будет управлять локальная операционная система, но промежуточный уровень позволяет использовать единый набор служб, давая пользователю однородность. Основная задача - скрыть разнообразие базовых платформ от приложений.
Распределённые операционные системы не предназначены для управления набором независимых компонент, а сетевые операционные системы не дают одной согласованной системы. Поэтому нужны системы, которые объединяют плюсы сетевых операционных систем (масштабируемость, открытость, итд), и плюсы распределённых систем (прозрачность, относительная простота использования). Программное обеспечение промежуточного уровня скрывает неоднородность, например. Отдельными узлами всё также будет управлять локальная операционная система, но промежуточный уровень позволяет использовать единый набор служб, давая пользователю однородность. Основная задача -- скрыть разнообразие базовых платформ от приложений.
\subsection{Модели промежуточного уровня}
\subsection{Модели промежуточного уровня}
\begin{enumerate}
\begin{enumerate}
\item представление всех объектов в виде файлов (нет отличия между удалёнными и локальными файлами) тогда программное обеспечение будет построено по принципу распределённой файловой системы (distributed filesystem);
\item представление всех объектов в виде файлов (нет отличия между удалёнными и локальными файлами) тогда программное обеспечение будет построено по принципу распределённой файловой системы (distributed filesystem);
@ -193,13 +200,13 @@
От промежуточного уровня предполагается полнота описания интерфейса. Неполнота приводит к тому, что программисты сами дописывают промежуточный уровень что приводит к неоднородности системы.
От промежуточного уровня предполагается полнота описания интерфейса. Неполнота приводит к тому, что программисты сами дописывают промежуточный уровень что приводит к неоднородности системы.
\subsection{Распределённое событие}
\subsection{Распределённое событие}
В распределённых системах может возникнуть необходимость использовать извещения от удалённых подсистем. Так могут возникать два типа событий: сильно и слабо связанные. При сильно связанном событии происходит прямое уведомление, обе стороны должны быть активны одновременно. При слабо связанном событии - передача информации происходит через вспомогательный сервис, источники (издатели) напрямую не взаимодействуют с получателями (подписчиками), что позволяет получателям подписаться на событие и отвязывает сервис от необходимости находиться с получателем на одном компьютере. Распределённое событие может быть реализовано как вызов метода удалённого объекта.
В распределённых системах может возникнуть необходимость использовать извещения от удалённых подсистем. Так могут возникать два типа событий: сильно и слабо связанные. При сильно связанном событии происходит прямое уведомление, обе стороны должны быть активны одновременно. При слабо связанном событии -- передача информации происходит через вспомогательный сервис, источники (издатели) напрямую не взаимодействуют с получателями (подписчиками), что позволяет получателям подписаться на событие и отвязывает сервис от необходимости находиться с получателем на одном компьютере. Распределённое событие может быть реализовано как вызов метода удалённого объекта.
\subsection{Распределённые транзакции (ACID)}
\subsection{Распределённые транзакции (ACID)}
\begin{enumerate}
\begin{enumerate}
\item атомарность - всё или ничего
\item атомарность -- всё или ничего
\item согласованность - либо успех либо откат - все данные логически целостны, согласованность не нарушается
\item согласованность -- либо успех либо откат -- все данные логически целостны, согласованность не нарушается
\item изоляция - объектам вне транзакции не видны промежуточные состояния данных внутри транзакции
\item изоляция -- объектам вне транзакции не видны промежуточные состояния данных внутри транзакции
\item постоянство - в случае успешности изменения имеют постоянных характер.
\item постоянство -- в случае успешности изменения имеют постоянных характер.
\end{enumerate}
\end{enumerate}
\begin{figure}[h!]
\begin{figure}[h!]
\centering
\centering
@ -214,7 +221,7 @@
\end{enumerate}
\end{enumerate}
\section{Общие сведения о J2EE}
\section{Общие сведения о J2EE}
\textbf{Платформа J2EE} - это комплекс взаимодействующих технологий базирующихся на спецификациях фирмы Sun (Oracle) и представляющих собой стандарт разработки серверных приложений уровня предприятий.
\textbf{Платформа J2EE} -- это комплекс взаимодействующих технологий базирующихся на спецификациях фирмы Sun (Oracle) и представляющих собой стандарт разработки серверных приложений уровня предприятий.
Особенности стандарта J2EE:
Особенности стандарта J2EE:
\begin{itemize}
\begin{itemize}
@ -267,7 +274,7 @@ Java-serverlets
\begin{itemize}
\begin{itemize}
\item Web-уровень
\item Web-уровень
\item EJB
\item EJB
\item Уровень сервера БД (EIS - enterprise information server)
\item Уровень сервера БД (EIS -- enterprise information server)
\end{itemize}
\end{itemize}
Приложение должно поддерживать:
Приложение должно поддерживать:
@ -280,14 +287,14 @@ Java-serverlets
Уровень приложений содержит:
Уровень приложений содержит:
\begin{itemize}
\begin{itemize}
\item Java - серверлеты
\item Java -- серверлеты
\item Java - страницы JPS
\item Java -- страницы JPS
\item Страницы HTML
\item Страницы HTML
\item JavaScript
\item JavaScript
\item Классы
\item Классы
\end{itemize}
\end{itemize}
Уровень бизнес логики (EJB) - работает в адресном пространстве сервера приложений и через компоненты EJB осуществляет доступ к БД.
Уровень бизнес логики (EJB) -- работает в адресном пространстве сервера приложений и через компоненты EJB осуществляет доступ к БД.
Основные задачи контейнера EJB:
Основные задачи контейнера EJB:
\begin{enumerate}
\begin{enumerate}
\item Доступ к инфраструктуре J2SE
\item Доступ к инфраструктуре J2SE
@ -313,8 +320,8 @@ Java-serverlets
\item Web-контейнер
\item Web-контейнер
\item EJB-контейнер
\item EJB-контейнер
\end{itemize}
\end{itemize}
\subsection*{Из конспекта 2017}
%\subsection*{Из конспекта 2017}
\includegraphics[width=14cm]{01-dis-00-2017.pdf}
%\includegraphics[width=14cm]{01-dis-00-2017.pdf}
\section{Протоколы}
\section{Протоколы}
\subsection{Верхнего уровня}
\subsection{Верхнего уровня}
@ -324,7 +331,7 @@ Java-serverlets
Примеры специальных прикладных протоколов: FTP, HTTP\footnote{В настоящее время HTTP в том числе используется в системах, связь которых с Web не предполагается. Например, в RMI HTTP используется для обращения к удаленным объектам}.
Примеры специальных прикладных протоколов: FTP, HTTP\footnote{В настоящее время HTTP в том числе используется в системах, связь которых с Web не предполагается. Например, в RMI HTTP используется для обращения к удаленным объектам}.
\subsection{Промежуточного уровня}
\subsection{Промежуточного уровня}
К промежуточному уровню относятся приложения, логически помещаемые на прикладной уровень, но содержащие множество протоколов общего назначения, что дает им право на их собственный уровень, независимый от других более специализированных приложений. \textbf{Например:} Различные методы аутентификации. Протоколы аутентификации не привязаны к какому либо конкретному приложению, поэтому они встраиваются в системы промежуточного уровня на правах общей службы. Протоколы авторизации также имеют тенденцию к переходу на независимый уровень. \textbf{Другой пример}– множество протоколов \textit{распределенного подтверждения}. Протоколы подтверждения делают так, чтобы в группе процессов либо все процессы прошли через определенную операцию, либо операция не была применена ни к одному из процессов. Этот механизм (атомарность) используется при организации транзакций. \textbf{Еще пример}– протоколы распределенной блокировки, при помощи которых может быть предотвращен одновременный доступ к ресурсам сразу нескольких процессов, распределенных по множеству машин. Эти протоколы также могут быть реализованы в виде общедоступной службы промежуточного уровня, который не зависит от какого либо конкретного приложения. Коммуникационные протоколы промежуточного уровня поддерживают высокоуровневые коммуникационные службы, например есть высокоуровневые коммуникационные протоколы, которые позволяют процессам прозрачно вызывать процедуры или обращаться к объектам на удаленных машинах. Существуют также коммуникационные службы высокого уровня для запуска и синхронизации потоков данных в реальном времени. \textbf{Еще один пример}– предоставляемые некоторыми системами– надежные службы групповой рассылки, способные поддерживать тысячи получателей, разбросанных по глобальной сети.
К промежуточному уровню относятся приложения, логически помещаемые на прикладной уровень, но содержащие множество протоколов общего назначения, что дает им право на их собственный уровень, независимый от других более специализированных приложений. \textbf{Например:} Различные методы аутентификации. Протоколы аутентификации не привязаны к какому либо конкретному приложению, поэтому они встраиваются в системы промежуточного уровня на правах общей службы. Протоколы авторизации также имеют тенденцию к переходу на независимый уровень. \textbf{Другой пример}-- множество протоколов \textit{распределенного подтверждения}. Протоколы подтверждения делают так, чтобы в группе процессов либо все процессы прошли через определенную операцию, либо операция не была применена ни к одному из процессов. Этот механизм (атомарность) используется при организации транзакций. \textbf{Еще пример}-- протоколы распределенной блокировки, при помощи которых может быть предотвращен одновременный доступ к ресурсам сразу нескольких процессов, распределенных по множеству машин. Эти протоколы также могут быть реализованы в виде общедоступной службы промежуточного уровня, который не зависит от какого либо конкретного приложения. Коммуникационные протоколы промежуточного уровня поддерживают высокоуровневые коммуникационные службы, например есть высокоуровневые коммуникационные протоколы, которые позволяют процессам прозрачно вызывать процедуры или обращаться к объектам на удаленных машинах. Существуют также коммуникационные службы высокого уровня для запуска и синхронизации потоков данных в реальном времени. \textbf{Еще один пример}-- предоставляемые некоторыми системами надежные службы групповой рассылки, способные поддерживать тысячи получателей, разбросанных по глобальной сети.
Описанный подход к подразделению на уровни приводит к слегка измененной эталонной модели взаимодействия, а именно: по сравнению с моделью OSI сеансовый уровень и уровень приложений заменены одним промежуточным уровнем, который содержит независящий от приложения протокол. Мы ограничимся достаточно подробным рассмотрением трёх служб: удаленный вызов процедур, удаленное обращение к объектам, очереди сообщений.
Описанный подход к подразделению на уровни приводит к слегка измененной эталонной модели взаимодействия, а именно: по сравнению с моделью OSI сеансовый уровень и уровень приложений заменены одним промежуточным уровнем, который содержит независящий от приложения протокол. Мы ограничимся достаточно подробным рассмотрением трёх служб: удаленный вызов процедур, удаленное обращение к объектам, очереди сообщений.
@ -338,18 +345,21 @@ Java-serverlets
\end{itemize}
\end{itemize}
Идея, стоящая за RPC, состоит в том, чтобы удаленный вызов процедур выглядел так же, как и локальный. Вызываемая программа не должна уведомляться о том, что вызываемая процедура располагается на другой машине, и наоборот. Если процедура является удаленной, то в библиотеку помещается специальная версия этой процедуры, называемая клиентской \textbf{заглушкой} (\textit{вероятнее всего, имеется ввиду паттерн Facade (80\%) или Proxy(20\%), прим. Овчинников}).
Идея, стоящая за RPC, состоит в том, чтобы удаленный вызов процедур выглядел так же, как и локальный. Вызываемая программа не должна уведомляться о том, что вызываемая процедура располагается на другой машине, и наоборот. Если процедура является удаленной, то в библиотеку помещается специальная версия этой процедуры, называемая клиентской \textbf{заглушкой} (\textit{вероятнее всего, имеется ввиду паттерн Facade (80\%) или Proxy(20\%), прим. Овчинников}).
\def\svgwidth{50mm}
\begin{figure}[H]
\input{pics/01-dis-00-rpc.pdf_tex}
\centering
\fontsize{12}{1}\selectfont
\includesvg[scale=1.01]{pics/01-dis-00-rpc.svg}
\end{figure}
Если \code{read}, например, локальная процедура, то она вызывает процедуру ОС. В отличие от оригинальной функции (т.е. функции, которая вызывается локально), клиентская заглушка не запрашивает данные ОС. Заглушка упаковывает параметры в сообщение и путем вызова процедуры \code{send()} требует переслать это сообщение на удаленный сервер. После вызова \code{send()} клиентская заглушка вызывает процедуру \code{receive()}, блокируясь до получения ответа.
Если \code{read}, например, локальная процедура, то она вызывает процедуру ОС. В отличие от оригинальной функции (т.е. функции, которая вызывается локально), клиентская заглушка не запрашивает данные ОС. Заглушка упаковывает параметры в сообщение и путем вызова процедуры \code{send()} требует переслать это сообщение на удаленный сервер. После вызова \code{send()} клиентская заглушка вызывает процедуру \code{receive()}, блокируясь до получения ответа.
Когда сообщение приходит на сервер, ОС сервера передает его серверной заглушке. Серверная заглушка – фрагмент кода, который преобразует запросы, приходящие по сети, в вызовы локальных процедур. Обычно серверная заглушка запускает процедуру \code{receive} и блокируется, ожидая входящих сообщений. После получения сообщения, серверная заглушка распаковывает сообщение, извлекает параметры и традиционным способом вызывает процедуру сервера. Параметры передаются через стек. Затем процедура выполняется и возвращает результат. Упаковывается результат, серверная заглушка вызывает процедуру \code{send} для передачи результата.
Когда сообщение приходит на сервер, ОС сервера передает его серверной заглушке. Серверная заглушка -- фрагмент кода, который преобразует запросы, приходящие по сети, в вызовы локальных процедур. Обычно серверная заглушка запускает процедуру \code{receive} и блокируется, ожидая входящих сообщений. После получения сообщения, серверная заглушка распаковывает сообщение, извлекает параметры и традиционным способом вызывает процедуру сервера. Параметры передаются через стек. Затем процедура выполняется и возвращает результат. Упаковывается результат, серверная заглушка вызывает процедуру \code{send} для передачи результата.
\subsubsection{Спецификация параметров и генерация заглушек в RPC}
\subsubsection{Спецификация параметров и генерация заглушек в RPC}
При вызове нужно, чтобы обе стороны следовали одному протоколу, т.е. нужно, чтобы они договорились о формате сообщений, которыми они будут обмениваться, о порядке действий, представлении простых типов данных. Обе стороны должны сформировать заглушки. Заглушки, работающие по одному протоколу для разных процедур, различаются только интерфейсом. Интерфейс состоит из набора прототипов процедур, которые могут быть вызваны клиентом, но реализованы на сервере. Для упрощения создания заглушек интерфейсы часто описываются с использованием языка определения интерфейсов IDL\footnote{interface description language}. Интерфейсы, определенные на IDL, могут быть скомпилированы в заглушки. Поскольку клиентские и серверные заглушки легко сгенерировать полностью автоматически, все системы промежуточного уровня, основанные на RPC используют IDL для поддержки разработки ПО.
При вызове нужно, чтобы обе стороны следовали одному протоколу, т.е. нужно, чтобы они договорились о формате сообщений, которыми они будут обмениваться, о порядке действий, представлении простых типов данных. Обе стороны должны сформировать заглушки. Заглушки, работающие по одному протоколу для разных процедур, различаются только интерфейсом. Интерфейс состоит из набора прототипов процедур, которые могут быть вызваны клиентом, но реализованы на сервере. Для упрощения создания заглушек интерфейсы часто описываются с использованием языка определения интерфейсов IDL\footnote{interface description language}. Интерфейсы, определенные на IDL, могут быть скомпилированы в заглушки. Поскольку клиентские и серверные заглушки легко сгенерировать полностью автоматически, все системы промежуточного уровня, основанные на RPC используют IDL для поддержки разработки ПО.
\subsubsection{О расширении модели RPC}
\subsubsection{О расширении модели RPC}
Здесь речь идет об асинхронном вызове удаленных процедур. Базовая модель – синхронная.
Здесь речь идет об асинхронном вызове удаленных процедур. Базовая модель -- синхронная.
Можно предположить, что ответ не нужен. Тогда не нужно блокировать вызов приложений.
Можно предположить, что ответ не нужен. Тогда не нужно блокировать вызов приложений.
@ -370,10 +380,14 @@ Java-serverlets
\item Обнаружение машины-сервера.
\item Обнаружение машины-сервера.
\item Обнаружение службы-сервера, т.е. нужного процесса на этой машине.
\item Обнаружение службы-сервера, т.е. нужного процесса на этой машине.
\end{enumerate}
\end{enumerate}
В общем случае для того, чтобы связаться с сервером, клиенту нужно знать конечную точку (\textit{endpoint, прим. Овчинников}) машины сервера, в которую он может посылать сообщение. Конечная точка (порт) используется ОС сервера для получения входящих сообщений от различных внешних процессов. В системе DCE на каждой из серверных машин процессом, известным под названием DCE Демон, поддерживается таблица пар сервер - конечная точка. Перед тем как сервер станет доступным для входящих запросов, он должен запросить уОС конечную точку. Далее сервер регистрирует эту конечную точку у DCE Демона. DCE Демон записывает эту информацию, включая протоколы, по которым осуществляется обмен информацией в конечных точках, для последующего использования. Сервер службы каталогов также регистрирует предоставленный серверной машине сетевой адрес и имя, под которым сервер будет доступен.
В общем случае для того, чтобы связаться с сервером, клиенту нужно знать конечную точку (\textit{endpoint, прим. Овчинников}) машины сервера, в которую он может посылать сообщение. Конечная точка (порт) используется ОС сервера для получения входящих сообщений от различных внешних процессов. В системе DCE на каждой из серверных машин процессом, известным под названием DCE Демон, поддерживается таблица пар сервер -- конечная точка. Перед тем как сервер станет доступным для входящих запросов, он должен запросить уОС конечную точку. Далее сервер регистрирует эту конечную точку у DCE Демона. DCE Демон записывает эту информацию, включая протоколы, по которым осуществляется обмен информацией в конечных точках, для последующего использования. Сервер службы каталогов также регистрирует предоставленный серверной машине сетевой адрес и имя, под которым сервер будет доступен.
\def\svgwidth{150mm}
\input{pics/01-dis-00-dce.pdf_tex}
\begin{figure}[H]
\centering
\fontsize{12}{1}\selectfont
\includesvg[scale=1.01]{pics/01-dis-00-dce.svg}
\end{figure}
\begin{enumerate}
\begin{enumerate}
\item Регистрация конечной точки;
\item Регистрация конечной точки;
@ -386,10 +400,10 @@ Java-serverlets
\paragraph{Обращения к удаленным объектам}
\paragraph{Обращения к удаленным объектам}
По мере накопления опыта применения механизма RPC в распределенных системах пришло понимание того, что эти принципы могут быть применены и к объектам. При этом единственно правильным способом доступа к данным является использование методов, доступ к которым осуществляется через интерфейс объекта. Объект может реализовывать множество интерфейсов. Интерфейсы могут наследоваться разными классами, и в каждом классе интерфейс может реализовываться по-разному. Подразделение на интерфейсы и объекты, реализующие эти интерфейсы, очень важно для распределенных интерфейсов. Такое четкое разделение позволяет помещать интерфейс на одну машину, а сам объект на другую.
По мере накопления опыта применения механизма RPC в распределенных системах пришло понимание того, что эти принципы могут быть применены и к объектам. При этом единственно правильным способом доступа к данным является использование методов, доступ к которым осуществляется через интерфейс объекта. Объект может реализовывать множество интерфейсов. Интерфейсы могут наследоваться разными классами, и в каждом классе интерфейс может реализовываться по-разному. Подразделение на интерфейсы и объекты, реализующие эти интерфейсы, очень важно для распределенных интерфейсов. Такое четкое разделение позволяет помещать интерфейс на одну машину, а сам объект на другую.
\begin{figure}[H]
\begin{figure}
\centering
\centering
\def\svgwidth{120mm}
\fontsize{12}{1}\selectfont
\input{pics/01-dis-00-proxy.pdf_tex}
\includesvg[scale=1.01]{pics/01-dis-00-proxy.svg}
\caption{Обобщённая организация распределённых объектов с использованием заместителей клиентов}
\caption{Обобщённая организация распределённых объектов с использованием заместителей клиентов}
\label{pic:dceProxy}
\label{pic:dceProxy}
\end{figure}
\end{figure}
@ -423,10 +437,10 @@ Java-serverlets
\textbf{Разрешение ссылки}– это общепринятый термин процесса поиска объекта по ссылке. В случае явной привязки клиент должен до обращения к методам объекта вызвать специальную функцию для привязки к объекту. При явной привязке обычно возвращается указатель на локально доступный заместитель.
\textbf{Разрешение ссылки}– это общепринятый термин процесса поиска объекта по ссылке. В случае явной привязки клиент должен до обращения к методам объекта вызвать специальную функцию для привязки к объекту. При явной привязке обычно возвращается указатель на локально доступный заместитель.
\paragraph{Реализация ссылок на объекты}
\paragraph{Реализация ссылок на объекты}
Ссылки на объекты должны содержать достаточно информации, чтобы обеспечить клиентами привязку к объектам. Один из вариантов ссылки – простая ссылка на объект – содержит сетевой адрес машины, на которой размещен реальный объект вместе с конечной точкой, определяющей сервер, который управляет объектом, и указанием на то, что это за объект. На практике конечная точка соответствует локальному порту, который динамически выделяется локальным хост сервером. Недостатки такого варианта:
Ссылки на объекты должны содержать достаточно информации, чтобы обеспечить клиентами привязку к объектам. Один из вариантов ссылки -- простая ссылка на объект – содержит сетевой адрес машины, на которой размещен реальный объект вместе с конечной точкой, определяющей сервер, который управляет объектом, и указанием на то, что это за объект. На практике конечная точка соответствует локальному порту, который динамически выделяется локальным хост сервером. Недостатки такого варианта:
\begin{enumerate}
\begin{enumerate}
\item если на сервере произойдет сбой, и после восстановления он получит другую конечную точку, то все ссылки на объект станут неправильными. Решение – создать на серверной машине локального демона, который будет опрашивать известные конечные точки, и отслеживать назначение конечных точек серверу в таблице конечных точек. После привязки клиента к объекту нужно запросить у демона текущую конечную точку сервера. Такой подход требует кодирования идентификатора сервера в ссылке на объект. Отсюда следствие – сервер всегда должен регистрироваться локальным демоном, чтобы его можно было найти.
\item если на сервере произойдет сбой, и после восстановления он получит другую конечную точку, то все ссылки на объект станут неправильными. Решение – создать на серверной машине локального демона, который будет опрашивать известные конечные точки, и отслеживать назначение конечных точек серверу в таблице конечных точек. После привязки клиента к объекту нужно запросить у демона текущую конечную точку сервера. Такой подход требует кодирования идентификатора сервера в ссылке на объект. Отсюда следствие – сервер всегда должен регистрироваться локальным демоном, чтобы его можно было найти.
\item Идея кодирования сетевого адреса машины-сервера в ссылке на объект – это тоже неудачная идея. Проблема подобного подхода в том, что в этом случае сервер невозможно перенести на другую машину, не объявив недействительными все ссылки на объекты, которыми он управлял.
\item Идея кодирования сетевого адреса машины-сервера в ссылке на объект -- это тоже неудачная идея. Проблема подобного подхода в том, что в этом случае сервер невозможно перенести на другую машину, не объявив недействительными все ссылки на объекты, которыми он управлял.
\end{enumerate}
\end{enumerate}
\textbf{Решение}– распространение идеи локальных демонов, поддерживающих таблицы конечных точек на сервер локализации, постоянно следящий за работой серверов, на которых расположены объекты. Тогда ссылка на объект должна содержать сетевой адрес сервера локализации, а также действующий в системе идентификатор сервера.
\textbf{Решение}– распространение идеи локальных демонов, поддерживающих таблицы конечных точек на сервер локализации, постоянно следящий за работой серверов, на которых расположены объекты. Тогда ссылка на объект должна содержать сетевой адрес сервера локализации, а также действующий в системе идентификатор сервера.
@ -439,10 +453,10 @@ Java-serverlets
\item на каждую сущность ссылается не более одного идентификатора (\textit{как сложно он сказал о связи один-к-одному, прим Овчинников});
\item на каждую сущность ссылается не более одного идентификатора (\textit{как сложно он сказал о связи один-к-одному, прим Овчинников});
\item идентификатор всегда ссылается на одну и ту же сущность (\textit{однозначный и неизменяемый, проще говоря, прим Овчинников}).
\item идентификатор всегда ссылается на одну и ту же сущность (\textit{однозначный и неизменяемый, проще говоря, прим Овчинников}).
\end{itemize}
\end{itemize}
Связывание имён - это установление соответствия имени и адреса. Имена бывают составные. Составное имя - это последовательность простых имён, задающих путь к объекту через ряд контекстов именований. Сервер именований обычно поддерживает две операции:
Связывание имён -- это установление соответствия имени и адреса. Имена бывают составные. Составное имя - это последовательность простых имён, задающих путь к объекту через ряд контекстов именований. Сервер именований обычно поддерживает две операции:
\begin{itemize}
\begin{itemize}
\item операция связывания (создаёт новое связывание имени для объекта), используется для регистрации объекта сервера на сервере именований. В качестве параметра принимается имя и объектная ссылка.
\item операция связывания (создаёт новое связывание имени для объекта), используется для регистрации объекта сервера на сервере именований. В качестве параметра принимается имя и объектная ссылка.
\item операция разрешения - возвращает объектную ссылку для имени, переданного в качестве параметра.
\item операция разрешения -- возвращает объектную ссылку для имени, переданного в качестве параметра.
\end{itemize}
\end{itemize}
Можно выделить три типа имён:
Можно выделить три типа имён:
\begin{enumerate}
\begin{enumerate}
@ -452,9 +466,9 @@ Java-serverlets
\end{enumerate}
\end{enumerate}
Пространства имён удобно разбить на три уровня:
Пространства имён удобно разбить на три уровня:
\begin{enumerate}
\begin{enumerate}
\item глобальный - содержимое этого уровня почти всегда постоянно;
\item глобальный -- содержимое этого уровня почти всегда постоянно;
\item административный - редко меняется, можно использовать репликацию и кэширование для увеличения быстродействия;
\item административный -- редко меняется, можно использовать репликацию и кэширование для увеличения быстродействия;
\item управленческий - меняется часто, для эффективности и производительности операции поиска и обновления. Операции поиска происходят в два этапа: обращение к службе именования (полуаем идентификатор), определение ссылки по идентификатору (находим объект). На этом уровне могут работать службы локализации, на входе идентификатор, на выходе ссылка. Один из вариантов - передача указателей. Для этого часть используется пара заместитель-скелетон.
\item управленческий -- меняется часто, для эффективности и производительности операции поиска и обновления. Операции поиска происходят в два этапа: обращение к службе именования (полуаем идентификатор), определение ссылки по идентификатору (находим объект). На этом уровне могут работать службы локализации, на входе идентификатор, на выходе ссылка. Один из вариантов -- передача указателей. Для этого часть используется пара заместитель-скелетон.
\end{enumerate}
\end{enumerate}
\item\textbf{Трейдинг}. Определяет местонахождение объектов-серверов исходя из предоставляемых объектами-серверами функций и требуемого качества обслуживания. То есть клиент отправляет не имя, а требуемую функцию с условиями (предикатом). Трейдер выбирает поставщика услуги по запросу и параметрам клиента. Компоненты трейдинга:
\item\textbf{Трейдинг}. Определяет местонахождение объектов-серверов исходя из предоставляемых объектами-серверами функций и требуемого качества обслуживания. То есть клиент отправляет не имя, а требуемую функцию с условиями (предикатом). Трейдер выбирает поставщика услуги по запросу и параметрам клиента. Компоненты трейдинга:
\begin{enumerate}
\begin{enumerate}
@ -473,15 +487,20 @@ Java-serverlets
\subsection{Удалённое обращение к методам}
\subsection{Удалённое обращение к методам}
После того как клиент связался с нужным объектом, он, через заместитель, обращается к методу (RMI remote method invocation). Упаковка обращения это маршаллинг, распаковка демаршаллинг. Вызов напоминает RPC. Стандартный способ поддержки это описание интерфейсов объектов (IDL interface definition language).
После того как клиент связался с нужным объектом, он, через заместитель, обращается к методу (RMI remote method invocation). Упаковка обращения это маршаллинг, распаковка демаршаллинг. Вызов напоминает RPC. Стандартный способ поддержки это описание интерфейсов объектов (IDL interface definition language).
\begin{enumerate}
\begin{enumerate}
\item Динамическое обращение - процесс, когда параметры обращения к методу собираются во время выполнения программы. Метод становится определён только на этапе выполнения программы.
\item Динамическое обращение -- процесс, когда параметры обращения к методу собираются во время выполнения программы. Метод становится определён только на этапе выполнения программы.
\item Статическое обращение - подход, который использует заранее заданные определения интерфейсов. Требует, чтобы интерфейсы объекта были известны при разработке клиентской части.
\item Статическое обращение -- подход, который использует заранее заданные определения интерфейсов. Требует, чтобы интерфейсы объекта были известны при разработке клиентской части.
\end{enumerate}
\end{enumerate}
Когда объекты распределённые - объекты доступны со всех машин. Ссылки на объекты при вызове методов передаются по значению, то есть копируются с одной машины на другую.
Когда объекты распределённые -- объекты доступны со всех машин. Ссылки на объекты при вызове методов передаются по значению, то есть копируются с одной машины на другую.
\def\svgwidth{50mm}
\begin{figure}
\input{pics/01-dis-01-rmi.pdf_tex}
\centering
\fontsize{12}{1}\selectfont
\includesvg[scale=1.01]{pics/01-dis-01-rmi.svg}
\caption{}
\label{pic:01-dis-01-rmi}
\end{figure}
Если объект был локальным он копируется, если были ссылки - копируются только ссылки.
Если объект был локальным он копируется, если были ссылки -- копируются только ссылки.
