2. Обзор dss.

Decentralized System Services (DSS) – средство создания распределенных приложений на основе сервисов.

Приложение в контексте MSRS – это композиция слабосвязанных параллельно выполняющихся сервисов. Тогда для реализации такого приложения необходимо следующее.

Слабая связанность компонентов – это обеспечивает их взаимозаменяемость и легкость повторного использования. Например, можно отключить или подключить сенсор без последствий для приложения в целом.

Разделение состояния и поведения – состояние сервиса (state) полностью открыто и при этом отделено от его поведения (behavior). Это очень важно в распределенной системе и позволяет сервисам легко взаимодействовать друг с другом как локально, так и удаленно по сети. Поведение в этой ситуации превращается в операции над состоянием, которые могут его изменять.

Работа с состоянием сервиса, а не с сессией (session-less) – текущее состояние сервиса определяется им самим, и оно идентично для всех, кто бы его ни запросил. Сервис не создает индивидуальных сессий для тех, кто с ним работает.

Работа со структурированными данными – состояние сервиса не может быть однородной массой, и структурирование на базе типов CLR позволяет работать со сложными структурами данных.

Работа с событиями изменения состояния сервиса – отделение состояния и его структурированность дают возможность сообщать об изменениях тем, кому это важно. В DSS есть модель, позволяющая отправлять и получать уведомления об этих событиях, а также подписываться на них.

Поддержка Web UI – анализировать и отлаживать распределенные приложения достаточно сложно. Структурированные данные в состоянии сервиса можно сериализовать с помощью XML и просматривать с помощью любого браузера. При помощи XSLT можно поверх XML данных создать простой пользовательский интерфейс.

Чтобы реализовать все описанные выше возможности, были частично использованы два существующих подхода к работе с сервисами: REST и Web Services.

REST (Representational State Transfer) – этот термин обозначает абстрагированную и формализованную Web-архитектуру и был предложен Роем Филдингом в 2000 г. REST построена на идее Тима Бернерс-Ли «URI ссылается на ресурс, и все взаимодействия с этим ресурсом происходят путем обмена состояниями». Важно отметить, что REST – это подход к созданию приложений; на текущий момент он успешно реализован в World Wide Web.

Про Web Services говорят уже давно и много. В основе Web-сервисов лежит протокол SOAP, который как раз и позволяет работать со структурированными данными и событиями.

Какой-то один из подходов, REST или Web-Services, не позволяет реализовать в платформе робототехники все задуманные возможности. Поэтому была выбрана унифицированная модель, в основу которой лег протокол Decentralized System Services Protocol (DSSP), в свою очередь базирующийся на SOAP. Реализация DSSP в Microsoft Robotics Studio предназначена специально для работы с сервисами.

Microsoft Robotics Developers Studio (MRDS) основана на 2 компонентах:

1. среда параллельных и связанных вычислений (CCR);

2. децентрализованные программные сервисы (DSS).

Программная модель CCR предназначена для реализации многопотоковых и межзадачных синхронизаций. Модель DSS используется для построения приложений на свободно связанных сервисах. Сервисы могут выполняться на разных узлах сети, так что DSS обеспечивает инфраструктуру взаимодействия, что позволяет сервисам прозрачно работать на других узлах, использующих те же конструкции CCR, которые могут быть использованы, если работать локально.

Назначение DSS:

1. управление базовыми функциями приложений роботов;

2. запуск и остановка сервисов, управление потоками сообщений между сервисами через порты сервисов;

3. базовый блок MRDS – сервис;

Компоненты сервиса:

1. соглашение – определяет сообщения, которые можно отправить сервису, а также глобально уникальную ссылку, называемую идентификатором соглашения, которая идентифицирует сервис и записывается в форме URI (Universal Resourse Identifier);

2. внутренне состояние – информация, которую хранит сервис для управления своими операциями;

3. поведение – набор операций, которые сервис может выполнить и которые реализованы в виде обработчиков;

4. контекст исполнения – отношения сервиса с другими сервисами и начальное состояние сервиса.