opendaylight Md-sal

Md-sal中
How To Look Up Data In MD-SAL –Helium Version Posted by Kanika
Previously I wrote how to look up data in MD-SAL data store but that holds good
only for OpenDaylight’s Hydrogen release. In OpenDaylight’s Helium release, data broker API’s have been changed. Here is how you can look up data in MD-SAL data store if you are using OpenDaylight’s Helium v ersion. Note that you also have to switch your OSGI bundle to be config subsytem aware before you can start using
new DataBroker service.
import mon.base.Optional;
import org.opendaylight.controller.md.sal.binding.api.DataBroker;
import mon.api.data.LogicalDatastoreType;
import org.opendaylight.controller.md.sal.binding.api.ReadOnlyTransaction ;
...
...
//Look up all the nodes from MD-SAL operational data store
InstanceIdentifier<Nodes> nodesIdentifier = InstanceIdentifier.builder().node(Nodes.class).toInstance();
Optional<Nodes> nodes= null;
try {
nodes= readTx.read(LogicalDatastoreType.OPERATIONAL, nodesIdentifier).get();
List<Node> nodeList = nodes.getNode();
} catch (InterruptedException | ExecutionException e) {
e.printStackTrace();
}
How To Insert Data In MD-SAL Data Store – Helium Version
Posted by Kanika
Previously I wrote how to insert data in MD-SAL data store but that holds good only for OpenDaylight’s Hydrogen release. In OpenDaylight’s Helium release, data broker API’s have been changed. Here is how you can insert data in MD-SAL data store if
you are using OpenDaylight’s Helium version. Note that you als o have to switch your
OSGI bundle to be config subsytem aware before you can start using new DataBroker service.
AD-SAL与MD-SAL的比较
AD-SAL
主要功能：定义抽象服务，吸收南向协议的差异，提供统一的抽象服务和API，并提供相应的Request Routing。

北向的Plugin可以通过调用AD-SAL提供的北向API来实现对南向Plugin的调用，操作其管理的设备和服务。

在AD-SAL中，抽象服务由南向和北向API实现，南北向API是一对一的映射关系。

这种架构比较好理解，也很常用。

而开发者在开发过程中，要充分考虑下层协议和Plugin 对服务抽象层提供的服务的支持程度。

这里写图片描述
MD-SAL
功能：提供Request Routing和用来定义抽象服务和相应API的基础框架。

管理基于Yang Model定义的各种Plugin。

需要说明的是，抽象服务和相应API严格的说是由各个Plugin通过yang model
和service来定义，而不是由MD-SAL定义。

这里会引出Yang Tools Plugin这样一个神器，他通过各个Plugin的model 用这些Sevice Interface实现具体的API和服务内容。

Plugin通过MD-SAL和生成的API（RPC，Notification）、DataStore 去利用其他各个Plugin的服务和数据。

其实在这个架构中，所有功能模块的信息交互、数据存储调用都是通过MD-SAL来完成。

简单的解释MD-SAL 的主要功能就是管理基于Yang Model定义的各种Plugin。

二者比较
在AD-SAL中，南北向API是1：1的对应关系，同一API无法被复用。

所有南北向Plugin的功能都需要定义相应的AD-SAL API来承载，造成AD-SAL模块会更加庞大、实现更为复杂、维护困难性增加。

而MD-SAL加入了自动化的思路，所有模块的通信都要经过MD- SAL，不过结构更复杂，从架构上避免了很多问题，不过也增加了学习成本。