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

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

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

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

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

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

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

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

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

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

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

二、MD-SAL

2.1 基礎(chǔ)

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

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

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

l DataStore： 分為Config和Operational，其本質(zhì)上是樹，并通過(guò)Instance identifier來(lái)標(biāo)識(shí)子樹或節(jié)點(diǎn)；

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

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

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

1.數(shù)據(jù)訪問(wèn)

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

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

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

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

2.消息模式(messaging pattern)

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

l Data Broker： 對(duì)Data Store進(jìn)行事務(wù)訪問(wèn)。

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

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