ONOS 系统组件介绍

1、 系统层次结构：
ONOS是按功能层来划分结构，

2、 服务与子系统
一个服务是指多个组件所构成的功能单元，其中组件能在层之间建立垂直切片，并将其作为软件栈。我们将能够生成服务的组件集合称为子系统
Device 子系统-管理基本device库
Link子系统-管理基本Link库
Host 子系统-管理基本终端host库和他们在网络中的位置信息
Topology 子系统-管理由时间先后顺序生成的网络topo图
PathService –用最新的网络topo来计算和发现设备与设备或则host与host之间的路径
FlowRule子系统-管理安装在设备上的match/action flow rule和提供flow metrics
Packet 子系统-允许应用监听来自网络设备的数据包同时允许应用通过一个或者多个网络设备将这些数据包转发到网络中

上图的子系统一部分已经实现，
3、 子系统的结构
在组成每个子系统的组件中，组件来自三个主要层中的其中一层，并且能够被一个或者多个已实现的JAVA接口识别
下图总结了子系统组件之间的关系，图中顶部和底部点线代表的是北向和南向APIs生成的层与层之间的界限

Provider
ONOS栈中最底下的一层，Providers通过特定协议库与network对接，通过ProviderService接口与core对接
对协议感知（指定协议）的Providers负责通过各种控制和配置协议与网络环境交互，同时为core提供指定服务的感知数据。Providers也能够从其他子系统收集数据，并转换成指定服务的数据
一些Providers也可以通过Provider接口接受core的指令，并使用合适的协议将指令作用到网络。
Provider ID
一个Provider对应一个Provider ID, Provider ID的主要作用是为provider提供一个外部化的身份，这样即便provider被卸载，其它设备和模型实体任然可以和provider保持关联
Mutiple Providers
一个子系统会涉及到多个provider，其中有的Provider会被指定为主导的有的会被指定为附属的，主导的Provider拥有与其服务相关联的的entities，附属的Provider作为overlay向主导的provider提供信息，这样就避免的底层信息之间的冲突
Device 子系统是支持Mltiprovider服务中的一个。
Manager
Manager是core中的一个组件，通过Provider提供的信息为其它应用和服务提供服务，它提供的了几个接口：
一个北向服务接口，应用和其它的core组件可以通过它了解到具体的网络状态。
一个AdminService接口，通过这个接口管理员的命令可以作用在网络或者系统中
一个南向的ProviderRegistry接口，Provider通过此接口向Manager注册，然后具备相互通信的条件。
一个南向的ProviderService，注册过的Provider可以通过此接口 与Manager相互收发信息。
使用这些服务的时候会收到一些同步的服务请求信息和异步时间监听信息（被EventListener接口实现）
Store
也是core中的组件与Manager紧密关联，Stores的任务是索引，保持和同步Manager收到的信息，这就确保了多个ONOS实例在进行通信的时候，信息的一致性和稳定性
Application
应用通过AdminService和Service接口能够操作Manager收集的信息，应用的功能比较广泛，从显示网络topo（web brower）到设置网络流量的路径。
Application ID
每个应用都有一个唯一的ID，ONOS通过这个ID获取应用的相关信息，应用提供应用名可以在CoreService中注册一个有效的ID，应用名的方式最好遵循DNS反向命名法eg：org,onlab.onos.fwd

并不所有的子系统都拥有全部的组件，也不是所有组件都拥有这些功能，例如：TopologyProvider的作用就是。。。。。。。。。。。
Event and Description
ONOS中两个信息发布的基本单元，和services一样，Event和Descriptions与特定网络元素和内容相关联，一旦创建都是不可变的。
Descriptions
Descriptions可以跨南向API传递网络元素的信息，比如，HostDescription包含主机的MAC地址和IP地址还有他们在网络中的位置信息（VLAN ID和设备/端口），Description通常可以组成一个或者更多的对象模型，这是多种网络组件的ONOS表述。
Events
Managers通过Events通知listeners关于网络中的变化，在分布式的设置中Stores则用它来通知同等events，一个Event是由一个事件类型和模型对象组成。例如，可以用DeviceEvent来通知DeviceListeners一些关于设备被侦测或则已经不在网路中的信息，还有网络中的一些变化情况。
Event dispatch
基于Manager的输入信息，由Store产生Events，然后将生成的Events通过StoreDelegate接口指派给对应的listeners，StoreDelegate接口最终调用的是EventDeleveryService。必要时，StoreDelegate会将store和EventDeliveryService移除以确保事件只到达指定的listeners，manager为store提供了StoreDelegate的类的实现。
Event Listeners
只要实现了EventListener接口的任何组件都是Event listeners。EventListener子接口由监听的事件子类的类型来分类。一个典型的实现模式是，让Event listener成为Manager或者应用的内部类，在内部类中合适的服务将会基于接受到的事件被调用。这限制了事件对外部子系统，子系统管理或则应用的处理
下图描述了Description，Event和组件之间的关系。