一种基于WoT的资源模型的实现方法与流程

本发明涉及物联网资源访问控制领域，具体涉及一种基于WoT的资源模型的实现方法。

背景技术：

在传统物联网中，由于软硬件平台的差异性和设备的多样性，设备间无法直接互联通信，难以实现对这些异构设备的统一访问，最终无法屏蔽底层硬件设备、通信协议等因素造成的异构性。同时，在设备抽象为资源后，受到通信距离等因素的限制，难以实现对资源的远程访问和控制，导致访问控制的灵活性大大降低。

技术实现要素：

本发明为解决物联网中设备间异构性问题以及无法远程访问控制资源的问题，提出了一种基于WoT的资源模型的实现方法，其将设备唯一映射为Web中的资源，并通过发布这些资源接口使其能被远程访问和控制。

本发明的实现方法是通过如下步骤实现的，一种基于WoT的资源模型的实现方法，包括如下步骤：步骤一、将设备分为静态与动态两大类，分别建立静态设备所对应的静态资源模型、动态设备所对应的动态资源模型；步骤二、将设备映射为Web中的资源，通过步骤一中建立的静态资源模型与动态资源模型，将设备映射为Web中唯一的URI路径；步骤三、通过静态资源模型与动态资源模型，采用Servlet技术，将现实中的设备与Web中的URI一一对应；步骤四、通过键入URI路径实现对相应资源的访问与控制。

作为本发明改进的技术方案，通过静态设备的地理位置、静态资源标识符、资源属性以及资源编号构建静态资源模型。

作为本发明改进的技术方案，动态设备所对应的动态资源模型包括针对上传静态数据的动态资源模型以及下发控制指令的动态资源模型。

作为本发明改进的技术方案，通过动态设备的地理位置、动态资源标识符、上传静态数据标识符、资源属性以及资源编号构建上传静态数据的动态资源模型。

作为本发明改进的技术方案，通过动态设备的地理位置、动态资源标识符、下发控制指令标识符、资源属性、资源编号以及具体的指令构建下发控制指令的动态资源模型。

作为本发明改进的技术方案，将设备映射的资源封装成WebService接口，发布于云平台。

有益效果

本发明将资源分为静态资源与动态资源两大类，分别建立了对应的结构模型，并映射为Web中唯一的URI路径，通过Servlet技术实现了对资源的访问和控制，有效解决了物联网中设备间异构性问题，并通过发布这些资源接口，使得各资源能被远程访问和控制。

附图说明：

图1为本发明的静态资源的资源模型示意图；

图2为本发明的静态资源映射过程示意图；

图3为本发明的动态资源的资源模型示意图；

图4为本发明的动态资源上传静态数据映射过程示意图；

图5为本发明的动态资源下发控制指令映射过程示意图；

图6为本发明的URI访问控制资源实现流程示意图；

图7为本发明的开放资源接口架构示意图；

图8为本发明的静态资源接入Web效果图；

图9为本发明的动态资源的五层结构模型接入Web效果图；

图10为本发明的动态资源的六层结构模型接入Web效果图；

图11为本发明的远程静态资源访问图；

图12为本发明的远程动态资源访问图；

图13为本发明的远程动态资源控制图。

具体实施方式

为使本发明实施例的目的和技术方案更加清楚，下面将结合本发明实施例，对本发明的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例

一种基于WoT的资源模型的实现方法，包括如下步骤：

步骤一、将设备分为静态与动态两大类，分别建立静态设备所对应的静态资源模型、动态设备所对应的动态资源模型；

针对静态设备，通过静态设备的地理位置、静态资源标识符、资源属性以及资源编号构建静态资源模型；

动态设备所对应的动态资源模型包括针对上传静态数据的动态资源模型以及下发控制指令的动态资源模型；通过动态设备的地理位置、动态资源标识符、上传静态数据标识符、资源属性以及资源编号构建上传静态数据的动态资源模型；通过动态设备的地理位置、动态资源标识符、下发控制指令标识符、资源属性、资源编号以及具体的指令构建下发控制指令的动态资源模型；

步骤二、将设备映射为Web中的资源，通过步骤一中建立的静态资源模型与动态资源模型，将设备映射为Web中唯一的URI路径；

步骤三、通过静态资源模型与动态资源模型，采用Servlet技术，将现实中的设备与Web中的URI一一对应；

步骤四、通过键入URI路径实现对相应资源的访问与控制；

步骤五、将设备映射的资源封装成WebService接口，发布于云平台。

具体的为：

1.静态资源模型

考虑到映射过程中设备与资源需要一一对应，因而需要引入资源的地理位置属性用于区分不同位置的资源。为了确定资源的静态和动态属性，通过一个标志字段来进行区分，本实施例的静态资源模型中用Sensor来标识静态属性。同一位置可能出现多个静态设备资源，因此引入资源属性区分不同属性的静态资源。又考虑到同一位置可能出现多个相同属性的静态资源，最后还需要引入该位置资源的编号进行区分。通过这四个资源的描述内容，便可以将静态设备唯一进行资源化，防止冲突问题的产生。具体静态资源模型如图1所示：静态资源的资源模型分为地理位置、静态资源标识符、资源属性以及资源编号四层，因而只需要把四层对应的描述内容转换成相应的属性字段，并拼接成一个URI路径，那么通过该URI路径便可以访问到对应的设备资源，具体如图2所示。

2.动态资源模型

动态资源与静态资源的区别是动态资源不仅能够上传自身的状态和数据，同时能够对其进行控制，因而动态资源描述的资源模型只需要在静态资源的基础上进行修正。不难发现，用于标识静态资源和动态资源的标志位需要变换，在本实施例中动态资源模型中使用Control来标识动态属性。动态资源的映射过程与静态相似，但是由于动态资源存在上传静态数据和下发控制指令的双向问题，即分别对应五层和六层结构模型，因而分别进行映射。

具体的为：由于动态资源有上下行的双向数据传输方向，因而需要通过一个可选字段来标识是上传实时静态数据还是下发动态控制命令，具体为上传静态数据标识符与下发控制指令标识符，本实施例中上传静态数据标识符可选字段使用Static，下发控制指令标识符选用Dynamic。当需要对资源进行控制时（下发控制指令标识时），还需要确定对应的控制指令。故动态资源模型的资源模型图如图3所示。针对上传静态数据，可设为五层结构模型，具体的为传静态数据模型是根据设备所映射的动态资源的地理位置、动态资源标识符、上传静态数据标识符、资源属性以及资源编号来确定上传静态数据，将地理位置、动态资源标识符、上传静态数据标识符、资源属性以及资源编号转换为相应的属性字段并拼接成上传静态数据的URI路径，如图4所示；针对下发控制指令的六层结构模型，只需在五层的基础上加上一层控制指令，并将可选字段置为Dynamic即可，具体的为：下发控制指令模型是根据地理位置、动态资源标识符、下发控制指令标识符、资源属性、资源编号以及控制指令来标识资源正被反向控制，并将地理位置、动态资源标识符、下发控制指令标识符、资源属性、资源编号以及控制指令映射为下发控制指令的URI，具体如图5所示。

3.资源访问控制流程

通过以上对资源的描述和映射，将现实中的设备与Web中的URI一一对应，通过键入URI便可访问对应的资源。以上内容通过Servlet技术可以实现，实现的具体流程如图6所示：在浏览器中输入对应的URI路径，通过解析URI可以得到资源描述的各个字段，判断资源URI中是Sensor字段还是Control字段，确定该资源的静态和动态属性；若为Sensor则为静态资源，通过路径中的地理位置、资源属性以及资源编号便可以确定该资源，并获取数据予以显示；若为Control则为动态资源，此时需要判断可选字段，若为Static则获取对应资源上传的静态数据，进行实时反馈，若为Dynamic则将相应的指令发送给对应的资源，控制其完成指令所要求的操作。

4.资源接口发布

为了能使更多的平台访问和控制资源，通过将各个资源封装成WebService接口，发布于云平台，这样突破了地域等条件的限制，所有资源化后的设备都能够通过调用封装的API接口访问得到；又因为接口的发布是在上述模型的基础上进行，因而远程访问也不会出现对应错乱问题。

图7给出了接口发布的架构图，左侧为现有技术中直接将设备通过资源描述和映射拓展到Web中，可以通过浏览器等访问资源，但是仅仅是在本地进行访问和控制，不能满足远程访问控制的要求，因而需要在两者之间加入云平台，通过云平台发布资源API接口，便可打破本地的限制，使其能够通过调用接口远程访问控制，如图7中右侧部分所示。

5.实例验证

下面以温度传感器以及车位锁为例，分别作为静态资源和动态资源，使用Servlet技术实现了上述资源模型，具体实现效果如下所示。

1)静态资源

根据静态资源的结构模型，可以得出温度传感器对应的URI，其中地理位置location字段对应/NJUPT/nanmenweather，Sensor表示该资源为静态资源，temperature即为资源的属性，资源编号为1，所以对应的URI为/NJUPT/nanmenweather/temperature/1。

考虑到资源访问控制的便捷性，在Eclipse平台新建了一个WoTResource的Web项目，所有静态和动态资源都通过这个项目进行访问和控制。该项目部署于Tomcat容器之中，因而总体的资源访问路径需要加上容器的路径，访问的结果如图8所示。

2)动态资源

根据动态资源的五层结构模型，可以得到获取车位锁当前状态的URI路径。地理位置location字段为/NJUPT/nanmen，Control表示为动态资源，由于是获取车位锁的当前状态，即为上传静态数据，因而可选字段为Static，资源属性和编号分别为carlock和1，动态资源仍通过WoTResource项目拓展到Web，其访问的结果如图9所示。

对于车位锁的控制URI，与访问URI类似，只需要将Static字段设置为Dynamic，同时拼接上控制指令up，即将一号车位锁升起，其控制的结果如图10所示。

最后将这些资源封装为WebService接口发布于服务其中，使得安卓等更多的平台能够远程调用这些资源，具体实现效果：通过在服务器中新建WebService项目，编写封装静态资源和动态资源的Java类，并将它们在服务器中启动运行，第三方平台便可以通过这些发布的接口进行访问和控制。通过安卓平台编写了一个应用程序来调用封装的API接口，用户安装安卓APP连网即可访问这些资源，结果如图11、12、13所示。

以上仅为本发明的实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些均属于本发明的保护范围。