1 前言
在學習OpenDaylight的過程中，總是遇到AD-SAL( API-Driven SAL)和MD-SAL（Model-Driven SAL）等概念。在努力查找資料學習之後，有了一點學習筆記，寫出來加深印象。同時也給同樣迷惑的同學一點幫助。
2 About MD-SAL
MD-SAL使得在SDN控制器那些豐富的服務和模塊可以使用統一的數據結構和南向和北向的API。
上圖引用地址：https://wiki.opendaylight.org/images/4/4d/SAL-Comparison.png
MD-SAL提供請求路由（request routing）和基礎設施去支持服務的適配，但它不提供服務的適應本身;業務適配是由插件提供。MD-SAL認爲適配插件是一個普通的插件：它向SAL提供數據，並通過模型生產的API來讀取消費數據。
2.1 Request outing
爲SAL中，request routing可用於消費者的請求路由，從而尋找到對應的生產者。當一個plugin註冊之後，就會在routing table中有對應記錄，consumer向SAL發起RPC應用申請的時候，會由request routing查找routing table，找到對應的plugin。
在md-sal/sal-binding-api/...、binding/api/rpc目錄下可以找到RpcRouter.java等文件，都與RPC routing有關。當然request routing還有notification的routing,並不僅僅只是rpc。
2.2 Bundle register
AbstractBrokerAwareActivator：在一個具體的plugin實現中會繼承AbstractBindingAwareProvider類,而AbstractBindingAwareProvider繼承了AbstractBrokerAwareActivator類。
當一個bundle啓動時就會調用AbstractBrokerAwareActivator。這個類實現了org.osgi.framework.BundleActivator接口。BunbleActivator中的start（BundleContext context）和stop(BundleContext context)方法用於開啓bundle和關閉bundle.在AbstractBrokerAwareActivator中，實現了start和stop兩個方法，分別調用了startImpl和stopImpl兩個具體的方法。startImpl是在bundle開始的時候，用於初始化，資源申請等。同理，stopImpl是bundle關閉時，資源的釋放。
同理，消費者類似。
2.3 onSessionInitialized
每一個消費者或生產者和SAL之間的通信都可以具體稱之爲Session(會話)。上一小節提到的BundleActivator接口中有兩個方法start和stop的參數都是BundleConetxt.在BundleContext接口中定義了許多方法，如：
可實現bundle的註冊。具體鏈接：http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html
在onSessionInitialized方法中，通常會調用session.addRpcImplementation(Class Serviceinterface,T implementation)。其方法定義在RpcProvider.java中，用於指明bunlde初始化時的接口和實現等運行實體。
3 Register to MD-SAL
3.1 BindingAwareBroker
BindingAwareProvider和BindingAwareConsumer都實現了BindingAwareBroker interface,用 於實現生產者和消費者的在MD-SAL註冊。此接口可以消除生產者和消費者之間的直接關係。
其他文件的功能根據文件名稱基本可以瞭解。博主也沒有太多深究。
3.2 RPC register
調用addRpcImplementation(class <T> serviceInterface, T implementation)方法將RPC註冊到MD-SAL,具體可查看RpcProviderRegister.java。舉例如下：
具體鏈接：http://sdntutorials.com/how-to-register-a-service-to-md-sal/
消費者可以通過getRpcService(class serviceInterface)調用對應的RPC。
4 Plugin development process
上圖引用地址：https://wiki.opendaylight.org/images/3/39/Plugin_design_process.png
在ODL中開發一個plugin的流程如上所示。以Ping爲例，首先需要使用YANG定義一個model,即model-ping。使用maven編譯的時候，會調用YANG Tools自動生成對應的API.然後生成API OSGI Bundle。
接着我們需要對接口進行實現，也即plugin source code.在ping例子中ping-plugin就是plugin source code。通過maven編譯生成plugin OSGI Bundle.最後都部署到OSGI上。將對應的jar包放到controller對應目錄中，運行controller時就會和控制器一起運行。但是在全局編譯的時候還需要再對應的pom.xml中對其進行描述，從而使得在編譯時將對應的bundle編譯並生成對應的jar，從而成功在controller中添加功能。
Example
借用官網的一張圖，解（翻）釋（譯）一下添加新流表時，ODL內部運行的場景。
- 當plugin/app啓動時，對應的bundle已經完成了註冊。a）流編程服務(還是flow programmer service舒服)在md-sal註冊，提供流數據配置通知服務。b）OF 插件和其他的插件在SAL上註冊AddFlow RPF實現。注意RPC在plugin model中定義，而API是在編譯過程中生成的。
- 一個客戶app通過控制器提供的REST API請求add flow。客戶端app需要提供這個REST調用的全部參數。
- 從“add flow”來的數據發序列化，然後一個新流就在flow service 配置數據樹上創建了。若成功REST調用馬上回回覆調用者成功信息。
- 由於flow programmer service已經註冊去接收在flow service data tree上的數據變化消息的通知。MD-SAL產生一個data changed的通知併發給Flow programmer service.
- flow programmer service 讀取該消息，併產生添加動作。
- 在這個過程中還其他的操作中，flow programmer service 需要告訴OF plugin在適當的交換機上添加flow。Flow programmer service 使用OF plugin生成的API去創建"AddFlow"RPC所需要的輸入參數DTO(data transfer obiect).
- Flow programmer service 獲取到服務的實例，然後引用服務中的“AddFlow”RPC。MD-SAL將會將請求路由到適當的OF plugin。
- "AddFlow"RPC 請求被路由到OF plugin，然後“AddFlow”RPC的實現方法被引用。
- “AddFlow”RPC實現通過OF plugin API去讀取RPC 輸入參數的DTO.
- "AddFlow"RPC 被遠程運行，相應的flow_mod被下發到相應的交換機。
5 後語
對於MD-SAL，我只是有一個概念，離真正瞭解還有很多距離。文中若有錯誤指出，敬請指出，共同進步！
其實官網上已經有很多資料，在學習的過程中，OpenDaylight SDN研究羣（194240432）的共享資料幫助了我很多。接下來我將學習官網教程toaster,希望能在那個例子中得到實踐經驗，爲以後的工程開發打下基礎。以目前的狀況來看，我還需要花很多時間來學習ODL，之後纔是真正的SDN應用開發。
轉載自：李呈博客@李呈，http://www.muzixing.com/pages/2014/08/13/opendaylightzhong-md-salxue-xi-bi-ji.html
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，不過結構更復雜，從架構上避免了很多問題，不過也增加了學習成本。