Материал: 456
Всвязи с переходом разработчиков прикладных программ от структурной парадигмы к объектной появилась необходимость в ис-
пользовании удаленных объектов ( remote method invocation, RMI ).
Удаленный объект представляет собой некоторые данные, совокупность которых определяет его состояние. Это состояние можно изменять путем вызова его методов. Обычно возможен прямой доступ к данным удаленного объекта, при этом происходит неявный удаленный вызов, необходимый для передачи значения поля данных объекта между процессами. Методы и поля объекта, которые могут использоваться через удаленные вызовы, доступны через некоторый внешний интерфейс класса объекта. Внешний интерфейс компоненты распределенной системы в таких системах обычно совпадает с внешним интерфейсом одного из входящих в компоненту классов.
Вмомент, когда клиент начинает использовать удаленный объект, на стороне клиента создается клиентская заглушка, называемая посредником ( proxy ). Посредник реализует тот же интерфейс, что и удаленный объект. Вызывающий процесс использует методы посредника, который маршализирует их параметры для передачи по сети, и передает их по сети серверу. Промежуточная среда на стороне сервера десериализует параметры и передает их заглушке на стороне сервера, которую называют каркасом ( skeleton ) или, как и в удаленном вызове процедур, заглушкой:
Каркас связывается с некоторым экземпляром удаленного объ-
екта. Это может быть как вновь созданный, так и существующий экземпляр объекта, в зависимости от применяемой модели использования удаленных объектов, которые будут рассмотрены ниже.
При использовании удаленных объектов проблемными являются вопросы о времени их жизни:
–в какой момент времени создается экземпляр удаленного
объекта;
–в течение какого промежутка времени он существует.
Для описания жизненного цикла в системах с удаленными объектами используются два дополнительных понятия:
–активация объекта: процесс перевода созданного объекта в состояние обслуживания удаленного вызова, то есть связывания его с каркасом и посредником.
–деактивация объекта: процесс перевода объекта в неиспользуемое состояние.
Выделяют три модели использования удаленных объектов:
–модель единственного вызова ( singlecall );
–модель единственного экземпляра ( singleton );
–модель активации объектов по запросу клиента ( client activation ).
1.5.Распределенные события и транзакции
Вопросы для рассмотрения: Подписчики и издатели слабосвязанных событий. Атомарность. Согласованность. Изоляция. Постоянство. Распределенная транзакция. Транзакция.
Рекомендуемая литература: 1.
Перечень дополнительных ресурсов: 2, 3, перечень ресурсов в сети Интернет.
Наименование вида самостоятельной работы: изучение ли-
тературы.
При разработке программного обеспечения достаточно часто возникает потребность получать извещения о каких-либо событиях, возникающих асинхронно, то есть в некоторые произвольные моменты времени. В распределенных системах так же может возникнуть необходимость использования таких извещений, получаемых от удаленной системы. Можно выделить два подхода к обработке событий – тесно связанные и слабо связанные события. При тесно связанном со-
бытии происходит прямое уведомление одной стороны другой стороной. Хотя этот метод можно использовать, например, вместе с однонаправленным асинхронным вызовом, ему свойственен ряд недостатков, ограничивающих его применение в распределенных системах:
–обе компоненты системы должны выполняться одновременно;
–для уведомления нескольких компонент об одном событии уведомляющей стороной должны использоваться механизмы для ведения списка получателей событий;
–затруднена фильтрация или протоколирование событий. Поэтому в распределенных системах так же применяются сла-
бо связанные события, когда источники события (издатели) не взаимодействуют напрямую с получателями событий (подписчиками). Промежуточная среда в этом случае должна предоставить сервис, позволяющий подписчику подписаться на какое-либо событие или отказаться от подписки, а издателю – инициировать событие для рассылки подписчикам
При использовании слабосвязанных событий подписчики, издатели и менеджер событий могут располагаться на различных компьютерах. Само событие может быть реализовано как, например, вызов менеджером событий некоторого зарегистрированного метода удаленного объекта.
Наряду с распределенными событиями, РИС использует распределенные транзакции.
Транзакция – последовательность операций с какими-либо данными, которая либо успешно выполняется полностью, либо не выполняется вообще.
Транзакции являются основой приложений, работающих с базами данных, однако в распределенной системе может быть недостаточно использования только транзакций систем управления базами данных. Например, в распределенной системе в транзакции может участвовать несколько распределенных компонент, работающих с несколькими независимыми базами данных.
Распределенной называется транзакция, охватывающая операции нескольких взаимодействующих компонент распределенной системы. Каждая из этих компонент может работать с какими-либо СУБД или иными службами, например, использовать очереди сообщений, или даже работать с файлами. При откате транзакции все эти операции должны быть отменены. Для этого необходимо выполнение
двух условий:
–промежуточная среда должна поддерживать управление распределенными между несколькими компонентами транзакциями;
–компоненты распределенной системы не должны работать с какими-либо службами или ресурсами, которые не могут участвовать
втранзакции.
Распределенные транзакции являются важнейшим элементом поддержания целостности данных в распределенной системе. Поэтому для более широкого их применения промежуточная среда может содержать механизмы, которые при необходимости (и определенных затратах времени на написание кода) позволят использовать в распределенных транзакциях внешние службы, не поддерживающие транзакции. Такой механизм называется компенсирующим менеджером ресурса ( compensating resource manager ).
2.ЛАБОРАТОРНЫЕ РАБОТЫ
2.1.Лабораторная работа № 1
«Исследование распределенной информационной системы. Технологии разработки программных компонентов»
Рекомендуемая литература: 1.
Перечень дополнительных ресурсов: 1, 2, перечень ресурсов в сети Интернет.
Цель работы: Изучить особенности распределенных информационных систем. Освоить технологии разработки программных компонентов.
Задание:
В рамках лабораторной работы необходимо провести анализ конфигуратора на платформе 1С:Предприятие 8.
Описание должно содержать: Перечень всех объектов.
Описание объектов и правила их создания (использования). Интерфейс главного окна конфигуратора.
Правила администрирования платформы.
По результатам лабораторной работы составить общий отчет в электронном виде, содержащий выше указанные аспекты.
2.2 Лабораторная работа №2 «Разработка требований к распределительной информационной
системе»
Рекомендуемая литература: 1.
Перечень дополнительных ресурсов: 1, 3, перечень ресурсов в сети Интернет.
Цель работы: Изучить особенности распределенных информационных систем. Освоить технологии формирования требований.
Задание:
–Изучить теоретический материал по данной теме.
–Построить опорные точки зрения на основании метода VORD для формирования и анализа требований. Результатом должны явиться две диаграммы: диаграмма идентификации точек зрения и диаграмма иерархии точек зрения.
–Составить информационную модель будущей системы, включающую в себя описание основных объектов системы и взаимодействия между ними. На основании полученной информационной модели и диаграмм идентификации точек зрения, диаграмма иерархии точек зрения сформировать требования пользователя и системные требования.
–Провести аттестацию требований, указать какие типы проверок выбрали.
–На основании описания системы (Лабораторная работа №1), информационной модели, пользовательских и системных требований составить техническое задание на создание программного обеспечения. ТЗ должно содержать основные разделы, описанные в ГОСТ 34.602-89.
–Построить отчёт, включающий все полученные уровни модели, описание функциональных блоков, потоков данных, хранилищ и внешних объектов.
Лабораторную работу рекомендуется выполнять в группах по 2
–4 человека.
В качестве стандарта разработки требований к РИС необходимо использовать: ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» и ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»