BMSTU/01-distributed-information-systems.tex

\documentclass{article}

\input{../common-preamble}
\input{../fancy-listings-preamble}
\input{../bmstu-preamble}
\author{Локтев Даниил Алексеевич (426ю можно досдать отчёты по лабам)}
\title{Распределённые информационные системы}
\date{2021-09-08}

\begin{document}
\maketitle
\newpage
\section{Предисловие}
\subsection{Оргвопросы}
лекции один раз в две недели (всего 8 лекций),  лабораторные работы (3 шт) с 9й недели (25.10) 507ю по понедельникам 1350-1715. Лучше делать дома и приходить защищать (отчёты по каждой лабораторной)

Итоговая форма - зачёт (2 модуля, рубежный контроль письменно и лабы):
\begin{enumerate}
\item симулятор распределения вычислений по эвм, 
\item пакман алгоритмы на графах, 
\item клиент-сервер на двух разных языках.
\end{enumerate}
\subsection{Литература}
Танненбаум, ван Стеен: Распределённые системы. Принципы и парадигмы

Лычёв: Распределённые автоматизированные сиситемы (учебное пособие)

Карпов: Архитектура распределённых систем программного обеспечения

Радченко: Распределённые вычислительные системы

Хон, Вульф: Шаблоны интеграции корпоративных приложений
\section{Основное понятие}
распределённая информационная система - это такая информационная система, в которой информация и её обработка распределены между несколькими устройствами. То есть это набор независимых устройств, которые пользователю предоставляются как единое целое. Может быть распределена как аппаратная, так и программная часть. В первую очередь это распределённое программное обеспечение. Основная общая модель - это клиент-сервер. Клиент выдаёт запросы и получает от сервера ответы. Взаимодействие может быть двух видов:
\begin{itemize}
\item синхронное - клиент даёт запрос и только после получения ответа продолжает работу.

  \begin{frm}
    \def\svgwidth{70mm}
    \input{pics/01-dis-00-sync.pdf_tex}
    \label{pic:clientsync}
  \end{frm}
  
  Клиент запраживает службу у Сервера и ожидает ответа от сервера, полностью бездействуя
\item асинхронное - клиент не блокируется.

  \begin{frm}
    \def\svgwidth{70mm}
    \input{pics/01-dis-00-async.pdf_tex}
    \label{pic:clientasync}
  \end{frm}
  
  Клиент запраживает службу у Сервера и возвращает управление себе, работает без ожидания. Когда приходит ответ от Сервера, клиент посылает сигнал подтверждения получения ответа.
\end{itemize}
Процессы внутри информационных систем делятся на две группы:
\begin{itemize}
\item реализующие некоторую службу (служебные процессы). серверы
\item запрашивающие службу у процессов первого типа. клиенты.
\end{itemize}
Типы клиент-серверных архитектур
\begin{enumerate}
\item одноярусные: все три слоя (логических уровня) находятся в одном ярусе - то есть одно устройство. Презентационный слой - это терминал, а логика и ресурсы это приложение;
\item двухярусные: обычно, отображение отделяется от обработки;
\item трёхярусные: презентационный слой на клиенте, слой прикладной логики на среднем ярусе и слой управления ресурсами отделяется на третье устройство;
\item многоярусные: обычно прикладной слой уже делается на разном железе. Или примером такой архитектуры может служить объединение неоднородных систем в одну.
\end{enumerate}
При реализации клиент-серверной архитектуры есть три слоя \textit{(есть ощущение, что здесь речь о \textbf{MVC}, прим. Овчинников)}
\begin{enumerate}
\item презентационный слой (интерфейс, UI) то, с чем работает пользователь (обычно клиент);
\item слой прикладной логики (слой логики приложения, APP);
\item слой управления ресурсами (организовывает доступ к данным, RES) включает в себя не только просто ресурсы, но и другие двух- и трёхъярусные модели.
\end{enumerate}
\begin{figure}[H]
  \centering
  \def\svgwidth{50mm}
  \input{pics/01-dis-00-division.pdf_tex}
  \caption{Варианты деления клиент-серверной архитектуры}
  \label{pic:division}
\end{figure}

Например: 
приложение розничных продаж, где все взаимосвязи происходят через логику приложений, база данных у каждого будет со своим сегментом данных, поэтому ресурсы, получается, отделены друг от друга.

\begin{tikzpicture}[ x=1pt, y=1pt, yscale=1, xscale=1, transform shape ]
\draw (0,0) rectangle (75, 100); 
\draw (2, 30) node [anchor=north west][inner sep=0.75pt][align=left] {Доступ\\к данным};
\draw (2, 60) node [anchor=north west][inner sep=0.75pt][align=left] {Логика\\приложения};
\draw (105,0) rectangle (210, 100); 
\draw (107, 30) node [anchor=north west][inner sep=0.75pt][align=left] {Доступ\\к данным};
\draw (107, 60) node [anchor=north west][inner sep=0.75pt][align=left] {Логика\\приложения};
\draw (107, 90) node [anchor=north west][inner sep=0.75pt][align=left] {Пользовательский\\интерфейс};
\draw (240,0) rectangle (315, 100); 
\draw (242, 30) node [anchor=north west][inner sep=0.75pt][align=left] {Доступ\\к данным};
\draw (242, 60) node [anchor=north west][inner sep=0.75pt][align=left] {Логика\\приложения};
\draw (100,110) rectangle (215, 150); 
\draw (130, 135) node [anchor=north west][inner sep=0.75pt][align=left] {Пользователь};

\draw[->] (150, 110) -- (150, 90);
\draw[<-] (155, 110) -- (155, 90);

\draw[<->] (60, 46) -- (108, 46);
\draw[<->] (200, 46) -- (243, 46);

\draw (2, 0) node [anchor=north west][inner sep=0.75pt][align=left] {Система онлайн\\платежей};
\draw (107, 0) node [anchor=north west][inner sep=0.75pt][align=left] {Система розничных\\продаж};
\draw (242, 0) node [anchor=north west][inner sep=0.75pt][align=left] {Партнёр по\\доставке товаров};
\end{tikzpicture}

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

\begin{tikzpicture}[ x=1pt, y=1pt, yscale=1, xscale=1, transform shape ]
\draw (0,0) rectangle (100, 100); 
\draw (2, 60) node [anchor=north west][inner sep=0.75pt][align=left] {Логика\\приложения};
\draw (2, 10) node [anchor=north west][inner sep=0.75pt][align=left] {Клиентская часть};
\draw (42, 90) node [anchor=north west][inner sep=0.75pt][align=left] {Логика\\для клиента};
\draw (110,0) rectangle (210, 100); 
\draw (152, 60) node [anchor=north west][inner sep=0.75pt][align=left] {Логика\\приложения};
\draw (112, 10) node [anchor=north west][inner sep=0.75pt][align=left] {Клиентская часть};
\draw (112, 90) node [anchor=north west][inner sep=0.75pt][align=left] {Логика\\для клиента};
\draw (0,110) rectangle (100, 210); 
\draw (2, 170) node [anchor=north west][inner sep=0.75pt][align=left] {Логика\\приложения};
\draw (2, 210) node [anchor=north west][inner sep=0.75pt][align=left] {Управяющий сервер};
\draw (110,110) rectangle (210, 210); 
\draw (152, 170) node [anchor=north west][inner sep=0.75pt][align=left] {Логика\\приложения};
\draw (112, 210) node [anchor=north west][inner sep=0.75pt][align=left] {Управяющий сервер};

\draw[<->] (10, 60) -- (10, 150);
\draw[<->] (50, 160) -- (155, 160);
\draw[<->] (80, 80) -- (145, 50);
\draw[<->] (50, 50) -- (115, 80);
\draw[<->] (170, 150) -- (170, 60);

\end{tikzpicture}

\section{Программная компонента}
Программная компонента - это единица программного обеспечения, исполняемая на одном компьютере в пределах одного процесса и представляющая некий набор сервисов или служб, которые используются через её внешний интерфейс другими компонентами, выполняемыми как на этом же компьютере, так и на удалённом. Распределённая информационная система - это набор взаимодействующих программных компонент, выполняемых на одном или нескольких связанных компьютерах и выглядящих с точки зрения пользователя как единое целое. Распределение должно быть скрыто от пользователя, то есть пользователь должен представлять, что система это единое целое. Такое сокрытие называется "прозрачность".

Основные характеристики распределённых информационных систем
\begin{enumerate}
\item совместное использование ресурсов
\item открытость (с точки зрения программиста)
\item параллельность
\item масштабируемость
\item отказоустойчивость
\item прозрачность
\end{enumerate}

Заблуждения о распределённых информационных системах 
\begin{enumerate}
\item сеть является надёжной
\item задержка равна нулю
\item полоса пропускания неограничена
\item сеть является безопасной
\item топология сети не меняется (с течением времени)
\item есть только один администратор (у каждой части системы может быть свой)
\item сеть однородна (топологии могут быть разными даже в рамках одной системы)
\end{enumerate}
\section{Существующие концепции}
Как строится распределённая система: можно разделить как на аппаратном, так и на программном уровне
\subsection{Концепции аппаратных решений}
\begin{figure}[h!]
  \includegraphics[width=10cm]{01-dis-00-concept.png}
  \label{pic:concept}
\end{figure}
\subsection{Концепции программных решений}
Именно программное решение более явно отличает распределение системы. Распределённые системы в этом плане похожи на обычные операционные системы: есть менеджер ресурсов, который помогает пользователям и аппаратным составляющим совместно использовать процессоры, память, сеть и другие периферийные устройства, и работать с системой, как с распределённой.  Именно программно скрывает распределённость от пользователя. Операционные системы для распределённых систем можно разделить на категории:
\begin{itemize}
\item \textbf{слабо связанные:} операционная система воспринимается как набор независимых операционных систем. Подвид - сетевые операционные системы. Для них не требуется прямой доступ к аппаратному обеспечению. Не требуют, чтобы аппаратное обеспечение на котором они функционируют было однородным и управлялось как единая система. Абстрагирует от аппаратных решений. Но одной только сетевой операционной системы недостаточно для создания распределённой системы, необходимы также компоненты, которые поддерживают прозрачность распределения. За такие компоненты отвечает промежуточный уровень распределённой системы:
  
  \includegraphics[width=8cm]{01-dis-00-spo.png}
\item \textbf{сильно связанные:} операционная система старается работать с одним глобальным представлением ресурсов, которыми она управляет. Обычно используется именно такая связанность для управления распределёнными системами.
\end{itemize}
\subsection{Програмное обеспечение промежуточного уровня}
Распределённые операционные системы не предназначены для управления набором независимых компонент, а сетевые операционные системы не дают одной согласованной системы. Поэтому нужны системы, которые объединяют плюсы сетевых операционных систем (масштабируемость, открытость, итд), и плюсы распределённых систем (прозрачность, относительная простота использования). Программное обеспечение промежуточного уровня скрывает неоднородность, например. Отдельными узлами всё также будет управлять локальная операционная система, но промежуточный уровень позволяет использовать единый набор служб, давая пользователю однородность. Основная задача - скрыть разнообразие базовых платформ от приложений.
\subsection{Модели промежуточного уровня}
\begin{enumerate}
\item представление всех объектов в виде файлов (нет отличия между удалёнными и локальными файлами) тогда программное обеспечение будет построено по принципу распределённой файловой системы (distributed filesystem);
\item промежуточный уровень основан на удалённом вызове процедур (RPC remote procedure call). Процессу разрешается вызывать процедуру из другого процесса. Вызов ничем не отличается от вызова локальной процедуры.
  
 \includegraphics[width=8cm]{01-dis-00-rpc.png}

 Когда происходит обращение к удалённому объекту, принцип тот же, но к объетам, удалённый вызов например метода, передача данных об объекте.
\item модель распределённых документов (вся информация располагается в документах, которые прозрачны для пользователя). По сути это дополнительные заголовки, объектизация файлов для проверки целостности, расположения, итд.
\end{enumerate}
\subsection{Службы промежуточного уровня}
Программное обеспечение должно организовывать прозрачность путём предоставления высокоуровневых средств связи (скрыть низкий уровень). этому содействуют:
\begin{enumerate}
\item Служба именования (совместный поиск и использование сущностей). Любая сущность может иметь фиксированное местоположение, или сущность может мигрировать, но нейминг нас от этого абстрагирует;
\item служба сохранности (механизм распределённых транзакций), поддержка целостности данных. Контроль успешности транзакций, например, с БД. В случае неуспеха возвращает все объекты в исходное состояние.
\item служба защиты (обычно распределены и часто это создаёт проблемы, но позволяет взаимозаменять такие службы). 
\end{enumerate}

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

\subsection{Распределённое событие}
В распределённых системах может возникнуть необходимость использовать извещения от удалённых подсистем. Так могут возникать два типа событий: сильно и слабо связанные. При сильно связанном событии происходит прямое уведомление, обе стороны должны быть активны одновременно. При слабо связанном событии - передача информации происходит через вспомогательный сервис, источники (издатели) напрямую не взаимодействуют с получателями (подписчиками), что позволяет получателям подписаться на событие и отвязывает сервис от необходимости находиться с получателем на одном компьютере. Распределённое событие может быть реализовано как вызов метода удалённого объекта.
\subsection{Распределённые транзакции (ACID)}
\begin{enumerate}
\item атомарность - всё или ничего
\item согласованность - либо успех либо откат - все данные логически целостны, согласованность не нарушается
\item изоляция - объектам вне транзакции не видны промежуточные состояния данных внутри транзакции
\item постоянство - в случае успешности изменения имеют постоянных характер.
\end{enumerate}
\begin{figure}[h!]
  \centering
  \includegraphics[width=8cm]{01-dis-00-distrans.png}
  \caption{Участники распределённой транзакции}
  \label{pic:distrans}
\end{figure}
Условия необходимые для отмены транзакции:
\begin{enumerate}
\item Промежуточная среда должна поддерживать управление распределенными между несколькими компонентами транзакции.  
\item Компоненты распределенной системы не должны работать с какими либо службами ли ресурсами которые не могут участвовать в транзакции 
\end{enumerate}

\section{Общие сведения о J2EE}
\textbf{Платформа J2EE} - это комплекс взаимодействующих технологий базирующихся на спецификациях фирмы Sun (Oracle) и представляющих собой стандарт разработки серверных приложений уровня предприятий.

Особенности стандарта J2EE:
\begin{itemize}
\item Независимость от платформы 
\item Простота разработки приложений уровня предприятия на основе компонентных технологий 
\item Переносимость и расширяемость 
\item Поддержка многопользовательского режима 
\item Возможность разработки распределенных приложений 
\item Интеграционные возможности
  \begin{itemize}
  \item с другими платформами 
  \item с корпоративными информационными системами 
  \end{itemize}
\item Обеспечение надежной защиты 
\end{itemize}

Состав J2EE:
\begin{itemize}
\item Спецификация 
\item Образцовые реализации платформы 
\item Модель приложений J2EE 
\item Набор тестов для совместимости 
\end{itemize}

Технологии J2EE:
\begin{itemize}
\item Вызов удаленных методов RMI (Remote Method Invocation) 
\item Интерфейс наименования каталогов JNDI (Java Naming And Directory Interface) 
\item Сервис сообщений JMS (Java Message Service) 
Java-serverlets 
\item Сервис страниц JSP (Java Server Pages) (HTML + JS) 
\item Организация работы с базой данных JDBC (Java data base connectivity) 
\item Служба транзакций JTA (Java Transaction API); Сервис транзакций JTS (Java transaction Service) 
\item Контейнер компонентов логики EJB (Enterprise Java Beans) 
\item Язык определения интерфейсов IDL (Interface Definition Language) 
\item Почта и структура активизация работы JJM (Java Beans Java Mail) и JAF (Java Beans Activation Framework) 
\item Архитектура соединителей и коннекторов J2EE Connector Architecture 
\item XML парсер JAXP (Java Api for Xml Parsing) 
\item Идентификация и авторизация JAAS (Java Authentication and Authorization Service) 
\end{itemize}

\begin{figure}[h!]
  \centering
  \includegraphics[height=4cm]{01-dis-00-platform.png}
  \caption{Архитектура J2EE}
  \label{pic:j2eearch}
\end{figure}

Уровни платформы:
\begin{itemize}
\item Web-уровень 
\item EJB 
\item Уровень сервера БД (EIS - enterprise information server) 
\end{itemize}

Приложение должно поддерживать:
\begin{itemize}
\item Браузер 
\item Апплеты 
\item Автономные Java приложения 
\item Приложения клиенты написанные на других языках 
\end{itemize}

Уровень приложений содержит:
\begin{itemize}
\item Java - серверлеты 
\item Java - страницы JPS 
\item Страницы HTML 
\item JavaScript 
\item Классы 
\end{itemize}

Уровень бизнес логики (EJB) - работает в адресном пространстве сервера приложений и через компоненты EJB осуществляет доступ к БД.
Основные задачи контейнера EJB:
\begin{enumerate}
\item Доступ к инфраструктуре J2SE 
\item Управление жизненным циклом компонентов 
\item Доступ к БД (JDBC) 
\end{enumerate}

Когда клиент обращается к компоненту, контейнер перехватывает это сообщение для обеспечения безопасности. Разработчику предоставляется 3 механизма взаимодействия:
\begin{enumerate}
\item Методы обратного вызова (RMI) до или сразу после некоторого события 
\item Контекст EJB Context 
\item Интерфейс имен (JNDI) 
\end{enumerate}
Контейнер EJB автоматически формирует набор свободных соединений с БД.

\includegraphics[width=7cm]{01-dis-00-ejb.png}

Контейнер позволяет объединить несколько компонентов EJB внутри одной транзакции. Компонент EJB представляет собой законченный функциональный модуль встроенный в приложение платформы J2EE соответствующими классами и файлами.  
Контейнеры J2EE:
\begin{itemize}
\item Контейнер клиентского приложения 
\item Серверная часть 
\item Web-контейнер 
\item EJB-контейнер 
\end{itemize}
\subsection*{Из конспекта 2017}
\includegraphics[width=14cm]{01-dis-00-2017.pdf}

\section{Протоколы}
\subsection{Верхнего уровня}
Поверх транспортного уровня в модели OSI присутствует 3 дополнительных уровня. Однако в протоколах, действующих в Интернете, все, что выше транспортного уровня, собирается в одну группу. С точки зрения промежуточного уровня ни подход OSI, ни подход, действующий в Интернете, не является удачным. Сейчас на верхнем уровне собирают все протоколы, которые не удалось отнести к боле низким уровням.

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

Примеры специальных прикладных протоколов: FTP, HTTP\footnote{В настоящее время HTTP в том числе используется в системах, связь которых с Web не предполагается. Например, в RMI HTTP используется для обращения к удаленным объектам}.
\subsection{Промежуточного уровня}
К промежуточному уровню относятся приложения, логически помещаемые на прикладной уровень, но содержащие множество протоколов общего назначения, что дает им право на их собственный уровень, независимый от других более специализированных приложений. \textbf{Например:} Различные методы аутентификации. Протоколы аутентификации не привязаны к какому либо конкретному приложению, поэтому они встраиваются в системы промежуточного уровня на правах общей службы. Протоколы авторизации также имеют тенденцию к переходу на независимый уровень. \textbf{Другой пример} – множество протоколов \textit{распределенного подтверждения}. Протоколы подтверждения делают так, чтобы в группе процессов либо все процессы прошли через определенную операцию, либо операция не была применена ни к одному из процессов. Этот механизм (атомарность) используется при организации транзакций. \textbf{Еще пример} – протоколы распределенной блокировки, при помощи которых может быть предотвращен одновременный доступ к ресурсам сразу нескольких процессов, распределенных по множеству машин. Эти протоколы также могут быть реализованы в виде общедоступной службы промежуточного уровня, который не зависит от какого либо конкретного приложения. Коммуникационные протоколы промежуточного уровня поддерживают высокоуровневые коммуникационные службы, например есть высокоуровневые коммуникационные протоколы, которые позволяют процессам прозрачно вызывать процедуры или обращаться к объектам на удаленных машинах. Существуют также коммуникационные службы высокого уровня для запуска и синхронизации потоков данных в реальном времени. \textbf{Еще один пример} – предоставляемые некоторыми системами – надежные службы групповой рассылки, способные поддерживать тысячи получателей, разбросанных по глобальной сети.

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

\subsubsection{Удаленный вызов процедур (RPC)}
Программа не должна знать, что вызывается удаленная процедура. Сложность реализации:
\begin{itemize}
\item Разные адресные пространства на разных машинах.
\item Различные типы процессоров на разных машинах.
\item Компьютеры во время вызова удаленной процедуры могут дать сбой.
\item Передача параметров может осуществляться по-разному.
\end{itemize}
Идея, стоящая за RPC, состоит в том, чтобы удаленный вызов процедур выглядел так же, как и локальный. Вызываемая программа не должна уведомляться о том, что вызываемая процедура располагается на другой машине, и наоборот. Если процедура является удаленной, то в библиотеку помещается специальная версия этой процедуры, называемая клиентской \textbf{заглушкой} (\textit{вероятнее всего, имеется ввиду паттерн Facade (80\%) или Proxy(20\%), прим. Овчинников}).

\def\svgwidth{50mm}
\input{pics/01-dis-00-rpc.pdf_tex}

Если \code{read}, например, локальная процедура, то она вызывает процедуру ОС. В отличие от оригинальной функции (т.е. функции, которая вызывается локально), клиентская заглушка не запрашивает данные ОС. Заглушка упаковывает параметры в сообщение и путем вызова процедуры \code{send()} требует переслать это сообщение на удаленный сервер. После вызова \code{send()} клиентская заглушка вызывает процедуру \code{receive()}, блокируясь до получения ответа.

Когда сообщение приходит на сервер, ОС сервера передает его серверной заглушке. Серверная заглушка – фрагмент кода, который преобразует запросы, приходящие по сети, в вызовы локальных процедур. Обычно серверная заглушка запускает процедуру \code{receive} и блокируется, ожидая входящих сообщений. После получения сообщения, серверная заглушка распаковывает сообщение, извлекает параметры и традиционным способом вызывает процедуру сервера. Параметры передаются через стек. Затем процедура выполняется и возвращает результат. Упаковывается результат, серверная заглушка вызывает процедуру \code{send} для передачи результата.

\subsubsection{Спецификация параметров и генерация заглушек в RPC}
При вызове нужно, чтобы обе стороны следовали одному протоколу, т.е. нужно, чтобы они договорились о формате сообщений, которыми они будут обмениваться, о порядке действий, представлении простых типов данных. Обе стороны должны сформировать заглушки. Заглушки, работающие по одному протоколу для разных процедур, различаются только интерфейсом. Интерфейс состоит из набора прототипов процедур, которые могут быть вызваны клиентом, но реализованы на сервере. Для упрощения создания заглушек интерфейсы часто описываются с использованием языка определения интерфейсов IDL\footnote{interface description language}. Интерфейсы, определенные на IDL, могут быть скомпилированы в заглушки. Поскольку клиентские и серверные заглушки легко сгенерировать полностью автоматически, все системы промежуточного уровня, основанные на RPC используют IDL для поддержки разработки ПО.

\subsubsection{О расширении модели RPC}
Здесь речь идет об асинхронном вызове удаленных процедур. Базовая модель – синхронная.

Можно предположить, что ответ не нужен. Тогда не нужно блокировать вызов приложений.

\subsubsection{О спецификации DCE (Distributed Computing Environment)}
Среда построена с использованием технологии LPC (Local Procedure Call). Модель программирования, лежащая в основе DCE – это клиент-сервер. Процессы пользователей действуют как клиенты, вызывающие удаленные службы, предоставляемые серверными процессами. Вся связь между клиентами и серверами осуществляется с помощью LPC. Некоторые службы, работающие по этому принципу:
\begin{enumerate}
\item Служба распределенных файлов. Представляет собой всемирную файловую систему, предоставляющую прозрачные методы доступа к любому файлу системы одинаковым образом.
\item Служба каталогов. Используется для отслеживания местонахождения любого из ресурсов системы (компьютеры, принтеры и так далее). Служба каталогов позволяет процессу запрашивать ресурс.
\item Служба защиты. Позволяет защищать ресурсы любого компьютера. При этом получение некоторых данных может быть открыто только тем, кому это разрешено.
\item Служба распределенного времени. Позволяет поддерживать глобальную синхронизацию часов различных компьютеров.
\end{enumerate}
Система DCE RPC позволяет клиенту получить доступ к удаленной службе простым вызовом локальных процедур. Система DCE RPC может автоматически определить необходимый сервер и установить связь между клиентом и сервером. Все это называется привязкой (binding).
Эта система может управлять транспортировкой сообщений в обе стороны, а при необходимости управлять их дроблением и последующей сборкой, например когда один из параметров является массивом. DCE RPC может автоматически отслеживать преобразования типов данных между клиентом и сервером, даже если они работают на системах с разной архитектурой.

\paragraph{Привязка клиента к серверу.}
Чтобы разрешить клиенту вызвать сервер необходимо, чтобы сервер был зарегистрирован и был готов к приему входящих вызовов. Регистрация сервера дает клиенту возможность обнаружить сервер и выполнить привязку к серверу. Обнаружение сервера происходит в два этапа:
\begin{enumerate}
\item Обнаружение машины-сервера.
\item Обнаружение службы-сервера, т.е. нужного процесса на этой машине.
\end{enumerate}
В общем случае для того, чтобы связаться с сервером, клиенту нужно знать конечную точку (\textit{endpoint, прим. Овчинников}) машины сервера, в которую он может посылать сообщение. Конечная точка (порт) используется ОС сервера для получения входящих сообщений от различных внешних процессов. В системе DCE на каждой из серверных машин процессом, известным под названием DCE Демон, поддерживается таблица пар сервер - конечная точка. Перед тем как сервер станет доступным для входящих запросов, он должен запросить у ОС конечную точку. Далее сервер регистрирует эту конечную точку у DCE Демона. DCE Демон записывает эту информацию, включая протоколы, по которым осуществляется обмен информацией в конечных точках, для последующего использования. Сервер службы каталогов также регистрирует предоставленный серверной машине сетевой адрес и имя, под которым сервер будет доступен.

\def\svgwidth{150mm}
\input{pics/01-dis-00-dce.pdf_tex}

\begin{enumerate}
\item Регистрация конечной точки;
\item Регистрация службы;
\item Поиск сервера службы каталогов;
\item Запрос конечной точки;
\item Выполнение вызова RPC.
\end{enumerate}

\paragraph{Обращения к удаленным объектам}
По мере накопления опыта применения механизма RPC в распределенных системах пришло понимание того, что эти принципы могут быть применены и к объектам. При этом единственно правильным способом доступа к данным является использование методов, доступ к которым осуществляется через интерфейс объекта. Объект может реализовывать множество интерфейсов. Интерфейсы могут наследоваться разными классами, и в каждом классе интерфейс может реализовываться по-разному. Подразделение на интерфейсы и объекты, реализующие эти интерфейсы, очень важно для распределенных интерфейсов. Такое четкое разделение позволяет помещать интерфейс на одну машину, а сам объект на другую.

\begin{figure}[H]
  \centering
  \def\svgwidth{120mm}
  \input{pics/01-dis-00-proxy.pdf_tex}
  \caption{Обобщённая организация распределённых объектов с использованием заместителей клиентов}
  \label{pic:dceProxy}
\end{figure}

Когда клиент выполняет привязку к распределенному объекту, в адресное пространство клиента загружается специфическая реализация интерфейса объекта, называемая заместитель. Заместитель-клиент аналогичен клиентской заглушке в системах LPC. Заместитель выполняет:
\begin{enumerate}
\item упаковку параметров (маршаллинг) в сообщениях при обращении к методам;
\item распаковку (демаршаллинг) данных из ответных сообщений, содержащих
результаты обращений к методам и соответственно передачу результатов клиенту.
\end{enumerate}

Сами объекты находятся на сервере и предоставляют необходимый клиентскому заместителю интерфейс. Входящий запрос на обращение к методу сначала попадает на серверную заглушку (скелетон). Скелетон осуществляет распаковку запроса (демаршаллинг) и преобразует входящий запрос в корректное обращение к методу через интерфейс объекта, находящегося на сервере.
\begin{frm}
  \textbf{Замечание:} Состояние большинства распределенных объектов не распределяется, т.е. оно локализовано на одной машине. Такие объекты также называют удаленными. Состояние распределенных объектов может быть физически распределено по нескольким машинам, но это распределение скрыто от клиента за интерфейсами объектов.
\end{frm}
Скелетон также отвечает за маршаллинг (упаковку) параметров в ответном сообщении и их пересылку заместителю клиента.

\paragraph{Объекты времени компиляции и объекты времени исполнения}
Объекты в распределенных системах существуют в различной форме: в одних случаях они соответствуют объектам выбранного языка программирования и представляют собой объекты времени компиляции, т.е. являются экземплярами класса. Другой способ – создание распределенных объектов непосредственно во время выполнения. Использование объектов времени компиляции в распределенных системах обычно значительно упрощает создание распределенных приложений (например, Java-объект может быть полностью описан в рамках своего класса, интерфейс которого он реализует). Компиляция определения класса порождает код, позволяющий создавать экземпляры объектов языка Java, а интерфейсы можно скомпилировать в клиентские и серверные заглушки, позволяющие обращаться к объектам Java с удаленных машин. Недостаток использования объектов времени компиляции состоит в зависимости от конкретного языка программирования. При работе с объектом времени исполнения способ, которым они будут реализованы, обычно остается открытым. Например, можно решить написать на языке С библиотеку, содержащую набор функций, которые могут работать с общим файлом данных. Эту реализацию надо превратить в объект, методы которого будут доступны с удаленной машины. Традиционный способ – использовать адаптер объектов, который исполняет роль оболочки реализации с единственной задачей – придать реализации видимость объекта.

\paragraph{Сохранные и нерезидентные объекты}
\textbf{Сохранный объект} – это объект, который продолжает существовать, даже не находясь постоянно в адресном пространстве процесса, другими словами сохранный объект не зависит от своего текущего сервера. На практике сервер, обычно управляющий таким объектом, может сохранить состояние объекта вспомогательном запоминающем устройстве и завершить работу. Позже вновь запущенный сервер может считать состояние объекта в свое адресное пространство и обработать запрос на обращение к объекту.

\textbf{Нерезидентный объект} – это объект, который существует до тех пор, пока сервер управляет им. Когда сервер завершает работу, этот объект прекращает существование.

\paragraph{Привязка клиента к объекту}
Системы с распределенными объектами обычно предоставляют ссылки на объекты, уникальные в пределах системы. Такие ссылки могут свободно передаваться между процессами, запущенными на различных машинах, например как параметры обращения к методу. Когда процесс хранит ссылку на объект, то перед обращением к любому из методов в объекте процесс должен в первую очередь выполнить привязку к этому объекту. Результатом привязки будет заместитель, размещаемый в адресном пространстве процесса и реализующий специфический интерфейс с методами, к которым обращается процесс. Во многих случаях привязка осуществляется автоматически.

Когда система получает ссылку на объект, то ей требуется способ отыскать сервер, управляющий этим объектом и поместить заместителя в адресное пространство клиента. В случае неявной привязки (автоматической) клиент прозрачно связывается с сервером в момент разрешения ссылки и получения доступа к объекту в действительности.

\textbf{Разрешение ссылки} – это общепринятый термин процесса поиска объекта по ссылке. В случае явной привязки клиент должен до обращения к методам объекта вызвать специальную функцию для привязки к объекту. При явной привязке обычно возвращается указатель на локально доступный заместитель.

\paragraph{Реализация ссылок на объекты}
Ссылки на объекты должны содержать достаточно информации, чтобы обеспечить клиентами привязку к объектам. Один из вариантов ссылки – простая ссылка на объект – содержит сетевой адрес машины, на которой размещен реальный объект вместе с конечной точкой, определяющей сервер, который управляет объектом, и указанием на то, что это за объект. На практике конечная точка соответствует локальному порту, который динамически выделяется локальным хост сервером. Недостатки такого варианта:
\begin{enumerate}
\item если на сервере произойдет сбой, и после восстановления он получит другую конечную точку, то все ссылки на объект станут неправильными. Решение – создать на серверной машине локального демона, который будет опрашивать известные конечные точки, и отслеживать назначение конечных точек серверу в таблице конечных точек. После привязки клиента к объекту нужно запросить у демона текущую конечную точку сервера. Такой подход требует кодирования идентификатора сервера в ссылке на объект. Отсюда следствие – сервер всегда должен регистрироваться локальным демоном, чтобы его можно было найти.
\item Идея кодирования сетевого адреса машины-сервера в ссылке на объект – это тоже неудачная идея. Проблема подобного подхода в том, что в этом случае сервер невозможно перенести на другую машину, не объявив недействительными все ссылки на объекты, которыми он управлял.
\end{enumerate}

\textbf{Решение} – распространение идеи локальных демонов, поддерживающих таблицы конечных точек на сервер локализации, постоянно следящий за работой серверов, на которых расположены объекты. Тогда ссылка на объект должна содержать сетевой адрес сервера локализации, а также действующий в системе идентификатор сервера.

\section{Определение местонахождения распределённых объектов}
\begin{enumerate}
\item \textbf{Именование}. За именование отвечает служба именования объектов (naming service). Её основное назначение - управление пространствами имён, представляющими собой наборы связей между именами и объектными ссылками, известными в распределённой системе. Клиент отправляет службе имя, в ответ получает ссылку. Идея в связи имени с объектом, находящемся на сервере. Имена нужны для совместного использования ресурсов, определения уникальных сущностей, ссылок на местоположение объектов и так далее. Чтобы работать с нужной сущностью (функцией, методом, объектом) необходимо иметь к ней доступ через точку доступа. Точка доступа - это, по сути, адрес сущности. Например, это узел с запущенным сервером, адрес которого формируется IP-адресом и портом. Имена, в отличие от адресов, проще в работе с ними. Также, часто в качестве имён могут использоваться идентификаторы. Свойства идентификаторов:
  \begin{itemize}
  \item идентификатор ссылается не более, чем на одну сущность (однозначность);
  \item на каждую сущность ссылается не более одного идентификатора (\textit{как сложно он сказал о связи один-к-одному, прим Овчинников});
  \item идентификатор всегда ссылается на одну и ту же сущность (\textit{однозначный и неизменяемый, проще говоря, прим Овчинников}).
  \end{itemize}
Связывание имён - это установление соответствия имени и адреса. Имена бывают составные. Составное имя - это последовательность простых имён, задающих путь к объекту через ряд контекстов именований. Сервер именований обычно поддерживает две операции:
  \begin{itemize}
  \item операция связывания (создаёт новое связывание имени для объекта), используется для регистрации объекта сервера на сервере именований. В качестве параметра принимается имя и объектная ссылка.
  \item операция разрешения - возвращает объектную ссылку для имени, переданного в качестве параметра.
  \end{itemize}
Можно выделить три типа имён:
  \begin{enumerate}
  \item имена удобные для восприятия человеком;
  \item идентификаторы;
  \item адреса.
  \end{enumerate}
Пространства имён удобно разбить на три уровня:
\begin{enumerate}
\item глобальный - содержимое этого уровня почти всегда постоянно;
\item административный - редко меняется, можно использовать репликацию и кэширование для увеличения быстродействия;
\item управленческий - меняется часто, для эффективности и производительности операции поиска и обновления. Операции поиска происходят в два этапа: обращение к службе именования (полуаем идентификатор), определение ссылки по идентификатору (находим объект). На этом уровне могут работать службы локализации, на входе идентификатор, на выходе ссылка. Один из вариантов - передача указателей. Для этого часть используется пара заместитель-скелетон.
\end{enumerate}
\item \textbf{Трейдинг}. Определяет местонахождение объектов-серверов исходя из предоставляемых объектами-серверами функций и требуемого качества обслуживания. То есть клиент отправляет не имя, а требуемую функцию с условиями (предикатом). Трейдер выбирает поставщика услуги по запросу и параметрам клиента. Компоненты трейдинга:
  \begin{enumerate}
  \item Импортёр;
  \item Экспортёр;
  \item Трейдер.
  \end{enumerate}
Шаги работы трейдинга
  \begin{enumerate}
  \item экспортёр информирует трейдера о том что он может предоставить;
  \item импортёр просит трейдера найти сервис, трейдер находит нужный сервис и показывает импортёру куда обращаться;
  \item импортёр обращается к найденному экспортёру.
  \end{enumerate}
\end{enumerate}

\subsection{Удалённое обращение к методам}
После того как клиент связался с нужным объектом, он, через заместитель, обращается к методу (RMI remote method invocation). Упаковка обращения это маршаллинг, распаковка демаршаллинг. Вызов напоминает RPC. Стандартный способ поддержки это описание интерфейсов объектов (IDL interface definition language).
\begin{enumerate}
\item Динамическое обращение - процесс, когда параметры обращения к методу собираются во время выполнения программы. Метод становится определён только на этапе выполнения программы.
\item Статическое обращение - подход, который использует заранее заданные определения интерфейсов. Требует, чтобы интерфейсы объекта были известны при разработке клиентской части.
\end{enumerate}
Когда объекты распределённые - объекты доступны со всех машин. Ссылки на объекты при вызове методов передаются по значению, то есть копируются с одной машины на другую.

\def\svgwidth{50mm}
\input{pics/01-dis-01-rmi.pdf_tex}

Если объект был локальным он копируется, если были ссылки - копируются только ссылки.

\section{Вопросы к РК2}
У каждого по два вопроса.
\begin{enumerate}
\item Общие сведения о платформе .NET
\item процессы и потоки
\item перенос кода в распределённых информационных системах
\item Серверы объектов в распределённых информационных системах
\item Общие сведения о протоколах OSI и протоколах промежуточного уровня
\item RPC
\item обращение к удалённым объектам
\item определение месторасположения распределённых объектов
\end{enumerate}


\end{document}