Взаимодействие TransportKP и UserKP

Общее

Schedule

Публикуется клиентом один раз. Содержит свойства

• hasRoute - Route

Route

• tspType - string. Тип маршрута open/closed.
• hasPoint. Содержит точки (Point) для построение по ним маршрута (кроме начальной точки, она совпадает с положением пользователя (???))
• hasMovement. Результат работы TransportKP — перемещения между точками
• hasStartMovement. Первый Movement
• processed - свойство обновляется TransportKP при обновлении маршрута.
• updated - свойство обновляемое UserKP для уведомления о том, что содержимое запроса (hasPoints) изменилось.

User

• provides - Schedule. Пока каждый UserKP может создать только один Schedule (нужно ли больше?)
• hasLocation - Location. Местоположение пользователя.

UserKP

Инициализация

• Ищет в smartspace'е User'а со своим id, если не найдено — создает
• Ищет в smartspace'е свой Schedule'е, если найдено, подписывается (см. далее), если не найдено — ничего не создает.

Публикация местоположения

• При получении новых координат публикует новый объект Location
• Обновляет свойство hasLocation у своего объекта User
• Старый Location не удаляет, т.к. на него может ссылаться SearchRequest

Публикация запроса

• Если запрос (Schedule->Route) уже существует в smartspace'е, то удаляются все свойства hasPoint
• Если запроса не существует, то он публикуется и подписывается
• Добавляется свойства Route::hasPoint
• Добавляется или изменятеся свойство Route::tspType
• Обновляется свойство Route::updated (присваивается уникальное значение — случайное или текущее время).

Подписка на Schedule

Подписывается на свойство processed объекта Route.

Завершение работы

Отписывается от свойства processed объекта Route. Удаляет из SIB'а созданные ранее объекты Schedule, Route и User.

TransportKP

Инициализация

Подписывается на изменение свойства updated у класса Route. Подписывается на изменение Location'а у класса User'а. Обе подписки только на свойства, а не на конкретные объекты.

При получении обновления updated:

• Получает объект Route, у которого изменилось updated.
• Получает Schedule, которому соответствует измененный Route (через template-запрос).
• Получает User, которому соответствует полученный на п. 2 Route (через template-запрос).
• goto "Дальнейшие действия при получении обновлений"

При получении обновления Location

• Получает User'а, у которого обновился Location через template-запрос
• Получает Schedule и Route для User'а через запрос свойства.
• goto "Дальнейшие действия при получении обновлений"

Дальнейшие действия при получении обновлений

• Получает Point'ы, Location'ы, tspType'ы и т.п. из вышеперечисленных классов
• Передает все что выше в Java-код.
• Ищет/добавляет в кэш-е полученного User'а и его текущее состояние.
• Передает все данные из smartspace'е в процедуру обновления состояния (состояние может быть пустым, процедура обновления должна обновить при необходимости или создать маршрут). Процедура обновления делает следующее
  • Если маршрута еще не построено, то построить, используя tspType, точки и Location.
  • Если изменился только Location, смотреть насколько он изменился и если сильно - обновить маршрут
  • Если изменился tspType или точки, то перестроить маршрут полностью (или придумать как в алгоритме SimulatedAnnealing'а можно оптимально обновить маршрут при изменении этих данных).
• После перестроения маршрута опубликовать его в SmartSpace'е, обновив в конце свойство processed.

Завершение работы

• Отписывается от всех подписок

Вопросы

• Допустимо ли использовать искусственные поля processed и updated для уведомления других KP об изменении данных?
  • • это решает проблему атомарности обновления (т.к. smartslog не может обновлять много индивидов в одну транзакцию).
  • • KP может подписаться на одно свойство, а не отдельно на точки, tspType и т.п.
  • • искуственное поле, возможно нарушает идеологию smartspace'ов
• Допустимо ли подписываться на обновление свойства без указания индивида (т.е. подписка на triple <any-subject> <updated> <any-object>)?