1. SAL架構編程
系統的體系結構以下圖所示:設計模式
上圖中的子系統以下:架構
綁定無關生產者:它們的功能以綁定無關的數據DOM格式公開;
綁定感知生產者:它們的功能以針對一個或多個生成的綁定接口編譯的形式顯示; app
綁定無關消費者 - 以DOM的形式調用
綁定感知消費者 - 以一個或多個接口的形式調用ide
2.子系統類型插件
在Controller架構的上下文中,定義了兩個子系統類別:設計
YANG支持經過YANG Schema和模塊對頂級子系統進行建模,但不容許將現有模型重用於嵌套在頂級子系統上下文中的子系統。爲了支持嵌套,引入了YANG擴展,這將擴展模式以容許子系統在單個數據樹中進行模型嵌套。代理
3.頂級子系統orm
頂級子系統能夠是部署在Controller中的控制器組件或應用程序(provider或消費者),它們使用Controller SAL與其餘控制器組件、應用程序和插件進行通訊。blog
頂級子系統子系統一般:每一個系統/ AP或者具備單個實例I,或者具備多個版本實例,每一個實例對於由YANG模型定義的修訂是惟一的; 對於多個版本實例,每一個實例表示單個封閉系統。
頂級子系統的主要例子是代理(Broker)和數據倉庫(Data Repositories)。
4. 嵌套子系統
嵌套子系統表示不是頂級的實體(例如組件、虛擬系統和網元),而且能夠將多個實例掛載到樹的不一樣級別和不一樣分支。
嵌套子系統的實例不直接映射到生產者實例:單個生產者(provider)能夠導出(export)嵌套子系統的多個實例。
嵌套子系統可使用與頂級子系統不一樣的模型和模式。
5.嵌套數據存儲(DataStore)
嵌套子系統的數據在控制器的數據存儲區中的節點(附件點)下「附加」(或「掛載」)。
嵌套子系統中的數據能夠表示存在於另外一(遠程)系統中的數據或本地控制器組件(例如插件)中的數據。它也能夠由Controller組件動態生成,或者從其餘協議轉換。
附加(安裝)數據及其結構具備如下屬性:
提供嵌套子系統服務的組件負責:
6.RPC
消費者可能須要調用嵌套子系統提供的功能。 RPC代理必須提供可以在生產者中啓用嵌套RPC功能。此外,代理必須可以將RPC路由到嵌套子系統的生產者。
原文連接:https://wiki.opendaylight.org/view/OpenDaylight_Controller:_SAL_Architecture_Overview