Связь с ресурсами на удаленной CSE - OneM2M

Question

Мы пытаемся внедрить стандарт oneM2M, и у нас есть вопрос, касающийся процесса обмена данными между Remote CSE и IN-CSE. Я написал то, что я понял из документации шаг за шагом ниже. Некоторые из вопросов нам не так понятны, поэтому, прежде чем приступить к реализации, я должен убедиться, что все предельно ясно.

Я собираюсь задать вопрос, прежде чем рассказать все, что мы понимаем из документации. Тогда я собираюсь написать шаг за шагом, какое решение мы думаем. Вопрос в том, что запрос, который отправляется IN-AE, предназначен для MN-CSE, которому IN-CSE следует перенаправить запрос в MN-CSE, или он должен обработать его сам.

Прежде всего, у нас есть две абсолютно отдельные CSE. Один - IN-CSE, другой - MN-CSE, как показано ниже.

У IN-CSE есть дерево ресурсов

/in-cse61
   /in-cse61/csr-34
      /in-cse61/ae-1234

MN-CSE имеет дерево ресурсов

/mn-cse34
   /mn-cse34/csr-61
   /mn-cse34/ae-123456
      /mn-cse34/cnt-1
         /mn-cse34/cin-01
         /mn-cse34/cin-02
         /mn-cse34/cin-03
      /mn-cse34/cnt-2

Мы пропустили любые проблемы безопасности на данный момент. Допустим, IN-AE хочет общаться с MN-CSE, как мы уже говорили выше.

1- IN-AE должен отправить запрос на обнаружение или получение в IN-CSE, в котором говорится, что я получу все дочерние ресурсы Remote CSE.

2- Какова точная разница между отправкой запроса на обнаружение или отправкой запроса на получение? Мы думали, что запрос на обнаружение возвращает только URI ресурса, но запрос на получение возвращает целые данные точного ресурса. Правильный ли этот подход?

3- После получения всех remoteCSE, теперь я знаю идентификаторы remoteCSE. Затем я могу отправить запрос на обнаружение в MN-CSE, чтобы получить в нем AE. Мы думаем два варианта:

а. ~/ В-cse61/ CSR-34? Фу =1& RTY =2
б. ~/ Мин-cse34? Фу =1& RTY =2

Вариант a: Если IN-AE хочет только сделать запрос на обнаружение для дерева ресурсов IN-CSE, IN-CSE должен позаботиться об этом, не перенаправляя его в MN-CSE. Поскольку IN-CSE уже знает, что /in-cse61/csr-34 является своего рода допустимым RemoteCSE для него, но путь запроса начинается с ~/in-cse61, то он должен обрабатываться IN-CSE.

Вариант b: если IN-AE хочет сделать запрос на обнаружение для дерева ресурсов MN-CSE, то IN-CSE может понять, что это связано с RemoteCSE, просмотрев часть /mn-cse34 пути запроса, поскольку он не начинается с IN Ресурс -CSE.

Таким образом, IN-AE(например, смартфон) каким-то образом должен решить, какой CSE должен обрабатывать запрос? Есть ли что-то, что мы считаем неправильным?

--------------------- EDITED ---------------------------- ----------

Я проверил архитектуру Руководства разработчика приложений TR-0025 http://www.onem2m.org/application-developer-guide/architecture

Согласно этому примеру, смартфон (IN-AE) может управлять Light#1(ADN-AE-1) через IN-CSE.

После завершения процессов регистрации и первоначального создания ресурса система готова обнаруживать и затем управлять индикаторами.

GET /~/mn-cse/home_gateway?fu=1&rty=3&drt=2 HTTP/1.1
Host: in.provider.com:8080

Хотя CSE-ID среднего узла и имя CSEBase среднего узла используются в URL-адресе HTTP-запроса, хост адресован IN-CSE. Это означает, что запрос на обнаружение, отправленный из IN-AE, сначала обрабатывается IN-CSE, а затем перенаправляет его в mn-cse. Однако вы сказали мне обратное, сказав: " Как правило, поиск или обнаружение ограничивается только ресурсами хост-CSE и не переходит к удаленным CSE автоматически. ".

На TR-0025 данный пример показан как общий сценарий. А также в TR-0034, на самом деле он проходит запрос, как вы видите на диаграмме.

Answer 1

В вашем вопросе есть много вопросов, которые необходимо решить.

Прежде всего, в oneM2M нет специального объекта с именем "IN-AE". Это просто имя, которое используется для AE, который подключается к IN-CSE в TR-0025 oneM2M : Управление освещением с использованием руководства разработчика HTTP-связывания. Прикладная сущность может быть фактически подключена к IN-CSE или MN-CSE по тому же протоколу (mca), хотя могут существовать AE, которые специально предназначены для работы на одной конкретной CSE.

Что касается вашего пункта 2, разница между запросом на получение и обнаружением:
Запрос извлечения направлен на ресурс для его извлечения. Например, запрос на извлечение, отправленный ресурсу Container /mn-cse34/cnt-1 (из вашего примера), извлечет сам ресурс Container и его атрибуты.
Запрос на обнаружение также нацелен на ресурс, и технически он очень похож на обычный запрос на получение. Но кроме того, вы предоставляете критерии фильтра и тип результата обнаружения. Например, запрос на обнаружение, отправленный тому же ресурсу Container /mn-cse34/cnt-1, может вернуть все ссылки на ContentInstances из этого ресурса Container. В зависимости от фильтра и типа результата вы можете получить полные ресурсы или только ссылки на них.

Пожалуйста, ознакомьтесь со спецификацией oneM2M Функциональная архитектура TS-0001, разделы 10.2.6 Обнаружение и 8.1.2 Запрос полного объяснения и список возможных параметров для запроса на обнаружение.

Что касается пунктов 1 и 3 вашего вопроса: я не знаю, что хочет решить ваша АЕ, но в ней должно быть представление о структуре данных. Это хорошая идея, чтобы организовать данные структурированным и единообразным способом, например, используя контейнеры, FlexContainers, группы и т. д. Таким образом, приложению не нужно просматривать все дерево ресурсов CSE, которое со временем может стать действительно большим. Конечно, может случиться так, что это общее приложение, которое должно пройти через большую и ранее неизвестную структуру. В этом случае приложение может использовать запрос на обнаружение для получения соответствующих ресурсов. Обратите внимание, что вы также можете выполнять поиск по метаданным ресурсов, например, меток, даты и времени и т. Д. Это может быть полезно для сокращения набора результатов.

Как правило, поиск или обнаружение ограничивается только ресурсами хост-CSE и не переходит к удаленным CSE автоматически. Исключением являются объявленные ресурсы. Эти ресурсы объявляются удаленной CSE, где они получают своего рода "теневой" аналог, и они предоставляют вашему приложению некоторую информацию о состоянии ресурсов, а также о том, как их получить (через атрибут ссылки). Но если вы действительно хотите получить доступ к удаленной CSE, и у вашего приложения есть права для этого, атрибут pointOfAccess предоставляет вам адрес удаленной CSE.

Но, как уже было сказано, в общем случае ваше приложение (AE) подключено к одной CSE. На этой CSE размещаются все ресурсы AE или ресурсы, к которым AE имеет доступ. Также имейте в виду, что AE должно иметь разрешение (через AccessControlPolicy) на CSE для доступа к ресурсу.

Обновить

Возможно, мне нужно немного подробнее рассказать о том, как работать с удаленной CSE. Пока игнорируем объявленный ресурс, есть две возможности, что ваш "IN-AE" может получить доступ к ресурсу на удаленной CSE:

• Вы можете отправлять запросы, такие как извлечение, обновление и т. Д., На удаленный ресурс CSE в IN-CSE. Эти запросы затем направляются в реальный экземпляр "mn-cse" посредством соединения Mcc между IN-CSE и MN-CSE. Это имеет то преимущество, что "IN-AE" не нужно заботиться о том, как напрямую подключиться к MN-CSE "mn-cse" (например, могут быть установлены межсетевые экраны и т. Д. Для защиты MN-CSE).
  Вы можете увидеть это, если посмотрите на HTTP-запрос в примере TR-0025 ( http://www.onem2m.org/application-developer-guide/implementation/content-instance-retrieve).
  GET /~/mn-cse/home_gateway/light_ae1/light/la HTTP/1.1
  Этот получатель http-запроса - IN-CSE. Но, как вы можете видеть, он нацелен на ContentInstance в удаленном CSE mn-cse.
• Если вам действительно необходим прямой доступ к удаленному CSE, например, из соображений производительности, тогда ваш "IN-AE" может извлечь атрибут pointOfAccess и получить прямой доступ к удаленному CSE "mn-cse". В этом случае "IN-AE" фактически становится AE удаленного CSE "mn-cse" и должен знать, как к нему подключиться.