一 、軟件系統(tǒng)設(shè)計

理想情況下，提到軟件系統(tǒng)的設(shè)計，系統(tǒng)架構(gòu)人員想到的是如何架構(gòu)軟件，軟件開發(fā)人員想到的是如何更好地組織業(yè)務(wù)邏輯代碼，這些設(shè)計能夠更好地保證軟件正常運行。不理想的情況便是沒有設(shè)計或者設(shè)計不多，開發(fā)代碼靠的是開發(fā)人員自身的素養(yǎng)，有人更偏好前端實現(xiàn)，有人覺得后端實現(xiàn)可能更好，于是同一套代碼中，造成技術(shù)體系的混亂，如果項目比較緊張，那么內(nèi)部質(zhì)量很難保障，那么技術(shù)債就這樣形成了。

一般情況下，軟件系統(tǒng)的研發(fā)分為需求獲取與分析、架構(gòu)設(shè)計、代碼實現(xiàn)、系統(tǒng)發(fā)布、上線等階段。其中，架構(gòu)設(shè)計可以細分為架構(gòu)需求、分析、設(shè)計、文檔化、評審、修改和實現(xiàn)等過程，我們以簡化歸一，描述為：提供UI界面和消息接口服務(wù)，UI選擇B\\S架構(gòu)風(fēng)格，消息可以是REST、SOAP以及AMQP等類型，數(shù)據(jù)庫采用關(guān)系型數(shù)據(jù)庫。如下圖所示：

下一步就開始圍繞業(yè)務(wù)領(lǐng)域，進行系統(tǒng)的建模，一般有兩種方式：第一種是數(shù)據(jù)庫的設(shè)計，考慮需要那些表，表中包含應(yīng)該哪些字段，將業(yè)務(wù)需求抽象為數(shù)據(jù)模型；第二種是業(yè)務(wù)邏輯的面向?qū)ο笤O(shè)計，將業(yè)務(wù)需求抽象為對象之間的關(guān)系。我們以第一種方式進行系統(tǒng)的建模(以Java為例)：

①通過建模工具(Power Design)進行概念數(shù)據(jù)模型和物理數(shù)據(jù)模型的建模；

②根據(jù)數(shù)據(jù)庫的表，借助于代碼生成工具生成表對應(yīng)的Java對象；

③根據(jù)業(yè)務(wù)邏輯劃分不同的Service服務(wù)，對應(yīng)Domain Object；

④根據(jù)UI設(shè)計劃分不同的Action，對應(yīng)View Object；

⑤根據(jù)業(yè)務(wù)流程設(shè)計各層之間的調(diào)用關(guān)系，并進行不同層之間的對象轉(zhuǎn)換。

根據(jù)上述步驟我們簡單地得到如下圖所示的業(yè)務(wù)邏輯的設(shè)計：

我們可以簡單地將圖中的設(shè)計理解為業(yè)務(wù)邏輯的服務(wù)抽象層的設(shè)計。

二、MD-SAL

2.1 基礎(chǔ)

從OpenDaylight Lithium版本開始采用MDSE(Model-Driven Software Engineering,模型驅(qū)動軟件工程)設(shè)計。MDSE描述了一個框架，該框架支持模型建模，并可以基于模型生成相關(guān)的代碼和API接口。

MD-SAL(Model-driven Service Abstraction Layer，模型驅(qū)動的服務(wù)抽象層)可以看成是一個消息總線驅(qū)動、可擴展的中間件。“M”是模型，即為YANG語言，“MD”是模型驅(qū)動，即使用YANG作為數(shù)據(jù)和接口的建模語言，并為服務(wù)之間的通信提供基礎(chǔ)框架：消息傳遞和數(shù)據(jù)存儲功能。

由前面的文章可知，MD-SAL包含DataStore、RPC、Notification和Mount等概念，其中需要關(guān)注如下：

l DataStore： 分為Config和Operational，其本質(zhì)上是樹，并通過Instance identifier來標識子樹或節(jié)點；

l RPC： RPC的本質(zhì)上是不同進程間訪問的一種通信形式。在NETCONF協(xié)議中 RPC是NETCONF客戶端對NETCONF服務(wù)器的訪問。而在MD-SAL中，RPC用于服務(wù)消費者(使用者)對服務(wù)生產(chǎn)者(提供者)的訪問，不再是嚴格上的RPC定義。

同時，YANG Tools項目是一個旨在方便YANG開發(fā)的基礎(chǔ)設(shè)施項目庫，MD-SAL擴展了該項目，并為Java服務(wù)和應(yīng)用程序提供NETCONF和YANG支持。它具有解析和處理YANG架構(gòu)、基于YANG模式驗證XML結(jié)構(gòu)和基于YANG模式的REST API等組成部分。

2.2 設(shè)計實現(xiàn)

1.數(shù)據(jù)訪問

MD-SAL通過兩個不同的代理(brokers)訪問DataStore的數(shù)據(jù)：DOM Broker和Binding-Aware Broker。如下圖所示：

l DOM Broker： DataStore可以看作是XML數(shù)據(jù)庫，對于XML的解析通常采用DOM模型(Document Object Model，文檔對象模型)。DOM broker可以看成操作DataStore節(jié)點的請求代理。DOM Broker提供了基于XML DOM的API。

l Binding-Aware Broker： DOM形式的API不易于開發(fā)人員編程，該Broker支持YANG到Java語言的綁定，并提供基于YANG模型生成的接口和類，也就是Java的API。

l BA-BI Connector： 用于連接DOM Broker和Binding-Aware Broker，與Mapping Service、Schema Service、Codec Registry和Codec Generator等組件一起實現(xiàn)：DOM(BI)格式和Java DTO(BA)之間的轉(zhuǎn)換。

2.消息模式(messaging pattern)

MD-SAL提供了一組基于代理的消息傳遞模式，這些代理提供以數(shù)據(jù)為中心而非API的集成，并在服務(wù)之間傳輸YANG建模數(shù)據(jù)。事實上，MD-SAL包含了管理特定消息傳遞模式的不同代理，如圖所示：

l Data Broker： 對Data Store進行事務(wù)訪問。

l RPC Broker： 提供消費者和生產(chǎn)者之間的單播消息，消費者向生產(chǎn)者發(fā)送請求消息，生產(chǎn)者以異步消息的形式進行響應(yīng)。

l Notification Broker： 采用訂閱發(fā)布機制，由發(fā)布者發(fā)送并傳送給其訂閱者的多播消息。