美國國家金融服務公司

出自 MBA智库百科(https://wiki.mbalib.com/)

美國國家金融服務公司股東於2008年6月25日批准該公司被美洲銀行收購，預計該交易將於7月1日完成，交易額為28億美元左右。

　　1969年，Countrywide公司由David Loeb and Angelo R Mozilo(安吉羅·莫茲羅)。

　　Countrywide Financial通過它的子公司，在國內及國外市場提供抵押銀行業務及多樣化的金融服務。消費者業務包括抵押貸款，保險及其他金融產品。商務對商務業務包括資金市場，業務處理和保險。他們的總部設在加州的Calabasas。

　　一家IT部門分佈廣泛、業務發展迅猛的貸款公司把應用轉化成服務，通過消息匯流排聯繫起來，並且讓業務獲得新的靈活性。

　　半個世紀以來，隨著客戶、產品和市場的不斷增加，美國Countrywide Financial公司的貸款、保險和銀行服務業務也在急劇發展，IT系統隨之越來越複雜。為了應對需求增加的情況，Countrywide公司決定採用靈活的SOA方案，希望實現企業IT部門孜孜以求的長遠目標：降低複雜性，提高擴展性，減少管理費用。

　　選擇SOA

　　Countrywide公司分幾個業務部門，每個部門都雇用了IT人員，獨立工作。2002年，主要支持公司貸款部門的一個業務部門——全國服務系統開發部門（CSSD）啟動了SOA項目，如圖所示。

　　據CSSD負責應用開發的高級副總裁Peter Presland-Byrne聲稱，該部門之所以選擇了SOA方案，是因為應用程式支持業務問題，而且採用的某些模式適用於SOA的兩個主要屬性：基於服務的功能抽象，以及註重提供這些基本服務的重用組件。他說：“我們儘量從服務層面看待業務模式的結構。”

　　實施中採用幾種技術與做法

　　CSSD開始實施SOA後，很快發現，許多應用程式裡面所含的服務有著與其他應用程式同樣的功能。

　　Presland-Byrne認為：“我們需要抽取服務，這是一項日常工作，如果出現功能重覆，還要決定選擇哪些服務。”他預料，為了支持Web服務，需要進一步抽取服務，因為這種支持功能在CSSD使用的IBM iSeries中檔伺服器服務環境當中“不是原本就有的”。

　　Presland-Byrne指出，抽取核心服務、讓應用程式使用公用服務而不是各行其事，這是SOA方案的一個重要方面，這就需要開發軟體時要註重可重用性。

　　為了便於遵守SOA，Countrywide公司評估了新的軟體開發方法，確保新方法適合SOA，提供一致的兼容性，儘量重覆使用現有服務。Countrywide公司最初把SOA看成了中心目標，但後來認識到SOA推崇的重用思想才是中心目標。Presland- Byrne說：“如果你真正支持重覆使用，SOA就有可能成為現實。”

　　Countrywide公司還決定使用消息系統，作為連接應用程式和數據源的機制。Presland- Byrne說，因為公司使用好幾項不同種類的技術，包括Java和微軟 .Net，所以一定要做到與消息無關（messaging-agnostic），以確保系統不會依賴某項有技術。Countrywide公司還在很大程度上依賴IBM的MQSeries和WebSphere MQ Integrator中間件，用於傳送消息、處理服務；並依賴Flashline的開發環境，用於管理服務和軟體組件。

　　雖然公司跨CSSD的諸多應用程式，對消息系統實行了標準化，但不需要一致的數據模型。相反，公司使用中間件確保一致的信息流；需要時，就映射及轉換數據格式。對CSSD而言，強制使用一致的數據模型不合實際，因為“一旦引入第三方工具，一致的數據模型就無從談起”，Presland-Byrne說,“我們引入的中間件可以轉換這些不同的標準。這就是集成工具的用途所在。”

　　Presland-Byrne認為，更重要的是，充當“緩衝器”的中間件——負責在諸多服務之間轉換業務邏輯和數據格式——必須與服務邏輯分離開來。這樣一來，不同的應用程式就可以同時使用同一服務，用不著在應用程式或者數據發生變化時，改動服務代碼。另外，你還可以同時運行新老版本的服務，無論是在轉換期間，還是為了滿足不同應用程式的需求。在這兩種情況下，IT人員可以讓服務保持原樣。

　　Presland-Byrne強調，考慮到Countrywide公司的大多數服務是在內部，儘管公司不是高度依賴Web服務或者相關技術，譬如SOAP，不過它的確把Web服務用於客戶和現場代理人所用的少數幾個應用程式。然而，Countrywide公司往往使用XML，作為服務和中間件的語義數據標準，因為XML非常普遍適用和廣為人知。

　　未來發展計劃

　　在業務部門部署SOA的同時，Countrywide公司現正在探討如何擴大這種方案的用途，用於各部門之間的溝通。Presland-Byrne承認，這就需要重新分析服務、消除重覆現象。該公司已經開始把用戶身份識別合併成一項服務，這樣只要通過單次登錄（SSO），就可以跨企業訪問該服務。

　　因為每個業務部門的發展模式和技術生命周期各不相同，想在全公司一下子實施SOA在2002年並不可能。如今由於每個業務部門都接受了SOA概念，技術成熟程度也很相似，推廣這種架構“是我們現在能夠處理的”。Presland-Byrne認為。

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

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

　　2) SOA的使用範圍：需求決定同時也限制功能。SOA並不是包治百病的萬靈丹，它最主要的應用場合在於解決在Internet環境下的不同商業應用之間的業務集成問題。在下麵我們會詳細討論Internet的各種特點如何決定SOA的特點，這裡我們只需要先簡單回顧一下Internet環境區別於 Intranet環境的幾個特點：

• a) 大量異構系統並存，電腦硬體工作方式不同，操作系統不同、編程語言也不同；
• b) 大量、頻繁的數據傳輸仍然速度緩慢並且不穩定；
• c) 版本升級無法完成，我們根本就無法知道互聯網上有哪些機器直接或者間接的使用某個服務。

　　1、獨立的功能實體

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

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

　　2、大數據量低頻率訪問

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

　　3、基於文本的消息傳遞

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

　　此外，對於一個服務來說，Internet與區域網最大的一個區別就是在Internet上的版本管理極其困難，傳統軟體採用的升級方式在這種鬆散的分散式環境中幾乎無法進行。採用基於文本的消息傳遞方式，數據處理端可以只選擇性的處理自己理解的那部分數據，而忽略其它的數據，從而得到的非常理想的兼容性。

　　HTTP協議：一個典型的SOA實現

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

• 1) 客戶端，通常是通過瀏覽器，向伺服器端以文本的方式發送一個請求，索取一個Web頁面；
• 2) 伺服器端接收到這個請求之後，根據請求的內容進行處理並且返回一個符合HTML語法的文本；
• 3) 客戶端接收到伺服器端的響應文本後調用本地的程式，通常還是瀏覽器，把返回的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的關係。

　　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加以辨別和區分。因此只需要我們為不同的版本提供不同的處理就可以輕鬆實現版本控制的目標。

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

　　使用基於文本方式的SOAP調用，擺脫遠程調用中出現的函數參數類型等與數據無關的信息，保證所有SOAP傳遞的都是有意義的商業數據。依賴於Schema，而不是類定義對這些數據進行解釋。

　　傳統的三層Web應用將可能變成四層結構：傳統意義上的商業邏輯層將被進一步劃分為存放每個會話(Session)信息的客戶邏輯層和與狀態無關Sateless的SOA層。