com_inetd_rpc

1.

2.

Лекция
по дисциплине «Распределенные информационные
системы» (РИС)
Тема: «Технологии построения
распределенных информационных
систем»

3.

1. COM/DCOM

4.

Что такое COM?
COM (Component Object Model) - это стандарт, позволяющий
разработчикам повторно использовать в своем коде
независимые компоненты ПО. При этом им не нужно знать
внутреннее устройство данных компонентов, заниматься их
совместимостью на разных языках программирования и
повторной компиляцией.

5.

Структура COM
СОМ-объект представляет собой двоичный код, который
выполняет какую-либо функцию и имеет один или более
интерфейс. СОМ-объект содержит методы, которые позволяют
приложению пользоваться СОМ-объектом. Эти методы
доступны благодаря СОМ-интерфейсам. Клиенту достаточно
знать несколько базовых интерфейсов СОМ-объекта, чтобы
получить полную информацию о составе
свойств и методов объекта. СОМ-объект может содержать
один или несколько интерфейсов.

6.

Структура COM
СОМ-интерфейс применяется для объединения методов
СОМ-объекта. Интерфейс позволяет клиенту правильно
обратиться к СОМ-объекту, а объекту - правильно ответить
клиенту. Названия СОМ-интерфейсов начинаются с буквы I.
Клиент может не знать, какие интерфейсы имеются у СОМобъекта. Для того чтобы получить их список, клиент
использует базовый интерфейс lunknown, который есть у
каждого СОМ-объекта.

7.

Структура COM
СОМ со-классы (coclass) - это классы, которые содержат
один или более СОМ-интерфейс. Вы можете не обращаться к
СОМ-интерфейсу непосредственно, а получать доступ к СОМинтерфейсу через со-класс. Со-классы идентифицируются при
помощи идентификаторов класса (CLSID).

8.

Структура COM
Пользователем СОМ-объекта называется приложение или
часть приложения, которое использует СОМ-объект и его
интерфейсы в своих собственных целях. Как правило, СОМобъект находится в другом приложении.

9.

Структура COM

10.

Функционирование COM
Основная цель технологии СОМ – обеспечение
возможности экспорта объектов. Идея экспорта объектов
заключается в том, что один модуль создает объект, а другой
его использует посредством обращения к методам.
Клиент получает доступ к сервисам объекта только через
интерфейс и его методы, непосредственного доступа к
объекту у них нет.
Уже созданный интерфейс не может быть изменен ни при
каких обстоятельствах.
Объект COM всегда реализуется внутри некоторого сервера.
Сервер СОМ представляет собой исполняемый файл.

11.

Типы сервера COM
- внутренний сервер (in-process server) реализуется
динамическими библиотеками, которые подключаются к
приложению-клиента и работают в одном с ним адресном
пространстве.
- локальный сервер (local server) создается отдельным
процессом, который работает на одном компьютере с
клиентом.
- удаленный сервер (remote server) создается процессом,
который работает на другом компьютере по отношению к
клиенту.

12.

Условия обеспечения работы COM
Для обеспечения работы локальных и удаленных серверов
используется механизм маршалинга и демаршалинга.
Маршалинг реализует единый в рамках СОМ формат упаковки
параметров запроса, демаршалинг отвечает за распаковку.
Чтобы вызывать методы интерфейса объекта СОМ, клиент
должен получить указатель на этот интерфейс. Для каждого
интерфейса существует собственный указатель.
Любой объект СОМ является экземпляром некоторого класса.
Информация обо всех зарегистрированных и доступных в
данной операционной системе классах СОМ собрана в
специальной библиотеке СОМ.

13.

Схема работы COM
1. Сначала клиент обращается к библиотеке СОМ, передавая
ей имя требуемого класса и необходимого в первую очередь
интерфейса
2. Библиотека при помощи диспетчера управления службами
(SCM – Service Control Manager) обращается к системному
реестру, по идентификатору класса находит информацию о
сервере и запускает его
3. Сервер создает экземпляр класса – объект и возвращает
библиотеке указатель на запрошенный интерфейс
4. После этого библиотека возвращает клиенту указатели на
объект и интерфейс

14.

Схема работы COM
5. После создания происходит инициализация – объект
должен загрузить необходимые данные, считать настройки из
системного реестра и т. д. За это отвечают специальные
объекты СОМ, которые называются моникерами (monikers).
6. Для запуска экземпляра класса используется специальный
объект – фабрика класса. Для каждого класса должна
существовать собственная фабрика класса.

15.

Интерфейсы COM
Каждый объект СОМ обязательно имеет интерфейс IUnknown.
Он содержит три метода:
- QueryInterface - возвращает указатель на интерфейс
объекта, идентификатор ID которого передаётся в параметре
метода. Если такого интерфейса объект не имеет, метод
возвращает Null.
- AddRef – механизм учёта ссылок.
- Release – механизм учёта ссылок.

16.

DCOM
Распределённая модель многокомпонентных объектов
(Distributed Component Object Model, DCOM) – это протокол,
обеспечивающий гибкое, защищённое и эффективное
взаимодействие программных компонентов в сетевой среде
Когда клиент и компонент хранятся на разных машинах,
DCOM просто заменяет локальный механизм взаимодействия
процессов сетевым протоколом. Ни клиент, ни компонент не
знают о том, что соединение между ними стало гораздо
длиннее

17.

DCOM

18.

2. inetd

19.

inetd
Фоновая задача (фоновой процесс) — это процесс, который
работает в фоне, на заднем плане. Имеется в виду, что
оболочка операционной системы, которая выполняет
фоновый процесс, не ждёт завершения или окончания
процесса, как это происходит с обычными программами.
Оболочка может запустить ещё много процессов сразу после
запуска одного фонового так, что они будут выполняться
одновременно. На самом деле процессы будут выполняться
поочерёдно то один, то другой, но скорость переключения
между процессами слишком быстра для человеческого
восприятия, поэтому нам кажется, что они выполняются
одновременно.

20.

inetd
Оболочка UNIX-систем подразделяет запущенные ей группы
процессов на «переднего плана», «фоновые» и
«приостановленные», и поддерживает перевод групп
процессов из одного из выше названных классов в другой. Для
этого используется & (амперсенд) в конце командной строки,
клавиатурная комбинация Ctrl-Z (приостанавливает
текущую группу процессов переднего плана), и команды jobs,
fg и bg

21.

inetd

22.

inetd
Отличие фоновых процессов от «демонов» (служб) UNIXсистем в том, что «демон» полностью утрачивает ассоциацию
с пользовательским терминалом и оболочкой ОС, зачастую
продолжая существовать и после выхода породившего его
процесса оболочки. Фоновый же процесс по-прежнему
сохраняет логическую ассоциацию с терминалом и оболочкой
Демон inetd управляет другими демонами. Он запускает
демоны-клиенты, когда для них есть работа, а после
выполнения задачи позволяет им тихо завершиться.

23.

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

24.

inetd

25.

inetd
Многие демоны могут использоваться либо традиционным
способом (т.е. они запускаются однократно и работают до
выключения системы), либо под контролем демона inetd.
Одной из распространённых задач администрирования
является запуск каких-то задач в определённое время с
заданной периодичностью. В UNIX этой цели служит
планировщик заданий cron.

26.

3. RPC

27.

RPC
Удалённый вызов процедур (или Вызов удалённых процедур)
(от англ. Remote Procedure Call (RPC)) — класс технологий,
позволяющих компьютерным программам вызывать функции
или процедуры в другом адресном пространстве (как правило,
на удалённых компьютерах). Обычно, реализация RPC
технологии включает в себя два компонента: сетевой протокол
для обмена в режиме клиент-сервер и язык сериализации
объектов (или структур, для необъектных RPC).

28.

RPC
Различные реализации RPC имеют очень отличающуюся друг
от друга архитектуру и разнятся в своих возможностях: одни
реализуют архитектуру SOA, другие CORBA или DCOM. На
транспортном уровне RPC используют в основном протоколы
TCP и UDP, однако, некоторые построены на основе HTTP (что
нарушает архитектуру ISO/OSI, так как HTTP изначально не
транспортный протокол).

29.

Идея RPC
Идея RPC состоит в расширении хорошо известного и
понятного механизма передачи управления и данных внутри
программы, выполняющейся на одной машине, на передачу
управления и данных через сеть. Средства удалённого вызова
процедур предназначены для облегчения
организации распределённых вычислений и создания
распределенных клиент-серверных информационных систем.

30.

Характерные черты RPC
- Асимметричность, то есть одна из взаимодействующих
сторон является инициатором;
- Синхронность, то есть выполнение вызывающей процедуры
приостанавливается с момента выдачи запроса и
возобновляется только после возврата из вызываемой
процедуры.

31.

Проблемы RPC
- Так как вызывающая и вызываемая процедуры выполняются
на разных машинах, то они имеют разные адресные
пространства, и это создает проблемы при передаче
параметров и результатов, особенно если машины находятся
под управлением различных операционных систем или имеют
различную архитектуру (например, используется прямой или
обратный порядок байтов). Так как RPC не может
рассчитывать на разделяемую память, то это означает, что
параметры RPC не должны содержать указателей на ячейки
нестековой памяти и что значения параметров должны
копироваться с одного компьютера на другой. Для
копирования параметров процедуры и результата выполнения
через сеть выполняется их сериализация.

32.

Проблемы RPC
- В реализации RPC участвуют как минимум два процесса —
по одному в каждой машине. В случае, если один из них
аварийно завершится, могут возникнуть следующие ситуации:
при аварии вызывающей процедуры удалённо вызванные
процедуры станут «осиротевшими», а при аварийном
завершении удалённых процедур станут «обездоленными
родителями» вызывающие процедуры, которые будут
безрезультатно ожидать ответа от удалённых процедур.
- Неполная обратная совместимость между ЯП

33.

Принцип работы RPC

34.

Пример кода RPC

35.

СПАСИБО ЗА ВНИМАНИЕ