SOA與企業應用

 SOA（service-oriented Architecture，也叫面向服務的體系結構或面向服務架構）是指為了解決在Internet環境下業務整合的需要，通過連線能完成特定任務的獨立功能實體實現的一種軟體系統架構。SOA是一個元件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行互動。

      傳統的Web（HTML/HTTP）技術有效的解決了人與資訊系統的互動和溝通問題，極大的促進了B2C模式的發展。WEB服務(XML/SOAP/WSDL）技術則是要有效的解決資訊系統之間的互動和溝通問題，促進B2B/EAI/CB2C的發展。SOA（面向服務的體系)則是採用面向服務的商業建模技術和WEB服務技術，實現系統之間的鬆耦合，實現系統之間的整合與協同。WEB服務和SOA的本質思路在於使得資訊系統個體在能夠溝通的基礎上形成協同工作。

 　 對於面向同步和非同步應用的，基於請求/響應模式的分散式計算來說，SOA是一場革命。一個應用程式的業務邏輯（businESs logic）或某些單獨的功能被模組化並作為服務呈現給消費者或客戶端。這些服務的關鍵是他們的鬆耦合特性。例如，服務的介面和實現相獨立。應用開發人員或者系統整合者可以通過組合一個或多個服務來構建應用，而無須理解服務的底層實現。舉例來說，一個服務可以用。NET或J2EE來實現，而使用該服務的應用程式可以在不同的平臺之上，使用的語言也可以不同。

一、SOA具有的特性

　　SOA服務具有平臺獨立的自我描述XML文件。Web服務描述語言（WSDL， Web Services DesCRiption Language）是用於描述服務的標準語言。

　　SOA 服務用訊息進行通訊，該訊息通常使用XML Schema來定義（也叫做XSD， XML Schema Definition）。消費者和提供者或消費者和服務之間的通訊多見於不知道提供者的環境中。服務間的通訊也可以看作企業內部處理的關鍵商業文件。

　　在一個企業內部，SOA服務通過一個扮演目錄列表（DIrECtory liSTing）角色的登記處（Registry）來進行維護。應用程式在登記處（Registry）尋找並呼叫某項服務。統一描述，定義和整合（UDDI， UniverSAl Description， Definition， and Integration）是服務登記的標準。

　　每項SOA服務都有一個與之相關的服務品質（QOS， quality of service）。QoS的一些關鍵元素有安全需求（例如認證和授權），可靠通訊（譯註：可靠訊息是指，確保訊息“僅且僅僅”傳送一次，從而過濾重複資訊。），以及誰能呼叫服務的策略。

二、SOA三大基本特徵

      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上的版本管理極其困難，傳統軟體採用的升級方式在這種鬆散的分散式環境中幾乎無法進行。採用基於文字的訊息傳遞方式，資料處理端可以只選擇性的處理自己理解的那部分資料，而忽略其它的資料，從而得到的非常理想的相容性。

三、面向服務架構（SOA）的原則

      SOA的強大和靈活性將給企業帶來巨大的好處。如果某組織將其IT架構抽象出來，將其功能以粗粒度的服務形式表示出來，每種服務都清晰地表示其業務價值，那麼，這些服務的顧客（可能在公司內部，也可能是公司的某個業務夥伴）就可以得到這些服務，而不必考慮其後臺實現的具體技術。更進一步，如果顧客能夠發現並繫結可用的服務，那麼在這些服務背後的IT系統能夠提供更大的靈活性。
但是，要得到種強大和靈活性，需要有一種實現架構的新方法，這是一項艱鉅的任務。企業架構設計師必須要變成“面向服務的架構設計師”，不僅要理解SOA，還要理解SOA的實踐。在架構實踐和最後得到的架構結果之間的區別非常微妙，也非常關鍵。本文將討論SOA的實踐，即：面向架構的設計師在構建SOA時必須要做的事情。

      SOA的原則

      SOA是一種企業架構，因此，它是從企業的需求開始的。但是，SOA和其它企業架構方法的不同之處在於SOA提供的業務敏捷性。業務敏捷性是指企業對變更快速和有效地進行響應、並且利用變更來得到競爭優勢的能力。對架構設計師來說，建立一個業務敏捷的架構意味著建立這樣一個IT架構，它可以滿足當前還未知的業務需求。

      要滿足這種業務敏捷性，SOA的實踐必須遵循以下原則：

      * 業務驅動服務，服務驅動技術

      從本質上說，在抽象層次上，服務位於業務和技術中間。面向服務的架構設計師一方面必須理解在業務需求和可以提供的服務之間的動態關係，另一方面，同樣要理解服務與提供這些服務的底層技術之間的關係。

      * 業務敏捷是基本的業務需求

      SOA考慮的是下一個抽象層次：提供響應變化需求的能力是新的“元需求”，而不是處理一些業務上的固定不變的需求。從硬體系統而上的整個架構都必須滿足業務敏捷的需求，因為，在SOA中任何的瓶頸都會影響到整個IT環境的靈活性。

      * 一個成功的SOA總在變化之中

      SOA工作的場景，更象是一個活的生物體，而不是象傳統所說的“蓋一棟房子”。IT環境唯一不變的就是變化，因此面向服務架構設計師的工作永遠不會結束。對於習慣於蓋房子的設計師來說，要轉向設計一個活的生物體要求嶄新的思維方式。如下文所寫的，SOA的基礎還是一些類似的架構準則。

      SOA基礎

      在IT行業有兩個越來越普遍的發展方向，一個是架構方面的，一個是方法學方面的，面向服務的架構設計師可以從中有所收穫。第一個就是MDA（模型驅動架構），由提出CORBA的OMG模型提出。MDA認為架構設計師首先要對待建立的系統有一個形式化的UML（也是由OMG提出）的模型。MDA首先給出一個平臺無關的模型來表示系統的功能需求和Use Cases，根據系統搭建的平臺，架構設計師可以由這個平臺無關的模型得到平臺相關的模型，這些平臺相關模型足夠詳細，以至於可以用來直接生成需要的程式碼。

      MDA的核心就在於在設計階段系統就已經完全描述，這樣，在建立系統的時候，幾乎就沒有錯誤解釋的可能，模型也就可以直接生成程式碼。但MDA有一些侷限性：首先，MDA假設在建立模型之前，業務需求已經全部描述，而這一點，在當前典型的動態業務環境中幾乎是不可能的。第二，MDA沒有一個反饋機制。如果開發人員對模型有需要改動的地方，並沒有提供給他們這麼一個途徑。

      SOA的另一個基礎是敏捷方法（AM），其中非常有名的方法是極限程式設計（XP）。象XP這樣的AM提供了在需求未知或者多變的環境中建立軟體系統的過程。XP要求在開發團隊中要有一個使用者代表，他幫助書寫測試來指導開發人員的日常工作。開發團隊中的所有成員都參與到設計之中，並且設計要儘量小並且非形式化。AM的目標是僅僅建立使用者想要的，而不是在一些形式化模型上耗費工作量。AM的核心思想就在於其敏捷性－處理需求變更的敏捷性。AM的主要弱點是其規模上的限制，例如，XP在一個小團隊和中型專案中效果不錯，但是當專案規模增大時，如果沒有一個一致的清晰的計劃，專案成員很難把握專案中的方方面面。

      從表面看來，MDA和AM似乎是相對立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型，而AM恰恰要避開它們。但是，我們還是決定冒險把這些不同方法中的一些元素提取出來，放入到一個一致的架構實踐中。

      在SOA中有三個抽象層次，按照SOA的第一條準則：業務驅動服務、服務驅動技術。AM將業務模型直接和實踐連線起來，表現在平臺相關的模型之中。MDA並沒有把業務模型和平臺無關模型分開來，而是把平臺無關模型做為起點。SOA必須連線這些模型，或者說抽象層次，得到單一的架構方法。我們將從五個檢視的架構實現方法來實現這個連線。

      SOA的五檢視實現方法

      企業架構設計師發現他們的職業非常有競爭力並且值得驕傲，因為他們要從很多方面來通盤考慮IT系統。Kruchten（RUP的開發負責人）將這些方面提取出來，在應用到SOA時，我們稱為五檢視實現方法（five-view approach）。

      四個方框表示對一個架構的不同審視方法，分別代表不同的涉眾（stakeholder）。弟五個檢視，use-cASe檢視涵蓋了其它檢視，在架構中扮演的是一個特殊的角色。部署檢視將軟體對映到底層平臺和相關硬體上，是系統部署人員對架構的檢視；實現檢視描述了軟體程式碼的組織，是從開發人員角度出發的檢視；業務分析人員則利用過程檢視進行工作，它描述的是軟體系統的執行時特性。最後，邏輯檢視表示的是使用者的功能需求。在SOA中，面向服務的架構必須能夠以use-case檢視中的用例將使用者連線到服務，將服務連線到底層的技術。

      為了表示物件導向的架構是如何工作在這些檢視之上，讓我們將他們置於SOA元模型的上下文之中。SOA中兩個領域存在重疊：由業務模型和服務模型表示的業務領域和由服務模型及平臺相關模型表示的技術領域（兩個領域共享服務模型）。業務使用者通過邏輯檢視和過程檢視處理粗粒度的業務服務，根據變化的業務需求，按照需要將它們安排在過程之中。另一方面，技術專家的工作是建立並維護服務和地層技術之間的抽象層。表示這些服務的中間模型，起到的是軸心的作用，業務以它為中心進行。

      SOA元模型從MDA中繼承平臺無關模型和平臺相關模型，但是新增了AM和使用者互動以及敏捷的反饋這兩部分，後者通過橢圓之間的雙向箭頭來表現。類似地，元模型通過引入由中心的服務模型提供的中間層抽象解決了AM在伸縮性方面的問題。這樣，服務模型中的任何需求的變化，都會反映到使用者每天的業務處理中。同樣，由於底層技術是模型驅動的，技術專家也可以根據這些變化的需求迅速而有效地作出應變。

      SOA實踐和過去解決企業架構傳統方式的不同之處就在於其對敏捷性的支援。如前所說，SOA的第三條原則就在於它總在變化之中。這種恆在的變化性環境是SOA實踐的基石。如圖所示，涉眾（stakeholders，譯者注：RUP中也有這個詞，表示軟體開發中涉及到的各種角色如：使用者、設計人員、開發人員乃至測試人員等等。）在一個必需的基礎上影響到整個架構的變化。在當技術專家在每天的日常工作中不斷對變化的業務需求作出響應的這種情況下，設計階段和執行階段之間的界限變得模糊起來，很難清晰地分離這兩個階段。

      剩下的部分

      我們已經為面向服務的架構提供了一個高層次的框架，其中MDA和AM的元素幫助工具的使用者來建立和維護SOA。但是，SOA中還缺少一些內容－那就是軟體開發商和專業的服務組織必需提供的。理想情況下，開發商必需提供面向服務的業務流程、工作流以及服務的協調工具和服務；另外，能夠以一種敏捷的、平臺無關的方式充分反映業務服務的建模工具也是必須的；技術專家必須配備可以從模型中自動生成程式碼，並在程式碼變化時更新模型的工具，最後，開發商必須提供支援SOA的軟體，幫助面向服務的架構設計師以一種可信並且可伸縮的方式建立位於服務和底層技術之間的抽象層次。幸運的是，這方面的產品即將上市。

      另外，最重要的就是貫穿本文的自頂而下的SOA實現方法了。今天關於Web services的大部分思考都是自底而上的：“這是如何建立Web services的方法，現在，我們來使用它們整合吧”，對Web services技術的這種方法是偉大的第一步，因為它可以驚人地降低整合的開銷，這是現在的技術管理人員最樂意見到的了。但當經濟進一步發展，IT走出低谷，企業會尋求IT的幫助來提高組織戰略意義上的核心價值。使用面向服務的架構，IT可以提供給企業實現業務敏捷性的這樣一個框架。

四、為什麼選擇面向服務架構（SOA）？

　　不同種類的作業系統，應用軟體，系統軟體和應用基礎結構（application infrastructure）相互交織，這便是IT企業的現狀。一些現存的應用程式被用來處理當前的業務流程（business processes），因此從頭建立一個新的基礎環境是不可能的。企業應該能對業務的變化做出快速的反應，利用對現有的應用程式和應用基礎結構（application infrastructure）的投資來解決新的業務需求，為客戶，商業夥伴以及供應商提供新的互動渠道，並呈現一個可以支援有機業務（orGAnic business）的構架。SOA憑藉其鬆耦合的特性，使得企業可以按照模組化的方式來新增新服務或更新現有服務，以解決新的業務需要，提供選擇從而可以通過不同的渠道提供服務，並可以把企業現有的或已有的應用作為服務， 從而保護了現有的IT基礎建設投資。

　　如圖1的例子所示，一個使用SOA的企業，可以使用一組現有的應用來建立一個供應鏈複合應用（supply chain composite application），這些現有的應用通過標準介面來提供功能。

 

　　Figure 1. Supply chain application. Click on thumbnail to view full-sized image.

　　服務架構

　　為了實現SOA，企業需要一個服務架構，圖2顯示了一個例子：

 

　　Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.

　　在圖2中， 服務消費者（service consumer）可以通過傳送訊息來呼叫服務。這些訊息由一個服務匯流排（service bus）轉換後傳送給適當的服務實現。這種服務架構可以提供一個業務規則引擎（business rules engine），該引擎容許業務規則被合併在一個服務裡或多個服務裡。這種架構也提供了一個服務管理基礎（service management infrastructure），用來管理服務，類似稽核，列表（BIlling），日誌等功能。此外，該架構給企業提供了靈活的業務流程，更好地處理控制請求（regulatory requirement），例如Sarbanes Oxley（SOX），並且可以在不影響其他服務的情況下更改某項服務。

五、面向服務架構（SOA）基礎結構

　　要執行，管理SOA應用程式，企業需要SOA基礎，這是SOA平臺的一個部分。SOA基礎必須支援所有的相關標準，和需要的執行時容器。圖3所示的是一個典型的SOA基礎結構。接下來的章節將逐一討論該結構的每個部分。

 

　　Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.

　　SOAP， WSDL， UDDI

　　WSDL，UDDI和SOAP是SOA基礎的基礎部件。WSDL用來描述服務；UDDI用來註冊和查詢服務；而SOAP，作為傳輸層，用來在消費者和服務提供者之間傳送訊息。SOAP是Web服務的預設機制，其他的技術為可以服務實現其他型別的繫結。一個消費者可以在UDDI登錄檔（registry）查詢服務，取得服務的WSDL描述，然後通過SOAP來呼叫服務。

　　WS-I Basic Profile

　　WS-I Basic Profile，由Web服務互用性組織（Web Services Interoperability Organization）提供，是SOA服務測試與互用性所需要的核心構件。服務提供者可以使用Basic Profile測試程式來測試服務在不同平臺和技術上的互用性。

　　J2EE 和 .Net

　　儘管J2EE和。NET平臺是開發SOA應用程式常用的平臺，但SOA不僅限於此。像J2EE這類平臺，不僅為開發者自然而然地參與到SOA中來提供了一個平臺，還通過他們內在的特性，將可擴充套件性，可靠性，可用性以及效能引入了SOA世界。新的規範，例如 JAXB（Java API for XML Binding），用於將XML文件定位到Java類；JAXR（Java API for XML Registry）用來規範對UDDI登錄檔（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用來呼叫遠端服務，這使得開發和部署可移植於標準J2EE容器的Web服務變得容易，與此同時，實現了跨平臺（如。NET）的服務互用。

　　服務品質

　　在企業中，關鍵任務系統（MISsion-critical system，譯註：關鍵任務系統是指如果一個系統的可靠性對於一個組織是至關重要的，那麼該系統就是該企業的關鍵任務系統。比如，電話系統對於一個電話促銷企業來說就是關鍵任務系統，而文書處理系統就不那麼關鍵了。）用來解決高階需求，例如安全性，可靠性，事物。當一個企業開始採用服務架構作為工具來進行開發和部署應用的時候，基本的Web服務規範，像WSDL，SOAP，以及UDDI就不能滿足這些高階需求。正如前面所提到的，這些需求也稱作服務品質（QoS，quality of services）。與QoS相關的眾多規範已經由一些標準化組織（standaRDS BOdies）提出，像W3C（World WIDE Web Consortium）和OASIS（the Organization for the Advancement of Structured InfORMation Standards）。下面的部分將會討論一些QoS服務和相關標準。

　　安全

　　Web服務安全規範用來保證訊息的安全性。該規範主要包括認證交換， 訊息完整性和訊息保密。該規範吸引人的地方在於它藉助現有的安全標準，例如，SAML（as Security Assertion Markup Language）來實現web服務訊息的安全。OASIS正致力於Web服務安全規範的制定。

      可靠

　　在典型的SOA 環境中，服務消費者和服務提供者之間會有幾種不同的文件在進行交換。具有諸如“僅且僅僅傳送一次”（ once-and-only-once delivery），“最多傳送一次”（ at-most-once delivery），“重複訊息過濾”（duplicate message elimination），“保證訊息傳送”（guaranteed message delivery）等特性訊息的傳送和確認，在關鍵任務系統（mission-critical systems）中變得十分重要。WS-Reliability 和 WS-ReliableMessaging是兩個用來解決此類問題的標準。這些標準現在都由OASIS負責。

　　策略

　　服務提供者有時候會要求服務消費者與某種策略通訊。比如，服務提供商可能會要求消費者提供Kerberos安全標示，才能取得某項服務。這些要求被定義為策略斷言（policy assertions）。一項策略可能會包含多個斷言。WS-Policy用來標準化服務消費者和服務提供者之間的策略通訊。

　　控制

　　當企業著手於服務架構時，服務可以用來整合資料倉儲（silos of data），應用程式，以及元件。整合應用意味著例如非同步通訊，並行處理，資料轉換，以及校正等程式請求必須被標準化。在SOA中，程式是使用一組離散的服務建立的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用來控制這些服務的語言。WSBPEL目前也由OASIS負責。

　　管理

　　隨著企業服務的增長，所使用的服務和業務程式的數量也隨之增加，一個用來讓系統管理員管理所有執行在多相環境下的服務的管理系統就顯得尤為重要。WSDM（Web Services for Distributed Management）規定了任何根據WSDM實現的服務都可以由一個WSDM適應（WSDM-compliant）的管理方案來管理。

　　其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-COOrdination 和 WS-Transaction 標準中描述， 這些都是OASIS 的工作。

六、SOA 不是Web服務

　　在理解SOA和Web服務的關係上，經常發生混淆。根據2003年4月的Gartner報導，Yefim V. Natis就這個問題是這樣解釋的：“Web服務是技術規範，而SOA是設計原則。特別是Web服務中的WSDL，是一個SOA配套的介面定義標準：這是Web服務和SOA的根本聯絡。”從本質上來說，SOA是一種架構模式，而Web服務是利用一組標準實現的服務。Web服務是實現SOA的方式之一。用Web服務來實現SOA的好處是你可以實現一箇中立平臺，來獲得服務，而且隨著越來越多的軟體商支援越來越多的Web服務規範，你會取得更好的通用性。

七、面向服務架構（SOA）的優勢

　　SOA的概念並非什麼新東西，SOA不同於現有的分散式技術之處在於大多數軟體商接受它並有可以實現SOA的平臺或應用程式。SOA伴隨著無處不在的標準，為企業的現有資產或投資帶來了更好的重用性。SOA能夠在最新的和現有的應用之上建立應用；SOA能夠使客戶或服務消費者免予服務實現的改變所帶來的影響；SOA能夠升級單個服務或服務消費者而無需重寫整個應用，也無需保留已經不再適用於新需求的現有系統。總而言之，SOA以藉助現有的應用來組合產生新服務的敏捷方式，提供給企業更好的靈活性來構建應用程式和業務流程。

八、採用服務驅動型方法的企業體驗著以下業務和 IT 好處

      面向服務架構的業務好處

      效率： 將業務流程從 " 煙囪 " 狀的、重複的流程向維護成本較低的高度利用、共享服務應用轉變。 
      響應： 迅速適應和傳送關鍵業務服務來滿足市場需求，為客戶、僱員和合作夥伴更高水準的服務。 
      適應性： 更高效地轉入轉出讓整個業務變得複雜性和難度更小，達到節約時間和資金的目的。

      面向服務架構的 IT 好處

      複雜性降低： 基於標準的相容性，與點到點的整合相比降低了複雜性。 
      重用增加： 通過重用以前開發和部署的共享服務，實現了更有效的應用程式 / 專案開發和交付。 
      遺留整合： 用作可重用服務的遺留應用程式降低了維護和整合的成本。 
      如今的服務驅動型企業都在體驗著開發的高效率，服務的高可靠性和服務的高質量，以最大限度獲得業務機會所帶來的這些好處。

九、SOA在國際市場上反響強烈

      自2004年初業界推出SOA後，Bea、IBM、ORACLE、微軟等業界巨頭紛紛釋出自己的SOA戰略，建議使用者在進行企業IT建設時考慮SOA。

      ZapThink調研公司在最近發表的一份報告中預測，到2006年，基於SOA架構(面向服務的架構)的中介軟體產品將成為網路化商業系統的主要設計思路，其中70％的商業企業公司將使用SOA架構。

      按照Gartner的預測，到2008年，SOA將成為佔有絕對優勢的軟體工程實踐方法，它將結束傳統的整體軟體體系架構長達40年的統治地位。屆時，將有60％的商業公司在進行商業IT建設時會轉向SOA。

      IDC預測到 2007年，包括軟體、服務和硬體在內的SOA市場將達到210億美元，其中商業企業方面的市場將達到120億美元。

      綜上所述SOA已經成為大勢所趨，有著廣闊的市場空間和巨大的發展潛力；而在商業企業中的應用，將成為SOA未來發展的一大亮點。

      SOA已經引起國內商業企業的重視

      國內基於SOA架構Web服務目前還是集中在一些企業內部，而國內一些有影響的行業使用者正在搭建其核心業務系統，比如商業領域的流通行業和銷售行業的大集中正在起步。因此當商業企業需要更好地服務客戶，需要更好地與上、下游合作伙伴協同工作，並且自己內部的核心業務之間也需要協同工作時，基於SOA架構中介軟體產品就會為這類新的業務應用提供理想的底座，這種新的應用被稱作面向服務的業務應用。

      現在，很多商業企業都準備在2006年內開始規劃使用這些基於SOA架構的應用，可想而知，這些SOA架構的中介軟體產品將在兩年內迅速發展，並在五年內在整個IT行業內獲得廣泛應用。

      商業企業資訊化存在的問題

      商業企業資訊系統多數處於封閉執行的狀態，企業之間、企業與上游供應商、下游消費者之間資訊不對稱。商業企業之間無法形成協同效應。資訊系統即無法滿足消費者的綜合需求也無法達到企業間的商務協同自動化和智慧化的需求。資訊化的經濟效益難以有效發揮。同時資訊化標準不健全，如電子交換介面標準、業務流程協同標準；流通中的票證、單據格式標準；電子資料交換所必須的結構化資料標準等。

     採用傳統的系統架構技術和傳統的EAI和B2Bi技術則存在系統封閉、廠商依賴性強、耦合度高、重用性差，擴充套件性差、無法和上下游企業的系統建立統一的介面等問題。而採用SOA 技術則可以有效解決上述問題，由於SOA基於HTTP/SOAP/WSDL等開放式技術，對於特定廠商產品依賴性小；系統開放、互操作性強，可以建立統一的WEB服務用於和不同的上下游企業資訊系統實現供應鏈協同。由於SOA的鬆耦合特性、比較符合集團和各下屬機構的商業關係，業務流程整合和專案協調的阻力會有效降低。

      SOA以服務為基本單元，更加貼近於企業的商業活動，業務梳理和建模的複雜度會有效降低，重用性也會有效提高。另外採用SOA，企業IT系統所提供的服務會更容易擴充套件、組合和變更，符合該集團目前業務發展變化較快的特點，可以有效的降低該集團IT系統的長期擁有總體成本。我們將該集團公司作為一個試點，推進SOA技術的運用，來有效解決上述問題。

      “協同商務”的新經濟時代即將到來

      採用SOA技術最終將使得各個商業企業之間、各個關聯的經濟實體之間實現高效實時的聯接，使得整個產業鏈實現自動化的協同商務，將會有力的提高商業企業的應變能力，轉變現有的商業運作模式，轉變經濟增長的方式。SOA技術將促進資訊系統在商業企業貿易活動中的全面滲入和發展，對於簡單的貿易活動，將會由資訊系統自動化實現；對於複雜的貿易活動，資訊系統將會為企業管理人員提供足夠的決策資訊並可以高效的執行決策。SOA技術的應用將會全面提高商務的自動化、智慧化和實時化水平。

      採用SOA技術實現協同商務可以提高城市範圍內商流、物流、資金流和資訊流的執行效率，擴大北京市商業企業整體規模效益，加強商業企業的整體對外競爭力，拉動經濟增長，降低企業運營成本，推動城市流通訊息技術創新體系的建立，提高北京市流通現代化水平，促進城市管理現代化和城市社會經濟資訊化的程式。

      採用SOA技術可以將將物流企業、物業企業、商業企業、消費者整體整合在一起，對供應鏈關聯企業、物流企業以及網上支付體系、安全認證體系等環境建設具有明顯的帶動作用，有利於促進支撐環境協同發展。

      促進商業企業資訊化標準的制定，完善政府職能

      採用SOA技術為資訊系統的溝通提供了技術基礎，而隨著SOA在商業企業的應用，必將促進統一的商業領域電子商務行業標準的發展和制定，對促進國家商業企業資訊標準體系的建立和完善具有重要支撐作用。

      SOA技術為政府對商業經濟的執行狀況提供了實時監測和指導的技術可能性，將從根本上改變政府對社會經濟的管理方式。

      基於SOA的協同商務帶來的最直接的好處就是由於貿易範圍的空前擴大而產生的全球貿易活動的大幅度增加，因而提高了貿易環節中大多數角色的交易量，因此，全球範圍的經濟形勢將向一個良好的增長趨勢發展。它還可以擴大地方商業企業整體規模效益，加強商業企業的業務整合和商業協同效應，提高商業企業的整體對外競爭力，通過協同商務有效降低企業運營成本，推動城市流通訊息技術創新體系的建立，提高地方的流通現代化水平，促進城市管理現代化和城市社會經濟資訊化的程式。

      SOA在商業企業的應用可以將物流企業、物業企業、商業企業、消費者整體整合在一起，對供應鏈關聯企業、物流企業以及網上支付體系、安全認證體系等環境建設具有明顯的帶動作用，可推動資訊化各環節的全面應用與發展，有利於促進產業鏈和支撐環境協同發展，從而也創造了更多的就業機會和社會財富。

      資訊產業是知識經濟的核心和主要的推動力，而企業資訊化又是目前資訊產業中最具前途的發展趨勢，因此說企業資訊化的發展，必將直接或間接地推動知識經濟的浪潮。這種知識經濟有著大量的無形成本和高附加值，在東南亞金融危機的同時，高科技給美國帶來的是"高增長速度、高就業率、低通貨膨脹率"。這也是我國在宣傳知識經濟的熱潮中應注意的一個真正有價值的切入點。

      SOA技術由於其前所未有的資訊系統整合與自動協同能力，成為繼網際網路以來又一個革命性的技術，將會把目前基於WEB/網際網路的知識經濟推進到一個前所未有的新階段。

十、SOA 企業考慮事項

      服務驅動型企業在對客戶、合作伙伴和僱員的高效化服務方面得到了優化 -- 並加速了業務服務響應時間。然而，成為服務驅動型企業，需要的不僅僅是產品的部署。對實現服務驅動型架構感興趣的企業將希望能與一個有經驗的 SOA 提供商合作，它提供的服務可以保護企業在業務和 IT 方面的投入，他們考慮到了以下幾個方面：

 

 

      業務戰略： 組織需要明確驅動關鍵業務流程的業務戰略，它將用於成形 SOA 的框架。一旦識別出業務問題，就可以用一種一致的、可複用的方法對其進行定義，並實現解決方案。在這個關鍵的基礎階段，業務通常需要與一個擁有開發 SOA 業務戰略經驗、並能共享橫向和縱向市場最佳實踐的提供商進行合作。 
      體系結構： 為了解決方案快速和動態的交付，企業必須開發一種允許裝配元件和服務的體系結構框架。通過與有經驗的 SOA 提供商合作，企業可以獲得相應的參考案例，以快速搭建一個關注複用、避免 " 煙囪 " （ stovepipe ）式應用程式和 IT 資源 " 孤島 " 的體系結構。此外，有經驗的 SOA 提供商還可以幫助企業對專案的易管理性進行設計。

      構建模組： 不管是對體系結構還是對程式設計模型來說， SOA 都是是思考構建軟體模型的一種優秀方式。與 SOA 提供商進行合作能讓組織能夠識別可在 SOA 實現中使用或重用的構建模組程式碼、服務、應用程式和元件。與有經驗的 SOA 提供商進行合作還有一個好處，企業可以獲得對構造元件、企業域（ domains ）、服務和規範資料模型的參考經驗。

      專案和應用程式： SOA 創造了一種在更強大、更靈活的程式設計模式中搭建應用程式的新方法。與 SOA 提供商合作的企業可以更好地識別將被合併到 SOA 結構體系中的現存的和正在使用的應用程式。有經驗的 SOA 提供商還將引導專案基礎架構的搭建，並對正在進行中的專案提供有效的管理。 
成本和收益： 在一個 SOA 專案中，開發和維護成本將大大削減，。有經驗的 SOA 提供商可以幫助企業構造 SOA 基金模式，並構建 " 行動案例 " ，包括評估基礎構造成本和效益、實現專案的最佳投資回報（ ROI ）以及開發商務案例。

      組織和統轄： 組織需要為新的面向服務的 IT 組織識別角色和職責，並優化經驗集便於以後使用。有經驗的 SOA 提供商可以幫助企業實現這些目標，同時組織一個有效的設計 " 複用工廠 " （ Reuse Factory ），幫助定義統轄模式，並最終保證客戶滿意。