基于SOA的Web服務(wù)應(yīng)用構(gòu)建關(guān)鍵技術(shù)研究

引言

SOA是一個體系結(jié)構(gòu)概念，與具體的技術(shù)無關(guān)，Web服 務(wù)是一種實現(xiàn)方式，也可以基于其他技術(shù)來實現(xiàn)SOA，比如 OSGi （Open Services Gateway initiative））CORBA （Common Object Request Broker Architecture，公共對象請求代理體系 結(jié)構(gòu)）、DCOM、RPC等。而且，Web服務(wù)不僅僅限于實現(xiàn) SOA，通過將一個方法公開為Web服務(wù)，可以實現(xiàn)過程式的 RPC。

1 SOA和Web服務(wù)

最初，Web服務(wù)被描述為一種連接技術(shù)。這種方式由于 是基于已有的HTTP協(xié)議之上，因此具有簡單、安全和無障 礙的特點。SOAP與WSDL的出現(xiàn)和應(yīng)用可以說是軟件技術(shù) 史上的一個里程碑。

Web 服務(wù)之前的 CORBA、MQ、EJB、COM/COM+ 等 技術(shù)可以很好地解決在某種特定平臺或技術(shù)之上的分布式計 算問題，它們都很強大。然而，業(yè)務(wù)全球化和企業(yè)國際化導(dǎo)致 信息現(xiàn)代化必須面臨“不同系統(tǒng)平臺、不同組件技術(shù)和不同技 術(shù)下的遺留系統(tǒng)整合”的現(xiàn)實情況。而Web服務(wù)提供了一種 技術(shù)，即不管什么平臺、什么技術(shù)和什么開發(fā)語言，它能夠通 過WSDL技術(shù)和標(biāo)準(zhǔn)將不同平臺、不同技術(shù)和不同開發(fā)語言 下的業(yè)務(wù)服務(wù)發(fā)布出去，客戶端可以通過基于HTTP的SOAP 協(xié)議來遠程調(diào)用。由于訪問是基于HTTP，因而遠程調(diào)用可以 突破防火墻，實現(xiàn)互聯(lián)網(wǎng)級別的遠程調(diào)用。因此，目前軟件 技術(shù)已走向了“無技術(shù)”時代。所謂“無技術(shù)”時代并不是不 要任何技術(shù)，而是通過Web服務(wù)實現(xiàn)了企業(yè)級應(yīng)用系統(tǒng)基于 平臺無關(guān)性、技術(shù)無關(guān)性和語言無關(guān)性的開發(fā)、整合、部署和 運行的全新時代。

SOA與Web服務(wù)的關(guān)系如圖1所示。

Web服務(wù)用機器可處理的格式，以特定的Web服務(wù)描述 語言描述接口及其他系統(tǒng)與Web服務(wù)的互動，以SOAP消息 實現(xiàn)通信。事實上，可以把Web服務(wù)看做是一種至少具有以 下制約的SOA :

第一是接口必須基于互聯(lián)網(wǎng)協(xié)議，如HTTP、FTP、 SMTP ；第二是消息必須是XML格式的。

REST （Representational State Transfer，表現(xiàn)層狀態(tài)轉(zhuǎn)化） 在Web領(lǐng)域已經(jīng)得到了廣泛的接受，是基于SOAP和WSDL 的Web服務(wù)的更為簡單的替代方法。REST定義了一組體系架 構(gòu)原則，可以根據(jù)這些原則設(shè)計以系統(tǒng)資源為中心的Web服 務(wù)，包括使用不同語言編寫的客戶端如何通過HTTP處理和 傳輸資源狀態(tài)。Web服務(wù)具體實現(xiàn)應(yīng)具備以下SOA技術(shù)點： 2關(guān)鍵技術(shù)研究

2.1服務(wù)的連接與集成（Integration）

服務(wù)的主要形式是點對,點（Point-to-point）和中心輻射（總 線式）方式。點對點方式就是服務(wù)消費者與服務(wù)直接連接。每 個服務(wù)消費者必須確保與所有相連的服務(wù)接口保持一致（例如 同步或異步、SOAP或REST、服務(wù)的版本、安全性問題等）。 圖2所示是點對點服務(wù)的連接方式。

點對點方式適用于以下環(huán)境：

-服務(wù)和服務(wù)消費者的數(shù)量較小

-采用同質(zhì)技術(shù)體系

中心輻射型(Hub-and-spoke)的主要方式是總線型(ESB)) 有些ESB廠商認(rèn)為ESB不屬于中心輻射型，其實ESB在邏 輯拓?fù)渖先匀粚儆谥行妮椛湫?，只不過其組件可能是分布式的, 以消除性能瓶頸和單點故障(SPOF, single-point-of-failure)。 圖3所示是總線型連接方式。

圖3總線型連接方式

近年來，ESB往往被視為構(gòu)建SOA的基石之一。實踐證 明，ESB是企業(yè)構(gòu)建真正的SOA架構(gòu)應(yīng)用所必須的基礎(chǔ)設(shè)施。 ESB可以理解為一類產(chǎn)品，即在服務(wù)消息者和服務(wù)之間連接 和中介所有通信和接口的中間件產(chǎn)品。也可以理解為一種模式, 具有多個廠商和開源實現(xiàn)。實際應(yīng)用中，一般從一個廠商或開 源實現(xiàn)開始，根據(jù)業(yè)務(wù)需要增加擴展或定制。

服務(wù)使用Web服務(wù)或其他標(biāo)準(zhǔn)或適配器連接到一個公共 的骨干背板上。ESB管理接口的相容性、服務(wù)的路(基于內(nèi)容、 可用性、負(fù)載或其他規(guī)則，可能是動態(tài)決定，可能是一對多或 多對一的聚合)以及數(shù)據(jù)轉(zhuǎn)換問題(格式和業(yè)務(wù)語義)?？梢?促進系統(tǒng)的松耦合。減少連接的復(fù)雜性。

ESB適用于技術(shù)上異構(gòu)、變化快速和大規(guī)模系統(tǒng)如果 具體的把ESB產(chǎn)品和傳統(tǒng)EAI里面的消息總線類產(chǎn)品(如 ActiveMQ)做個比較，兩者差異就很大了，主要有三方面。第 一，ESB以SOA面向業(yè)務(wù)的哲學(xué)為基礎(chǔ)，所以它主要是通過 配置來建立，而不是通過編程建立；第二，ESB必須有能力 在不同的協(xié)議之間建立互通機制，包括傳統(tǒng)的消息機制(JMS) 和Web服務(wù)接口(WS)；第三，除了消息(服務(wù))代理方式外, ESB還必須為SOA服務(wù)治理提供服務(wù)的生命周期管理，而非 簡單的過濾、轉(zhuǎn)發(fā)、路由，包括服務(wù)發(fā)布、注冊、使用、推廣、 效益統(tǒng)計、升級等。

2.2日艮務(wù)發(fā)布與發(fā)現(xiàn)

服務(wù)發(fā)布(publish)指在目錄服務(wù)(directory service)中 發(fā)布和更新Web服務(wù)的信息。服務(wù)發(fā)現(xiàn)(discovery)指客戶 使用發(fā)現(xiàn)服務(wù)(discovery service)發(fā)現(xiàn)已注冊的服務(wù)。發(fā)現(xiàn) 服務(wù)是目錄服務(wù)的一種特例。包括靜態(tài)和動態(tài)兩種。服務(wù)發(fā) 布和發(fā)現(xiàn)均可以基于人工，注冊庫是自動方式的一種。

Repository (翻譯為資源倉庫或存儲庫)和Registry (注 冊中心)經(jīng)常混用，通常都指用來注冊服務(wù)的一個中心位置。 如果嚴(yán)格區(qū)分的話，區(qū)別在于Repository除了注冊服務(wù)及其元 數(shù)據(jù)外，還可以注冊任何其他制品；而Registry 一般僅用于 服務(wù)的定位。存儲庫比注冊中心包含的內(nèi)容更為豐富，目前一 般采用存儲庫的較多，因為同時可以實現(xiàn)治理(Governance) 的一些功能。服務(wù)注冊本就屬于SOA治理(SOA governance) 的范疇。

通用描述、發(fā)現(xiàn)與集成(Universal Description，Discovery and Integration，UDDI)標(biāo)準(zhǔn)旨在為Web服務(wù)提供一個平臺 中立的注冊表。UDDI可被用作私有或公開的注冊表。然而， UDDI的術(shù)語相當(dāng)晦澀和復(fù)雜，它的動態(tài)發(fā)現(xiàn)功能過于想當(dāng)然， UDDI Registry的實現(xiàn)比較少。如今只有少數(shù)企業(yè)用戶在使 用UDDI，公共的注冊表就更少了?，F(xiàn)實當(dāng)中，除了少數(shù)幾個 商業(yè)產(chǎn)品(在那里它的復(fù)雜度用戶看不到)，很少用到UDDI。 UDDI的失敗并不意味著對注冊表的需求也隨之消失，大多 數(shù)公司轉(zhuǎn)而尋求別的替代。可以使用簡單的數(shù)據(jù)庫或輕量目 錄訪問協(xié)議(Lightweight Directory Access Protocol，LDAP) 應(yīng)用，甚至在Wiki上保存一個目錄。開源注冊表方案，如 MuleSource 的 Galaxy 及 WSO2 的 Registry，試圖填補這一空白。 2.3 BPM、服務(wù)編排與編配

BPM (業(yè)務(wù)流程管理)是設(shè)計、制定規(guī)則、控制、分析 操作過程的軟件，涉及人、組織、應(yīng)用、文檔和其他資源。在 尋求良好的性能、對變化迅速的市場及時響應(yīng)、發(fā)展軟件等方 面，SOA和BPM是天生的“伴侶” BPM工具和技術(shù)在設(shè)計 和編排SOA服務(wù)時，非常有用。目前，有如下幾種BPM標(biāo)準(zhǔn)：

BPEL-WS規(guī)范在2003年4月提 交給了 OASIS Organizationfor the Advancement of Structured Information Standards，結(jié)構(gòu)化信息標(biāo)準(zhǔn)促進組織)并更名為WSBPEL(Web Services Business Process Execution Language) 規(guī) 范，2007 年 4 月發(fā)布 WSBPEL2.0 版本，除了 Microsoft, BEA、IBM、 SAP和Siebel, Sun Microsystems和甲骨文公司也相繼加入了 OASIS組織。除去政治因素，BPEL的流行還在于Web正成 為分布式系統(tǒng)架構(gòu)的平臺以及SOA的雄起，SOA強調(diào)服務(wù)的 分解和解耦，而BPEL則對這些Web服務(wù)進行編制，兩者密 不可分。但BPMN到BPEL的轉(zhuǎn)換存在著先天上的缺陷，原 因是BPMN是基于圖的，而BPEL是基于塊的，BPEL是一 個結(jié)構(gòu)化(塊[Block])和非結(jié)構(gòu)化(控制鏈和事件)的混合體。 這個缺陷導(dǎo)致有些BPMN建模的流程無法映射到BPEL,兩

者的雙向工程更是存在問題。這個缺陷成為人們反復(fù)詬病的對 象。許多支持BPEL的產(chǎn)品為了解決這一問題，不得不在用戶 建模時做出種種限制，讓用戶繪制不出無法轉(zhuǎn)換的模型。

BPMN2.0正式版本于2011年1月3日發(fā)布。BPMN2.0 正式將自己更名為 Business Process Model And Notation (業(yè)務(wù) 流程模型和符號)，相比BPMN1.X,最重要的變化在于其定 義了流程的元模型和執(zhí)行語義，即它自己解決了存儲、交換 和執(zhí)行的問題，BPMN由單純的業(yè)務(wù)建模重新回歸了它的本 源，即作為一個對業(yè)務(wù)人員友好的標(biāo)準(zhǔn)流程執(zhí)行語言的圖形 化前端。BPMN2.0 一出手，競爭就結(jié)束了，XPDL、BPEL和 BPDM各自準(zhǔn)備回家釣魚?？雌饋韯倮咚坪跏荁PMN,但 看看BPMN2.0的領(lǐng)導(dǎo)者，就會發(fā)現(xiàn)最后的勝利者還是IBM, Oracle和SAP這些大廠商們，他們提交的草案明確要賦予 BPMN2.0以執(zhí)行語義，這迫使BPDM團隊撤回了其提交，并 將他們的提議與BPDM團隊想法合并，這就是BPMN2.0最 后內(nèi)容的由來。

BPMN的目標(biāo)是期望通過一套統(tǒng)一的建模、執(zhí)行模型填 起業(yè)務(wù)人員與開發(fā)人員之間的那道鴻溝

服務(wù)編排(choreography):在編排的業(yè)務(wù)流程中，流程 的每個節(jié)點都自己決定接下來怎么往前走。舉例來說，每個節(jié) 點可能都在自己的虛擬機里運行，從某個內(nèi)向(in-port)的隊 列接收消息，執(zhí)行處理，然后決定往哪個向外(out-port)的 隊列發(fā)送消息。從某種意義上來說，節(jié)點并不知道自己在更大 的流程中扮演什么樣的角色。在編排的服務(wù)中，并沒有“流程 實例”的概念，而是采用存在于流程節(jié)點內(nèi)部某處的消息。

服務(wù)編配(orchestration)：編配的業(yè)務(wù)流程是集中管理的, 通常還是在單個虛擬機內(nèi)。拿BPEL來說，每一個流程啟動, 都會創(chuàng)建這個流程的“實例”，交給BPEL引擎管理。如果是 長時間的流程，該實例則有可能被持久放在數(shù)據(jù)庫(這個處理 過程叫做“脫水”)。

2.4服務(wù)安全

對Web服務(wù)的威脅涉及網(wǎng)絡(luò)基礎(chǔ)設(shè)施、應(yīng)用和托管系統(tǒng)。 要使Web服務(wù)安全，需要一組基于XML的安全機制來解決 有關(guān)消息層次的安全性、認(rèn)證、基于角色的接入控制、分布安 全策略的執(zhí)行等。

Web服務(wù)需要點到點還是端到端的安全機制，決定于威 脅的程度和面臨的安全風(fēng)險?！岸说蕉恕笔侵笍淖畛醯恼埱笳?到最終的接收者，傳統(tǒng)的面向連接的點到點安全機制不能滿足 Web服務(wù)的終端到終端的安全需求。但是，安全性需要在風(fēng) 險和對抗措施的成本之間進行折中，如果風(fēng)險可以容忍，那 么點到點傳輸層的安全機制也是可用的，只要它能夠提供足夠 的對抗能力。

傳統(tǒng)的網(wǎng)絡(luò)安全機制，如傳輸層的SSL和TLS、VPN、 IPSec、S/MIME等，都可以用于Web安全保護，但它們都是 點到點的安全技術(shù)，對端到端的安全性是不夠的。

現(xiàn)在，Web服務(wù)的應(yīng)用拓?fù)浒ù罅恳苿釉O(shè)備的組合、 網(wǎng)關(guān)、代理、負(fù)載均衡器、外包數(shù)據(jù)中心等，并且是全球分布、 動態(tài)配置的系統(tǒng)。所有這些系統(tǒng)依靠消息處理中介的能力去 轉(zhuǎn)發(fā)消息。中介設(shè)施的數(shù)據(jù)接收和轉(zhuǎn)發(fā)超越傳輸層，數(shù)據(jù)的 完整性和安全性信息可能喪失。這一情況迫使任何消息處理 器要信任前一個中介設(shè)施的安全性評估，并且完全相信它們 對消息內(nèi)容的處理。一個全面的Web服務(wù)安全性體系結(jié)構(gòu)所 需要的是端到端的安全性。成功的Web服務(wù)安全性解決方案 應(yīng)當(dāng)同時成功地對傳輸層和應(yīng)用層實現(xiàn)安全保護，提供全面的 安全性能力。

信息系統(tǒng)通常采用的安全性保護技術(shù)，可以用于Web服 務(wù)，包括以下方面：

認(rèn)證。認(rèn)證是對服務(wù)請求者和提供者身份的檢驗， 有時候還需要對雙方進行互相認(rèn)證?？捎玫募夹g(shù)包括：口令、 證書、LDAP、Kerberos、PKI ；

授權(quán)?？刂普埱笳呓尤胭Y源，并規(guī)定請求者的接入 權(quán)利。通常采用最小接入權(quán)限的策略；

數(shù)據(jù)完整性和機密性。一般使用數(shù)據(jù)加密和簽名技術(shù)；

交易正確性；

不可抵賴；

端到端的消息完整性和機密性；

安全的消息傳輸。保證信息安全性、消息的加密和 簽名技術(shù)；

審計蹤跡。可以通過對資源的監(jiān)測和守護而得到。

安全策略的分布執(zhí)行；

跨領(lǐng)域的身份標(biāo)識。支持不同領(lǐng)域身份標(biāo)識的映射;

安全的發(fā)現(xiàn)機制；

發(fā)現(xiàn)與信任。

2 Web服務(wù)架構(gòu)示例

以服務(wù)發(fā)現(xiàn)為例，完成服務(wù)發(fā)布。下面是SOAP服務(wù)發(fā) 布使用的詳細(xì)過程。

發(fā)布通過WSOL ESB完成，目前發(fā)布SOAP服務(wù)到 ESB,必須提供正確可用的WSDL文件。提供方式有兩種： 第一是給管理員提供可訪問WSDL的URL ；第二是把WSDL 以純文本文件發(fā)送給管理員。

發(fā)送URL方式可以訪問WSDL所在URL的協(xié)議，必 須是 HTTP/HTTPS 協(xié)議。例如：http : //yczy.zys.zbb.hj/wiki/ ws.php?wsdl,這樣，管理員可以在ESB上導(dǎo)入此URL所包含 的WSDL內(nèi)容，從而創(chuàng)建相應(yīng)的SOAP Web Service。

發(fā)送WSDL文件，發(fā)送的WSDL文件必須是純文本文件, 內(nèi)容為XML。這樣才能為系統(tǒng)進行解析處理。下面是WSDL 的示例作為參考，主要代碼如下：

<?xml version=v1.0 v?>

<wsdl : definitions name= ” WikiService ” targetNamespace=” http : //wiki.hyperats.com/”

xmlns : ns1=” http : //schemas.xmlsoap.org/soap/ http”xmlns : soap=” http : //schemas.xmlsoap.

org/wsdl/soap/‘‘ xmlns : tns=” http : //wiki.hyperats. com/”xmlns : wsdl=” http : ^schemas.xmlsoap.

org/wsdl/” xmlns : xsd=” http : //www.w3.org/2001/ XMLSchema” >

<!-- Messages -->

<wsdl: message name=” helloResponse” >

<wsdl : part element=” tns : helloResponse” name=” parametersv>

</wsdl part>

</wsdl message>

<wsdl: message name=” hello” >

< w s d l : part el e m e n t = ” tns : hello ” name=” parametersv>

</wsdl part>

</wsdl message>

<!--省略-->

</wsdl message>

<!-- Operations -->

<wsdl: portType name="WikiWs">

<wsdl: operation name="hello">

<wsdl : input message= "tns : hello" name="hello">

</wsdl input>

<wsdl : output message="tns : helloResponse" name="helloResponse"〉

</wsdl output>

</wsdl operation>

<!--省略-->

</wsdl portType>

<!-- Protocol binding -->

<wsdl : binding name="WikiServiceSoapBinding"

type="tns : WikiWs">

<soap : binding style="document" transport="http : // schemas.xmlsoap.org/soap/http"></soap binding>

<wsdl: operation name=” hello” >

<soap : operation soapAction=””

style=” documentv></soap : operation>

<wsdl: input name=” hello” >

<soap : body use=” literalv></

soap body>

</wsdl input>

<wsdl: output name=” helloResponse” >

<soap : body use=” literalv></

soap body>

</wsdl output>

</wsdl operation>

<!--省略-->

</wsdl binding>

<!-- Service endpoint -->

<wsdl: service name="WikiService">

<wsdl: port binding="tns : WikiServiceSoapBinding" name="WikiPort">

<soap : address location="http :

〃192.168.12.44/ws.php"></soap : address>

</wsdl port>

</wsdl service>

</wsdl definitions>

這樣就完成了服務(wù)發(fā)布工作。

3結(jié)語

通過構(gòu)建面向服務(wù)的應(yīng)用支撐環(huán)境，各級保障部門、各 個業(yè)務(wù)系統(tǒng)的信息服務(wù)，都能夠通過服務(wù)的包裝，成為隨取即 用的IT資產(chǎn)，以服務(wù)的形式對外發(fā)布，以松耦合原則實現(xiàn)共享, 并可將各種服務(wù)快速整合，開發(fā)出組合式應(yīng)用，達到“整合即 開發(fā)”的目的。

20211221_61c1e905b8896__基于SOA的Web服務(wù)應(yīng)用構(gòu)建關(guān)鍵技術(shù)研究