Intel-iot-services-orchestration-layer使用教程（一）

Intel-iot-services-orchestration-layer

一、基本概念

1.Hub, Thing and Service

• Service：在IOT Layer这个IDE中内置了很多服务，我们可以直接从左面的菜单拖拽到右侧；服务代表着某些功能的调用，它能够接受输入并且产生输出；Service当从左侧被拖拽到右侧画布上时，会变成可视化的组件，包含输入和输出。
• Thing:Thing是服务的上层，Things可以包含多种服务，举个例子，一个“灯”是一个Thing，它的服务可以包含turn on,turn off,set color等等.一个Things也可以是云服务的集合，比如“云存储”作为一个Thing，它的服务可以包括“store a file”或者“fetch a file”等等。
• Hub：Things组成了Hub，举个例子，一个板子可以作为一个Hub，它可能包括很多传感器，这些传感器被称作“Things”,每一个传感器发送数据和采集数据又可以看成是“Service”.

下面图解释了三者的关系：

2.Center, Hub and Broker

• Center:Hub管理所有的Things，而Center管理所有的Hub.Center提供了基于HTML5的IDE,所以我们能在web上创建我们的APP。当然，UI也是被IOT Application支持的。
  那些通过开发人员拖拽而产生的工作流（WorkFlow）是IOT应用的逻辑，被存储在Center上，也被Center执行。

• Broker：工作流用到了被各种各样Hubs管理的Services.因此，在工作流执行的时候，Center 需要和这些Hubs通信并向它们发送消息，然后从这些Hubs的Services接收消息。这些消息被发送的时候就要用到Broker，Broker就像是代理（Proxy），消息（无论是从hub发送到Center的还是从Center发送到Hub上的）总是会先发给Broker，然后Broker再转发到目的地（dispatch it to the right target.）。
  IOT允许使用多种类型的Broker,eg,一个Broker可以是基于MQTT的，也可以是基于HTTP的，等等。

Advanced developers could enable more kind of Brokers by implemented a very limited set of APIs required by Intel(r) IoT Services Orchestration Layer.

3.How to start Center, Hub and Broker？

下图展示了Center, Broker and Hubs的关系：

4.Application, Workflow and UI

• Application:开发者会用HTML5的IDE来创建应用，每个应用都会有其特定的应用逻辑和特定的UI来为终端用户点击使用。

• Workflow:应用逻辑会由一个或多个workflow组成，这样开发者们就可以很容易地把他们通过编辑服务和者拖拽服务组装成一起。下图描述了一个workflow：
  

• Nodes, Ports and Edges of a Workflow:如上图所示，工作流由节点（node）和边（edge）组成。

每一个节点都是a Service of a Thing on a Hub.

每一个节点可能有零个、一个或者多个端口，左边的端口叫做输入，右边的端口叫做输出。节点从输入端口接收数据，然后从输出端口发送数据。

一个node就代表了一个服务，消息到达输入节点就触发了该节点的服务。

典型应用会提供一个交互式的界面UI与终端用户交互。我们在IDE里开发UI需要两步：

1. 第一，要选择 UI widgets然后布局，这决定了UI的样子；
2. 第二，要提取数据或者从widgets接受数据，这才能够使UI接受真正的用户数据。

第一步：UI widgets有很多内置的，开发者可以从左面拖拽到右侧画板上，然后进行相应的配置。

第二步：wire UI widgets into workflow.这些被拖拽到画板上的widgets 就像service,用输入和输出，可以连接到现有的工作流进程。

5.Introduction of Widget

Widget 是终端用户UI的基本元素。
Widget class的编写需要一定的规范。
具体widget类的写法参照官方文档：

http://01org.github.io/intel-iot-services-orchestration-layer/#getstarted/advanced/basics/4-UI_Widget

二、配置

1.当我们启动Center和Hub的时候，一个配置文件是必不可少的，默认是./config.json，来指定Center和Hub的行为。

学习配置文件的最好方式就是去看示例中的config.json.

http://01org.github.io/intel-iot-services-orchestration-layer/#getstarted/advanced/configuration

2.基本配置项

配置项可以直接看官方文档：

http://01org.github.io/intel-iot-services-orchestration-layer/#getstarted/advanced/configuration/1-Basic_Items

因为Center和Hub的交流是通过Broker,因此，每一个hub和center都应该为broker指定详细信息。

3.还需要配置LOG，每个日志消息有两个属性,即它的级别和类别。

日志的级别分为：debug, info, warn or error。

日志的类别定义了日志关联的组件，如message, center, hub, etc。

日志是否输出取决于配置。

4.Center的配置

Center提供了两个web服务器，一个用来支持web IDE,另一个用来支持web UI。我们需要设置这些web服务器使用的端口。

Center通过心跳机制去感知Hub的状态（Online/Offline）,所以在Center上有一个heartbeat服务器需要被配置。

5.Hub的配置

三、Use Service

1.所有可以使用的内置服务都被放置在IDE的左侧，它是一个三级层次结构。从上到下分别是：Hubs->Things->Services.

有的服务可以被编辑，点击</>图标进入编辑页面。

2.画板上的服务：

3.配置如何调用服务

当一个service有多个输入时，服务可能会要求所有输入端口都有数据到达时它才会启动。而IOT提供了很多可视化的配置项满足这样的需求。

阶段的服务调用，有下面四种状态：

①. Stage: Data Arrivial: A message arrives at the inport of a Service

对于消息到达输入端口来说，消息在其被消费来唤醒服务前需要被存储，消息的存储有两种方式，Buffered Mode和Cache Mode.

②. Stage: Trigger: According to the configuration, it decides whether the data arrival can results in the next stage so called Prepare

消息被存储之后，它将会被触发（Trigger）会进入到Prepare状态。当然，特殊的时候，我们可能希望数据只是被存储但不会触发服务，也不会进入到next stage，这是可以通过可视化IDE配置的。

③. Stage: Try to Prepare IN object: Collect the data stored at inports and prepare that as the input (so called IN object) for service invocation. NOTE that the Prepare could fail to form an IN object (e.g. no data has been arrived on other required inport etc.), and thus would NOT actually invoke the service, i.e. would NOT enter the next stage.

下一个阶段是准备阶段，service从输入读取数据作为参数，然后使用它们组成一个新的对象等待输出。这里如果设置所有输入端口的状态为Grouped，那就意味着只有所有端口的输入都到达并且有效，它们才会一起组成IN对象。

④. Stage: Service Execution: Really invokes and executes the Service with the IN object. Related messages used to form the IN object would be consumed once. During the excution, sendOUT maybe invoked 0 to N times to send messages through one or multiple its outports.

最后的状态就是执行服务，会消费掉输入的数据消息然后发送message作为输出。

附注：①有一些服务被称作是“Heads”，因为它们没有输入，就像“延时触发”服务，它没有任何输入，工作流开始的时候自动被触发，所以它的存储方式一定的“cached”(so could set default value)和“NOT Grouped”.
附注：②还有一些服务不需要存储输入的消息而直接进入到触发模式，我们可以通过下图设置：