SOA的解決之道

SOA面對的難題和夢想是：第一、軟件復用與成本攤薄；第二、需求滿足與變化適應；第三、軟件整合與軟件立舊。那么SOA的解決之道是什么？

在說明這個問題之前，我們先看看古人的一個故事，很有意思。

秦國的兵工業

縱覽兩千年前秦國的戰爭史幾乎就是一部典型的大軍團作戰史，在文治方面略輸文采，稍遜風騷”的秦始皇在武功上卻是功勛卓著，戰績非凡。他驅使著秦軍這支歷史上著名的虎狼之師”短短十年間，竟吞并六國，席卷中原，進而又北逐匈奴，南服百越，最終一統天下，坐擁天下。

究竟是一種什么樣的技術力量在背后強力支撐著秦軍，使其能夠頻繁發動著大軍團作戰，面對不同的對手不斷地取得勝利而最終在軍事上強勢崛起呢？歷史文獻中一直不曾給出過真正完整的答案。

隨著大量秦國兵器的考古發掘，專家逐步為我們解開了這個千古迷團，一支裝備精良，武器先進的秦帝國軍隊被完整地復原，一個龐大的秦國武器設計生產場面也隨之真實地情景再現。其武器設計質量在讓人為之嘆為觀止的同時，也給我們當今裝備研制生產領域帶來許多有益地啟示。原因很多，其中裝備設計制造標準化最是令人嘆為觀止。

專家們對春秋戰國時期的兵器進行考古研究時發現，那時各個諸侯國即使在同一地點遺留下的兵器，也存在著輕重不等，大小不一，形式多樣等普遍現象，而只有秦國的兵器，卻不論時間相隔多年，地點相距多遠，其造型和尺寸卻是幾乎驚人地完全一致。例如：在兵馬俑坑中發現的三棱箭頭有4萬多支，其制作得極其規整，箭頭底邊寬度的平均誤差只有正負0.83毫米。北京理工大學的冶金專家對秦軍箭頭做了金相分析，結果發現它們的金屬配比基本相同，數以萬計的箭頭竟然是按照相同的技術標準鑄造出來的。

專家們還對秦傭坑兵器的弩機進行測試，結果發現數百件弩機的牙、栓、刀和其他部件，完全可以互換通用，輪廓誤差不超過1毫米。在戰場上，秦軍士兵可以隨時把損壞的弩機中仍舊完好的部件重新拼裝使用。專家同時還發現在青銅劍上有三條90多厘米長的棱線，將細長的劍身分成八個面，秦軍戈的圓弧部分加工得也十分規整，箭頭上三個流線型的表面也完全對稱。手工要完成這樣的表面加工有很大的難度，但實際情況是，兵馬俑坑中幾萬件兵器幾乎都是相同的質量。如何保證質量的同時大批量生產呢？實施標準化一定是其重要手段。盡管按今天的工業標準看，這些兵器的標準化仍舊是比較粗糙和初步的，但是，在兩千多年前，秦人執著于統一標準，保證了所有秦軍戰士使用的都是當時最優秀的武器。

由秦國兵工業的強健發展直至最后奠基秦國的霸主地位，軟件從業者可以得到如下啟示：

一 制造業和軟件業的相互羨慕

制造業羨慕軟件業，因為雖然設計成本很高，但是，設計完成后，軟件的生產成本極低。

而軟件業其實更羨慕制造業，生產成本很高，但是設計成本被成千上萬的生產過程攤薄了。

從秦國的兵工業看看我們羨慕的地方。

首先，看看復用與成本攤薄的問題，兵器的設計成本很高，需上百人年才能完成。但是，設計被復用了上百萬次后，成本被攤薄到很小很小。

其次，看看滿足需求和變化適應的問題，恰恰是軟件行業無法做到的，秦軍的需求非常統一。

最后，看看整合與立舊的問題，由于標準，弩機的牙、栓、刀和其他部件，完全可以互換通用，輪廓誤差不超過1毫米。在戰場上，秦軍士兵可以隨時把損壞的弩機中仍舊完好的部件重新拼裝使用，這是軟件業最想做到的。

其實，軟件業一直在努力向這個方向發展。

于是，軟件工程、軟件工廠、軟件藍領等概念一直被軟件業追捧。當然，軟件的復雜度遠遠高于秦國的兵器，那么我們看看SOA對于幾個方面的解決之道。

二 軟件復用與成本攤薄

當SomeThing軟件開發完成，實現了某種功能，如果無需在其他很多地方再重新編寫或維護它，那么無疑會提高生產率。然而，重用實現起來并不輕松，也并非自動化的。首先，必須以一種可重用的方式來組織或編寫代碼。然后，必須知道存在一段可以被重用的代碼。在組織代碼方面，不同的編程語言以不同的方式為重用提供內置支持。過程和函數是大多數程序員所熟悉的基本單元。面向對象的語言，比如C++和Java，還提供了定義和擴展自定義的類型或類的手段。這些特性背后的基本理念就是封裝（也就是說，只需通過一些定義良好的接口來訪問其中的功能，實現對于您而言是一個黑盒子）。這些特性有其用途和優點，但是當涉及到支持更大規模的重用時，它們也存在一些局限性。

首先，SomeThing軟件是用C++開發的，只有特別熟悉C++的程序員才能進行有效的重用。

其次，如果A公司的開發人員開發了SomeThing軟件，A內部的其他開發人員要發現SomeThing軟件可以被他使用也不是一件容易的事情，更不用說B公司、C公司的開發人員了。

最后，這個層面上的代碼并不支持網絡，這意味著無法跨機器調用這些代碼，也無法在另一種編程語言中透明地重用它們。例如，SomeThing軟件是C++開發的，那么不費一番工夫，我是無法在Java中調用SomeThing軟件的。

為了這個目標，軟件業前赴后繼，用了大量的概念和方法，如面向過程、面向對象、CORBA技術，ActiveX、COM技術、COM+技術、DCOM技術和Agent技術等等。

SOA是如何解決這一問題的呢？首先讓我們看一看SOA中的術語服務”。

服務很難精確的定義，可以理解為被調用的功能。

這個功能有以下幾個重要的特征：

1、容易被找到：一個做好的服務，一定告訴別人；

2、明確說明能干什么：接口明確描述；

3、獨立：不要依賴于其他的系統的功能和狀態；

4、誰都能調用：不依賴于操作系統、編程語言和軟件部署。

上面幾個特征表述是非常形象的表述，其實目標只有一個希望大家都來調用我”。

一方面，不限制操作系統、編程語言、軟件部署的機器；

另一方面，更方便的讓其他軟件調用。

W3C把SOA定義為一組可調用的組件，其接口描述可以被公開和發現”。

SOA是一種思想，它絕對不是萬能的，它需要開發者根據自身行業的特征，設計哪一部分功能作為一個組件。只有你的功能劃分得非常合理，才能做到軟件復用和成本攤薄。

三 需求滿足與變化適應

SOA的方法在需求的滿足和變化的適應方面并沒有太多其他獨到的地方，它依然是基于軟件的復用和成本的攤薄。

需求的滿足和變化的適應要求服務合理地提供出來：

第一、需要滿足服務的幾個重要特征；

第二、服務要適合行業需要，是對行業需求的抽象，要考慮到行業其他軟件如何調用；

第三、需要有合適的顆粒度，以便可以組合出各種各樣的需求，并且需求變化時可以快速重組，同時，服務的一個部分需要變更，則不要影響全局；。

那么從本質上來講，SOA對需求的滿足和變化的適應方面的建議不是直接滿足需求和需求的變化，而是通過接口的調用和調用的組合來滿足的。

四 軟件整合與軟件立舊

討論完軟件復用與成本攤薄和需求滿足與變化適應后，軟件整合與軟件立舊就是一個非常容易理解的問題了。

軟件以接口的形式出現，自然軟件的整合更加容易，軟件的立舊更加輕松。

SOA的軟件整合似乎是很理想的一件事情，如果你要開發一個軟件，用于自己網站的會員在網上預訂酒店，軟件整合的過程大致如下：

1、你發現美國的一臺服務器，上面是一個提供房源的服務，你調用其中一些服務，解決了房源信息問題；

2、你發現了日本的一臺服務器，上面提供了展示酒店的服務，你調用其中的一些服務，解決了酒店信息展示的問題；

3、你發現中國的一臺服務器，提供地圖服務....

4、你發現法國的一臺服務器，提供客戶服務的服務...

5、....

組合后，你的軟件快速實現。

由于你可以選擇的服務眾多，可以任意組合服務的各種功能，很好的滿足了客戶的需求。而那些服務的提供商，也通過你對他的服務的使用，獲取了收益，達到了他的軟件的復用和成本的攤薄。

SOA的支持與其中重要的概念

孤木難成林”，既然這個概念是解決軟件行業問題的概念，那么就需要整個軟件行業支持。目前，幾乎所有的軟件巨頭都在支持SOA，包括IBM、微軟、Oracle、BEA、SAP等等，還有一家AVAYA--我們行內非常熟悉的廠商。SOA已經不是一個大家爭論的概念了，而是實戰了。

SOA還有兩個重要的概念，即ESB和BPM。

第一個概念 ESB企業服務總線

SOA的服務組件暴露的是一種粗粒度的接口，其目的是使應用之間能夠異步共享數據。而使用ESB，一種集成架構將應用程序和分離的集成組件拉在一起，以產生服務裝配組合從而形成復合的業務流程，進而自動化一個即時企業中的業務功能。

ESB為SOA提供實現骨架。那就是說，它通過一個跨越多種協議的消息總線來提供一個有關命名路由目的地的高度分布的世界來提供松散耦合的，事件驅動的SOA。ESB中的應用程序(和集成組件)在理論上是彼此解耦的，而且通過總線彼此連接為暴露為事件驅動服務的邏輯端點。

通過分布式的部署配置基礎設施，ESB能有效率地提供對在擴展企業中分布的服務的中心配置、部署和管理。一種普遍集成的新方式應用諸如SOA、EAI、B2B和Web服務之類的技術的通常目標主要是創建一個集成架構，且能夠深入并且跨越整個擴展企業。對于一個集成基礎設施到達到這種普遍性，它必須具有下列各項特性:

它必須能夠適應多種集成情形項目的通常目的需要，不管是大型的還是小型的。適應性包括提供一個能夠經受協議、接口技術、甚至流程模型的變化趨勢的持久架構。

·它必須以一種單一和統一的方式，以及一個通用的基礎設施來連接擴越擴展企業的各種應用。

·它必須能夠擴展超出單一公司IT中心的邊界。并且自動化伙伴關系，比如在B2B 和供應鏈的情況下。

·它必須具有設計的簡單性和較低的進入門坎，使得日常的IT專業人員也能夠成為自我修練的集成架構師。

·它必須提供一個跨越普遍集成的 SOA，它能使集成架構師能夠對公司的應用資產和自動化業務流程有一個廣泛的、抽象的視圖。

·它需要有能夠反應和符合不斷變更的業務需求和競爭的壓力需要的靈活性和能力。

在ESB中，應用和事件驅動服務以一種松散耦合的方式緊密地聯系在SOA中。這使得它們能夠彼此獨立運行，并且仍然能夠提供廣泛的業務功能價值。

ESB架構解決了這些需要，并且正在被各種通用的集成項目所采用。它也能夠在企業應用層面普遍地伸展，不管是物理位置還是技術平臺。任何應用都可以通過大量的連接選擇插入到一個ESB網絡中，并且可以立即參與到與那些通過總線暴露為共享服務的應用之間的數據共享之中。這是 ESB 為什么經常被稱為集成網絡或集成構造的緣故。

簡單一點，下面兩種構架的方式，第一種，雜亂無章，第二種，非常清晰，第二種用的就是ESB的方式。

第二個概念 BPM服務流程管理

業務流程管理系統（Business Process Management簡稱BPM)。BPM的定義分為合作戰略部分與軟件部分。其注重點是通過建模、自動化、管理和優化任意一種業務流程，來管理公司業務流程的效率和效果。

而SOA中的服務也是需要流程的，二者之間是需要融合的。

沒有SOA，BPM一樣會出現并得到實現，但是，在SOA將更多標準和系統整合成為可能的基礎上，通過SOA而在整體范圍內實現BPM將會得到最大程度的簡化。就我聽到的最為形象的一個比喻則是，在脫離SOA協助下的BPM如同一個將一只手捆綁在背上的人努力想要去達到的目標。”

而目前面臨的主要的問題是，當大家都去支持SOA的時候，BPM如何去實現，或者如何去整合原有的BMP。