Взаимодействие 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

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

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

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

TransportKP

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

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

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

• Получает объект Route, у которого изменилось updated.
• Получает Schedule, которому соответствует измененный Route (через tempalte-запрос).
• Получает 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 ?