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 https://www.360docs.net/doc/a010547138.html,mon.base.Optional;

import org.opendaylight.controller.md.sal.binding.api.DataBroker;

import https://www.360docs.net/doc/a010547138.html,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 nodesIdentifier = InstanceIdentifier.builder().node(Nodes.class).toInstance();

Optional nodes= null;

try {

nodes= readTx.read(LogicalDatastoreType.OPERATIONAL, nodesIdentifier).get();

List 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，不过结构更复杂，从架构上避免了很多问题，不过也增加了学习成本。