Web services與SOA

Web services:

Web 是使應用程式可以以與平台和程式設計語言無關的方式進行互相通信的一項技術。Web 服務是一個軟體接口，它描述了一組可以在網絡上通過标準化的 XML 消息傳遞通路的操作。它使用基于 XML 語言的協定來描述要執行的操作或者要與另一個 Web 服務交換的資料。一組以這種方式互動的 Web 服務在面向服務的體系結構（Service-Oriented Architecture，SOA）中定義了特殊的 Web 服務應用程式。

軟體業最終會接受這樣的事實：跨多個作業系統、程式設計語言和硬體平台內建軟體應用程式不可能由任何一種專門的環境來解決。傳統上，這個問題一直是一個緊耦合問題，調用遠端網絡的應用程式通過自己發出的函數調用和請求的參數與遠端網絡緊密地聯系在一起。在 Web 服務出現之前，在大多數系統上，采用的是固定的接口，但對于環境或需要的改變，這缺乏靈活性或适用性。

Web 服務所使用的 XML 可以用真正與平台無關的方式來描述任何（所有）資料，以跨系統交換資料，是以轉向了松耦合應用程式。而且，Web 服務可以在較抽象的層面上工作，較抽象層面可以按照需要動态地重新評估、修改或處理資料類型。是以，從技術層面上講，Web 服務可以更友善地處理資料，并且允許軟體更自由地進行通信。

從更高的概念層面上講，我們可以将 Web 服務視為一些工作單元，每個單元處理特定的功能任務。再往上一步，可以将這些任務組合成面向業務的任務，以處理特定的業務操作任務，進而使非技術人員去考慮一些應用程式，這些應用程式可以在 Web 服務應用程式工作流中一起處理業務問題。是以，一旦由技術人員設計并建構好 Web 服務之後，業務流程架構設計師就可以聚集這些 Web 服務來解決業務層面上的問題。這裡借用汽車引擎來作類比，業務流程架構設計師考慮将整個汽車引擎與汽車架構、車身、變速器和其他系統組合在一起，而不是研究每個引擎内的各個部件。而且，動态的平台意味着引擎可以與其他汽車制造商的變速器或部件一起工作。

最後一個方面是，Web 服務可以有助于在組織内的業務人員和技術人員之間架起一座橋梁。Web 服務使業務人員能更容易了解一些技術上的操作。業務人員可以描述出一些事件和活動，然後技術人員可以将這些事件和活動與相應的服務相關聯。

有了通用定義的接口和設計良好的任務，重用這些任務就變得更容易了，因而重用這些任務所代表的應用程式也就變得容易了。應用程式軟體的可重用性意味着在軟體上的投資有了更好的回報，因為可以從同一資源産生更多收益。可重用性使業務人員可以考慮以一種新的方式來使用現有的應用程式，或者以一種新的方式将應用程式提供給合作夥伴，是以可能增加合作夥伴間的業務交易。

是以，Web 服務試圖解決的主要問題是資料和應用程式內建的問題，是将技術性的功能轉換成面向業務的計算任務的問題。這兩個方面使業務人員可以就流程或應用程式層面與他們的合作夥伴進行交流，同時為适應新形勢或按照需要與不同合作夥伴進行合作留有動态的餘地。

文章引用自：http://www-128.ibm.com/developerworks/cn/webservices/newto/websvc.html

SOA:

内容簡介

SOA是英文Service-Oriented Architecture，即服務導向架構的縮寫。這個詞彙最近一兩年頻頻出現在各種技術期刊上。但是一直以來對于SOA到底是什麼一直沒有明确的回答；SOA有什麼特點？适合用于解決哪些問題？與其他的技術有什麼差別與聯系？Web Service和SOA又是什麼關系？SOA的出現對于軟體架構設計有什麼影響？本文将就上面提到的這些問題，嘗試根據作者自己的了解給出SOA的定義；總結出SOA特有的三個基本特征；然後以HTTP協定為例對這些特征進行解釋；最後簡要的說明SOA對今後軟體架構設計可能帶來的影響。

SOA定義

下面是作者給SOA下的一個定義：SOA是指為了解決在Internet環境下業務內建的需要，通過連接配接能完成特定任務的獨立功能實體實作的一種軟體系統架構。從這個定義中我希望表達的前提有下面兩點：

１）軟體系統架構： SOA不是一種語言，也不是一種具體的技術而是一種軟體系統架構，它嘗試給出在特定環境下推薦采用的一種架構，從這個角度上來說，它更像一種模式(Pattern)。是以它與很多已有的軟體技術比如面向對象技術，是互補的而非互斥的。它們分别面向不同的應用場景，用來滿足不同的特定需求。

２）SOA的使用範圍：需求決定同時也限制功能。SOA并不是包治百病的萬靈單，它最主要的應用場合在于解決在Internet環境下的不同商業應用之間的業務內建問題。在下面我們會詳細讨論Internet的各種特點是如何決定了SOA的特點，這裡我們隻需要先簡單回顧一下Internet環境差別于Intranet環境的幾個特點：ａ）大量異構系統并存，計算機硬體工作方式不同，作業系統不同、程式設計語言也不同；ｂ）大量、頻繁的資料傳輸仍然速度緩慢并且不穩定；ｃ）版本更新無法完成，我們根本就無法知道網際網路上有哪些機器直接或者間接的使用某個服務。

基于上面的前提，下面就讓我們一起看一下SOA的基本特征。

SOA三大基本特征

獨立的功能實體

在Internet這樣松散的使用環境中，任何通路請求都有可能出錯，是以任何企圖通過Internet進行控制的結構都會面臨嚴重的穩定性問題。SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的元件技術，如.NET Remoting， EJB，COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體；當這些宿主運作結束時這些元件的壽命也随之結束。這樣當宿主本身或者其它功能部分出現問題的時候，在該宿主上運作的其它應用服務就會受到影響。

SOA架構中非常強調實體自我管理和恢複能力。常見的用來進行自我恢複的技術，比如事務處理(Transaction)，消息隊列(Message Queue)，備援部署(Redundant Deployment)和叢集系統(Cluster)在SOA中都起到至關重要的作用。

大資料量低頻率通路

對于.NET Remoting，EJB或者XML-RPC這些傳統的分布式計算模型而言，他們的服務提供都是通過函數調用的方式進行的，一個功能的完成往往需要通過用戶端和伺服器來回很多次函數調用才能完成。在Intranet的環境下，這些調用給系統的響應速度和穩定性帶來的影響都可以忽略不計，但是在Internet環境下這些因素往往是決定整個系統是否能正常工作的一個關鍵決定因素。是以SOA系統推薦采用大資料量的方式一次性進行資訊交換。

基于文本的消息傳遞

由于Internet中大量異構系統的存在決定了SOA系統必須采用基于文本而非二進制的消息傳遞方式。在COM、CORBA這些傳統的元件模型中，從伺服器端傳往用戶端的是一個二進制編碼的對象，在用戶端通過調用這個對象的方法來完成某些功能；但是在Internet環境下，不同語言，不同平台對資料、甚至是一些基本資料類型定義不同，給不同的服務之間傳遞對象帶來的很大困難。由于基于文本的消息本身是不包含任何處理邏輯和資料類型的，是以服務間隻傳遞文本，對資料的處理依賴于接收端的方式可以幫忙繞過相容性這個的大泥坑。

此外，對于一個服務來說，Internet與區域網路最大的一個差別就是在Internet上的版本管理極其困難，傳統軟體采用的更新方式在這種松散的分布式環境中幾乎無法進行。采用基于文本的消息傳遞方式，資料處理端可以隻選擇性的處理自己了解的那部分資料，而忽略其它的資料，進而得到的非常理想的相容性。

HTTP協定：一個典型的SOA實作

每一項新技術都是在一些舊的技術基礎上發展出來的。正如XML根本思想來自于在60年代就已經出現的早期标記性語言一樣，SOA雖然這兩年才出現，但是它所表達的觀念應該說在網絡這種分布式系統結構出現不久就已經廣泛應用了。例如我們最熟悉的HTTP協定就是一個非常典型的SOA架構設計。HTTP協定的工作過程簡單叙述如下：

１）用戶端，通常是通過浏覽器，向伺服器端以文本的方式發送一個請求，索取一個Web頁面；

２）伺服器端接收到這個請求之後，根據請求的内容進行處理并且傳回一個符合HTML文法的文本；

３）用戶端接收到伺服器端的響應文本後調用本地的程式，通常還是浏覽器，把傳回的HTML文本的内容展現出來。

下面來看一下HTTP協定如何滿足了SOA的特點：

• 獨立的功能實體：作為伺服器端的Web伺服器是絕對不會因為用戶端的狀況變化而改變的，它總是非常穩定的按照自己的内在邏輯運作，響應外部的請求，管理自己的資源和資料。這裡一個非常好的例子就是Web伺服器對緩存(Cache)的處理，很多Web伺服器為了提高性能都或多或少的對資料進行緩存，但是緩存資料、重新整理資料這些于用戶端完全無關的操作完全由伺服器端獨立完成，完全不受用戶端的影響。
• 大資料量低頻率通路：對于一個HTTP請求來說，用戶端與伺服器之間通路的邊界非常簡單：就是一個請求，一個響應，沒有任何其它的資訊往返。無論用戶端申請的網頁上除了文字之外還有什麼資訊，對于用戶端來說，它發出的請求隻是簡單的告訴Web伺服器它所需要的網頁的位置；至于為了生成這個網頁，伺服器端是否需要通路資料庫，執行Servlet或者其它的CGI程式對用戶端而言，都是完全透明的。
• 基于文本的消息傳遞：迄今為止相容性最好的系統可能就是HTTP協定支撐的大部分的web應用了，我們可以在Windows平台下用IE檢視網際網路上一個Linux＋Apache伺服器上的由Perl腳本自動生成的網頁。這裡的關鍵就是所有内容都是以格式化的文本方式傳遞的，不管Perl腳本如何執行，隻要它的輸出是符合HTML規範的網頁，就可以被用戶端的浏覽器解釋。而由于不同的作業系統上對于相同的HTML的解釋遵循相同的規範，是以不同作業系統下仍然能夠看到一緻的使用者界面。

我們上面基本描述了SOA作為一種軟體架構有哪些特點，下面讓我們一起看看Web Service與SOA的關系。

SOA于Web Service

Web Service是就現在而言最适合實作SOA的一些技術的集合，事實上最近SOA的火爆在很大程度上歸功于Web Service标準的成熟和應用的普及為廣泛的實作SOA架構提供了基礎。下面讓我們看看Web Service中的各種協定是如何互相工作來滿足SOA所需的特點的：

• 獨立的功能實體：通過UDDI的目錄查找，我們可以動态改變一個服務的提供方而無需影響用戶端的應用程式配置。所有的通路都通過SOAP通路進行，隻要WSDL接口封裝良好，外界用戶端是根本沒有辦法直接通路伺服器端的資料的。

• 大資料量低頻率通路：通過使用WSDL和基于文本(Literal)的SOAP請求，我們可以實作能一次性接收大量資料的接口。這裡需要着重指出的是SOAP請求分文本方式和遠端調用(RPC)兩種方式，正如上文已經提到的，采用遠端調用方式的SOAP請求并不符合這點要求。但是令人遺憾的是現有的大多數SOAP請求采用的仍然是遠端調用(RPC)方式，在某些平台上，例如IBM WebSphere的早期版本，甚至沒有提供文本方式的SOAP支援。
• 基于文本的消息傳遞：Web Service所有的通訊是通過SOAP進行的，而SOAP是基于XML的，不同版本之間可以使用不同的DTD或者XML Schema加以辨識和區分。是以隻需要我們為不同的版本提供不同的處理就可以輕松實作版本控制的目标。

SOA對于軟體架構設計的影響

無論您現在的系統是否牽涉到基于Internet的業務內建，采用SOA推薦的架構都對提高您系統的擴充性有很大幫助，下面是在系統中引入SOA後需要在軟體架構方面做出的改變：

• 使用基于文本方式的SOAP調用，擺脫遠端調用中出現的函數參數類型等與資料無關的資訊，保證所有SOAP傳遞的都是有意義的商業資料。依賴于Schema，而不是類定義對這些資料進行解釋。
• 傳統的三層Web應用将可能變成四層結構：傳統意義上的商業邏輯層将被進一步劃分為存放每個會話(Session)資訊的客戶邏輯層和與狀态無關Sateless的SOA層。

總結

本文根據作者自己對SOA的了解給出了SOA的定義，總結了SOA的三點特征并且簡要的從程式員的角度指出SOA的出現對于軟體架構設計的影響，希望本文能幫助您對SOA有較為深入