面向服務的架構（SOA）是一個元件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。

SOA五種基本架構模式

目前，面向服務的架構（SOA）已成為連線複雜服務系統的主要解決方案。雖然SOA的理論很容易理解，但要部署一個設計良好、真正實用的SOA系統卻非常困難。本文試圖通過解析SOA的模式，提供與架構相關的技術指導，進而對以上問題提供詳盡的的解答。

在本文中，一共提到了五種模式。表1列出了這五種模式以及各自相關的問題。

表1：模式列表

其中服務託管（ServiceHost）與主動式服務（Active Service）是兩種最常見的模式——即使服務的使用範圍很小，通常也會使用這兩種模式。這兩種模式的主要內容都與解決服務相關問題有關，即與具體的服務部署有關（見圖1）。

模式一：服務託管

服務託管是我們要討論的第一個模式。它是最基本的模式，或者至少是最基本的模式之一。服務託管模式主要負責執行著服務例項的環境，以及與此相關的路由任務。

問題

隨便選一個服務，任何服務都可以，別告訴我具體是哪個：）。你可以找到一些處理傳入的訊息或請求的監聽程式碼；你可以找到一些連線元件的程式碼，還有一些初始化並激活這個服務的程式碼；或許你還能找到一些能適當地配置服務的程式碼。有沒有覺得我很厲害？實際上，你可以在服務裡找到上面的所有程式碼，至少是大部分。

有許多工作都是重複性的、常見的。我們可以好好利用這一點。

如何使服務能夠適應不同的配置，避免設定監聽器、元件連線等重複性常規工作？

第一個辦法（實際上也不是什麼辦法），就是為每一個服務重寫所有的連線程式碼。很顯然，這不是個好方法，因為重寫的次數越多，就越可能產生一些缺陷。並且，對於維護來說，許多重複的程式碼產生的問題更為嚴重。在維護的時候，你不僅要確保每一個服務中的缺陷都已經得到修正，還要保證沒有任何疏漏、所有的服務都已經同步更新。

另一個相對較合理的辦法，就是建立一個共同任務庫，所有的服務都通過API與庫相連線。這樣確實會有所幫助，但是為了充分利用庫的功能，你仍然需要編寫連線程式碼。

還有一個辦法是利用繼承建立一個超類，用超類實現共同的功能，然後讓各個服務繼承這個類。然而利用繼承也有問題，因為服務的功能通常無法通過一個單獨的類獲得很好的實現。此外，不同的服務所處理的業務也完全不同——否則它們就是一樣的服務了。因此，也無法讓把這些服務歸於同一類結構。

繼承幾乎已經可以解決我們面臨的問題——因為我們只需要寫一次程式碼，只有不同的服務才需要定製。如果想不用繼承得到相同的結果，我們就得使用框架。

解決方案

建立一個通用的服務託管元件，把它當作服務的容器或者框架。容器是可以配置的，並執行服務連線、安裝等工作（見圖2）。

服務託管就像是一個肩負著許多職責的迷你框架。它的第一個職責就是正確地示例服務所包含的元件或類。服務託管還負責讀取配置資訊，比如，它可以讀取服務消費者用來連線服務的埠。其它職責包括建立服務環境，比如在終端建立監聽器。最後，服務託管可以負責連線元件——終端監聽器上的協議繫結或者建立一個與資料庫的連線。所有這些職責的共同特徵是它們都與服務的例項化和初始化有關，並且正如我們在問題部分所描述的一樣，你很可能會在多個服務中遇到同樣的情況。前面已經提到，服務託管是一個框架，與第二種方法中描述的庫的概念有所不同。庫是一個實用類或方法集，你可以呼叫它們來獲取特定的功能。而框架則包含了一些功能或流程，並通過呼叫程式碼來擴充套件流程或將其轉變為具體的流程。這就是“控制反轉（Inversion of Control）”原理。這種原理已經在面向物件的框架中獲得廣泛的應用，比如Spring或Spring.NET、Picocontainers等。

服務託管模式與其它方法相比有許多優勢。其中一個優勢前面已經提到——即服務託管是一種框架，它可以呼叫程式碼來改善效能，而無需你親自進行編排。另一個優勢是它能更好地實現開放/封閉原則（OCP）。OCP原則認為類應該是可以擴充套件的，但是不能修改；而框架的概念正是這個原則的具體表現。

一個服務託管可以託管多個服務——雖然這種情況可能並不常見。我們曾經構建了一個系統，使用的方案規模小到一臺計算機即可應付。這真的很方便。如果換另一種方案，那麼服務可能就要擴充套件到多臺計算機上，這樣你就得應用多個服務託管例項，各個主機託管服務的一部分，而不是整個服務。

服務託管模式已得到了技術供應商的廣泛應用，這一點我們可以在下面的技術相關部分看到。

技術相關

這一部分我們將簡單地瞭解一下利用當前的技術實現這個模式的意義。

服務託管是一種基本的SOA架構模式，因此大部分技術都支援這種模式。JAX-WS和Windows Communication Foundation都能用標記語言（XML）進行配置，並使用Web伺服器（比如Servlet引擎或IIS）完成大部分的連線工作。

Windows Communication Foundation還提供了一個稱為ServiceHost的類。Microsoft的說明文件是這樣解釋ServiceHost的：“如果你不使用Internet Information Services (IIS)Windows Activation Services (WAS)提供服務，就用ServiceHost類來配置並提供服務。IIS和WAS都能與ServiceHost進行互動。”從根本上說，其內建WCF對ServiceHost的執行與我們所描述的服務託管模式是基本一致的。

如果你要自己實現一個服務託管模式，那麼你可以從Spring（或者Spring.NET）、Picocontainers等輕量級容器中學習如何進行連線和例項化。這方面的技術實現並不多，因為服務託管模式實際上是一種相對簡單的模式。

輕量級容器與依賴性注射

Spring和其它一些框架被稱為“輕量級容器”。這些“輕量級容器”的優點是它們提高了方案的鬆耦合性和可測試性。這種優點是通過一種非SOA模式——依賴性注射模式（Dependency Injection Pattern）實現的。依賴性注射，正如名字所示，指一個類通過第三方“彙編程式”提供所需的介面。通過依賴性注射技術，類不再依賴於特殊的實現，而只依賴於介面和抽象類。這使可測試性獲得了提高，因為你可以使用樁或模擬來為類提供虛擬環境。這同時也提高了靈活性，因為只要它們之間的關係不變，你就可以輕鬆地改變具體的實現方式。

服務託管模式是一種簡單而有效、並且已經獲得廣泛應用的的模式。

質量屬性場景

這一部分是從需求的角度討論使用模式的架構效益。大多架構需求是根據使用場景表現的質量屬性（可擴充套件性、靈活性、效能等）來描述的。這些場景也可供其它可以應用模式的情況參考。

使用服務託管模式的主要原因是重用性。由於多個服務需要使用的相同任務只需寫一遍程式碼，因此重用性也隨之提高。這還能帶來另一個好處，就是可靠性的提高，因為你只需要除錯一次。另外，服務託管模式還能提供可移植性的質量屬性。由於這個模式的分離問題的效應，因此可移植性也得到了增強。另外由於可以使用標記語言配置服務環境，可移植性又會得到進一步提高。

下面的表2列出了幾個場景，可以給你慮使用服務託管模式的理由。

一旦配置好並開始執行服務，你就得決定服務應該是被動式的（應請求喚醒）或是主動式的（無需等待服務消費者啟用，並做一些零工，比如顯示狀態或處理超時）。正如名字所示，主動式服務模式下，服務是主動執行的，而不是被動的。

模式二：主動式服務

服務的自治性（Autonomous）很重要。自治效能夠提高服務之間的鬆耦合性，並使整體方案產生更好的靈活性。但是自治性服務有什麼實際意義呢？有人說，自治性意味著在不同的服務上工作的團隊的自治性。這種定義表示，由於各個服務之間只有契約上的關係，因此服務之間幾乎沒有依賴性。這意味著各團隊可以獨立工作，專心於自己的服務，而不會互相絆腳。雖然這是一個不錯的“功能”，但是同時還有一個更有價值（比如說商業價值）的定義，就是服務是非常自主（self-sufficient ）的。下面我們通過一個示例來解釋這個定義。

問題

有一家報紙訂閱代理機構（比如Ebsco或Blackwell），它需要為客戶建立一份申請。申請服務的一項內容是產生一份形式上的清單。要得到這樣的一份清單，該機構必須同時有給顧客的折扣率和從各出版商處能夠得到的折扣，這樣才能計算出這份申請是否有利潤。圖3就是這樣一個流程的簡單示意圖。

在場景示例中，申請服務需要等待另外兩個服務的資訊。顧客服務是內部服務，與申請服務是同一系統；但出版商的折扣服務卻很可能是外部服務——如果出版商的系統沒有聯機，那麼會對我們的申請服務造成什麼影響呢？會造成申請服務無法使用。即使我們花費了天文數字的資金來保證申請服務的容錯性，但現在的問題是完全無法使用，因為申請服務是與外部的出版商的服務隨時耦合的。因此申請服務不具有真正的自治性。

如何提高服務的獨立性以及如何處理暫時性的問題？

上面所描述的問題表明，僅僅根據請求喚醒的被動式服務是有問題的，因為服務可能無法滿足依賴於外部服務的契約條件（或服務等級協議）。

一個解決辦法是讓服務對先前的結果進行快取，但這隻能解決部分問題，因為這樣做資料就無法得到及時更新，並且時而也會有快取失效的情況發生，這時仍然需要連線其它服務。這種方法還有另一個問題，那就是如果傳入的請求過多，在處理一個請求的時候，其它的請求就會處於“等待”的狀態，這樣又會產生資源問題，因為而這些“等待”的請求都需要外部服務的輸入。

即使我們解決了前面的快取問題，我們仍然得處理其它的暫時性事件。暫時性事件包括重複發生，或者與時間相關的一次性事件。比如，生成每月賬單或釋出股票資料或任何其它重複性的報告都是暫時性事件。一種解決方法是從外部編排服務。這種方法的問題是你得將服務的業務邏輯具體化。但是請記住，封閉的服務層是應用SOA的一個重要原因。因此我們得另尋解決方案。

解決方案

要使服務成為主動式服務至少需要一個主動類（Active Class），這個類可以在邊界上，或者服務上，或者兩者都有。然後讓這個主動類處理暫時性問題和管理自治性。

主動服務模式意味著在服務層上執行“主動類”（見圖4）。在Official UML定義中，“主動類”是指“不需要呼叫方法即可啟動自身行為的物件。”這定義對服務也適用。就是說，服務可以有獨立的執行緒來處理迴圈類事件，比如每月賬單或釋出狀態。主動式服務也可以監控自身的情況，處理超時，甚至可以用來處理請求。

那麼，怎麼使用主動服務模式來解決我們上面提到的問題呢？就像帕特·森田在《空手道小子》裡扮演的宮城先生所說，“最好的防守就是不要在場。”如果你要避免等待另一個服務這種事情發生，那麼最好的辦法就是不要等待；你可以主動地、週期性地從其它服務獲取資料，更新你的快取。你還能給其它服務減少類似的麻煩，並預先發布自己的變化狀態。表面上看起來，快取資料可能會引起資料重複的問題，但實際上這種情況是不會發生的（詳見下面標註）。

快取與資料重複問題

我想有些人，特別是那些學過資料庫的人，看到我說從遠端服務主動獲取快取資料的時候，肯定會從椅子上蹦起來質疑我遠端資料複製的動機，認為我是不是大腦出了什麼問題。然而，在我看來，這已經不是相同的資料了。快取在服務上的資料是服務的資料，可以用來計算、處理甚至根據服務需要進行修改。當然，你也必須明白快取資料的服務並不是負責控制資料的。

一個帶有計時器的執行緒基本上足夠應付其它暫時性事件了（如果事件少，你可以為每一個事件安排一個定時器；或者定時喚醒，檢查哪些事件需要處理並處理它們）。

使用邊界元件的執行緒處理契約相關的暫時性問題是一個好辦法（比如，及時釋出狀態、超時等），而服務執行緒則可以處理純業務類的問題，比如傳送每月賬單或者處理傳入的訊息佇列。

現在我們看一下如何使用主動服務模式重灌安排圖3的情況。簡單重複一下，圖3是一個申請服務的流程，它需要從外部的釋出服務獲取外部資料，並同顧客服務一起為顧客生成一份清單（見圖5）。現在我們讓申請服務主動地定期獲取折扣資訊並快取結果，這樣當收到產生一份清單的請求時，申請服務就可以即時計算折扣，更快地返回結果，並且（在處理清單請求時）無需依賴外部服務。使用了主動式服務，請求服務便與其它服務分離了。

主動服務模式差不多就是一種理念，沒有太多的技術成分。

技術相關

這一部分討論如何使用SOA相關技術實現這個模式；然而，因為這裡並沒有太多的技術成分，因此我們也只是簡單的說明一下。

主動服務模式的技術理念就是在有特殊功能的服務或邊界元件上使用主動執行緒。從本質上說，主動服務模式取決於執行緒技術。你可以用任何語言實現這種執行緒技術。關鍵在於，你要用這個執行緒做什麼。在上面的段落裡我們用了從其它服務快取資料並處理重複性報告的例子。

下面的問題就是什麼時候應該使用主動服務模式？我們來看一下動機。

質量屬性場景

這一部分是從需求的角度討論使用模式的架構效益。大多架構需求是根據使用場景表現的質量屬性（可擴充套件性、靈活性、效能等）來描述的。這些場景也可供其它可以應用模式的情況參考。

主動服務是一些其它模式（比如前面提到的分離呼叫和blogjecting watchdog）的先決條件，而這些模式可以幫助處理質量屬性問題，比如可靠性與可用性。並且，即使是單獨使用主動服務模式也能滿足許多質量屬性要求。

通過預先準備的資料，主動式服務可以減少一些潛在的問題。它可以解決期限的問題，因為它能保證服務在期限之前完成任務（比如按時生成每月賬單）。另外，主動服務模式還有可用性的優勢，因為從其它服務查詢並快取資料意味著減少了服務的可用性對其它服務的依賴性。

下面的表3列出了一些主動服務模式可以發揮作用的場景。

模式三：事務處理服務模式

服務構建的另一個重要屬性是：怎麼處理從邊界元件或服務中得到的資訊？事務處理服務模式（Transactional Service Pattern）可以解決這種問題，並且還能解決可靠性問題。

可以把SOA活動簡化為服務收到服務消費者要求做某件任務的請求，服務處理請求（可能還會請求其它服務一起做這件任務），然後迴應發起請求的服務消費者。圖6顯示了這樣的一個商業系統中的活動場景。前臺與訂購服務進行對話。訂購服務登記訂單，把訂單傳送到供應商，然後通知賬單服務。這些事件處理完成後，訂購服務向電子商務前臺應用傳送一條確認資訊。這一切看起來井然有序，但萬一中途發生錯誤怎麼辦？

問題

比如說，訂購服務在確認訂單與處理的中途產生故障的話，也就是圖6中的步驟1.1與2.0之間，會出現什麼情況呢？我想顧客應該會坐在舒適的沙發上，喝著茶水，等著郵遞員把她訂購的東西送過來。但是雖然她在等，訂單卻已經消失得無影無蹤了。

那麼如果服務是在報賬服務處理訂單之間出現故障呢，也就是步驟2.3之前。這種情況下，訂購同樣會消失——除非訂購系統不等待報賬便處理了訂單，這幾乎是不可能的。更糟糕的是，我們已經向供應商傳送了訂單，供應商已經把賬單發了過來，並且貨物也隨之送了過來，我們還得給貨物準備庫存。

訊息處理過程處處都可能出現前面提到的這些情況。我們可以安慰自己，說大部分情況下系統會正常工作。然而就像莫非定律所說——我們的服務最終必然會在那宗百萬美元的訂單上垮掉。現在的問題是：

如何讓服務可靠地處理請求？

其中一個方案是把這個責任推給服務消費者。在上面提到的場景中，這意味著如果消費者沒有在步驟2.5中收到訂單確認資訊，那麼這個訂單就是失敗的。然而首先，這個方法並不健全，並會降低服務的自治性——服務無法控制消費者，也無法處理一些其它問題。另外，這隻能解決部分問題——那些與服務消費者有關的問題。服務之間的相互作用呢？比如在上面的訂購場景中提到的——即使在步驟2.1向供應商傳送訂單以後，仍然可能出現問題。

第二個辦法是同步處理訊息。同步操作在效能上會產生很大的問題，特別是當服務需要與外部服務、系統或資源互動的時候，因為服務在返回結果之前，整個流程都要等待第三方的迴應。更主要的是，實際上這並沒有真正解決問題。如果服務在流程中出現故障了，我們無法確認是哪裡的故障。我們只知道訊息傳輸出現了故障，而要確定故障環節，則需要服務消費者的幫忙。

表面看來，如果服務能夠使用永久性地儲存介質（比如到資料庫）就可以解決這個問題。我覺得這個方向是不錯；但是，這還不夠。因為如果服務在儲存狀態之前出現了故障，傳入的訊息仍然會丟失，並且服務對此一無所知。還應該注意到，如果使用永久性儲存介質，我們雖然可以追蹤到在過程的哪一環節出現故障，但是我們無法確定訊息是否已經發送到了其它服務。

要解決這些問題，以及整體的可靠性問題，我們需要事務處理服務。

解決方案

使用事務處理服務模式，一次性處理從讀取訊息到響應的整個流程。

事務處理服務模式的主要元件是訊息泵（message pump），見圖7。訊息泵監聽著終端或邊界傳入的訊息。如果接收到訊息，訊息泵就開始一個事務操作，讀取訊息，把訊息傳送到其它元件/類進行處理，處理後，結束事務操作（完成或失敗）。如果可以以事務處理的方式傳送請求或迴應，就可以把這些操作放入到事務處理中，否則你就需要為操作失敗準備補償邏輯。

使用事務處理程式設計模型的好處是它要麼是純語義學的，要麼完全不是，因此不存在邊界效應。由於事務的四個屬性（ACID），所有的操作和訊息都一定會被完全處理完、或完全沒有被處理，所以如果有訊息離開了服務，那麼觸發這個行為的傳入訊息肯定是被完全處理過了。

ACID事務

一個事務是一個完整的任務單位。一個任務單位如果滿足ACID所定義的四個屬性，那麼它就是一個事務。

* 原子：事務中的所有事件都是以一個原子單位的形式發生的（atomic unit）。這些事件要麼全部發生，要麼全部不發生。

* 一致：不管事務完成與否，事務的資源必需在整個過程保持一致。

* 隔離：所有外部的觀察者（不參與事務處理）都不能看到內部的狀態。只能在事務處理開始前或完成後檢視狀態。

* 持久：事務處理過程中做出的改動儲存在永久性儲存介質中，因此即使系統重啟後也不會丟失。

當然，你要選擇事務服務模式的重要因素肯定還是效能。由於需要準備、為了永續性而做的輸入輸出和鎖定管理等，事務通常會比較慢。我一般會預告確定目標場景並進行測試，以確保能夠得到一個足夠好的方案。

實現事務處理服務模式的一種方法是為所有服務間的訊息使用事務訊息傳輸。事務訊息傳輸（transactional message transport）使得模式的實現變得非常簡單——只要按照前面提到的步驟來就可以了：開始事務、讀取、處理、傳送、完成。另外一種方法，也是更常見的一種方法，是在接收到訊息後把訊息放到事務處理資源中（比如佇列或資料庫），然後向服務訊息者傳送一條確認訊息。但是這種情況下最初的訊息不包括在事務處理中，因此你要準備應付服務消費者的多次訊息傳送。比如，服務消費者沒有收到確認訊息，於是“又”傳送了一條請求訊息提取100萬美元。

圖8是圖6的事務處理服務模式。簡單重複一下，該場景是一個關於電子商務的前臺訂購服務。訂購服務登記訂單，把訂單傳送到供應商，然後通知賬單服務。這些事件處理完成後，訂購服務向電子商務前臺應用傳送一條確認資訊。

在圖8中，使用事務處理服務模式，步驟2.0到2.5（訂購服務的行為）處於同一事務中。這意味著如果你因為故障或其它意外沒有處理下訂單的訊息，那麼服務就不會發出任何訊息。這是個很讓人開心的訊息，因為我們不用再寫複雜的補償邏輯了。這裡有一個小問題，那就是如果訂購服務在步驟1.0到1.2之間出現故障的話會有什麼情況。該場景不是100%安全的；它有很小的機率在我們把訊息放到佇列等待處理的時候出現故障，從而沒有傳送確認訊息。這可能導致重複接收到同樣的請求。一個在服務這邊處理重複訊息的辦法是在服務啟動時檢視訊息佇列並對所有訊息傳送確認訊息，這種情況下，服務消費者可能會收到多於一條的確認訊息。

請注意，在這個示例中，只能在賬單處理過程僅僅產生一個發貨單的情況下使用單獨的事件。如果賬單服務還需要處理信用卡，並且訂購服務需要得到確認資訊才能繼續的話，就不能使用單獨的事件了。當不能使用單獨的事件的時候，需要把過程分成較小的事務，這時整個過程就被稱為連續操作。需要把流程分為幾個較小的事務的另一個條件是看服務是否是分散式的。

必須注意把事務的範圍定到終端/邊界和外部的訊息傳送者是不一樣的。雖然從表面看來，這個區別不是很重要；但是實際上它確實很重要——因為前者是增強服務的可靠性而後者是提高系統的耦合性並會給你帶來讓人頭痛的問題。如果你把事務擴充套件到服務之外，那將是非常大的轉變，因為其它的服務是執行在自己的機器的，有它自己的服務等級協議等等。把內部資源暴露到服務信任協議之外是很冒險的做法。

現在我們看看如何實現事務處理服務。

技術相關

這一部分我們將簡單的瞭解一下利用當前的技術實現這個模式的意義。

如果訊息傳輸是對事務敏感的，那麼實現事務處理服務就容易得多。大部分ESB（比如Sonic ESB和Iona Artix）都是事務敏感的，另外還有訊息中介軟體（比如MSMQ）、所有JMS實現以及SQL Server Service Broker。如果你在使用事務訊息傳輸，你可以通過僅僅在資源上建立一個事務來實現事務處理服務模式。如果，比如你還要在同一任務單元中進行更新資料庫的操作，你可能還需要分散式的事務處理。然後只要從ESB或訊息中介軟體讀取訊息、處理、傳送響應或其它處理過程生成的訊息到外部或目標佇列，最後一切順利的話結束事務。

要注意通常要在事務處理中用到多項資源，比如，一個訊息佇列和一個用於儲存訊息處理後的任何狀態變化的資料庫，這時你應該使用分散式事務處理。在.NET 2.0及以上版本中，如果有需要的話，你可以通過開啟一個TransactionScope物件（定義於System.Transactions）顯式地過渡到分散式事務處理。

如果訊息傳輸不支援事務，只在你把訊息儲存到了事務儲存庫（比如佇列或表）後有確認資訊。你仍然有在沒有得到服務消費者的確認的情況下處理事務的風險，因此你得做好再次接收請求的準備，以防確認訊息丟失或根本就沒有傳送。如果出現故障，而處理傳入的訊息的事務向其它服務傳送了訊息，你也要準備好補償邏輯。

毒資訊

當我們以事務的方式讀取資訊時，需要注意分辨並處理毒資訊。毒資訊是一種有缺陷的資訊，它會使服務發生故障，或者使服務在處理這條訊息的時候一直產生處理失敗的結果。原因在於，如果在事務中讀取了一條毒資訊，所產生的故障就會使資訊返回佇列；而毒資訊則在佇列中等待服務恢復，然後再被服務讀取，依此迴圈。某些資訊科技產品可以辯認這種毒資訊並將其丟棄。你需要確認的是這些辯論機制到位，並且能夠妥善地處理所有故障，或者至少把這些故障交給你親自處理。

有一種叫WS-ReliableMessaging貌似跟此有關。然而，雖然名字看起來很相似，但是實際上這只是一種能夠穩定地點對點傳輸訊息的協議，可以說更像是HTTP的TCP協議，跟永續性或事務處理根本沒有一點關係。但許多ESB是事務性質的，能夠支援這種協議，因此你可以通過結合標準協議和事務訊息處理來得到一個完善的結果。

其它相關的協議有WS-Coordination和其“同宗”的WS-AtomicTransaction和WS-BusinessActivity。現在我們主要來談談WS-AtomicTransaction。從根本上說，WS-AtomicTransaction定義了一種編排分散式事務處理的協議。一般來說，我不會建議使用WS-AtomicTransaction，因為它在服務間引入了太多的耦合關係。比如，在圖8描述的場景裡——我們真的想在等待外部供應商答覆的時候鎖定資源並且降低我們的訂單的優先順序嗎？

如果使用了事務敏感中介軟體的話，情況就會有所不同。這時已經不是跨越服務的單一事務，而是分成了三個更小的事務：一個傳送服務；內部中介軟體保障訊息的傳遞；最後一個在中介軟體與讀取者之間——這是與基礎設施的耦合，可以從邊界元件上分離出來。

質量屬性場景

這一部分是從需求的角度討論使用模式的架構效益。大多架構需求是通過使用場景表現的質量屬性（可擴充套件性、靈活性、效能等）來描述的。這些場景也可供其它情況作為應用模式的參考。

事務處理服務引入的事務語義可以簡化編碼和測試。另外，它還能極大地提高服務的可靠性與穩定性。因為其“全有或全無”的屬性使得編碼變得簡單，這讓開發人員能夠集中精力實現商業價值，而不是考慮一些邊界效應或者類似的問題。

下面是幾個場景，可以給你考慮使用服務託管模式的理由。

之所以事務處理服務模式能為我們節省編碼時間，是因為事務不像非事務程式碼有那麼多的邊界效應。還有一種可以節省編寫程式碼時間的模式是工作流化模式（Workflodize Pattern）。

模式四：工作流化模式

我曾經為一家移動公司做過一個專案，構建一個售後服務系統。大家應該都知道，移動公司之間的競爭是非常激烈的。競爭的結果就是，這家公司的銷售部門經常要夜以繼日地工作才能制定出新的使用方案或捆綁銷售計劃以提高銷售額：比如朋友、親情、PTT的公司業務、更低的國際電話費用等方案，3.5G網路的捆綁推廣等。對於這家公司來說，每週都會有好幾種新式應用方案產生。其記賬系統是基於Amdocs的，SAP系統應付新方案也很輕鬆。然而，市場競爭通常都是從銷售部門開始的，而不管IT部門的就緒度如何，因此如何儘快地支援新的銷售流程就成了迫切的需求。

幾乎所有企業的業務需求都是不斷變化的——雖然可能不像前面所描述的那般迫切，但它畢竟是存在的。我們必須尋找一種方式讓我們的服務適應這些不斷變化的過程。

問題

如何提高服務對不斷變化的業務流程的適應性？

最容易想到的方法是每次都等待變化的需求，然後根據需求變化開發程式碼，更新服務。這裡有幾個問題。首先，為了變更需求，你需要一個完整的開發週期。其次，程式碼變更意味著系統的很大一部分需要重啟——想一想一些諸如此類的問題吧：“我們昨天的計劃會不會受到這次更新的影響？”；“會對上個週期我們新增的那個類似的東西產生什麼影響？”等等。可以說越多的開發和測試就等於越長的上市時間。在我們的專案中，這意味著實施新的計劃需要幾個星期的時間，這會讓管理部門很不高興。這也意味著你的工作評定又降了一級，甚至更多。我們當然不能這麼做。

一個較好的辦法是將應用中比較穩定的部分從經常改變的部分中分離出來。比如在我們的方案中，像顧客姓名、地址等人口統計資料應該就是與銷售方案無關的穩定因素。雖然如此，編排穩定的邏輯仍然是一項繁瑣且容易出錯的任務。或許，我們可以想個更好的辦法……

解決方案

在服務中引入一個工作流引擎來處理不穩定的和經常變化的過程、以及編排穩定邏輯（stable logic）。

如圖9所示，工作流化模式是在服務中新增一個工作流引擎來驅動業務過程。工作流引擎中包含一個工作流例項（workflow instance）。最基本的形式是每個工作流負責一種請求型別；然而，工作流可以更復雜，處理連續的過程並且有多個接收外部服務請求或資料的入口點。

使用工作流的優勢是可以以活動為構建塊進行思考，從而更靈活、更輕鬆地安排流程。以活動流的方式建模過程意味著可以更容易地分辨並重用穩定的部分，直到有變化需求為止。既然活動可以進行自我測試，重用一個活動就代表你不用再進行大量的測試。而靈活地重新安排活動則代表你可以迅速地響應業務需求。

這個能夠更容易地（通過工作流）改變服務行為的誘人方案有一個問題：每次行為變更是否需要同時更新契約版本？回答當然是要看情況。我的原則是，對於契約行為來說，如果里氏代換原則成立，那麼就不需要新增新的版本。

什麼時候更新契約版本——里氏代換原則

里氏代換原則，或契約式設計，是一種面向物件的原則。Barbara Liskoy（里氏）是這樣說的：“如果對於每一個型別S的物件o1都有一個型別T的物件o2，使得以T定義的所有程式P在所有o1都被替換為o2的時候程式P的行為沒有變化，那麼S是T的一個子型別。”簡單地說，這就是指子類可以代替父類使用而不會破壞任何使用基類的行為。應用到SOA上這意味著改變服務的內部行為時，如果對於每個契約中定義的操作，前面的情況不變或較弱，而後面的情況（比如請求結果）不變或更強，那麼你就不需要建立新的契約版本。換言之，為了保持相同的契約版本，新的服務版本應該與客戶對舊的服務版本的期望行為保持一致。

下面我們把示例的場景工作流化，看看工作流是怎麼發揮作用的。簡單重複一下，該場景主要是關於如何更快地為移動公司引入新的使用方案。在引入新的方案的時候，後臺系統通常還沒有就緒——一般需要幾天甚至幾個星期的時間進行改動、測試和部署。而使用工作流的一個優勢就是可以在沒有後臺的人工干預的情況下為新方案提供請求路由支援。比如，我們可以先讓客戶關係管理（CRM）系統記錄某個客戶服務的變更，通知技術人員配置網路等，然後等後臺系統就緒了，再更新路由把流程指向新系統。此外，正如前面提到的，在這個流程中有許多步驟是穩定的，比如獲取客戶的人口統計資料（姓名、地址等）、為電話提供附加程式或附件等。這些步驟都是可以被幾乎全部銷售過程重用的活動或步驟。在這個場景中新增一個工作流可以極大地提高業務響應能力並保持業務敏捷性。如果某個競爭對手啟動了一個很受歡迎的新方案，那麼這家公司就可以在一天之內迴應一個有競爭力的方案。這是真正的有形商業資產。

工作流引擎的另一個優勢是能夠處理持續的過程。它把涉及多資訊互動的全部過程直觀地表示出來，使我們更容易對藍圖和過程有一個清楚的瞭解，因此可以從業務的角度來除錯過程。

當然，工作流化也可以與其它模式結合。比如，很容易通過作業排程（幾乎所有的工作流引擎都支援）實現主動式服務模式。

流程編排（Orchestrated Choreography）是一種與工作流化密切相關的模式；這兩種模式都使用相同的底層技術：使用工作流引擎。不過，雖然底層技術一樣，但是不同的架構考慮方式卻會導致選擇不一樣的模式。比如，兩者之間一個很明顯的不同就是工作流化侷限於一個單獨的服務中，而流程編排則需要在服務間新增調整性工作流。

技術相關

這一部分我們將簡單的瞭解一下利用當前的技術實現這個模式的意義以及實現模式所涉及的技術。

與工作流化模式相關的技術自然是工作流引擎。當前市場上有許多工作流引擎。微軟將Windows Workflow Foundation作為.NET 3.0的一部分，我覺得這會讓它在.NET世界中很受歡迎——雖然還有幾家其它公司為.NET提供了像Skelta或K2之類的工作流方案。Java自然能得到更多公司的支援，比如IBM、JBoss，以及專業的工作流公司Flux等等。Oracle甚至提供了一個工作流包（資料庫WF_Engine）和Java API支援。

大多工作流引擎都有內建的用以修改工作流的視覺化設計器。圖10是主動服務模式下用以生成報告的Flux的視覺化設計器。

使用像圖10所示之類的編輯器是修改流程的不錯選擇，通常你還可以使用XML來定義工作流。還有一些工具，比如開源（BSD許可證）OpenWFE，完全不提供視覺化編輯器，只能依靠XML來配置工作流。下面是一個在OpenWFE中編輯流程的示例。

例1：OpenWFE中信貸審批工作流的部分XML實現

<process-definition name="Credit approval">
<sequence>
.
.
.
<participant field-ref="order_value" />
<if>
<greater-than field-value="order_value" other-value="10000" />
<!-- then -->
<sequence>
<participant ref=”supervisor”/>
<subprocess ref=”ReviewAndApproveOrder”/>
</sequence>
<!-- else -->
<subprocess ref="TaskPaypal" />
</if>
.
.
.
</sequence>
</process-definition>

選擇工作流引擎——靈活性

編輯工作流可以考慮幾個簡單的模組，比如活動、異或分支（可能的執行路徑之一）、併發分支。要注意有時候會遇到更復雜的場景，像如何在不同步的前提下合併多個執行路徑，並且只執行一次後序的活動，還有如何處理一個活動的（各個活動需要同步的情況、活動數量無法預知的情況等等）多個例項，以及許多其它此類問題。這些問題的解決方案就是工作流模式（在“工作流模式頁面”上有描述，詳見http://is.tm.tue.nl/research/patterns/patterns.htm）。

我的建議是先了解一下引擎支援哪些工作流模式以保證良好的靈活性，而不會在後期走進死衚衕。雖然靈活性並不是唯一的選擇標準（還得考慮效能、可用性、安全性等），但我覺得作為一個以靈活性為前提而選擇的工具而言，靈活性是一個非常重要的標準。

某些工作流引擎，比如Microsoft Biztalk或WebSphere MQ Workflow，相對內部的工作流成本來說，更適合編排內部服務的互動。

質量屬性場景

這一部分是從需求的角度討論使用模式的架構效益。大多架構需求是通過使用場景表現的質量屬性（可擴充套件性、靈活性、效能等）來描述的。這些場景也可供其它可以應用模式的情況參考。

工作流化的主要優勢是能夠提高靈活性。設計一個工作流是一個視覺化過程（至少大多工作流實現如此），很容易掌握。附加的靈活性優勢也能在需求改變時加快上市時間。在我看來，工作流是使服務走向敏捷業務的最重要的工具。

下面是幾個場景，可以給你考慮使用工作流模式的理由。

由於你可以動態地改變服務行為，因此工作流化模式能夠提高服務的靈活性；另外還可以提高邊界元件模式的靈活性。

模式五：邊界元件

最後一個基本模式是邊界元件模式。稱其它模式為基本模式是因為它們有很大的通用性。但邊界元件模式不同，稱它為基本模式是因為這是一個實現其它模式的平臺。由於邊界元件模式是實現其它模式的一個步驟，具體的示例都是適應於在這個邊界元件上構建的模式的，所以很難想象一個具體的示例來展示它的必要性。不過，我會嘗試通常幾個簡單的例子和這些例子之間的共性來介紹邊界元件。

問題

場景1

我們曾經為一家公司開發了一個海軍C4I平臺（Military Naval C4I platform）。這個平臺有一些可以重用的服務。比如，核心服務之一提供了標準的中央目標檢視。平臺上第一套工具使用了TIBCO Rendezvous訊息設施。後來需要更換完全不同的技術（WSE 3.0 ）。這兩套工具都使用相同的業務邏輯，但是實現技術不同。

場景2

在另一個專案中（在工作流化模式中提到過），一家移動公司經常需要在一個處理訂單的服務中引入新的應用和銷售方案，比如朋友和親情、晚間話費等。由於詳細變動都是XML相關，因此這個服務介面是非常穩定的，但是業務邏輯卻要為適應新方案而經常變動。

這是一個與場景1截然相反的場景；這裡的介面與技術是不變的，而業務邏輯是變動的。

場景3

最後一個場景是許多專案中常見的一種情況。通常系統裡會有多個服務。雖然每個服務處理各自不同的業務，但所有這些服務都要執行一些常見的任務，比如在處理請求之前要確認請求是經過驗證的，儲存稽核條目等等。

在這個場景裡，我們遇到了一個不是與單個服務直接相關但在各服務之間重複性卻是最高的功能——因為即使一個服務是處理訂單的，另一個服務是面向顧客的，其記錄請求的程式碼都是基本一樣的。

這些場景的共性是每個服務都涉及多個問題（業務邏輯、技術、記錄等）。正如我們所見到的，所有這些問題都必須可以根據情況進行變更而不依賴於其它的問題——我們需要實現這種靈活性。因為我們的問題是：

如何讓服務、技術和其它交叉問題（比如安全、記錄等）等業務方面的問題可以按自己的步調變更而不產生相互的依賴性？

最簡單的（或許過分簡單了）辦法是不要做任何具體的變動。比如，直接把一部分邏輯當作Web服務。這對技術提供商的線上業務來說是很常見的，比如Microsoft (WCF)和 Sun (JAX-WS)提供的教程。然而，由於契約操作與業務邏輯實現直接糾纏在了一起，這給程式碼維護帶來了極大的不便——比如，如果要支援場景1，用這種方法來替換技術可能就會非常困難。

我們可以通過在複製服務上替換新技術來解決前面的在當前服務中替換技術的問題，這種方法也叫“自我克隆（own and clone）”。不過這也會產生維護上的問題，因為你現在有了同一業務邏輯的多個複本，因此你得改動所有複本，並且這還解決不了場景3裡要在多個服務上新增記錄功能的問題。

如果什麼也不做和克隆都行不通，那麼我們可能要考慮分開解決各個問題。

解決方案

關注點分離（SoC）在面向物件的設計中是一個為人熟知的概念。其背後的基本原則是單一責任原則（The Single Responsibility Principle），或簡稱為SRP。SRP認為要改變一個類只能有唯一的原因，這個原因就是責任（responsibility）。我們可以在SOA中應用同一原則，把業務邏輯看作是一個責任，把其它的問題看作是另一個責任，這樣我們就得到以下模式：

附加邊界元件（Add Edge Component(s)），用以實現服務並提高靈活性、分離業務邏輯與其它問題（比如契約、協議、終端技術和其它交叉問題）。

正如圖11所示，新增邊界元件的主要原因就是關注點分離。邊界元件可以處理所有這些交叉問題以及其它非核心業務問題。這些問題包括負載平衡、格式轉換和審計。這樣，服務的業務邏輯就交給了另一個專門處理業務邏輯的元件。這種分離支援所有前面提到的場景，因為分離可以允許各個部件自由調整。比如，要支援一項新技術（場景1），只需要新增一個邊界元件，但是業務邏輯並不需要更換。如果要改變業務邏輯的行為，就新增一個新的使用方案（場景2），而邊界元件則不需要更換。

從某種意義來說，邊界元件模式可以為SOA提供外觀（fa?ade）、代理、和AOP模式。

我們還要看一下如何解決場景3中服務間的交叉問題。最好的辦法是進一步擴充套件單一責任原則，並且注意邊界元件實際上是一個元件，不能把它對應於整個型別的類。比如，你可以應用管道和過濾架構型別，把多個類/元件連線到一起，各個類/元件處理特定的問題，以此來建立傳入或傳出的流程。比如，圖12即是一個邊界元件的示例。該示例中，邊界元件提供了一個驗證過濾器來確保訊息有正確的格式。然後是一個轉換過濾器把外部契約格式轉為內部格式。最後是一個路由過濾器，負責把訊息傳送到服務的正確元件。這些元件可以在各個服務中根據需求重用，並且能夠自由地進行更改。

雖然從一開始就在邊界元件和服務之間定義一個內部契約很有吸引力，但是實際上沒有理由這麼做，除非你必須支援多個外部契約（雖然實現與消費者一對一的契約非常麻煩——見PTP Integration反模式）。如果服務進展並且建立了新的契約版本，像場景1中像新增新技術，那麼在需要支援外部老版本的契約時你可能需要新增內部契約。

邊界元件非常有用，我在我設計的大部分SOA專案中都引入了這個模式。本書中提到的許多架構模式也都是基於邊界元件模式的擴充套件。

下面我們來看看邊界元件模式的技術相關問題。

技術相關

這一部分我們將簡單的瞭解一下利用當前的技術實現這個模式的意義以及實現模式所涉及的技術。

沒有任何技術能夠像邊界元件一樣自動處理那麼多問題。不過樂觀的說，沒有任何技術會影響你實現邊界元件模式，而且某些技術最終將幫你解決一些讓你困惑的問題。

比如，JAX-WS或Windows Communication Foundation (WCF)實際上已經為你實現了邊界元件模式，但它們只處理底層的問題，也就是它們稱為繫結（binding）的東西。這些問題是在各種WS*標準中提到的；比如WCF可以處理MTOM encoding或安全問題。然而，你還是需要自己編寫高層的問題，比如路由和契約轉換。這一點我在上面已經提到過。

還可以使用一種有趣的技術，是稱為Restlet的Java引擎。Restlet有一些內建的類，使其成為實現邊界元件模式的優秀範例。

邊界元件範例——Restlet引擎

Noelios Consulting公司的Restlet引擎是一個用以實現RESTful服務的Java庫，它有一些內建類（比如filter和router），可以讓我們很方便地構建邊界元件。請看圖13的示例。

圖13是一個在訂購服務上的可行的邊界配置。這個訂購服務的契約有兩種操作：getLast，返回上一次的訂單；和getAll，返回某個客戶所有的訂單。但是在實際呼叫業務邏輯之前，我們得先記錄它，處理它的狀態和情況，然後確定使用了正確的主機，最終呼叫正確的業務功能。新增一個邊界元件可以讓我們獲得以上效果，並且不會影響到只處理業務請求的業務邏輯。

下面是上述配置的部分程式碼。

例2：使用Restlet定義的邊界元件部分程式碼

Builders.buildContainer()
.addServer(Protocol.HTTP, portNumeber)
.attachLog("Log Entry")
.attachStatus(true, "[email protected]", "http://www.mysite.org")
.attachHost(portNumber)
.attachRouter("/orders/[+")
.attach("/getAll$", getAllRestlet).owner().start();
.attach("/getLast$", getLastOrderRestlet).owner().start();

現在所有的技術都支援邊界元件模式，有些甚至已經在內部實現。

質量屬性場景

這一部分是從需求的角度討論使用模式的架構效益。大多架構需求是通過使用場景表現的質量屬性（可擴充套件性、靈活性、效能等）來描述的。這些場景也可供其它可以應用模式的情況參考。

由邊界元件模式與許多質量屬性有關。這些屬性大多是由共同使用邊界元件模式和其它模式產生的結果。然而，有兩個質量屬性是直接與邊界元件模式相關的。第一個是靈活性——增強服務的適應性，提高服務的外部屬性，並且不會影響到業務邏輯。第二個是易維護性——關注點分離（SoC）使各元件的行為更易於理解。回想一下上面三個場景——在當前服務中新增新技術、在不改變契約的前提下改變業務行為、以及迅速解決交叉問題——通過邊界元件，我們可以在不影響方案的其它部分（或者至少將影響最小化）的情況下解決問題。下表列出了幾個使用邊界元件的示例場景。