Лекция №5. КВАЗИКОМПОНЕНТНЫЕ ТЕХНОЛОГИИ РЕАЛИЗАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ Учебные вопросы: 1. Понятие компонента

Лекция №5. КВАЗИКОМПОНЕНТНЫЕ ТЕХНОЛОГИИ
РЕАЛИЗАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ
Учебные вопросы:
1. Понятие компонента
2. Сокеты
3. Вызов удаленных процедур;
4. Системы распределенных объектов
Вопрос №1
Термин «компонент» в ИТ-отрасли используется для обозначения
различных понятий.
Можно выделить аппаратные (hardware components) и
программные (software components) компоненты.
Примерами аппаратного компонента могут служить
микропроцессор, жесткий диск, модули памяти.
Термин программный компонент (ПК) используется для
обозначения двух связанных, но разных понятий.
Если речь идет о программной архитектуре, то обычно под
компонентом подразумевается программный модуль,
реализующий некоторую функцию или набор функций, который
решает определенные подзадачи в рамках общих задач системы.
Если речь идет о компонентных технологиях программирования
или компонентно-ориентированной (component based)
разработке программного обеспечения (ПО), то под ПК понимают
объекты со специальными свойствами.
В дальнейшем термин компонент будет употребляться во втором
значении.
Под ПК понимают откомпилированный «двоичный компонент»,
который можно интегрировать в приложение «на лету». При
работе с компонентами исходный код обычно недоступен и
поэтому компонент нельзя изменять.
ПК можно рассматривать с точки зрения реализуемой
функциональности, реализации, исполняемого кода.
В первом случае речь идет об описании ПК в терминах
реализуемых сервисов. Для этого обычно используются языки
определения интерфейсов.
Во втором случае описывается внутреннее устройство ПК. Для
этого можно использовать, например, диаграммы классов.
В третьем случае описывается функционирование ПК с учетом
специфики платформы.
Типовой ПК обладает следующими свойствами:
• представляет собой фрагмент самодостаточного кода, т. е. для
его функционирования не требуется наличия дополнительных
библиотек;
• является самоустановливаемым модулем, который может быть
включен в состав системы, исключен из ее состава или заменен
на другой модуль, например, принадлежащий другому
производителю, при минимальном участии пользователя;
• может повторно использоваться в различных контекста;
• при работе с ПК используются механизмы динамического
связывания;
• может быть объединено с другими ПК в целях создания более
крупных ПК;
• пользователи применяют ПК преимущественно по принципу
черного ящика, т.е. пользователю известны только интерфейсы,
но не внутренняя структура системы.
Набор правил, определяющих интерфейсы ПК и их реализаций, а
также правил, по которым ПК работают в системе и
взаимодействуют друг с другом, называют компонентной
моделью (component model).
В компонентную модель входят также правила,
регламентирующие жизненный цикл ПК. Взаимодействовать друг
с другом могут только ПК, построенные в рамках одной модели.
Набор таких базовых, необходимых для функционирования
большинства компонентов служб, вместе с поддерживаемой с их
помощью компонентной моделью называется компонентной
средой (компонентным фрейворком, component framework).
Фазы развития технологий разработки распределенных систем
Вопрос №2
Сокеты позволяют связывать приложения напрямую, записывая
данные и читая данные из сокета. API для сокетов является
низкоуровневым и предоставляет максимальный контроль над
передаваемыми данными.
Работа с сокетами в самом общем виде выглядит следующим
образом.
1. Любой процесс может создать серверный сокет и привязать
его к какому-нибудь порту.
2. После этого сервер переходит в режим ожидания и ожидает
запрос со стороны клиента.
3. Клиент также создает сокет, через который он может
взаимодействовать с сервером.
4. Взаимодействие может реализовываться как с установлением
соединения, так и без установления соединения. В первом
случае в качестве транспорта используется протокол ТРС, а во
втором — UDP.
Недостатки:
• сокеты плохо подходят для работы со сложными структурами
данных, особенно если это программные компоненты
• сложность программирования, поскольку программирование
осуществляется на низком уровне
Вопрос №3
Сущность вызова удаленных процедур состоит в обеспечении
возможности программ вызывать процедуры, находящиеся на
других машинах.
Когда процесс, запущенный на хосте А, вызывает процедуру с
хоста В, процесс на хосте А приостанавливается, а выполнение
вызванной процедуры происходит на хосте В.
Информация может быть передана от вызывающего процесса к
вызываемой процедуре через параметры и возвращена процессу
в виде результата выполнения процедуры.
Можно выделить следующие шаги вызова удаленной процедуры.
1. Программа клиент выполняет локальный вызов процедуры
посредством обращения к заглушке на своей стороне.
2. Заглушка, расположенная на стороне сервера, перекодирует
запрос в стандартный формат. Этот процесс называют
маршаллингом (marshalling).
3. Заглушка, расположенная на стороне клиента, связывается с
серверной заглушкой.
4. Получив запрос на выполнение удаленной процедуры,
серверная заглушка выполняет операцию демаршаллинга
(unmarshalling). Демаршаллинг предполагает выполнение
операции обратной операции маршаллинга, т. е.
преобразование параметров запроса из сетевого во
внутренний формат.
5. Серверная заглушка вызывает требуемую процедуру.
6. Процедура выполняется на сервере, результаты выполнения
процедуры передаются серверной заглушке.
7. Серверная заглушка выполняет операцию маршаллинга и
отправляет результат клиентской заглушке.
8. Получив результат выполнения удаленной процедуры,
клиентская заглушка выполняет операцию демаршаллинга и
передает результат основной программе.
При работе с удаленными процедурами параметры передаются
по значению.
Использование механизма работы с удаленными процедурами
имеет существенные недостатки:
1. RPC ориентирован на процедурный стиль программирования,
а подавляющее большинство современных приложений —
объектно-ориентированные;
2. в рамках RPC реализуются статические вызовы, т.е. заглушки
встраиваются в текст как клиента, так и сервера, на этапе
разработки.
Вопрос №4
DCE включает следующие основные сервисы:
• службу распределенных файлов,
• службу каталогов,
• службу распределенного времени,
• имеется поддержка работы с нитями (Threads),
• вызов удаленных процедур и аутентификация,
• служба безопасности
• файловый сервис.
Служба распределенных файлов (distributed file service)
представляет собой файловую систему, предоставляющую
прозрачные методы доступа к любому файлу системы
одинаковым образом.
Служба каталогов (directory service) используется для
отслеживания местонахождения любого из ресурсов системы.
Служба каталогов позволяет процессу запрашивать ресурсы, не
зная, где они находятся, если это необходимо для процесса.
Служба безопасности (security service) позволяет защищать
ресурсы любого типа, кроме того, получение некоторых данных
может быть открыто только тем, кому это разрешено.
Служба распределенного времени (distributed time service)
предоставляет механизмы синхронизации часов различных
хостов.
Модель программирования, лежащая в основе всей системы DCE,
— это модель клиент-сервер, в которой связь между клиентами и
серверами осуществляется посредством использования RPC.
DCE поддерживает работу с объектами.
Распределенные объекты представляют собой удаленные
объекты, реализация которых находится на сервере.
Сервер создает объекты C++ и обеспечивает доступ к удаленным
клиентам
В рамках DCE поддерживаются два типа распределенных
объектов:
• динамические распределенные объекты (distributed dynamic
objects);
• именованные распределенные объекты (distributed named
objects).
Динамические распределенные объекты создаются сервером по
требованию клиента, к ним имеет доступ только один клиент.
Именованные распределенные объекты создаются сервером для
совместного использования несколькими клиентами и
регистрируются службой каталогов, так что клиент может найти
объект и выполнить привязку к нему.