Opendaylight之MD-SAL中级教程（一）

Origin article on: http://www.wyqbupt.com/2015/06/15/opendaylight%e4%b9%8bmd-sal%e4%b8%ad%e7%ba%a7%e6%95%99%e7%a8%8b/


这里我们需要一个ODL应用的开发，首先提供一个骨架代码，放在我的github上，下面是地址：
请自行下载,地址如下：
https://github.com/wyqbupt/ODL-skeleton/
下载命令：
git clone git@github.com:wyqbupt/ODL-skeleton.git


├── artifacts
├── distribution-karaf
├── features
│ └── src
│ └── main
│ └── resources
│ └── features.xml
├── parent
├── ODL-skeleton-api
├── ODL-skeleton-consumer
├── ODL-skeleton-impl
└── ODL-skeleton-it


首先打开应用根路径下的pom.xml
<parent>
       <groupId>org.opendaylight.ODL-skeleton</groupId>
       <artifactId>ODL-skeleton-parent</artifactId>
       <version>0.0.1-SNAPSHOT</version>
       <relativePath>parent</relativePath>
   </parent>




 relativePath这个很重要，这是我们能够找到根模块的地方，我们打开parent目录可以看见，maven 解析这些子模块的时候会先去读取根模块的内容。

下面是本模块的描述
<modelVersion>4.0.0</modelVersion>
   <artifactId>ODL-skeleton-aggregator</artifactId>
   <description>ODL-skeleton Project Archetype Top Level POM</description>
   <packaging>pom</packaging>
   <name>${project.artifactId}</name>

下面是模块的定义，这些模块名发现都是那些目录名，所有需要最终组合到一起的模块都要写进去，最终组合安装的过程会把下面这些模块都扔进OSGi容器内。
<modules>
        <!-- the ODL convention is to have parent and artifacts subdirectories -->
        <module>parent</module>
        <module>artifacts</module>
 
        <!-- TODO: add new features here -->
        <module>ODL-skeleton-impl</module>
        <module>ODL-skeleton-api</module>
        <module>ODL-skeleton-consumer</module>
        <module>features</module> 
        <module>distribution-karaf</module>
  </modules>




ODL-skeleton-api

这里定义了基本的api，还有yang文件的定义，后面我们写完yang文件后用yangtools去生成相应的java API和REST API。

先看pom.xml文件
<parent>
        <groupId>org.opendaylight.ODL-skeleton</groupId>
        <artifactId>ODL-skeleton-parent</artifactId>
        <version>0.0.1-SNAPSHOT</version>
        <relativePath>../parent</relativePath>
    </parent>


ODL-skeleton-impl

它主要包括相应的实现代码和应用的配置型代码，这部分唯一注意的是它是对api模块的依赖
打开所对应的pom.xml
<dependencies>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>ODL-skeleton-api</artifactId>
    </dependency>
    <dependency>
        <groupId>org.osgi</groupId>
        <artifactId>org.osgi.core</artifactId>
    </dependency>
</dependencies>


ODL-skeleton-consumer

因为在一个应用中，服务提供方是provider,接收方是comsumer。一个应用可以有provider或者consumer，或者两个都有。这个在应用中是可选的，暂时不做。

ODL-skeleton-it

这里面是最后应用整合安装的时候跑的测试性代码
features:
这是一个比较重要的module:
对于Karaf容器来说，每一个应用都是是一系列的feature,他们可以被安装进容器内。这个文件夹内定义了我们写的应用的feature和依赖关系。比如我们的应用都是链接在MD—SAL上，所以必须依赖MD-SAL。
先看pom.xml,这里我是参考了一下SDNhub上放的那个例子的feature的依赖关系，将那些org.apache.jasper之类的都放进去了。重点是前几个自己加的。
这是yangtools，这是利用yang来生成java代码的工具

<dependency>
    <groupId>org.opendaylight.yangtools</groupId>
    <artifactId>features-yangtools</artifactId>
    <classifier>features</classifier>
    <type>xml</type>
</dependency>
这是md-sal，基本所有的模块都接在上面，它充当链接各个应用的一个桥梁
<dependency>
    <groupId>org.opendaylight.controller</groupId>
    <artifactId>features-mdsal</artifactId>
    <classifier>features</classifier>
    <type>xml</type>
</dependency>
这是restapi配置时会用的
<dependency>
    <groupId>org.opendaylight.controller</groupId>
    <artifactId>features-restconf</artifactId>
    <classifier>features</classifier>
    <type>xml</type>
</dependency>

我们再来看feature内的src/main/resources/features.xml
下面这些内容是我们依赖的feature，以<repository>标示, 这些就是我前面说的parent根模块的作用，在parent根模块的pom.xml文件中定义这些变量，maven会自动去解析替换，至于这些版本应该定义成多少，或者说ODL提供了那些版本，我们可以在http://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/自行查找相应的项目存在的版本号。

这里需要注意的是，所有定义在这里的依赖feature，必须在feature的pom.xml文件中加入依赖！不然编译的时候过不去

<repository>mvn:org.opendaylight.yangtools/features-yangtools/${yangtools.version}/xml/features</repository>
    <repository>mvn:org.opendaylight.controller/features-mdsal/${controller.mdsal.version}/xml/features</repository>
    <repository>mvn:org.opendaylight.controller/features-nsf/${nsf.version}/xml/features</repository>
    <repository>mvn:org.opendaylight.controller/features-restconf/${controller.restconf.version}/xml/features</repository>
    <repository>mvn:org.opendaylight.openflowplugin/features-openflowplugin/${openflowplugin.version}/xml/features</repository>


剩下是我们之前讲的３个模块api,impl,consumer
这里就讲讲一个模块的feature的结构，每个feature都会依赖其他的feature,比如api依赖yangtools，那么我们就将odl-yangtools-common 和odl-yangtools-binding写入api内部包含的feature。


<feature name='odl-ODL-skeleton-api' version='${project.version}' description='OpenDaylight :: ODL-skeleton :: API'>
        <feature version='${yangtools.version}'>odl-yangtools-common</feature>
        <feature version='${yangtools.version}'>odl-yangtools-binding</feature>
        <!--<feature version='${restconf.version}'>odl-restconf</feature>-->
        <bundle>mvn:org.opendaylight.ODL-skeleton/ODL-skeleton-api/${project.version}</bundle>
    </feature>
以上是整个框架的讲解。
请先在根目录下mvn clean install试一下能否成功编译生成，成功之后karaf的运行路径在distribution-karaf/target/assembly/bin，以后启动我们自己的karaf就在这里


评论

发表评论

此博客中的热门博文

openflow switch(I)

图片
一、基础概念图： 　　首先我们先看下Open Flow Switch的整体结构，以便有一个初步的感性认识，如下图所示： 从上面架构图中，我们可以看到Open Flow Switch主要是由以下几个部分构成： 1、Remote Controller：我们知道，SDN网络将传统的网络结构划分成了Control Plane和Data Plane两部分，这里的Remote Controller正是Control Plane部分，通过约定的通信协议来远程控制管理OpenFlow Switch，增加、删除或者修改OpenFlow Switch的Flow Entries。 2、OpenFlow Channel：它可以被认为是OpenFlow Switch对外开放的接口，接受来自于Remote Controller的通信协议，进而来操纵OpenFlow Switch。 3、OpenFlow Protocol：一种通信协议规范，用于Remote Controller和OpenFlow Switch之间的消息交换。 4、Flow Table：包含多个Flow Entry记录，控制数据包的流向，具体过程可参考下文。 5、Group Table：相对于Flow Table，控制着数据包更高级的转发特性，比如Flooding、Multipath、Fast Reroute、Link Aggregation等。 6、Pipeline：由多个Flow Table链接而成，控制数据包的一系列行为。 OpenFlow Ports 1、Standard Ports（标准端口）：  　　OpenFlow Standard Ports通常被定义为是 Physical ports, logical ports和支持的 LOCAL Reserved ports （不包括其他的Reserved ports）。它们可被用于 ingress port，也可被用于 output port，同样可以用于 Group 里，它们都有 port counters。 2、Physical Ports（物理端口）： 　　OpenFlow Physical Ports是OpenFlow Switch定义的、 对应于物理交换机的一个硬件接口的port。 比如在一个以太网交...
阅读全文

YANG Tools:YANG to Java Mapping

1   YANG to JAVA mapping 1.1   Package name 1.1.1   Other package names 1.2   Class and interface name 1.3   Getters and setters name 1.4   Module 1.4.1   Data Interface 1.4.2   Service Interface 1.5   Typedef 1.5.1   Type's valid arguments 1.5.1.1   Enumeration's substatement enum 1.5.1.2   Bits's substatement bit 1.5.1.3   Union's substatement type 1.5.2   String mapping 1.6   Container 1.7   Leaf 1.8   Leaf-list 1.9   List 1.10   Choice and case 1.11   Grouping and uses 1.12   Rpc 1.13   Notification 1.14   Augment 1.15   Identity Package name The package name consists from following parts: opendaylight prefix  - every package name starts with prefix  org.opendaylight.yang.gen.v1  which is hardcoded in  BindingGeneratorUtil.moduleNamespaceToPackageName() . YANG version  - is specified through...
阅读全文

OpenDaylight架构简介

图片
在我们跳入代码之前，需要对OpenDaylight控制器进行高级概述。 OpenDaylight是一个模块化平台，大多数模块 reusing  一些常见的服务和接口。 每个模块都是在多供应商子项目下开发的。 你可以在这里找到项目的列表。 在OpenDaylight平台上构建应用程序的想法是利用其他平台包中的功能，每个平台包都通过Java接口导出重要的服务。 许多这些服务是在称为MD-SAL的适应层上在提供者 - 消费者模型中构建的。 在OpenDaylight的核心编程中的MD-SAL数据存储涉及采用用于SDN应用开发的模型 - 视图 - 控制方法： 1. YANG Model for  数据，RPC和通知 （ YANG Model for data, RPC and notifications ） 2.REST API视图通过RESTconf实现自动生成和访问 3.Java编码处理数据更改，通知和RPC回调 （ Java Implementation coded to handle data changes, notifications and RPC call backs） 3.1模型驱动的SAL（MD-SAL） 模型驱动的服务适配层（MD-SAL）是平台的内核，不同的 层和模块通过API互连 。 以下是关于MD-SAL的一些重要注意事项：    1. 每个API都 是在构建期间从 YANG语言中定义的模型生成的 ，并且当模型包（ model bundle ）装入到Karaf平台时 加载到控制器中 。   2.在平台的核心是逻辑集中的数据存储，其将相关状态保持在两个桶中 - 1）配置数据存储，2）操作数据存储。   3.使用MD-SAL映射逻辑， 所有事件调用和数据通过此中央数据存储区从“提供者”到“消费者” 。 3.2  YANG  模型 OpenDaylight大量使用YANG来 建模在不同模块间的数据 ，通知或  remote procedure call  （RPC）。 对于那些不熟悉YANG的学生，我们建议您通过Tail-F系统学习YANG教程。 简而言之，YANG是一种用于描述存储在容器...
阅读全文