一 、軟件系統(tǒng)設(shè)計(jì)
理想情況下,提到軟件系統(tǒng)的設(shè)計(jì),系統(tǒng)架構(gòu)人員想到的是如何架構(gòu)軟件,軟件開(kāi)發(fā)人員想到的是如何更好地組織業(yè)務(wù)邏輯代碼,這些設(shè)計(jì)能夠更好地保證軟件正常運(yùn)行。不理想的情況便是沒(méi)有設(shè)計(jì)或者設(shè)計(jì)不多,開(kāi)發(fā)代碼靠的是開(kāi)發(fā)人員自身的素養(yǎng),有人更偏好前端實(shí)現(xiàn),有人覺(jué)得后端實(shí)現(xiàn)可能更好,于是同一套代碼中,造成技術(shù)體系的混亂,如果項(xiàng)目比較緊張,那么內(nèi)部質(zhì)量很難保障,那么技術(shù)債就這樣形成了。
一般情況下,軟件系統(tǒng)的研發(fā)分為需求獲取與分析、架構(gòu)設(shè)計(jì)、代碼實(shí)現(xiàn)、系統(tǒng)發(fā)布、上線(xiàn)等階段。其中,架構(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等類(lèi)型,數(shù)據(jù)庫(kù)采用關(guān)系型數(shù)據(jù)庫(kù)。如下圖所示:
下一步就開(kāi)始圍繞業(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版本開(kāi)始采用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è)消息總線(xiàn)驅(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ì)上是樹(shù),并通過(guò)Instance identifier來(lái)標(biāo)識(shí)子樹(shù)或節(jié)點(diǎn);
l RPC: RPC的本質(zhì)上是不同進(jìn)程間訪(fǎng)問(wèn)的一種通信形式。在NETCONF協(xié)議中 RPC是NETCONF客戶(hù)端對(duì)NETCONF服務(wù)器的訪(fǎng)問(wèn)。而在MD-SAL中,RPC用于服務(wù)消費(fèi)者(使用者)對(duì)服務(wù)生產(chǎn)者(提供者)的訪(fǎng)問(wèn),不再是嚴(yán)格上的RPC定義。
同時(shí),YANG Tools項(xiàng)目是一個(gè)旨在方便YANG開(kāi)發(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ù)訪(fǎng)問(wèn)
MD-SAL通過(guò)兩個(gè)不同的代理(brokers)訪(fǎng)問(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不易于開(kāi)發(fā)人員編程,該Broker支持YANG到Java語(yǔ)言的綁定,并提供基于YANG模型生成的接口和類(lèi),也就是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ù)訪(fǎng)問(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ā)送并傳送給其訂閱者的多播消息。
-
數(shù)據(jù)庫(kù)
+關(guān)注
關(guān)注
7文章
3712瀏覽量
64025 -
軟件系統(tǒng)
+關(guān)注
關(guān)注
0文章
61瀏覽量
9457 -
AMQP
+關(guān)注
關(guān)注
0文章
6瀏覽量
2534
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論