自面向服務(wù)架構(gòu)（SOA）演進(jìn)發(fā)展以來，SOA就一直被拿來跟Web模型“RESTful”接口進(jìn)行對(duì)比。盡管它們之間的差異已經(jīng)討論了很多，但大多數(shù)的討論都是晦澀難懂的，企業(yè)仍然報(bào)告說自己困惑于究竟哪一種模式相對(duì)而言更好。

    大多數(shù)應(yīng)用架構(gòu)師都意識(shí)到，如果應(yīng)用合適，開發(fā)實(shí)踐反映了雙方的目標(biāo)和好處的話，在某些情況下，將表述性狀態(tài)轉(zhuǎn)移（REST）與SOA結(jié)合起來是有可能且有優(yōu)勢(shì)的。最大的問題是目標(biāo)是否要開發(fā)一個(gè)自始至終的RESTful接口，同時(shí)滿足大部分SOA目標(biāo)，或者混合使用REST和SOA。   

SOA、REST分解

    SOA是為了促進(jìn)靈活、敏捷應(yīng)用開發(fā)而采取的一種架構(gòu)，該架構(gòu)通過在一般的工作流管理模型中常見組件來實(shí)現(xiàn)。這些組件之間是一種松耦合的關(guān)系，意味著組件是通過發(fā)布/訂購登記流程來定位的，而且使用了一種常見的對(duì)象訪問機(jī)制來鏈接（一般是是SOAP），使用了某種定義語言（WSDL）來描述將用戶和提供商連接在一起的特性和接口。該模型支持識(shí)別、安全和恢復(fù)流程的標(biāo)準(zhǔn)機(jī)制，在支持復(fù)雜的業(yè)務(wù)關(guān)鍵應(yīng)用方面擁有豐富的功能。

    RESTful模式是為了簡(jiǎn)化用戶通過瀏覽器訪問而設(shè)置的。盡管這種超文本標(biāo)記語言（HTML）先看后點(diǎn)的瀏覽方式已經(jīng)擴(kuò)展為允許在程序元素之間，而不僅僅是與用戶之間進(jìn)行更為結(jié)構(gòu)化的信息交換（擴(kuò)展標(biāo)記語言XML），其基本的接口是一樣的；組件仍是以統(tǒng)一資源定位（URL）的方式表示，并采用與互聯(lián)網(wǎng)兼容的域名解析系統(tǒng)（DNS）進(jìn)行解碼。

    組件連接不僅僅是松散而已，如果用戶本身在連接中的選擇不是可視化的話這種關(guān)聯(lián)根本就不存在。RESTful很容易開發(fā)和部署，它是輕量的，托管和維護(hù)的成本也很低廉，很適合典型的在線應(yīng)用。

    創(chuàng)建REST/SOA共生應(yīng)用的典型方法是在SOA應(yīng)用前端添加一個(gè)Web服務(wù)器，這會(huì)令SOA應(yīng)用為互聯(lián)網(wǎng)做好準(zhǔn)備，并讓它們可以為瀏覽器/瘦客戶端所訪問。雖然SOA組合應(yīng)用靈活性很高時(shí)這很好，但是瘦客戶端、移動(dòng)及Web訪問重要性的不斷增強(qiáng)，促使某些架構(gòu)師開始尋求在應(yīng)用之中運(yùn)用更多的RESTful概念。   

RESTful SOA的關(guān)鍵

    對(duì)于應(yīng)用架構(gòu)師來說，創(chuàng)建RESTful SOA的關(guān)鍵是定義可表示流程元素/資源的對(duì)象。在REST中，每一個(gè)對(duì)象都是通過URL來表示的，對(duì)象用戶負(fù)責(zé)將狀態(tài)信息打包進(jìn)每一條消息內(nèi)，以便對(duì)象的處理總是無狀態(tài)的。太復(fù)雜的對(duì)象，如那些表示多階段流程的，按照RESTful的形式編碼會(huì)很困難，其使用將會(huì)需要轉(zhuǎn)換設(shè)計(jì)模式或者其他的適配機(jī)制。

    RESTful SOA的第二大問題是組合管理及流程綁定。企業(yè)對(duì)正規(guī)的（基于SOAP）SOA最大的反對(duì)聲之一便是，這種等級(jí)的發(fā)現(xiàn)和綁定靈活性不足以適應(yīng)復(fù)雜性。他們報(bào)告說大多數(shù)應(yīng)用的組件是相對(duì)靜態(tài)的，在組件動(dòng)態(tài)引入的地方，它們往往表示的是由另一應(yīng)用暴露的功能或者甚至是另一用戶通過API來暴露的功能—具有諷刺意味的是，那往往是RESTful的！

    提供基于目錄的組件發(fā)現(xiàn)過程給RESTful接口是有可能的，如果這種水平的動(dòng)態(tài)性有必要的話，但是此類需求也許意味著在應(yīng)用前端使用RESTful、在后端采用SOA/SOAP的混合型方案的合理性。   

解決問題

    有些應(yīng)用架構(gòu)師也許擔(dān)心RESTful接口的安全問題。從嚴(yán)格意義上來說，雙方均可以采用相同的加密選項(xiàng)，但是在SOA/SOAP中，開發(fā)者對(duì)安全有著更為顯式的控制。然而，RESTful應(yīng)用可授權(quán)安全連接，開發(fā)者就可以確保做到同樣的控制了。有關(guān)是否采取安全措施的審計(jì)問題可通過測(cè)試對(duì)接口的不安全的HTTP調(diào)用來確保這種模式下的連接是不被允許的。

    協(xié)調(diào)和工作流線程有時(shí)候也會(huì)成為通過RESTful接口實(shí)現(xiàn)的SOA的考慮問題。當(dāng)然，許多消息總線協(xié)議都會(huì)支持RESTful接口的使用（具體支持視消息總線和選定開發(fā)語言而定）�？赡軜�(gòu)成挑戰(zhàn)的是，在組件失敗導(dǎo)致事務(wù)失敗時(shí)確保撤銷過程可實(shí)現(xiàn)。

    REST中沒有明確中介流程，也沒有具體機(jī)制來確保已成功完成的給定的RESTful流程是否可逆，進(jìn)行逆向時(shí)所需的信息要少很多。映射進(jìn)RESTful消息，將其進(jìn)行跨階段傳遞以便可回溯失敗，這個(gè)過程的建立相對(duì)容易，但是可能有必要開發(fā)這一能力而不是僅僅利用標(biāo)準(zhǔn)工具或能力。

    今天很大一部分的“服務(wù)”實(shí)現(xiàn)都是基于REST而非SOA/SOAP的，但是做關(guān)鍵任務(wù)應(yīng)用時(shí)企業(yè)已經(jīng)形成對(duì)正規(guī)SOA架構(gòu)的信任。對(duì)于安全/身份管理、可組合性及合規(guī)性絕對(duì)關(guān)鍵的應(yīng)用，想對(duì)其進(jìn)行RESTful化的再造可能會(huì)很困難。不過對(duì)于一般的企業(yè)來說，真正的問題是目前的應(yīng)用組件是否需要SOAP或者可以采用RESTful的方式訪問。

    如果能用上REST，就有可能提供更快的部署方式，與客戶、供應(yīng)商以及移動(dòng)員工的集成也更加簡(jiǎn)單，還可以為員工支持提供更加靈活的GUI調(diào)整。雖然連其支持者也承認(rèn)REST并非完美解決方案，但是對(duì)于許多SOA應(yīng)用來說，這是最好的解決方案。

核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/

本文標(biāo)題：為何要結(jié)合SOA和Restful接口？

本文網(wǎng)址：http://www.oesoe.com/html/support/1112189828.html