評論(0

美國國家金融服務公司

標籤: 暫無標籤

1969年,Countrywide公司由David Loeb and Angelo R Mozilo(安吉羅·莫茲羅)。 Countrywide Financial通過它的子公司,在國內及國外市場提供抵押銀行業務及多樣化的金融服務。消費者業務包括抵押貸款,保險及其他金融產品。商務對商務業務包括資金市場,業務處理和保險。他們的總部設在加州的Calabasas。

1公司業務

選擇SOA
Countrywide公司分幾個業務部門,每個部門都僱用了IT人員,獨立工作。2002年,主要支持公司貸款部門的一個業務部門——全國服務系統開發部門(CSSD)啟動了SOA項目,如圖所示。
據CSSD負責應用開發的高級副總裁Peter Presland-Byrne聲稱,該部門之所以選擇了SOA方案,是因為應用程序支持業務問題,而且採用的某些模式適用於SOA的兩個主要屬性:基於服務的功能抽象,以及注重提供這些基本服務的重用組件。他說:「我們盡量從服務層面看待業務模式的結構。」
軟體開發方法
為了便於遵守SOA,Countrywide公司評估了新的軟體開發方法,確保新方法適合SOA,提供一致的兼容性,盡量重複使用現有服務。Countrywide公司最初把SOA看成了中心目標,但後來認識到SOA推崇的重用思想才是中心目標。Presland- Byrne說:「如果你真正支持重複使用,SOA就有可能成為現實。」   Countrywide公司還決定使用消息系統,作為連接應用程序和數據源的機制。Presland- Byrne說,因為公司使用好幾項不同種類的技術,包括Java和微軟 .Net,所以一定要做到與消息無關(messaging-agnostic),以確保系統不會依賴某項有技術。Countrywide公司還在很大程度上依賴IBM的MQSeries和WebSphere MQ Integrator中間件,用於傳送消息、處理服務;並依賴Flashline的開發環境,用於管理服務和軟體組件。
「緩衝器」
Presland-Byrne認為,更重要的是,充當「緩衝器」的中間件——負責在諸多服務之間轉換業務邏輯和數據格式——必須與服務邏輯分離開來。這樣一來,不同的應用程序就可以同時使用同一服務,用不著在應用程序或者數據發生變化時,改動服務代碼。另外,你還可以同時運行新老版本的服務,無論是在轉換期間,還是為了滿足不同應用程序的需求。在這兩種情況下,IT人員可以讓服務保持原樣。
Presland-Byrne強調,考慮到Countrywide公司的大多數服務是在內部,儘管公司不是高度依賴Web服務或者相關技術,譬如SOAP,不過它的確把Web服務用於客戶和現場代理人所用的少數幾個應用程序。然而,Countrywide公司往往使用XML,作為服務和中間件的語義數據標準,因為XML非常普遍適用和廣為人知。
SOA定義
SOA是指為了解決在Internet環境下業務集成的需要,通過連接能完成特定任務的獨立功能實體實現的一種軟體系統架構。
獨立的功能實體
在Internet 這樣鬆散的使用環境中,任何訪問請求都有可能出錯,因此任何企圖通過Internet進行控制的結構都會面臨嚴重的穩定性問題。SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的組件技術,如.NET Remoting,EJB,COM或者CORBA,都需要有一個宿主(Host或者Server)來存放和管理這些功能實體;當這些宿主運行結束時這些組件的壽命也隨之結束。這樣當宿主本身或者其它功能部分出現問題的時候,在該宿主上運行的其它應用服務就會受到影響。
SOA架構中非常強調實體自我管理和恢復能力。常見的用來進行自我恢復的技術,比如事務處理(Transaction),消息隊列(Message Queue),冗餘部署(Redundant Deployment)和集群系統(Cluster)在SOA中都起到至關重要的作用。
基於文本的消息傳遞
由於Internet中大量異構系統的存在決定了SOA系統必須採用基於文本而非二進位的消息傳遞方式。在COM、CORBA這些傳統的組件模型中,從伺服器端傳往客戶端的是一個二進位編碼的對象,在客戶端通過調用這個對象的方法來完成某些功能;但是在Internet環境下,不同語言,不同平台對數據、甚至是一些基本數據類型定義不同,給不同的服務之間傳遞對象帶來的很大困難。由於基於文本的消息本身是不包含任何處理邏輯和數據類型的,因此服務間只傳遞文本,對數據的處理依賴於接收端的方式可以幫忙繞過兼容性這個的大泥坑。
此外,對於一個服務來說,Internet與區域網最大的一個區別就是在Internet上的版本管理極其困難,傳統軟體採用的升級方式在這種鬆散的分散式環境中幾乎無法進行。採用基於文本的消息傳遞方式,數據處理端可以只選擇性的處理自己理解的那部分數據,而忽略其它的數據,從而得到的非常理想的兼容性。

2HTTP協議

工作過程
HTTP協議的工作過程簡單敘述如下:
1) 客戶端,通常是通過瀏覽器,向伺服器端以文本的方式發送一個請求,索取一個Web頁面;
2) 伺服器端接收到這個請求之後,根據請求的內容進行處理並且返回一個符合HTML語法的文本;
3) 客戶端接收到伺服器端的響應文本后調用本地的程序,通常還是瀏覽器,把返回的HTML文本的內容展現出來。
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加以辨別和區分。因此只需要我們為不同的版本提供不同的處理就可以輕鬆實現版本控制的目標。

3SOA的影響

無論您現在的系統是否牽涉到基於Internet的業務集成,採用SOA推薦的架構都對提高您系統的擴展性有很大幫助,下面是在系統中引入SOA后需要在軟體架構方面做出的改變:
使用基於文本方式的SOAP調用,擺脫遠程調用中出現的函數參數類型等與數據無關的信息,保證所有SOAP傳遞的都是有意義的商業數據。依賴於Schema,而不是類定義對這些數據進行解釋。
傳統的三層Web應用將可能變成四層結構:傳統意義上的商業邏輯層將被進一步劃分為存放每個會話(Session)信息的客戶邏輯層和與狀態無關Sateless的SOA層。
上一篇[德摩根定理]    下一篇 [絘布]

相關評論

同義詞:暫無同義詞