与远程 CSE 上的资源通信 - OneM2M
Communication with resources on a remote CSE - OneM2M
我们正在尝试实施oneM2M 标准，并且对Remote CSE 和IN-CSE 之间的通信过程有疑问。我在下面逐步写下了我从文档中理解的内容。有些问题对我们来说不是很清楚，所以在进行任何实施之前，我需要确保一切都crystal清楚。
我要先问这个问题，然后再说出我们从文档中了解到的所有内容。那我就一步步写下我们想到的解决方案是什么。问题是，由 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 发送发现或检索请求，说让我获得远程 CSE 的所有子资源。
2- 发送发现或发送检索请求之间的确切区别是什么？我们认为发现请求 returns 只是资源 uri，但检索请求 returns 确切资源的全部数据。这种做法正确吗？
3- 获取所有远程自定义搜索引擎后，现在我知道了远程自定义搜索引擎的 ID。然后我可以向 MN-CSE 发送发现请求以在其中获取 AE。我们认为有两个选择：
a. ~/in-cse61/csr-34?fu=1&rty=2
b. ~/mn-cse34?fu=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 的资源 ID 开头。
所以 IN-AE（例如智能手机）应该以某种方式决定哪个 CSE 应该处理请求？有什么我们认为不对的地方吗？
--------------------已编辑------------------------ --------------
我已经检查了应用程序开发人员指南 TR-0025 的体系结构 http://www.onem2m.org/application-developer-guide/architecture
根据此示例，智能手机 (IN-AE) 可以通过 IN-CSE 控制 Light#1(ADN-AE-1)。
注册和初始资源创建过程完成后，系统准备好发现并控制灯。
GET /~/mn-cse/home_gateway?fu=1&rty=3&drt=2 HTTP/1.1
Host: in.provider.com:8080
虽然在 HTTP 请求中使用了中间节点 CSE-ID 和中间节点 CSEBase 名称 url，但主机被寻址到 IN-CSE。这意味着，从 IN-AE 发送的发现请求首先由 IN-CSE 处理，然后将其重定向到 mn-cse。但是您告诉我相反的说法“检索或发现通常仅限于托管 CSE 的资源，不会自动遍历远程 CSE。”。
在 TR-0025 中，给定示例显示为常见场景。
还有在 TR-0034，实际上它正在遍历请求，如图所示。
你的问题中有很多点需要解决。
首先，oneM2M中没有名为"IN-AE"的特殊实体。这只是 oneM2M 的 TR-0025 中用于连接到 IN-CSE 的 AE 的名称：使用 HTTP 绑定的灯光控制 开发人员指南。应用程序实体实际上可以通过相同的协议 (mca) 连接到 IN-CSE 或 MN-CSE，尽管可能有专门设计用于一个特定 CSE 的 AE。
关于您的第 2 点，retrieve 和 discovery 请求之间的区别：
retrieve 请求针对资源以检索它。例如，发送到 Container 资源 /mn-cse34/cnt-1 的检索请求（根据您的示例）将检索 Container 资源本身及其属性。
discovery 请求也是针对资源的，从技术上讲，它看起来非常像普通的 retrieve 请求。但除此之外，您还提供 筛选条件 和 发现结果类型 。例如，发送到同一 Container 资源 /mn-cse34/cnt-1 的发现请求可能 return 对 [=来自 Container 资源的 30=]ContentInstances。根据过滤器和结果类型，您可以获得完整资源或仅对它们的引用。
请查看 oneM2M 的规范 TS-0001 功能架构、10.2.6 发现 和 8.1 部分.2 Request 以获得 discovery 请求的完整解释和可能参数列表。
关于你问题的第 1 点和第 3 点：我不知道你的 AE 想要解决什么，但它应该有内置数据结构的概念。将数据组织成一个好主意结构化和统一的方式，例如通过使用 Containers、FlexContainers、Groups 等。这样应用程序就不需要浏览CSE 的整个资源树，随着时间的推移可能会变得非常大。当然也有可能是一般的应用需要遍历更大的先验未知结构。在那种情况下，应用程序可以使用 discovery 请求来获取相关资源。请注意，您还可以发现资源的元数据，例如标签、日期和时间等。这可能有助于减少结果集。
检索或发现通常仅限于托管CSE 的资源，不会自动遍历到远程CSE。 已公布 资源是个例外。这些资源被宣布给远程 CSE，在那里他们得到一种 "shadow" 对应物，并且他们为您的应用程序提供一些关于资源状态以及如何检索它们的信息（通过 link属性）。但是，如果您真的想访问远程 CSE 并且您的应用程序具有这样做的权限，则 pointOfAccess 属性会为您提供远程 CSE 的地址。
但如前所述，通常您的应用程序 (AE) 连接到单个 CSE。在那个 CSE 上托管了 AE 的所有资源，或者 AE 可以访问的资源。还要记住，AE 需要在 CSE 上获得权限（通过 AccessControlPolicy）才能访问资源。
更新
也许我需要详细说明如何使用远程 CSE。暂时忽略 宣布的 资源，您的 "IN-AE" 可以通过两种可能性访问远程 CSE 上的资源：
- 您可以向 IN-CSE 中的远程 CSE 资源发送 retrieve、update 等请求。这些请求然后通过 IN-CSE 和 MN-CSE 之间的 Mcc 连接转发到真正的 "mn-cse" 实例。这样做的好处是 "IN-AE" 不需要关心如何直接连接到 MN-CSE "mn-cse"（例如可能有防火墙等来保护 MN-CSE）。
如果您查看 TR-0025 (http://www.onem2m.org/application-developer-guide/implementation/content-instance-retrieve)
示例中的 HTTP 请求，您可以看到这一点
GET /~/mn-cse/home_gateway/light_ae1/light/la HTTP/1.1
这个 http 请求的接收者是 IN-CSE。但是，如您所见，它以远程 CSE mn-cse. 上的 ContentInstance 为目标
- 如果您确实需要直接访问远程 CSE，例如出于性能原因，那么您的 "IN-AE" 可以检索 pointOfAccess 属性并直接访问远程 CSE "mn-cse"。在那种情况下，"IN-AE" 实际上成为远程 CSE "mn-cse" 的 AE，并且需要知道如何连接到它。
我们正在尝试实施oneM2M 标准，并且对Remote CSE 和IN-CSE 之间的通信过程有疑问。我在下面逐步写下了我从文档中理解的内容。有些问题对我们来说不是很清楚，所以在进行任何实施之前，我需要确保一切都crystal清楚。
我要先问这个问题，然后再说出我们从文档中了解到的所有内容。那我就一步步写下我们想到的解决方案是什么。问题是，由 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 发送发现或检索请求，说让我获得远程 CSE 的所有子资源。
2- 发送发现或发送检索请求之间的确切区别是什么？我们认为发现请求 returns 只是资源 uri，但检索请求 returns 确切资源的全部数据。这种做法正确吗？
3- 获取所有远程自定义搜索引擎后，现在我知道了远程自定义搜索引擎的 ID。然后我可以向 MN-CSE 发送发现请求以在其中获取 AE。我们认为有两个选择：
a. ~/in-cse61/csr-34?fu=1&rty=2
b. ~/mn-cse34?fu=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 的资源 ID 开头。
所以 IN-AE（例如智能手机）应该以某种方式决定哪个 CSE 应该处理请求？有什么我们认为不对的地方吗？
--------------------已编辑------------------------ --------------
我已经检查了应用程序开发人员指南 TR-0025 的体系结构 http://www.onem2m.org/application-developer-guide/architecture
根据此示例，智能手机 (IN-AE) 可以通过 IN-CSE 控制 Light#1(ADN-AE-1)。
注册和初始资源创建过程完成后，系统准备好发现并控制灯。
GET /~/mn-cse/home_gateway?fu=1&rty=3&drt=2 HTTP/1.1
Host: in.provider.com:8080
虽然在 HTTP 请求中使用了中间节点 CSE-ID 和中间节点 CSEBase 名称 url，但主机被寻址到 IN-CSE。这意味着，从 IN-AE 发送的发现请求首先由 IN-CSE 处理，然后将其重定向到 mn-cse。但是您告诉我相反的说法“检索或发现通常仅限于托管 CSE 的资源，不会自动遍历远程 CSE。”。
在 TR-0025 中，给定示例显示为常见场景。 还有在 TR-0034，实际上它正在遍历请求，如图所示。
你的问题中有很多点需要解决。
首先，oneM2M中没有名为"IN-AE"的特殊实体。这只是 oneM2M 的 TR-0025 中用于连接到 IN-CSE 的 AE 的名称：使用 HTTP 绑定的灯光控制 开发人员指南。应用程序实体实际上可以通过相同的协议 (mca) 连接到 IN-CSE 或 MN-CSE，尽管可能有专门设计用于一个特定 CSE 的 AE。
关于您的第 2 点，retrieve 和 discovery 请求之间的区别：
retrieve 请求针对资源以检索它。例如，发送到 Container 资源 /mn-cse34/cnt-1 的检索请求（根据您的示例）将检索 Container 资源本身及其属性。
discovery 请求也是针对资源的，从技术上讲，它看起来非常像普通的 retrieve 请求。但除此之外，您还提供 筛选条件 和 发现结果类型 。例如，发送到同一 Container 资源 /mn-cse34/cnt-1 的发现请求可能 return 对 [=来自 Container 资源的 30=]ContentInstances。根据过滤器和结果类型，您可以获得完整资源或仅对它们的引用。
请查看 oneM2M 的规范 TS-0001 功能架构、10.2.6 发现 和 8.1 部分.2 Request 以获得 discovery 请求的完整解释和可能参数列表。
关于你问题的第 1 点和第 3 点：我不知道你的 AE 想要解决什么，但它应该有内置数据结构的概念。将数据组织成一个好主意结构化和统一的方式，例如通过使用 Containers、FlexContainers、Groups 等。这样应用程序就不需要浏览CSE 的整个资源树，随着时间的推移可能会变得非常大。当然也有可能是一般的应用需要遍历更大的先验未知结构。在那种情况下，应用程序可以使用 discovery 请求来获取相关资源。请注意，您还可以发现资源的元数据，例如标签、日期和时间等。这可能有助于减少结果集。
检索或发现通常仅限于托管CSE 的资源，不会自动遍历到远程CSE。 已公布 资源是个例外。这些资源被宣布给远程 CSE，在那里他们得到一种 "shadow" 对应物，并且他们为您的应用程序提供一些关于资源状态以及如何检索它们的信息（通过 link属性）。但是，如果您真的想访问远程 CSE 并且您的应用程序具有这样做的权限，则 pointOfAccess 属性会为您提供远程 CSE 的地址。
但如前所述，通常您的应用程序 (AE) 连接到单个 CSE。在那个 CSE 上托管了 AE 的所有资源，或者 AE 可以访问的资源。还要记住，AE 需要在 CSE 上获得权限（通过 AccessControlPolicy）才能访问资源。
更新
也许我需要详细说明如何使用远程 CSE。暂时忽略 宣布的 资源，您的 "IN-AE" 可以通过两种可能性访问远程 CSE 上的资源：
- 您可以向 IN-CSE 中的远程 CSE 资源发送 retrieve、update 等请求。这些请求然后通过 IN-CSE 和 MN-CSE 之间的 Mcc 连接转发到真正的 "mn-cse" 实例。这样做的好处是 "IN-AE" 不需要关心如何直接连接到 MN-CSE "mn-cse"（例如可能有防火墙等来保护 MN-CSE）。
如果您查看 TR-0025 (http://www.onem2m.org/application-developer-guide/implementation/content-instance-retrieve)
示例中的 HTTP 请求，您可以看到这一点GET /~/mn-cse/home_gateway/light_ae1/light/la HTTP/1.1
这个 http 请求的接收者是 IN-CSE。但是，如您所见，它以远程 CSE mn-cse. 上的 ContentInstance 为目标
- 如果您确实需要直接访问远程 CSE，例如出于性能原因，那么您的 "IN-AE" 可以检索 pointOfAccess 属性并直接访问远程 CSE "mn-cse"。在那种情况下，"IN-AE" 实际上成为远程 CSE "mn-cse" 的 AE，并且需要知道如何连接到它。