#onem2m
#onem2m
Вопрос:
Что, если IN-AE создаст группу источников света с помощью ADN-AE1 и ADN-AE2, управляя ими с помощью всего одного запроса. На диаграмме показано, что он использует один запрос для управления ими обоими, но когда я нажимаю на пример запроса, он создает <contentInstances> один за другим. Есть ли какой-либо пример, когда я могу управлять группой ресурсов только одним запросом, или это не входит в область oneM2M?
Потоки вызовов для управления несколькими источниками света показаны на рисунке ниже и упорядочены следующим образом:
Когда пользователь обновляет группу состояний освещения на своем смартфоне, IN-AE создает новый contentInstance, предназначенный для группы ресурсов контейнера Light ADN-AE, размещенных на MN-CSE. Запрос показан здесь
Для каждого успешно созданного contentInstances MN-CSE отправляет уведомление соответствующему источнику света ADN-AE.
———————- ——— ОТРЕДАКТИРОВАННЫЙ ——————————-
Ответ №1:
Ресурс <group> объединяет и управляет несколькими ресурсами (одного и того же или смешанного типа ресурсов), в вашем примере два <container> под ADN-AE1 и ADN-AE2.
В дополнение к другим своим атрибутам <группа> имеет виртуальный ресурс, называемый <Точка разветвления>. Этот виртуальный ресурс умножает внутренне каждый запрос, который он получает для всех подходящих ресурсов <group>, будь то СОЗДАНИЕ, ЧТЕНИЕ, ОБНОВЛЕНИЕ или УДАЛЕНИЕ.
В примере <container> существуют до того, как они организованы в группу, и к ним можно обращаться и управлять независимо. Ресурс <group> теперь объединяет их вместе и делает их доступными для приложения как единый объект. Когда эта <группа> получает запрос на СОЗДАНИЕ для <contentInstance>, группа автоматически создает новый ресурс <contentInstance> для всех своих ресурсов. Однако для ADN-AE не имеет значения, кто и как создал <contentInstance> where .
Интересно, что это отделяет приложение IN-AE от фактического развертывания и организации инфраструктуры. Просто представьте, что <group> объединяет все источники света в доме. Эта <группа> управляется AE home manager. Теперь другому AE для управления домом, когда жители уходят, не нужно много знать о реальных устройствах в доме. Для отключения всех источников света требуется только отправить один запрос на ресурс <group>.
Обновить
Проверьте oneM2M «TS-0001 — Функциональная архитектура», разделы «9.6.13 — Группа типов ресурсов» для <group> и «9.6.14 — Точка разветвления типа ресурса» для <fanOutPoint> для спецификации этого поведения.
Комментарии:
1. Итак, мне нужно только отправить <contentinstance> в соответствующую <group>, тогда cse должен позаботиться о том, как его обработать. Знаете ли вы какие-либо документы oneM2M, в которых приводится пример для этого сценария?
2. Точно, CSE отвечает за обработку и распределение запросов к ресурсам. Возможно, вам захочется проверить в TS-0001 разделы «9.6.13 — Группа типов ресурсов» для <группа> и «9.6.14 — Точка разветвления типа ресурса» для < Точка разветвления>.
3. Это хороший момент. Группа уже «знает» тип своих ресурсов через атрибут ‘MemberType’. Нет необходимости указывать тип. На самом деле это было бы бессмысленно, когда ‘MemberType’ смешан. CSE в любом случае должен был бы проверять отдельные типы ресурсов. Но, возможно, это следует уточнить в спецификации.
4. На самом деле я не упоминаю атрибут ‘MemberType’ <group> . В руководстве TR-0025 есть сообщение, которое обновляет состояние всех источников света с помощью группового разветвления (8.7.11.4). Дело в том, что запрос post не содержит никакого атрибута ‘ty’ в заголовке Content-Type в этом примере. Однако в спецификации указано, что каждый запрос post должен содержать атрибут ‘ty’ в их атрибуте content-type заголовка, но в примере этого нет. Так является ли это исключением для группового разветвления?
5. Вы правы, атрибут ‘ty’ должен присутствовать в запросе на СОЗДАНИЕ. Похоже, вы обнаружили проблему в TR-0025. Я перешлю это в oneM2M.