SOA

面向服務架構，它可以根據需求通過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件代理交互的人為依賴性。

SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、XML（標準通用標記語言的子集）/Web Service技術之後的自然延伸。

SOA將能夠幫助軟件工程師們站在一個新的高度理解企業級架構中的各種組件的開發、部署形式，它將幫助企業系統架構者更迅速、更可靠、更具重用性地架構整個業務系統。較之以往，以SOA架構的系統能夠更加從容地面對業務的急劇變化。

SOA系統是一種企業通用性架構。

這種具有中立的接口定義（沒有強制綁定到特定的實現上）的特徵稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用程序的每個服務的內部結構和實現逐漸地發生改變時，它能夠繼續存在。與之相反，緊耦合意味着應用程序的不同組件之間的接口與其功能和結構是緊密相連的，因而當需要對部分或整個應用程序進行某種形式的更改時，它們就顯得非常脆弱。

對松耦合的系統的需要來源於業務應用程序需要根據業務的需要變得更加靈活，以適應不斷變化的環境，比如經常改變的政策、業務級別、業務重點、合作伙伴關係、行業地位以及其他與業務有關的因素，這些因素甚至會影響業務的性質。我們稱能夠靈活地適應環境變化的業務為按需（On demand）業務，在按需業務中，一旦需要，就可以對完成或執行任務的方式進行必要的更改。

雖然面向服務的體系結構不是一個新鮮事物，但它卻是更傳統的面向對象的模型的替代模型，面向對象的模型是緊耦合的，已經存在二十多年了。雖然基於 SOA 的系統並不排除使用面向對象的設計來構建單個服務，但是其整體設計卻是面向服務的。由於它考慮到了系統內的對象，所以雖然 SOA 是基於對象的，但是作為一個整體，它卻不是面向對象的。不同之處在於接口本身。SOA 系統原型的一個典型例子是通用對象請求代理體系結構（Common Object Request Broker Architecture，CORBA），它已經出現很長時間了，其定義的概念與 SOA 相似。

然而， SOA 已經有所不同了，因為它依賴於一些更新的進展，這些進展是以可擴展標記語言（eXtensible Markup Language，XML）為基礎的。通過使用基於XML（標準通用標記語言的子集） 的語言（稱為 Web 服務描述語言（Web Services Definition Language，WSDL））來描述接口，服務已經轉到更動態且更靈活的接口系統中，非以前 CORBA 中的接口描述語言（Interface Definition Language，IDL）可比了。

Web 服務並不是實現 SOA 的唯一方式。前面剛講的 CORBA 是另一種方式，這樣就有了面向消息的中間件（Message-Oriented Middleware）系統，比如 IBM 的 MQseries。但是為了建立體系結構模型，您所需要的並不只是服務描述。您需要定義整個應用程序如何在服務之間執行其工作流。您尤其需要找到業務的操作和業務中所使用的軟件的操作之間的轉換點。因此，SOA 應該能夠將業務的商業流程與它們的技術流程聯繫起來，並且映射這兩者之間的關係。例如，給供應商付款的操作是商業流程，而更新您的零件數據庫，以包括進新供應的貨物卻是技術流程。因而，工作流還可以在 SOA 的設計中扮演重要的角色。

此外，動態業務的工作流不僅可以包括部門之間的操作，甚至還可以包括與不為您控制的外部合作伙伴進行的操作。因此，為了提高效率，您需要定義應該如何得知服務之間的關係的策略，這種策略常常採用服務級協定和操作策略的形式。

最後，所有這些都必須處於一個信任和可靠的環境之中，以同預期的一樣根據約定的條款來執行流程。因此，安全、信任和可靠的消息傳遞應該在任何 SOA 中都起着重要的作用。

我可以用面向服務的體系結構做什麼？

對 SOA 的需要來源於需要使業務 IT 系統變得更加靈活，以適應業務中的改變。通過允許強定義的關係和依然靈活的特定實現，IT 系統既可以利用現有系統的功能，又可以準備在以後做一些改變來滿足它們之間交互的需要。

下面舉一個具體的例子。一個服裝零售組織擁有 500 家國際連鎖店，它們常常需要更改設計來趕上時尚的潮流。這可能意味着不僅需要更改樣式和顏色，甚至還可能需要更換布料、製造商和可交付的產品。如果零售商和製造商之間的系統不兼容，那麼從一個供應商到另一個供應商的更換可能就是一個非常複雜的軟件流程。通過利用 WSDL 接口在操作方面的靈活性，每個公司都可以將它們的現有系統保持現狀，而僅僅匹配 WSDL 接口並制訂新的服務級協定，這樣就不必完全重構它們的軟件系統了。這是業務的水平改變，也就是説，它們改變的是合作伙伴，而所有的業務操作基本上都保持不變。這裏，業務接口可以作少許改變，而內部操作卻不需要改變，之所以這樣做，僅僅是為了能夠與外部合作伙伴一起工作。

另一種形式是內部改變，在這種改變中，零售組織決定它還將把連鎖零售商店內的一些地方出租給專賣流行衣服的小商店，這可以看作是採用店中店（store-in-store）的業務模型。這裏，雖然公司的大多數業務操作都保持不變，但是它們需要新的內部軟件來處理這樣的出租安排。儘管在內部軟件系統可以承受全面的檢修，但是它們需要在這樣做的同時不會對與現有的供應商系統的交互產生大的影響。在這種情況下，SOA 模型保持原封不動，而內部實現卻發生了變化。雖然可以將新的方面添加到 SOA 模型中來加入新的出租安排的職責，但是正常的零售管理系統繼續如往常一樣。

為了延續內部改變的觀念，IT 經理可能會發現，軟件的新配置還可以以另外的一種方式加以使用，比如出租粘貼海報的地方以供廣告之用。這裏，新的業務提議是通過在新的設計中重用靈活的 SOA 模型得出的。這是來自 SOA 模型的新成果，並且還是一個新的機會，而這樣的新機會在以前可能是不會有的。

垂直改變也是可能的，在這種改變中，零售商從銷售他們自己的服裝完全轉變到專門通過店中店模型出租地方。如果垂直改變完全從最底層開始的話，就會帶來 SOA 模型結構的顯著改變，與之一起改變的還可能有新的系統、軟件、流程以及關係。在這種情況下，SOA 模型的好處是它從業務操作和流程的角度考慮問題而不是從應用程序和程序的角度考慮問題，這使得業務管理可以根據業務的操作清楚地確定什麼需要添加、修改或刪除。然後可以將軟件系統構造為適合業務處理的方式，而不是在許多現有的軟件平台上常常看到的其他方式。

正如您可以看到的，在這裏，改變和 SOA 系統適應改變的能力是最重要的部分。對於開發人員來説，這樣的改變無論是在他們工作的範圍之內還是在他們工作的範圍之外都有可能發生，這取決於是否有改變需要知道接口是如何定義的以及它們相互之間如何進行交互。與開發人員不同的是，架構師的作用就是引起對 SOA 模型大的改變。這種分工，就是讓開發人員集中精力於創建作為服務定義的功能單元，而讓架構師和建模人員集中精力於如何將這些單元適當地組織在一起，它已經有十多年的歷史了，通常用統一建模語言（Unified Modeling Language，UML），並且描述成模型驅動的體系結構（Model-Driven Architecture，MDA）。

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

SOA的實施具有幾個鮮明的基本特徵。實施SOA的關鍵目標是實現企業IT資產的最大化作用。要實現這一目標，就要在實施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的一些關鍵元素有安全需求（例如認證和授權），可靠通信（譯註：可靠消息是指，確保消息“僅且僅僅”發送一次，從而過濾重複信息。），以及誰能調用服務的策略。

^[2]  隨着全球信息化的浪潮，信息化產業不斷髮展、延伸，已經深入了眾多的企業及個人，SOA系統架構的出現，將給信息化帶來一場新的革命。 ^[3] 

縱觀信息化建設與應用的歷程，儘管出現過XML（標準通用標記語言的子集）、Unicode、UML等眾多信息標準，但是許多異構系統之間的數據源仍然使用各自獨立的數據格式、元數據以及元模型，這是信息產品提供商一直以來形成的習慣。各個相對獨立的源數據集成一起，往往通過構建一定的數據獲取與計算程序來實現，這樣的做法需要花費大量工作。信息孤島大量存在的事實，使信息化建設的ROI（投資回報率）大大降低，ETL成為集中這些異構數據的有效工具。 ETL常用於從源系統中提取數據，將數據轉換為與目標系統相兼容的格式，然後將其裝載到目標系統中。數據經過獲取、轉換、裝載後，要產生應用價值，還需另外的數據展現工具予以實現，如此複雜的數據應用過程，必定產生高昂的應用成本。

結構化的數據管理尚可通過以上方法，予以實現其集成應用。在非結構化的內容方面，這些具有挑戰性的問題令人生畏。內容管理的應用方案基於不同的信息化應用系統，而且大部分是縱向的以組織部門為界限的。在內容管理市場中，經常使用來自不同廠商的產品來提供這些解決方案。即使是同一個廠商的產品，相互之間的功能也是經常重疊，並且無法集成。

隨着信息化建設的深入，不同應用系統之間的功能界限已趨於模糊。同時企業資源計劃系統和協同商務系統，又需要商業智能的分析展現數據提供用户操作依據。

在激烈競爭且多變的市場環境下，企業的管理模式很難固化，應用傳統的信息化軟件，當企業要做出一些改動時需要面對巨大的挑戰。

Teradata大中華區服務部總經理辛兒倫介紹説，從上世紀60年代應用於主機的大型主機系統，到80年代應用於PC的CS 架構，一直到90年代互聯網的出現，系統越來越朝小型化和分佈式發展。2000年WebService出現後，SOA被譽為下一代Web服務的基礎框架，已經成為計算機信息領域的一個新的發展方向。

SOA的出現給傳統的信息化產業帶來新的概念，不再是各自獨立的架構形式，能夠輕鬆的互相聯繫組合共享信息。

可複用以往的信息化軟件。基於SOA的協同軟件提供了應用集成功能，能夠將ERP、CRM、HR等異構系統的數據集成。

鬆散耦合方式，只要充分了解業務的進程，就可以不用編寫一行代碼，通過流程圖實現一套我們自己的信息系統。就像已經給你準備好了磚瓦和水泥，只需要想好蓋什麼樣的房子就可以輕鬆的蓋起。加快開發速度，並且減少了開發和維護的費用。軟件將所有的管理提煉成表單和流程，以記錄管理的內容，指定過程的流轉方向。

更簡便的信息和數據集成。信息集成功能可以將散落在廣域網和局域網上的文檔、目錄、網頁輕鬆集成，加強了信息的協同相關性。同時，複雜、成本高昂的數據集成，也變成了可以簡單且低成本實現的參數設定。創建了完全集成的信息化應用新領域。

在具體的功能實現上，SOA協同軟件所實現的功能包括了知識管理、流程管理、人事管理、客户管理、項目管理、應用集成等，從部門角度看涉及了行政、後勤、營銷、物流、生產等。從應用思想上看，SOA協同軟件中的信息管理功能，全面兼顧了貫穿整個企業組織的信息化軟硬件投入。儘管各種IT技術可以用於不同的用途，但是信息管理並沒有任意地將信息分為結構化或者非結構化的部分，因此ERP等結構化管理系統並不是信息化建設的全部；同時，信息管理也沒有將信息化解決方案劃分為部門的視圖，因此僅僅以部分為界限去構建軟件應用功能的思想未必是不可撼動的。基於SOA的協同軟件與 ERP、CRM等傳統應用軟件相比，關鍵的不同在於它可以在合適的時間、合適的地點並且有正當理由向需要它提供服務的任何用户提供服務。

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

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

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

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

要運行，管理SOA應用程序，企業需要SOA基礎，這是SOA平台的一個部分。SOA基礎必須支持所有的相關標準，和需要的運行時容器。圖4所示的是一個典型的SOA基礎結構。

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服務的關係上，經常發生混淆。根據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以藉助現有的應用來組合產生新服務的敏捷方式，提供給企業更好的靈活性來構建應用程序和業務流程。

A. 平衡最初的舊系統投資(Leverage initial investment)：

組織過去所投資的系統、軟硬體，如果能再利用等於賦予其新的價值，這也替組織降低成本並增加競爭力。

B. 基礎建設的便利性(Infrastructure Commoditization)：

讓所有的應用程式能相互溝通(互通性)。

C. 快速的接近市場(Faster time-to-market)：

服務的重複使用(再利用)，來縮短過去的組織流程，更快速的提供服務來接近市場。

D. 減少支出(Reduce Cost)：

服務的重複使用，可降低開發成本。因為開發新系統的成本，大部份比更新舊有系統來的花費大。

E. 減低風險(Risk mitigation)：

開發新系統的風險遠大於更新舊系統。

F. 持續改善商業流程的循環(Continuous improvement cycle for business process)

G. 中心流程處理(Process-centric processing)

一，SOA可通過互聯網服務器發佈，從而突破企業內網的限制，實現與供應鏈上下游夥伴業務的緊密結合。通過SOA架構，企業可以與其業務夥伴直接建立新渠道，建立新夥伴的成本得以降低。

二，SOA與平台無關，減少了業務應用實現的限制。要將企業的業務夥伴整合到企業的“大”業務系統中，對其業務夥伴具體採用什麼技術沒有限制。

三， SOA具有低耦合性特點，業務夥伴對整個業務系統的影響較低。在企業與各業務夥伴關係不斷髮生變化的情況下，節省的費用會越來越多。

四， SOA具有可按模塊分階段進行實施的優勢。可以成功一步再做下一步，將實施對企業的衝擊減少到最小。

五， SOA的實施可能並不具有成本顯著性。這要分三種情況加以討論：

(1) 當企業從零開始構建業務系統時，採用SOA架構與不採用SOA架構成本可看做是相同的。

(2) 當企業業務發展或發生企業重組等變化而原有系統不能滿足需要，而需要重構業務系統時，採用SOA架構與不採用SOA架構成本可看做是相同的。

(3) 當企業業務發生緩慢變化並可預見到將來需要重構業務系統時，由於可以按模塊分階段逐步實施SOA以適應變化的需要，這樣企業不需一下投入一大筆經費進行系統改造，而是根據企業業務發展情況和資金情況逐步投入，緩解了信息投入的壓力。

服務導向架構並不是一種全新的解決方案；相反，SOA是技術與架構的自然進化。系統架構一直在不斷進步，與商業保持高度一致。系統設計師與商家很早就認識到將技術與商業流程相協調的重要性，包括充分應用併合理化技術資源，以及為商業提供更好的支持。

SOA也在一定程度上源於早已有之的企業架構理論。企業架構對技術進行評估，但是更重要的是，它關注整個企業和全部的商業流程並提供了做出技術決策的背景信息。SOA工具則融合了互聯網技術，如HTTP和XML，以及綜合技術，如消息總線、轉譯技術和連接技術。 ^[4]