汪潤(rùn)　方英蘭　韓兵

摘要：SOA是一種服務(wù)導(dǎo)向的可重用組件模型。隨著SOA應(yīng)用服務(wù)數(shù)量、服務(wù)之間依賴關(guān)系復(fù)雜度的增加，服務(wù)發(fā)布與發(fā)現(xiàn)作為實(shí)現(xiàn)SOA架構(gòu)的一項(xiàng)重要基礎(chǔ)設(shè)施，如何管理現(xiàn)存服務(wù)變得越來(lái)越困難。針對(duì)集中式服務(wù)注冊(cè)中心存在單點(diǎn)失效的不足，通過(guò)構(gòu)建多節(jié)點(diǎn)的服務(wù)注冊(cè)中心避免單點(diǎn)失效導(dǎo)致其對(duì)外提供的服務(wù)發(fā)布、發(fā)現(xiàn)、查詢等接口不可用的缺陷。同時(shí)多個(gè)節(jié)點(diǎn)間基于消息與通知的方式，采用SSL建立安全的連接確保多個(gè)節(jié)點(diǎn)之間服務(wù)數(shù)據(jù)的一致性。針對(duì)Web服務(wù)之間內(nèi)生點(diǎn)對(duì)點(diǎn)調(diào)用存在硬編碼的不足，通過(guò)消息攔截分發(fā)機(jī)制有效緩解該問(wèn)題。本文擬在上述服務(wù)注冊(cè)中心的基礎(chǔ)上，提出一種基于SOA的軟件可重用開發(fā)模型，并在實(shí)際生產(chǎn)系統(tǒng)用戶管理系統(tǒng)設(shè)計(jì)，實(shí)現(xiàn)并驗(yàn)證該模型的有效性。

關(guān)鍵詞：UDDI；WSDL；SOA；SSL；服務(wù)

中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2018）06-0212-03

1引言

自從1996年SOA（Service-Oriented Architecture，面向服務(wù)架構(gòu)）的概念被Gartner提出以后，近二十年SOA的發(fā)展也經(jīng)歷了起起伏伏。近些年隨著Web Service的興起，使得SOA登上了第一次的巔峰。面向服務(wù)體系架構(gòu)是繼面向?qū)ο?、基于?gòu)件開發(fā)之后的一種新型軟件開發(fā)、部署和集成模式，為軟件開發(fā)提供了靈活的設(shè)計(jì)和開發(fā)方案口。在SOA的應(yīng)用中，幾乎所有對(duì)Web Service的介紹都會(huì)引入三種角色：服務(wù)供應(yīng)者，服務(wù)消費(fèi)者以及服務(wù)注冊(cè)中心。Web Service所具備的平臺(tái)獨(dú)立性，松耦合，自包含，服務(wù)可發(fā)現(xiàn)性等等可以很好地支持SOA架構(gòu)思想。其提供了一系列接口通過(guò)標(biāo)準(zhǔn)的XML格式消息在In-ternet上進(jìn)行發(fā)布，查找與訪問(wèn)。

服務(wù)提供者發(fā)布可通過(guò)網(wǎng)絡(luò)訪問(wèn)的服務(wù)，服務(wù)消費(fèi)者從本地或者服務(wù)注冊(cè)中心查找服務(wù)描述信息完成服務(wù)綁定。UDDI定義了服務(wù)發(fā)布與發(fā)現(xiàn)的標(biāo)準(zhǔn)，對(duì)服務(wù)提供者與服務(wù)消費(fèi)者提供了相應(yīng)的發(fā)布與發(fā)現(xiàn)API（Application Programming Inter-face）。通過(guò)UDDI，SOA系統(tǒng)可以實(shí)現(xiàn)服務(wù)的可發(fā)現(xiàn)性，可重用，互操作，位置透明和服務(wù)之間的松耦合。對(duì)服務(wù)提供者，服務(wù)消費(fèi)者而言，UDDI扮演著十分重要的“橋梁”角色。

2服務(wù)發(fā)布與發(fā)現(xiàn)模型研究現(xiàn)狀

在傳統(tǒng)的Web服務(wù)發(fā)布與發(fā)現(xiàn)體系結(jié)構(gòu)中，根據(jù)實(shí)現(xiàn)方式的不同，服務(wù)發(fā)布與發(fā)現(xiàn)模型可以分為集中式、分布式與混合式。

2.1集中式服務(wù)發(fā)布與發(fā)現(xiàn)模型

集中式服務(wù)發(fā)布與發(fā)現(xiàn)模型以傳統(tǒng)的UDDI為代表。該模型使用單一節(jié)點(diǎn)存儲(chǔ)服務(wù)提供者發(fā)布的服務(wù)，服務(wù)信息將會(huì)持久化到單一節(jié)點(diǎn)上。該模型通過(guò)解析WSDL與UDDI的映射關(guān)系，生成核心數(shù)據(jù)模型數(shù)據(jù)，如Business Entity，Business Ser-vice等等。服務(wù)消費(fèi)者根據(jù)查詢結(jié)果中服務(wù)描述信息構(gòu)建本地客戶端服務(wù)代理，進(jìn)行服務(wù)調(diào)用。文獻(xiàn)5探討了一種基于集中式UDDI的集成框架，并借助工程實(shí)踐驗(yàn)證上述框架的實(shí)用性與有效性。

2.2分布式服務(wù)發(fā)布與發(fā)現(xiàn)模型

面對(duì)高并發(fā)服務(wù)發(fā)布與發(fā)現(xiàn)應(yīng)用場(chǎng)景，集中式服務(wù)發(fā)布與發(fā)現(xiàn)模型存在性能瓶頸與單點(diǎn)失效的問(wèn)題。部分學(xué)者基于P2P對(duì)等網(wǎng)絡(luò)構(gòu)建了以分布式結(jié)構(gòu)為特點(diǎn)的服務(wù)發(fā)布與發(fā)現(xiàn)模型，適用于移動(dòng)網(wǎng)絡(luò)的服務(wù)發(fā)布與發(fā)現(xiàn)。該模型無(wú)中心節(jié)點(diǎn)，每個(gè)peer既可能是服務(wù)供應(yīng)者也可能是服務(wù)消費(fèi)者。服務(wù)請(qǐng)求以廣播的形式發(fā)送到P2P網(wǎng)絡(luò)中，服務(wù)提供者將滿足需求的服務(wù)返回給服務(wù)請(qǐng)求者。由于采用廣播的通信機(jī)制進(jìn)行服務(wù)發(fā)現(xiàn)，所以通信開銷較大。文獻(xiàn)2引入對(duì)等架構(gòu)，設(shè)計(jì)并實(shí)現(xiàn)基于結(jié)構(gòu)化對(duì)等協(xié)議的Web服務(wù)注冊(cè)系統(tǒng)。

2.3混合式服務(wù)發(fā)布與發(fā)現(xiàn)模型

混合式服務(wù)發(fā)布與發(fā)現(xiàn)模型是在集中式與分布式的基礎(chǔ)上，將多個(gè)節(jié)點(diǎn)組合成一個(gè)組，盡管降低了全局服務(wù)查詢的幾率，減少了節(jié)點(diǎn)之間的通訊開銷。但是隨著服務(wù)數(shù)量的增加，其服務(wù)發(fā)現(xiàn)算法異常復(fù)雜，并需要考慮如何分組以及分組中的中心節(jié)點(diǎn)問(wèn)題，不利于系統(tǒng)的擴(kuò)展，降低了系統(tǒng)的靈活性。

本文結(jié)合上述三種服務(wù)發(fā)布與發(fā)現(xiàn)模型的優(yōu)缺點(diǎn)，提出一種方案。針對(duì)集中式服務(wù)注冊(cè)中心存在單點(diǎn)失效的不足，通過(guò)構(gòu)建多節(jié)點(diǎn)服務(wù)注冊(cè)中心避免單點(diǎn)失效，并且多個(gè)服務(wù)注冊(cè)中心采用消息與通知的方式，基于雙向SSL安全交換不同節(jié)點(diǎn)之間存在差異的數(shù)據(jù)，保證不同節(jié)點(diǎn)之間服務(wù)數(shù)據(jù)的一致性。

3分布式UDDI系統(tǒng)模型設(shè)計(jì)

3.1體系結(jié)構(gòu)設(shè)計(jì)

分布式UDDI遵循UDDIv3版本規(guī)范，包含常用inquiry，publication等常用接口服務(wù)提供者通過(guò)服務(wù)注冊(cè)中心客戶端訪問(wèn)服務(wù)注冊(cè)中心，通過(guò)SOAP消息客戶端與服務(wù)注冊(cè)中心交互，將服務(wù)描述信息傳遞給publication接口。服務(wù)請(qǐng)求者通過(guò)客戶端提交服務(wù)查詢相關(guān)參數(shù)，服務(wù)器端inquiry接口根據(jù)客戶端傳遞過(guò)來(lái)的SOAP消息并解析該消息，按照關(guān)鍵詞查詢相關(guān)服務(wù)。

服務(wù)注冊(cè)中心整體上劃分為三個(gè)部分。第一部分提供對(duì)外暴露的接口信息，如服務(wù)發(fā)布接口，服務(wù)查詢接口，服務(wù)復(fù)制接口等等。第二部分提供對(duì)象關(guān)系映射，將服務(wù)提供者發(fā)布的服務(wù)持久化到關(guān)系數(shù)據(jù)庫(kù)或者服務(wù)消費(fèi)者提供的關(guān)鍵檢索數(shù)據(jù)庫(kù)，查找符合要求的服務(wù)描述信息。第三部分為關(guān)系數(shù)據(jù)庫(kù)。每個(gè)服務(wù)注冊(cè)中心包含唯一的標(biāo)識(shí)碼，類似主鍵；將其與其他的服務(wù)注冊(cè)中心區(qū)分開。多個(gè)服務(wù)注冊(cè)中心需要保證多個(gè)服務(wù)注冊(cè)中心關(guān)系數(shù)據(jù)庫(kù)中所保存服務(wù)數(shù)據(jù)的一致性。

3.2數(shù)據(jù)一致性的考慮

每一個(gè)服務(wù)注冊(cè)中心維護(hù)著本地?cái)?shù)據(jù)庫(kù)中存放的服務(wù)數(shù)據(jù)，在Business Entity，Business Service等數(shù)據(jù)模型產(chǎn)生改變的時(shí)候，源服務(wù)注冊(cè)中心（服務(wù)數(shù)據(jù)發(fā)生改變的源頭服務(wù)注冊(cè)中心）將會(huì)通知與其有關(guān)聯(lián)的所有其他節(jié)點(diǎn)。其他收到消息通知的節(jié)點(diǎn)從源服務(wù)注冊(cè)中心節(jié)點(diǎn)拉取改變的數(shù)據(jù)，并將改變的數(shù)據(jù)持久化到本地?cái)?shù)據(jù)庫(kù)。此種模式下，所有節(jié)點(diǎn)之間均會(huì)相互關(guān)聯(lián)，從邏輯上來(lái)看，節(jié)點(diǎn)之間構(gòu)成了無(wú)向圖這種數(shù)據(jù)結(jié)構(gòu)。

服務(wù)提供者在獲取authToken的基礎(chǔ)上，將服務(wù)描述信息發(fā)布到服務(wù)注冊(cè)中心。對(duì)服務(wù)注冊(cè)中心而言，其保存數(shù)據(jù)的有效l生與正確性是十分重要的。Replication接口為服務(wù)注冊(cè)中心之間交換數(shù)據(jù)提供了支持。服務(wù)注冊(cè)中心之間采用雙向SSL認(rèn)證，保證雙發(fā)交換數(shù)據(jù)之前知道對(duì)方的身份，確保對(duì)方在自己的信任庫(kù)中。

4服務(wù)發(fā)布與發(fā)現(xiàn)模型在用戶管理系統(tǒng)中的應(yīng)用

本文所述的用戶管理系統(tǒng)是企業(yè)在面對(duì)日常業(yè)務(wù)操作，實(shí)現(xiàn)信息化所構(gòu)建的后臺(tái)管理系統(tǒng)。該系統(tǒng)包含基礎(chǔ)的賬號(hào)管理，權(quán)限訪問(wèn)控制等常見功能。

本文擬在上述背景下，基于IBM SOMA（Service-oriented Modelingand Architecture）對(duì)用戶管理系統(tǒng)中的菜單模塊，角色模塊，權(quán)限模塊以及通用的支付模塊進(jìn)行服務(wù)建模；并以Web Service的形式對(duì)外暴露可訪問(wèn)的接口；利用Apache CXF框架組織上述服務(wù)（由上述服務(wù)構(gòu)建的系統(tǒng)定義為基礎(chǔ)服務(wù)系統(tǒng)SRS）。同時(shí)，將上述對(duì)外發(fā)布的服務(wù)發(fā)布到改進(jìn)的分布式服務(wù)注冊(cè)中心Apache JUDDI中。最后實(shí)現(xiàn)剝離上述模塊的用戶管理系統(tǒng)與上述服務(wù)進(jìn)行交互，實(shí)現(xiàn)相關(guān)的業(yè)務(wù)邏輯，同時(shí)提高程序的可維護(hù)性，可擴(kuò)展性，為未來(lái)開發(fā)不同產(chǎn)品時(shí)提供信息集成和共享能力。

4.1系統(tǒng)交互模型

整個(gè)交互模型由三種角色構(gòu)成。基于JUDDI的分布式服務(wù)注冊(cè)中心、用戶管理系統(tǒng)與基礎(chǔ)服務(wù)系統(tǒng)。JUDDI是基于UDDIv3規(guī)范的開源服務(wù)注冊(cè)中心，用于服務(wù)發(fā)布與發(fā)現(xiàn)。用戶管理系統(tǒng)是常見的企業(yè)后臺(tái)管理系統(tǒng)。基礎(chǔ)服務(wù)系統(tǒng)基于權(quán)限服務(wù)，菜單服務(wù)，用戶管理服務(wù)，支付服務(wù)；為其他應(yīng)用系統(tǒng)提供基礎(chǔ)服務(wù)的系統(tǒng)。使用JUDDI將二者集成，基礎(chǔ)服務(wù)系統(tǒng)將服務(wù)發(fā)布到JUDDI，用戶管理系統(tǒng)搜索相應(yīng)服務(wù)并構(gòu)建客戶端服務(wù)代理調(diào)用服務(wù)完成相應(yīng)的后臺(tái)業(yè)務(wù)邏輯。

4.2服務(wù)發(fā)布與查詢

4.2.1服務(wù)發(fā)布

服務(wù)建模的目標(biāo)是建立企業(yè)的服務(wù)模型，該服務(wù)模型作為業(yè)務(wù)與IT之間的橋梁是首先SOA對(duì)業(yè)務(wù)隨需應(yīng)變靈活性支持的關(guān)鍵因素。本文基于SOMA進(jìn)行服務(wù)建模。首先抽取用戶管理系統(tǒng)中的菜單模塊，角色模塊，權(quán)限模塊以及支付模塊。在此基礎(chǔ)之上，確定各個(gè)組件對(duì)外暴露決策以及接口的參數(shù)規(guī)范。最后采用Web Service的形式，使用Apache CXF框架組織服務(wù)，并對(duì)外發(fā)布，供服務(wù)消費(fèi)者請(qǐng)求與訪問(wèn)。

在服務(wù)注冊(cè)中心持久化Business Entity之后，將會(huì)觸發(fā)消息產(chǎn)生并通知其他服務(wù)注冊(cè)中心節(jié)點(diǎn)，當(dāng)前有數(shù)據(jù)更新。其他服務(wù)注冊(cè)中心接收到該通知之后，會(huì)根據(jù)通知中的參數(shù)主動(dòng)請(qǐng)求源服務(wù)注冊(cè)中心節(jié)點(diǎn)，拉取更新的數(shù)據(jù)，并持久化到本地。

4.2.2服務(wù)查詢

服務(wù)請(qǐng)求在服務(wù)注冊(cè)中心客戶端輸入服務(wù)名稱，分類等信息查詢，服務(wù)注冊(cè)中心根據(jù)關(guān)鍵詞匹配服務(wù)描述信息并返回結(jié)果。

4.3服務(wù)調(diào)用

用戶管理系統(tǒng)通過(guò)調(diào)用基礎(chǔ)服務(wù)系統(tǒng)來(lái)實(shí)現(xiàn)相應(yīng)的業(yè)務(wù)邏輯。具體的步驟如下。（1）用戶登錄系統(tǒng)時(shí)請(qǐng)求基礎(chǔ)服務(wù)系統(tǒng)提供的用戶管理服務(wù)，驗(yàn)證用戶名密碼是否正確，并返回驗(yàn)證結(jié)果。（2）在用戶通過(guò)驗(yàn)證的基礎(chǔ)上，用戶管理系統(tǒng)請(qǐng)求基礎(chǔ)服務(wù)系統(tǒng)角色服務(wù)獲取用戶所屬的角色以及該角色所擁有的權(quán)限（菜單以及按鈕）信息；（3）進(jìn)人后臺(tái)主界面，顯示菜單、按鈕等資源。二者之間的交互模型如圖1所示。

圖中展示了用戶管理系統(tǒng)調(diào)用基礎(chǔ)服務(wù)系統(tǒng)服務(wù)所做的特殊處理，主要是服務(wù)代理層與POJO模型對(duì)象轉(zhuǎn)換層；服務(wù)代理層在SOAP請(qǐng)求消息中加入當(dāng)前客戶端的信息，為服務(wù)調(diào)用提供憑證。POJO模型轉(zhuǎn)換層處理服務(wù)調(diào)用的結(jié)果，將服務(wù)調(diào)用的結(jié)果轉(zhuǎn)化為適用于本系統(tǒng)簡(jiǎn)單對(duì)象或者將本系統(tǒng)的簡(jiǎn)單對(duì)象處理為服務(wù)代理層適用的請(qǐng)求參數(shù)。

5實(shí)驗(yàn)與分析

5.1實(shí)驗(yàn)環(huán)境

該實(shí)驗(yàn)在1MB/S以太網(wǎng)的網(wǎng)絡(luò)環(huán)境中進(jìn)行測(cè)試，包括三臺(tái)阿里云服務(wù)器（Windows Server 2012、Intel雙核2.60GHz處理器、4GB內(nèi)存），軟件環(huán)境有Jdk1.7的Java平臺(tái)，Mysq15.5數(shù)據(jù)庫(kù)，Apache Tomcat 7應(yīng)用服務(wù)器，Apache Maven 3.5.0項(xiàng)目管理工具。JUDDI分布在兩臺(tái)獨(dú)立的阿里云服務(wù)器上，二者建立雙向的SSL連接，為服務(wù)數(shù)據(jù)的復(fù)制提供支持。使用SOAPUI對(duì)JUDDI中的服務(wù)是否可用進(jìn)行測(cè)試。同時(shí)記錄用戶管理系統(tǒng)在調(diào)用服務(wù)時(shí)產(chǎn)生的數(shù)據(jù)包括當(dāng)前調(diào)用的客戶端，調(diào)用時(shí)間等等。下面對(duì)比分析修改前方法調(diào)用與修改后服務(wù)調(diào)用在性能方面的差異。下面以獲取第三方支付憑證以及子菜單列表為例分析。

5.2實(shí)驗(yàn)結(jié)果

5.2.1獲取支付憑證耗時(shí)對(duì)比分析

圖2展示了在使用支付服務(wù)時(shí)，調(diào)用第三方支付獲取支付憑證用戶管理系統(tǒng)通過(guò)方法調(diào)用與服務(wù)調(diào)用所消耗的時(shí)間，耗時(shí)差距平均基本維持在50ms以內(nèi)。

5.2.2獲取菜單列表耗時(shí)對(duì)比分析

圖3展示了在使用菜單服務(wù)時(shí)，根據(jù)權(quán)限獲取當(dāng)前用戶所擁有的一級(jí)菜單時(shí)；獲取用戶一級(jí)菜單下的所有二級(jí)菜單所消耗的時(shí)間，耗時(shí)差距平均維持在1ms以內(nèi)。

在調(diào)用基礎(chǔ)服務(wù)系統(tǒng)提供的服務(wù)時(shí)，若客戶端提供的參數(shù)含義不符合服務(wù)要求的參數(shù)定義，服務(wù)調(diào)用將會(huì)出現(xiàn)異常，并不會(huì)返回預(yù)期的結(jié)果；基礎(chǔ)服務(wù)系統(tǒng)在對(duì)外暴露接口調(diào)用規(guī)范的同時(shí)會(huì)對(duì)服務(wù)的調(diào)用進(jìn)行監(jiān)控，將服務(wù)調(diào)用的客戶端，服務(wù)調(diào)用所消耗的時(shí)間，當(dāng)前調(diào)用的是哪個(gè)方式形成結(jié)構(gòu)化數(shù)據(jù)持久化到數(shù)據(jù)庫(kù)；供后期進(jìn)行數(shù)據(jù)分析。

在企業(yè)開發(fā)不同產(chǎn)品的過(guò)程中，往往會(huì)出現(xiàn)不同產(chǎn)品包含相似功能模塊的場(chǎng)景。從面向組件到面向服務(wù)，將各個(gè)產(chǎn)品功能類似的模塊抽象成服務(wù)，單獨(dú)維護(hù)與運(yùn)營(yíng)，提高相似模塊的復(fù)用性。服務(wù)組件部署于局域網(wǎng)之中，網(wǎng)絡(luò)開銷比較小，以這種開發(fā)方式有利于規(guī)范軟件開發(fā)過(guò)程，復(fù)用軟件構(gòu)件，降低軟件開發(fā)風(fēng)險(xiǎn)以及軟件維護(hù)成本。

6總結(jié)

本文在分析服務(wù)發(fā)布與發(fā)現(xiàn)模型的基礎(chǔ)上，設(shè)計(jì)并實(shí)現(xiàn)了基于UDDIv3規(guī)范的多節(jié)點(diǎn)Web服務(wù)注冊(cè)系統(tǒng)。通過(guò)Apache JUDDI構(gòu)建多服務(wù)注冊(cè)中心，用于服務(wù)發(fā)布與發(fā)現(xiàn)；采用消息與通知的方式維護(hù)多個(gè)服務(wù)注冊(cè)中心服務(wù)數(shù)據(jù)的一致性。結(jié)合實(shí)際生產(chǎn)系統(tǒng)用戶管理管理，抽取該系統(tǒng)中通用的菜單，角色，權(quán)限，支付模塊；并采用SOMA方法建模為服務(wù)，并發(fā)布到服務(wù)注冊(cè)中心。多節(jié)點(diǎn)的服務(wù)注冊(cè)中心能夠避免單節(jié)點(diǎn)服務(wù)注冊(cè)中心失效而導(dǎo)致其對(duì)外提供API不可用的問(wèn)題?；谙⒎职l(fā)模式能夠改善傳統(tǒng)Web Service點(diǎn)對(duì)點(diǎn)調(diào)用的缺點(diǎn)。文章對(duì)服務(wù)發(fā)布與發(fā)現(xiàn)的幾種模型進(jìn)行了深入研究，對(duì)基于SOA架構(gòu)的信息系統(tǒng)中服務(wù)發(fā)布與發(fā)現(xiàn)的應(yīng)用與實(shí)現(xiàn)技術(shù)進(jìn)行了分析與研究，在改進(jìn)的服務(wù)注冊(cè)中心的基礎(chǔ)上提出了一種軟件可重用開發(fā)模型，并在相關(guān)項(xiàng)目中進(jìn)行了驗(yàn)證與實(shí)現(xiàn)。