什么是SOA

        我們可能應該回答的第一個問題也是最基本的問題。什么是面向服務的體系結構(Service-Oriented Architecture, SOA)？這個問題的答案實際上涉及與開發相關的若干不同方面。

        SOA 是一種 IT 體系結構樣式，支持將您的業務作為鏈接服務或可重復業務任務進行集成，可在需要時通過網絡訪問這些服務和任務。這個網絡可能完全包含在您的公司總部內，也可能分散于各地且采用不同的技術，通過對來自紐約、倫敦和香港的服務進行組合，可讓最終用戶感覺似乎這些服務就安裝在本地桌面上一樣。需要時，這些服務可以將自己組裝為按需應用程序——即相互連接的服務提供者和使用者集合，彼此結合以完成特定業務任務，使您的業務能夠適應不斷變化的情況和需求（在有些情況下，甚至不需要人工干預）。

        這些服務是自包含的，具有定義良好的接口，允許這些服務的用戶——稱為客戶機或使用者——了解如何與其進行交互。從技術角度而言，SOA 帶來了“松散耦合”的應用程序組件，在此類組件中，代碼不一定綁定到某個特定的數據庫（甚至不一定綁定到特定的基礎設施）。正是得益于這個松散耦合特性，才使得能夠將服務組合為各種應用程序。這樣還大幅度提高了代碼重用率，可以在增加功能的同時減少工作量。由于服務和訪問服務的客戶機并未彼此綁定，因此可以完全替換用于處理訂單的服務，下訂單的客戶機-服務將永遠不會知道這個更改。所有交互都是基于“服務契約”進行的；服務契約用于定義服務提供者和客戶機之間的交互。通常，您將通過創建“基于消息的”系統來實現此目標。

        從業務的角度來說，面向服務的體系結構的重點在于開發能幫助您完成業務任務的技術，而不是通過技術約束來規定您的行動。例如，銷售過程（制造、運輸和收到貨款）可能會涉及數十個步驟和若干不同的數據庫和計算機系統。但就其實質而言，此過程包含一系列人工活動，例如：

銷售人員找到潛在客戶
客戶訂購產品
生產部門制造產品
生產部門發出產品
收款部門開具產品帳單
客戶支付產品貨款
面向服務的體系結構基于這些實際活動或業務服務進行組織，而不是形成公司所維護的不同的信息豎井 (Silo)。


        通過實現 SOA，可以帶來大量好處，包括以下各個方面：

更高的業務和 IT 一致性
基于組件的系統
松散耦合的組件和系統
基于網絡的基礎設施，允許分散于各地且采用不同技術的資源協同工作
動態構建的按需應用程序
更高的代碼重用率
更好地標準化整個企業內的流程
更易于集中企業控制

SOA體系結構

          Web 服務是用于實現 SOA 的最常見技術標準。不過，這并不是可以用于開發 SOA 的各個部分的唯一技術。很多 SOA——實際上是大部分——都涉及到集成遺留數據，此類數據包含在使用 MQSeries 和 Common Object Request Broker Architecture (CORBA) 等技術的系統中。其中的許多技術都已針對 SOA 進行了調整，不管有無 Web 服務包裝均可使用。事實上，可以僅使用 MQSeries、CORBA 甚至遠程過程調用（Remote Procedure Call，RPC）技術來實現 SOA。但 Web 服務正迅速成為用于支持 SOA 的事實標準。

SOA生命周期

         由于 SOA 涉及到業務的諸多方面，因此需要從一開始就對 SOA 項目進行細心的規劃和設計。您需要考慮項目的整個生命周期，從最初的階段到第一個實現，再一直到可能的修訂和重用。

         現在讓我們看看 SOA 生命周期，如圖 1 中所示。此部分概略說明了在生命周期的各個階段發生的事項，并詳細介紹了實現生命周期的各個步驟。



建模

        面向服務的體系結構項目的第一步幾乎和技術沒有任何關系，所有事項都與您的業務相關。請記住，面向服務的方法將業務所執行的活動視為服務，因此第一步是要確定這些業務活動或流程實際是什么。對您的業務體系結構進行記錄，這些記錄不僅可以用于規劃 SOA，還可以用于對實際業務流程進行優化。通過在編寫代碼前模擬或建模業務流程，您可以更深入地了解這些流程，從而有利于構建幫助執行這些流程的軟件。

        建模業務流程的程度將依賴于預期實現的深度。另外，這個程度還依賴于您在開發團隊中擔任的角色。如果您是企業架構師，您將會對實際的業務服務進行建模。如果您是軟件開發人員，您將可能對單個服務進行建模。

#p#副標題#e#

組裝

        對業務流程進行了建模和優化后，開發人員可以開始構建新的服務和/或重用現有的服務，然后對其進行組裝以形成組合應用程序，從而實現這些流程。在“建模”步驟中，您已經確定了需要何種類型的服務以及它們將訪問何種類型的數據。已經存在某種形式的實現這些服務或訪問該類數據所需的一些軟件。“組裝”步驟將要找到已經存在的功能，并為其添加服務支持。另外，還涉及到創建提供功能和訪問數據源所需的新服務，以便滿足您的 SOA 涉及的業務流程范圍內的需求。

部署

        進行了建模和組裝后，要將組成 SOA 的資產部署到安全的集成環境中。此環境本身提供專門化的服務，用于集成業務中涉及的人員、流程和信息。這種級別的集成可幫助確保將公司的所有主要元素連接到一起協同工作。此外，部署工作還需要滿足業務的性能和可用性需求，并提供足夠的靈活性，以便吸納新服務（并使舊服務退役），而不會對整個系統造成大的影響。

管理

        系統就位，一切都正常運行。 現在您可以對一切放手不管了，對嗎？不對。部署后，需要從 IT 和業務兩個角度對您的系統進行管理和監視。在“管理”步驟中收集的信息用于幫助實時地了解業務流程，從而能更好地進行業務決策，并將信息反饋回生命周期，以進行持續的流程改進工作。您將需要處理服務質量、安全、一般系統管理之類的問題。

        在本步驟中，您將監視和優化系統，發現和糾正效率低下的情況和存在的問題。由于 SOA 是一個迭代過程，因此，在此步驟中，您不僅要找出技術體系結構中有待改進之處，而且還要找出業務體系結構中有待改進之處。

        完成此步驟后就要開始新的“建模”步驟了。在“管理”步驟中收集的數據將用于重復整個 SOA 生命周期，再次進行整個過程

控制

        SOA 是一種集中系統；其中可以包含來自組織的不同部門的服務，甚至還能包含來自組織外的服務。如果沒有恰當的控制，這種系統很容易失控。

        控制對所有生命周期階段起到鞏固支撐作用，為整個 SOA 系統提供指導，并有助于了解系統全貌。它提供指導和控制，幫助服務提供者和使用者避免遇到意外情況。

SOA采用階段

         已經向您介紹了面向服務的體系結構和 SOA 開發的步驟，您現在可能已經確信應該開始構建自己的 SOA 了。如果您已經構建了基于 Web 的軟件服務，則已經達到了 SOA 采用的第一個階段。在此部分，我們將分析各個采用階段（從偶然構建服務到基于面向服務的體系結構原則對業務進行全面轉換），從而幫助您了解自己目前所處的位置以及確定需要實現的目標。

SOA 成熟階段

        您不大可能立即基于 SOA 進行全面的轉換。事實上，孤注一擲的方法會增加失敗的風險。應該轉而采用迭代的方法逐步通過各個采用階段，首先開發少數試點項目服務，然后逐步將您的 IT 系統更新為在 SOA 內工作的服務。我們將討論以下 SOA 采用階段：

構建服務
集成
轉換 IT
轉換業務

構建服務：具有特殊連接的根據需要提供的服務

        在 SOA 采用第一個階段，公司通常會很偶然地著手構建 SOA 服務。也就是說，由于需要解決特定的問題，他們選擇了面向服務的方法，而不使用傳統方法。在此階段，服務構建將更多地關注解決特定的問題，而不是對企業現有系統進行轉換。IT 部門將構建一些新服務，或許會將一些現有應用程序轉換為一組基于 Web 的服務。它們之間的鏈接將根據需要提供，而不是源自整個體系結構的要求。

集成：具有可靠連接的系統標準化服務接口

        發現了松散耦合體系結構的優勢、方便性和易維護性后，下一步就是利用這種靈活性通過組合服務來創建新的組合應用程序。例如，員工狀態服務可以與經理審批服務組合，以形成請假服務。這個過程可以采用自頂向下的方法，將重點放在最終結果和查找組件組成部分上。或者，可以采用自底向上的方法，將重點放在各個組成部分上，看看可以基于這些組成部分構建何種服務。他們之間的鏈接是預先計劃的且定義良好。

轉換 IT：組合可重用服務，利用多個來源的功能

        這個階段涉及到對您的信息技術基礎設施進行轉換，以便充分利用 SOA 的優勢。在此階段，所有系統將轉換為基于服務的應用程序，松散耦合是其中的規范做法，而不是例外。系統的所有組件都將根據 SOA 進行集成和連接，IT 系統的所有部分都在 SOA 內工作。

轉換業務：對服務進行動態的事件驅動的重新配置

        在 SOA 成熟的最后一個階段，業務與 SOA 完全集成，達到了這樣一個程度：所有合適的業務活動都被視為服務，可以最終在技術體系結構中對其進行建模、分析和實例化。達到此階段需要業務部門進行大量的工作和投入；不過，達到此階段后，業務將從面向服務的體系結構獲得最大的回報。