Практическая работа №15
Тема: Создание распределенного приложения на основе технологии Microsoft Remoting.
Цель: Получить практические навыки по созданию распределенного приложения на основе технологии Microsoft Remoting.
Ход работы
.Net Remoting - новейшая технология связывания распределенных приложений, предложенная корпорацией Microsoft. Она обеспечивает вызов методов удаленных объектов, находящихся под управлением среды Microsoft.Net. Поддерживается множество услуг, таких, как активация удаленных объектов, контроль времени их существования, взаимодействие между удаленными объектами через различные транспортные каналы.
Рисунок 1 – Архитектура.Net Remoting
Во многом.Net опирается на тот опыт, что был накоплен за много лет создания распределенных приложений на базе RPC, CORBA, DCOM и EJB. В архитектуре.Net Remoting также выделяют клиентскую и серверную машину. Сервером является хост, отвечающий на запрос, а клиентом - хост, его отправляющий. Однако в отличие, скажем, от EJB это разделение относительно условно - в любой момент роли могут быть изменены. В этом смысле она похожа на технологию Web-сервисов.
Как и в RPC и CORBA, клиент локально работает только с классом-посредником (proxy). Этот класс генерируется средой одним из трех способов: либо на основе экземпляра кода удаленного класса, либо на основе класса, содержащего описания интерфейсов удаленного класса (но не код его логики), либо специальным инструментом на основе получаемого с дистанционного сервера описания Web-сервиса.
Вкратце схема взаимодействия выглядит следующим образом: в сообщении, отсылаемом клиентом серверу, классы-посредники кодируют название вызываемого метода удаленного объекта и все входящие переменные. На сервере сообщение раскодируется (т. е. определяется название метода и все входящие параметры) и выполняется реальный метод. Чтобы передать какие-либо данные на сервер, достаточно вызвать метод класса-посредника в качестве аргументов метода, взяв эти данные. Например, можно передавать любые двоичные данные или строки текста. Сервер, в свою очередь, аналогичным образом может передать клиенту возвращаемое значение метода - оно будет раскодировано на клиенте через класс-посредник. В этом отношении.Net Remoting напоминает сериализацию Java-объектов, применяемую, в частности, в JMS.
|
|
Отличительной особенностью.Net Remoting является наличие нескольких четко разделенных слоев, отвечающих за сокрытие от пользователя сложностей дистанционного взаимодействия с объектом. Первым из них является слой "прозрачных" посредников (Transpa-rentProxy), отвечающих за упаковку всех параметров удаленного вызова в объект-посылку IMessage*1. Сформированная посылка передается в "настоящий" посредник (RealProxy), который уже и передает ее на удаленный сервер. Все эти классы заранее заданы средой.Net, но пользователь может расширять класс RealProxy, например, для подключения своих средств безопасности.
_____
*1 Для того чтобы параметр мог быть упакован подобным образом, его класс должен реализовывать интерфейс ISerializable.
Для взаимодействия с коммуникационным слоем RealProxy опирается на каналы. В канале важны два элемента - формовщик (formatters) и транспортировщик (transport sink). Формовщик отвечает за преобразование сообщения IMessage в пакеты данных протокола высокого уровня. В стандартном варианте.Net содержится два формовщика: двоичный и SOAP. Транспортировщик решает проблему доставки этих пакетов на более низком сетевом уровне - для стандартной редакции.Net это TCP и SOAP.
|
|
Таким образом, доступны два стандартных вида взаимодействия (пользователем могут быть описаны и иные): для взаимодействия по двоичному каналу через TCP и пересылки запросов к удаленным объектам в виде сообщений SOAP поверх HTTP. В первом случае достигается наибольшая производительность, но ценой утраты значительной части кросс-платформенности. Он подходит для построения приложений в локальных сетях. Во втором случае методы удаленного объекта видны как Web-сервисы, обращение к которым может происходить через Интернет и границу, определенную брандмауэром. При этом может использоваться любой транспортный протокол третьего уровня модели OSI, а не только IP, как в первом случае. Однако для его реализации требуются большие вычислительные и сетевые ресурсы, нежели для случая двоичной связью.
Протокол, который обращается к серверному приложению для доступа к своим объектам, настраивается при его запуске. Сначала регистрируется канал связи, затем как подключенные к нему регистрируются доступные дистанционные объекты. При регистрации канала указывается транспортный протокол (TCP, HTTP и пр.), протокол доступа (двоичный, SOAP и др.) и номер порта, по которому сервер будет принимать запросы.
В.Net различаются два типа объектов - активизируемые сервером и клиентом. Объекты, активизируемые клиентом, находятся под управлением менеджера контроля жизненного цикла, гарантирующего, что по истечении определенного срока действия объекта (срока аренды, в терминологии Microsoft) будет произведена необходимая очистка памяти. Среда предоставляет развитые средства для контроля за этой арендой, в том числе и со стороны самого объекта. Объекты, активизируемые сервером, делятся на объекты для однократного обращения (Single call) и "единичные" (Singleton). Экземпляры однократных объектов создаются в момент обращения к их методам, "единичные" объекты могут существовать долго и сохранять состояние между вызовами их методов.
|
|
Все настройки свойств объектов (типы объектов, каналы, номера портов) можно сохранить в конфигурационном XML-файле, благодаря чему перестройка приложения становится совсем простой.
Число типов объектов в.Net Remoting существенно меньше, чем в EJB. Например, отсутствуют Persistent-объекты, связанные с записями в базах данных. Но для модели вычислений, принятой в.Net, это не нужно. Нет также средств обеспечения транзакционности на уровне контейнера, наличествующих в серверах приложений EJB. Но часто подобные расширения создают лишь дополнительные сложности, не давая программистам никакой экономии сил. Например, создание и регистрация объекта EJB - очень трудоемкая вещь, а все, что нужно для создания дистанционно доступного класса.Net Remoting, - это определить его как класс, производный от класса MarshalByRefObject.
В заключение стоит отметить, что.Net Remoting совместим с иными технологиями удаленного доступа, например COM/DCOM (через средства самой Microsoft), а благодаря поддержке открытых стандартов, наподобие XML и SOAP, можно теоретически организовать взаимодействие приложениями на других платформах, в первую очередь Java.
Важной особенностью.Net Remoting является то, что она не ориентируется исключительно на синхронное взаимодействие, а при применении SOAP-транспорта настраивается и на асинхронный режим работы. Это означает, что она может быть применена в сочетании со средствами гарантированной доставки сообщений для обеспечения максимальной надежности системы в целом. Microsoft обещает в будущей платформе Indigo совместить средства транзакционности, гарантированной доставки и удаленного вызова под одной "крышей".
Задание:
Проектирование приложения
Для реализации поставленного задания выполните следующие действия.
1. Первое действие — запустите построитель приложений и создайте новое приложение. После включения компьютера на экране компьютера появляется запрос на ввод атрибутов пользователя. Запустите построитель приложений двойным щелчком левой кнопкой мыши на ярлыке GeniDAQ Builder (рис. 2), расположенном на рабочем столе.
Рисунок 2 – Конфигурирование кнопки меню в окне DISP1
В результате на экран будет выведено главное окно построителя приложений (рис. 3).
Рисунок 3 – Главное окно построителя приложений
Для запуска построителя задач в демонстрационном режиме последовательно нажмите кнопки Exit и OK.
Демонстрационный режим отличается непрерывным двухчасовым интервалом работы и меньшим количеством входных и выходных каналов. В нашем случае это несущественно. Нажмите кнопку New на панели инструментов (ее легко найти, так как все кнопки снабжены всплывающими подсказками). После этого в главном окне построителя приложений появится диалоговое окно настройки, которое может быть настроено так, как это показано на рисунке 4.
Рисунок 4 – Окно настройки приложения
При работе в учебной лаборатории в поле Location качестве каталога следует использовать каталог, к которому имеется полный доступ. После нажатия кнопки OK и подтверждения необходимости создания каталога Занятие 1, который до этого не существовал, в главном окне построителя задач появятся пустые окна редактора задач TASK1 и редактора форм отображения DISP1. Произведите щелчок мышью в области окна редактора задач и окно с заголовком Task Designer: TASK1 будет выдвинуто на передний план (рис. 5).
Рисунок 5 – Главное окно построителя приложений с окном Task Designer: TASK1 и панелью инструментов редактора задач
В окне построителя задач появится еще одна панель инструментов, содержащая пиктограммы встроенных функциональных блоков редактора задач.
Рисунок 5 – Пример диалогового окна настройки графика времени
Примечание
Атрибуты пользователя следует получить у преподавателя. Пользователь должен обладать правами администратора.
Создаваемое приложение настройте в соответствии с рисунком 6.
Рисунок 6 – Конфигурирование текстовой строки
2. Второе действие — задайте временные параметры запуска приложения. Для этого нажмите кнопку Task Properties на панели инструментов или выполните команду Setup | Task Properties, в появившемся окне задайте требуемое значение периода (рис. 7) и нажмите кнопку OK. В нашем примере задан период запуска приложения 100 миллисекунд.
Рисунок 7 – Задание временных параметров запуска приложения
3. Третье действие. Добавьте в окно отображения инкрементный регулятор и настройте его в соответствии с рисунком 8.
Рисунок 8 – Конфигурирование инкрементного регулятора
Добавьте в окно отображения индикатор и настройте его в соответствии с рисунком 9.
Рисунок 9 – Конфигурирование индикатора
Добавьте в это же окно три текстовых строки и настройте их в соответствии с рисунками 10, 11 и 12.
Рисунок 10 – Конфигурирование текстовой строки
Рисунок 11 – Конфигурирование текстовой строки
Рисунок 12 – Конфигурирование текстовой строки
В результате окно отображения приобретает вид, показанный на рисунке 13.
Рисунок 13 – Вид окна отображения
4. Четвертое действие. Выдвиньте на передний план окно редактора задач и разместите в нем функциональные блоки тег и блок архива тревог.
Произведите двойной щелчок левой кнопкой мыши над блоком тег и появится диалоговое окно его настройки (рис. 14).
Рисунок 14 – Конфигурирование функционального блока тег
Сконфигурируйте блок архива тревог в соответствии с рисунком 15.
Рисунок 15 – Конфигурирование функционального блока архива тревог
Соедините выход тега со входом блока архива тревог. Окно редактора задач приобретет вид, показанный на рисунке 16.
Рисунок 16 – Вид окна редактора задач
5. Пятое действие — сохраните созданный проект (стратегию). Для этого выполните команду File | Save As, в появившемся окне диалога укажите необходимую информацию (рис. 17) и нажмите кнопку Сохранить.
Рисунок 17 – Сохранение созданного программного проекта
Выполните команду Setup | Runtime Preference... и в появившемся окне диалога установите флаг Enable event log. Запустите созданный проект с помощью кнопки Start на панели инструментов (рис. 18).
Рисунок 18 – Демонстрация работы проектоа в окне отображения
Для отображения журнала событий выполните команду View | Event Log (рис. 19).
Рисунок 19 – Вид журнала событий
Используя инкрементный регулятор задайте текущие значения 81 и 19и обратите внимание на изменение состояния индикатора и связанного с этимпоявление звуковых сигналов. Подтвердите аварийные сообщения двойнымщелчком левой клавиши мыши на строках журнала событий, отображаемыхкрасным цветом. Остановить работу проекта можно с помощью кнопки Stop напанели инструментов.
6. Шестое действие. Завершите работу приложения. Для этого выполните команду
File | Exit.
- Ответить на контрольные вопросы.
Контрольные вопросы
1. Технология.Net Remoting.
2. Схема взаимодействия в.Net Remoting.
3. Отличительная особенность.Net Remoting.
4. Типы объектов в.Net.
5. Важная особенность.Net Remoting.