BizTalk Server 2006 或 WF？選擇適合您專案的正確工作流程工具 (英文)

發行項
03/19/2008

黃黃

22ix 紐約 (www.26ny.com)

2007 年 11 月

2008 年 2 月修訂

適用於：

Microsoft BizTalk Server 2006

Windows Workflow Foundation

總結：本文將針對各種應用程式和企業整合工作流程案例，提供在 Microsoft BizTalk Server 2006 與 Windows Workflow Foundation 之間選擇的指引。 (16 個列印的頁面)

工作流程在日常商務程式中很普遍，因此，常見的需求是尋找直接支援建置工作流程解決方案的程式設計工具。 Microsoft BizTalk Server 2006 和 Windows Workflow Foundation (WF) 是 Microsoft 針對程式設計工作流程解決方案的兩個主要工具。不過，由於它們之間的明顯重迭，許多架構設計人員和開發人員都難以決定哪些工作流程技術對於其用途有意義。

這特別正確，因為 WF 已清楚識別為未來慣用的工作流程技術，而 BizTalk Server 2006 仍是企業整合的進階伺服器產品。在BizTalk Server協調流程完全支援 WF 之前，架構設計人員和開發人員必須仔細選擇要投資的技術。

選擇正確工作流程技術的挑戰之一，就是工作流程可能代表許多事項：

使用者互動以完成工作的 UI 畫面流程。
應用程式或服務內的商務邏輯流程。
數人互動以完成商務程式。
協調系統之間的多個訊息交換，以處理商務交易。
協調將資料擷取、轉換和載入 (ETL) 資料庫的步驟。

雖然工作流程案例的範圍很廣泛，但將其分成四個廣泛的類別：人類工作流程、應用程式工作流程、企業整合工作流程，以及資料整合工作流程。

在四個主要工作流程類別中，應用程式工作流程和企業整合工作流程是人們最難以選擇技術的兩個領域。從工具選取的觀點來看，人類工作流程和資料整合工作流程案例相當簡單。人類工作流程需要使用者介面，而且通常是以檔為中心的，因此 Microsoft Office SharePoint Server 2007 是建置人類工作流程解決方案的建議平臺。 Microsoft SQL Server Integration Services (SSIS) 是資料整合案例的建議工具。

本文將提供在應用程式工作流程和企業整合工作流程案例中BizTalk Server 2006 與 WF 之間選擇的指引。

BizTalk Server協調流程引擎

BizTalk Server協調流程引擎一律是BizTalk Server吸引人的功能之一。引進時，這是 Microsoft 用來執行工作流程中心程式設計的最佳工具。 BizTalk Server協調流程提供視覺化程式設計環境，用於開發元件，以控制複雜的多步驟訊息流程，以完成特定的商務交易。

BizTalk Server協調流程程式碼成品與流程圖或整合模型語言 (UML) 活動圖表類似，商務分析師可能會產生以記錄商務程式。這些成品接著可以在協調流程引擎執行時間中編譯和執行，以提供長時間執行的交易和補償、持久性、容錯和災害復原等服務，這對於建置自動化任務關鍵性商務交易的系統至關重要。

未來工作流程基礎

雖然工作流程案例有不同的類別，但從程式設計的觀點來看，案例之間就已足夠，因此值得一來，嘗試建立工作流程開發的通用架構。 BizTalk Server中的協調流程引擎功能強大，但從未設計成在BizTalk Server之外使用;因此，無法有效地針對其他工作流程類別重新規劃BizTalk Server協調流程。

在 Microsoft .NET Framework 3.0 中發行的 WF 將視覺化、工作流程為中心的程式設計模型引進至設計為一般且可擴充的.NET Framework，足以用於 Windows 平臺上的所有工作流程相關案例。產生 WF 的小組能夠採用BizTalk Server協調流程引擎的最佳概念、考慮工作流程案例更廣泛的領域需求，並設計彈性足以支援所有架構的架構。

作為 WF 彈性的辨識項，Microsoft Office SharePoint Server 2007 會使用它來實作人類工作流程解決方案。其目的是要讓協力廠商 BPM 廠商在 WF 之上建置其解決方案，而不是建置自己的專屬工作流程引擎;數個廠商已經這麼做。個別開發人員也可以使用 WF 在.NET Framework應用程式中實作自訂應用程式工作流程。此方案也適用于未來版本的 BizTalk Server，以在 WF 上實作協調流程引擎，以實作企業整合工作流程解決方案。

圖 1. 使用正確的工作流程工具：BizTalk Server 2006 與 WF

選擇正確工作流程工具的程式

我們用來提供指引來協助您決定哪個工作流程工具適合您的專案，以描述最常見的工作流程案例，以便您可以判斷最適合您專案的案例或案例組合。然後，我們會針對每個案例提供特定指引，以取得哪一個工具，BizTalk Server 2006 或 WF，是最佳的選擇，以及原因。此外，我們將使用應用程式平臺基礎結構優化 (APIO) 模型，這是一種模型，可用來評等組織應用程式平臺和開發功能的成熟度，以在有效率地使用任一工具的案例中提供組織特定的指引。最後，我們將探討BizTalk Server 2006 和 WF 的藍圖，讓您可以針對您目前建置的應用程式做出最佳決策。

常見的工作流程案例

即使在將範圍限制在工作流程的應用程式和企業整合類別之後，仍要考慮各種不同的工作流程案例。如圖 2 所示，在一端的頻譜上，是 WF 清楚地是正確選擇的案例。其中一個範例是獨立軟體廠商內的工作流程功能， (ISV) 產品，其中BizTalk Server 2006 的授權成本和部署複雜度會相當禁止。在此案例中，身為 ISV，您是在進行商務軟體的企業中，而且裝載 WF 免費版金所需的額外程式設計工作是合理的投資。

圖 2. 整合和工作流程持續性

在頻譜的另一端是企業整合解決方案，這些解決方案是在公司 IT 部門內建置的，其中清楚BizTalk Server 2006 是正確的選擇。在此案例中，您想要專注于產生商業價值，而不是投資建置「管線」，讓您的解決方案可擴充、可靠且可管理;因此，BizTalk Server 2006 的授權成本相當值得，因為它提供的內容。

大部分專案都落在這兩端的頻譜之間。以下是一些常見的案例，其中需求會決定工作流程解決方案：

UI 頁面控制器- 複雜應用程式中的常見需求是根據所實作之特定使用案例的商務規則強制執行 UI 畫面導覽。最簡單的範例是一個精靈，可逐步引導使用者完成一組指定的畫面來完成工作。通常，這是以使用者動作和資料狀態為基礎的螢幕流覽可能性更複雜的圖表。
Model-view-controller (MVC) 模式是將這個導覽邏輯從表單本身提取的傳統技術，因此它們在不同的使用案例中更簡單且更容易重複使用。 MVC 模式中的控制器實際上是工作流程或狀態機器;因此，在實作這類應用程式時，尋找工作流程工具是自然的。
長時間執行的商務邏輯— 完成商務交易需要許多步驟時，使用者可能需要在程式中間停止，或等候其他使用者或系統的動作，再繼續。暫停暫時 (或「休眠」) 進程的能力，然後根據外來事件重新開機它，是工作流程概念的核心。若沒有工作流程引擎，開發人員會強制設計並手動撰寫程式碼的機制，以儲存不完整進程的狀態，並在繼續處理時重新叫用該狀態。使用設計良好的工作流程引擎時，原生支援這項功能，而不需要額外的開發人員工作。
動態可更新的程式流程- 雖然一開始可以將商務程式編碼成定義完善的循序步驟，但人類通常必須修改流程中間流，以考慮真實生活的情況。在費用核准程式中，提交費用報表的員工經理可能是預設核准者。不過，經理可能會決定將工作委派給 (，例如，因為經理正要播放) 或將核准呈報給上層 (，因為經理不確定特定費用) 的原則。讓使用者更新流程通常比事先嘗試預測流程的每個可能排列更簡單。
商務邏輯的規則抽象概念：在此案例中，您的目標是將商務規則與其他商務邏輯分開。良好的範例是表單驗證規則。在貸款應用程式計畫中，貸款應用程式表單可能有一組欄位驗證規則，使用者才能按 [ 提交 ] 按鈕來提交貸款應用程式。如果貸款人員會使用相同的表單來檢閱和核准貸款，則需要額外的驗證規則，因為它位於程式中的不同階段。
將驗證規則與表單分開實作，可讓您更輕鬆地在不同的案例中重複使用表單，並只藉由評估該案例的適當規則集來強制執行適當的驗證規則。
Web 服務匯總工具- 應用程式通常必須匯總來自數個不同 Web 服務的資料。在許多情況下，匯總邏輯本身可以和應該從應用程式擷取，並以本身許可權公開為可從其他應用程式重複使用的服務。這些服務通常稱為 複合 Web 服務，而且是成熟服務導向架構的重要元素。 Web 服務匯總工具案例通常為同步且短期執行。
長時間執行的商務程式— 本文中會使用長時間執行的商務程式案例來指定將多個應用程式整合在一起的伺服器型進程，而 商務邏輯 則用於單一應用程式內的邏輯。這些以伺服器為基礎的長時間執行商務程式的需求，適用于多執行緒、非同步行為、進程狀態的持續性、處理實例的相互關聯、延展性、可靠性、交易完整性等等的需求，遠高於應用程式內的商務邏輯。
商務對企業 (B2B) 程式— B2B 程式案例基本上與長時間執行的商務程式案例相同，不同之處在于前者除了內部應用程式之外，組織之間也是一樣。因此，安全性需求很重要。此外，您對特定資料格式和傳輸通訊協定的控制也更少，因為這些可能由您的商務夥伴所決定;因此，您需要能夠支援各種格式和通訊協定，並支援大量合作夥伴的特定交換設定。
商務程式的規則抽象概念-類似于商務邏輯案例中的規則抽象概念，當您想要將商務規則與長時間執行商務程式案例和 B2B 程式案例中的主要程式碼分開時，就會套用此案例。此案例需要較高層級的效能和延展性。此外，它可能需要工具，才能允許非程式設計工具檢視和編輯規則。
企業規則存放庫- 在此案例中，目標是建置可從企業中的所有應用程式叫用的中央共用規則存放庫。這可在組織中所有應用程式之間提供一致性，以套用重要的商務規則。類似于商務程式案例中的規則抽象概念，此案例需要高延展性和工具，才能允許非程式設計者檢視和編輯規則。此外，此案例需要規則存放庫能夠以企業中自己的實體身分存在、其本身的裝載機制與工作流程引擎分開，以及元件或 API，以便從各種應用程式執行規則。
企業服務匯流排 (ESB) /Message Broker—許多組織想要所有服務的標準化通訊基礎結構。此基礎結構的兩個最常見拓撲是 ESB 和訊息代理程式。發佈/訂閱傳訊和主題基底路由通常是此基礎結構的預期功能。

應用程式平臺基礎結構優化模型

在某些工作流程案例中，BizTalk Server 2006 和 WF 都符合技術需求。針對這些案例，進行正確的工作流程技術選擇，需要將解決方案比對到特定組織的需求。為了提出適用于您特定組織的建議，我們將使用應用程式平臺基礎結構優化 (APIO) 模型，如圖 3 所示。

圖 3. 應用程式平臺基礎結構優化 (APIO) 模型

APIO 模型是針對組織應用程式基礎結構、架構和開發實務分析組織成熟度的技術。此模型的目標是要讓組織能夠優化其靈活度，以提供 IT 解決方案以符合業務需求。

APIO 模型會使用組織成熟度的下列四個設定檔：

基本— 組織會將軟體視為成本。它們有大量孤立的應用程式，且整合或重複使用很少。他們所擁有的應用程式可能位於各種平臺上。它們對於基礎結構或開發技術沒有一致的標準;它們沒有一致的架構視覺。
標準化- 組織仍會將軟體視為成本，但已採取步驟來提升效率。他們具有架構願景，並嘗試考慮重複使用的機會。他們已開始整合某些應用程式，但大多是點對點整合。
進階— 組織會將軟體視為商務啟用者。他們具有專用的架構設計人員和清楚的架構願景。它們有許多服務，並達到高階的重複使用。所有核心商務程式都會自動化並受到監視。他們會使用集中式、封裝的整合平臺。
動態— 組織會將軟體視為策略性資產。他們在視覺和實作中具有非常成熟的 SOA。他們具有動態版本設定和重新部署服務的清楚程式。可以快速適應商務需求變更，並可快速與新的商務合作夥伴整合。

它不只是您身在何處，也不只是您的所在位置

APIO 模型中有些隱含的概念是每個組織都想要移至動態設定檔的概念。事實上，這取決於企業的性質，以及有關技術的管理原理。某些企業可能完全滿意，以留在基本或標準化設定檔中。

您應該考慮目前的設定檔，以及短期和長期目標，而短期目標是最重要的目標。「基本」設定檔中的組織，最終可能會選擇「動態」設定檔，一開始將焦點放在標準化設定檔中;因此，其技術決策大部分應該與標準化設定檔一致。

一般而言，BizTalk Server 2006 會更適合在進階或動態設定檔中的組織，或有短期目標。基本設定檔中相對滿意的組織可能沒有策略動機來採用 BizTalk Server 2006，也不想要有效地利用它的功能;因此，他們可能不想要投資。不過，如果基本設定檔中的組織已決定積極移至進階設定檔，則採用 BizTalk Server 2006 可能是該方向的策略步驟。

將 APIO 模型導入討論的重點是，最好瞭解組織的目前和目標 APIO 設定檔，有助於在 WF 與 2006 BizTalk Server 2006 之間做出決定，當技術案例可能受到任一技術支援時。兩個不同的組織可能會做出不同的選擇，每一個都適合其組織設定檔。

它全部都在主機中

在 BizTalk Server 2006 和 WF 之間選擇時，要考慮的最重要層面之一是工作流程的裝載需求。不同于 BizTalk Server 2006，WF 不提供「現成」裝載;您必須實作建立 Windows 進程的主機，並啟動工作流程執行所在的工作流程執行時間引擎。

為了建置可實際支援各種工作流程案例的架構，WF 會抽象化環境所提供的核心行為，例如 2006 BizTalk Server，讓各種主機可為這些服務提供特定的所需行為。

WF 工作流程主機提供的核心服務如下：

排程服務- 建立和管理執行時間引擎用來執行工作流程實例的執行緒。
Commit Work Batch 服務- 管理執行時間引擎用於資料庫作業的交易。
持續性服務— 當工作流程實例被導向至執行時間引擎時，處理工作流程實例的持續性。此服務是選擇性的。如果未提供，工作流程實例將不會保存，而且必須在記憶體中執行整個存留期。
追蹤服務- 可讓您記錄工作流程內的追蹤事件。此服務是選擇性的。

建置工作流程主機所需的專案

視您的工作流程案例和您必須提供給工作流程的服務而定，建置 WF 主機可能是簡單或禁止的。對於工作流程在應用程式內容中的案例，裝載 WF 相當簡單。應用程式本身會做為進程主機，而且核心服務的標準實作可以最少地進行設定。

不過，當您進入高度可調整且以伺服器為基礎的案例時，主機的必要複雜度會大幅跳躍。表 1 顯示可能需要的主機服務清單，其中大部分是BizTalk Server 2006 中提供的。

表 1. 主機服務

橫向擴充組態
負載平衡
容錯移轉
節流
執行緒管理
記憶體管理
服務隔離
例外狀況設定
失敗訊息管理
郵件追蹤

封存和清除
身分識別和模擬
多環境部署模型
健康狀況監視
使用率/效能追蹤
複合進程狀態管理
指令碼
災害復原
法規遵循
設定管理

您目前在哪一個業務？

如果您的工作是建置具有緊密期限的特定應用程式，您可能不想讓小組在應專注于實作必要的商務邏輯時建立複雜的主機而干擾。在此情況下，BizTalk Server 2006 相當值得購買，而不是嘗試建置健全的工作流程主機。如果您是大型企業中央架構小組的一部分，您可以選擇投資建置可跨組織使用的主機。即使如此，此工作也不應該輕量執行。

Workflow-Technology建議

針對應用程式內的案例：WF

對於包含在應用程式內的所有案例，包括 UI 頁面控制器、長時間執行的商務邏輯、動態更新的程式流程、Web 服務組合和商務邏輯的抽象概念，WF 是正確的工作流程技術選擇。

在大部分以應用程式為中心的案例中，使用模式需要應用程式與工作流程之間的同步、低延遲互動，這不是BizTalk Server 2006 的強度。基於效能考慮，BizTalk Server 2006 不適合這些案例;BizTalk Server協調流程會在專用的 BizTalk 伺服器上執行，並從用戶端應用程式叫用協調流程需要透過網路來回。此外，BizTalk Server 2006 設計將每個訊息保存至 MessageBox 資料庫以進行持久性時，會產生額外的延遲，如果必須同步呼叫工作流程，在互動式 UI 的內容中可能無法接受此延遲。

WF 更適合這些案例;它符合工作流程需求，而且比 BizTalk Server 2006 更簡單且便宜。這些案例中不需要BizTalk Server 2006 的傳訊功能，例如對應和配接器。裝載服務的需求相當適中，因此，在應用程式內裝載 WF 執行時間不需要大量工作。

針對大部分Business-Process案例：BizTalk Server 2006

對於涉及伺服器型商務程式的大部分案例，BizTalk Server 2006 是正確的選擇。其中包括 B2B 程式、來自商務程式的規則抽象、企業規則存放庫，以及企業服務匯流排 (ESB) /Message Broker。

這些案例需要高延展性。此外，他們需要能夠檢視執行中的進程，以及停止並重新啟動進程。最後，他們需要支援向外延展至多部伺服器。在這些案例中，BizTalk Server 2006 的進階裝載功能是必要的，且值得投資。

基本	標準化	進階	動態
WF → BizTalk Server 2006	BizTalk Server 2006	BizTalk Server 2006	BizTalk Server 2006

圖 4. 長時間執行的商務程式案例

BizTalk Server 2006 通常是長時間執行商務程式案例的最佳平臺。這些進程通常為非同步、長時間執行且具狀態。這些程式通常是組織的要徑任務;因此，它們需要高可用性、可見度、安全性和管理性。 BizTalk Server 2006 的群組或「伺服器陣列」拓撲可讓您管理伺服器陣列，以提供延展性和備援性。

BizTalk Server 2006 儲存進程狀態的持續性機制具有內建的強固安全性，以保護保存狀態的隱私權，這可能基於法規考慮而很重要。 BizTalk Server 2006 的商務活動監視 (BAM) ，以安全的方式提供適當的商務層級可見度。最後，這些案例通常需要支援異質訊息格式和傳輸通訊協定，包括舊版系統。

基於這些原因，BizTalk Server 2006 通常是針對以標準化、進階和動態設定檔為目標的組織的最佳選擇。這些組織通常會將長時間執行的商務程式案例視為對企業而言非常重要，而且在企業內非常常見;因此，他們特別購買 BizTalk Server 2006，以為其建立標準化平臺。

不過，對於基本 APIO 設定檔中的組織而言，WF 可能是較佳的選擇。這些組織通常不想要投資建置標準化的應用程式平臺。相反地，他們想要將成本降到最低，而BizTalk Server 2006 的授權和硬體成本可能非常禁止。此指引的例外狀況是對於高延展性、監視和支援各種訊息格式和傳輸通訊協定的需求。在此情況下，雖然組織不打算投資其應用程式平臺，但從頭開始建置裝載和傳訊功能的成本可能超過 BizTalk Server 2006 的成本。

基本	標準化	進階	動態
WF	WF → BizTalk Server 2006	BizTalk Server 2006	BizTalk Server 2006

圖 5. Web 服務匯總工具案例

BizTalk Server協調流程和 WF 工作流程都支援從工作流程取用外部 Web 服務，以及將工作流程公開為 Web 服務。因此，對於建置 Web 服務匯總工具解決方案，就像針對長時間執行的商務程式解決方案一樣，選擇取決於組織設定檔和裝載需求。

如果匯總 Web 服務只是匯總其他 Web 服務，BizTalk Server 2006 支援異質訊息格式和傳輸通訊協定的能力會增加少量價值。不過，如果服務也應該匯總未公開為 Web 服務的舊版環境的資料，BizTalk Server 2006 會增加價值。

因為使用模式很快速、同步要求/回應呼叫，所以BizTalk Server 2006 所提供的訊息持久性通常並不重要。事實上，由 MessageBox 持續性所導入的延遲實際上是責任。 BizTalk Server 2006 提供的主要值，是能夠管理跨多部伺服器的部署，以及監視執行中的實例。 BizTalk Server 2006 的 BAM 功能也可能有助於監視符合服務等級協定 (SLA) 。

基於這些原因，WF 是實作 Web 服務匯總工具的絕佳選擇，特別是在基本和標準化設定檔中的組織。其中BizTalk Server 2006 可能是優點的範例，就是您必須管理不同用戶端組織大量端點的端點。 BizTalk Server 2006 的接收埠和接收位置設定會特別處理此問題。在此情況下，憑證可能很重要，而且BizTalk Server 2006 支援設定和管理憑證，並將其套用至加密/解密可能很有用。

Future-Proofing

您想要確保投資軟體授權成本、學習工作流程技術，以及建置特定工作流程元件，將在未來提供您最大的價值。除了為特定工作流程案例和組織選擇正確的工作流程之外，您也必須考慮 BizTalk Server 2006 和 WF 的產品藍圖。這沒有簡單的答案。下列批註不會建立強式引數來選擇任一技術;相反地，它們是資料點，可協助您做出決策。

BizTalk Server 2006 R2 新增的內容

BizTalk Server 2006 R2 新增了兩個可能會影響您所選工作流程平臺的功能：WCF 配接器，以及 WCF 和 WF 的 BAM 攔截器。

WCF 配接器

如果您的小組已採用 Windows Communication Foundation (WCF) 作為在建置 SOA 中實作服務的標準技術，則BizTalk Server 2006 沒有 WCF 支援的事實，可能已將其視為建置及裝載複合 Web 服務的平臺。這可能已將您推送至 WF，即使 BizTalk Server 2006 是您案例和 APIO 設定檔的絕佳相符專案也一樣。

幸運的是，在 BizTalk Server 2006 R2 中引進絕佳的 WCF 整合，這已不再是問題。 BizTalk Server 2006 現在與 WCF 有強大的整合，而且它是一個絕佳的平臺，用來從更細微的服務建置複合服務，並將這些複合服務公開為 WCF 服務。

WF 的 BAM 攔截器

第二個相關的BizTalk Server 2006 R2 功能是引進 WF 的 BAM 攔截器。如果商務活動監視是解決方案的一個重要功能，您可能已推送至使用 BizTalk Server 2006—只是為了利用 BAM—當 WF 更適合您的案例時。使用 WF 的 BAM 攔截器，如果它是適合您專案的工作流程技術，而且仍然使用 BAM 作為企業商務活動監視解決方案，則可以選擇 WF。

BAM 是 BizTalk Server 2006 的一項功能，提供從BizTalk Server協調流程和資料擷取事件和資料，並在入口網站中呈現該資料，以供應商務使用者對商務程式的端對端可見度。 BAM 適用于 BizTalk Server 2006 應用程式的強大層面是 BAM 監視可在部署 BizTalk Server 2006 應用程式之後， (或「檢測」) 進行設定，而不需要修改 BizTalk Server 2006 程式碼成品。

BAM 設計為整個企業的商務活動監視解決方案;因此，非BizTalk Server 2006 應用程式可以將事件和資料摘要至 BAM。不過，執行此作業的 API 需要在外部應用程式中撰寫相當多的程式碼。 BizTalk Server 2006 R2 中的 BAM WF 攔截器可讓您更輕鬆地檢測 BAM 的 WF 工作流程，而不需要修改程式碼。藉由使用 BAM 攔截器，您可以追蹤商務程式，而不需要重新編譯 WF 或 WCF 解決方案;整合是透過組態檔來完成。

適用于 WF SDK 的 BizTalk Server 2006 延伸模組

BizTalk Server 2006 Extensions for WF SDK 已于 TechEd 2007 宣佈並示範。此 SDK 提供在 BizTalk Server 2006 中裝載 WF 工作流程的簡單機制。此工具適用于目前建置 WF 工作流程的 .NET 開發人員，並尋找簡單的方式來達成這些工作流程的強固、可調整裝載。

SDK 提供兩個自訂 WF 活動，也就是 btsReceive 活動和 btsSend 活動，可用於 WF 工作流程中，透過 BizTalk Server 2006 接收和傳送訊息。身為開發人員，您可以定義輸入和輸出訊息的 WCF DataContracts ，以及定義訊息交換模式的 ServiceContract 。在 WF 工作流程中，btsReceive 和 btsSend 活動會設定為使用定義的 ServiceContract，如圖 6 所示。

圖 6. btsReceive 和 btsSend 活動用於定義的 ServiceContract

完成並編譯 WF 工作流程之後，您可以以滑鼠右鍵按一下工作流程專案，然後選取 [產生協調流程] 以自動產生包裝函式協調流程 (請參閱圖 7) ，以起始 WF 工作流程，並將BizTalk Server 2006 訊息路由傳送至其中。

自動產生的包裝函式協調流程包含 ServiceContract中定義之訊息的架構。它也包含BizTalk Server協調流程圖形和程式碼，用於接收 2006 BizTalk Server 2006 訊息、建立和啟動工作流程實例、將輸入訊息 () 傳遞至工作流程實例、接收輸出訊息 () ，並將其轉送回 BizTalk Server 2006 傳訊引擎。若要完成 WF 工作流程的裝載，您只需要編譯和部署包裝函式協調流程，並使用一般BizTalk Server 2006 機制加以系結。

圖 7. 自動產生包裝函式協調流程

除了利用適用于 WF 工作流程的BizTalk Server 2006 BizTalk Server可調整裝載機制之外，BizTalk Server 2006 Extensions for WF SDK 還可讓您利用 BizTalk Server 2006 傳訊基礎結構。因此，您可以利用許多可用的配接器，將訊息傳入和移出 BizTalk Server 2006，以及管線處理，包括對應功能。

如同其功能一樣強大，wF SDK 的 BizTalk Server 2006 延伸模組應該用來做為工具，讓 WF 開發人員在 BizTalk Server 2006 之上部署其工作流程，而不是取代我們識別為 2006 BizTalk Server 2006 作為適當工具的協調流程。有些 WF 圖形在協調流程中包裝時無法運作。這是因為使用 BizTalk Server 2006 Extensions for WF SDK 在 BizTalk Server 2006 內裝載 WF 工作流程，不會提供與原生協調流程相同的裝載行為。 SDK 的常見問題清單 (包含在快速入門手冊) 中，概述這些差異。

結論

BizTalk Server 2006 和 Windows Workflow Foundation 是 Microsoft 用來在應用程式和企業整合工作流程類別中實作工作流程解決方案的主要工具。若要選擇哪一個適合您的專案，您必須先識別您要鎖定哪些工作流程案例。

接下來，使用圖 8 中的資料表來查看案例的建議工作流程技術。針對應用程式內的工作流程，建議使用 WF。針對大部分以伺服器為基礎的商務程式與 B2B 案例，建議您BizTalk Server 2006。

圖 8. 案例特定的工作流程技術

針對長時間執行的商務程式與 Web 服務匯總工具案例，任一技術都可以有影響地套用。在這些案例中，您應該評估您組織的目前和近期目標 APIO 設定檔。在這些案例中或移至進階或動態設定檔的組織應該使用 BizTalk Server 2006。基本和標準設定檔中的組織可以有效地使用這些案例的 WF。

最後，您應該考慮解決方案的發行日期和所需的存留期，相對於 BizTalk Server 2006 和 WF 的產品藍圖。使用此架構和本文中的指引，您應該能夠為您的專案選擇正確的工作流程。

附錄

卸載關於 BizTalk Server 2006 與 WF 的誤解

以下是有關 WF 和 BizTalk Server 2006 的一些常見誤解，以及我們用來去除這些引數的厘清引數：

WF 是取代 BizTalk Server 2006。不。由於 WF 是 Microsoft 針對程式設計工作流程提供的「最新且最大」供應專案，因此許多不熟悉 BizTalk Server 2006 的使用者一開始假設它已隨著 WF 發行而過時。更正此印象的簡單答案是 WF 是用於建置各種工作流程的低階開發人員架構，而 BizTalk Server 2006 是具有特定工作流程案例類別之進階功能的全方位伺服器產品：企業整合。 (請參閱圖 1.)
WF 僅提供這項功能的一小部分：工作流程和商務規則。雖然 WF 對於不需要 2006 BizTalk Server提供之所有其他功能的案例而言，更符合成本效益的解決方案可能比較簡單，但對於 BizTalk Server 2006 的核心企業整合案例，其無法支援BizTalk Server 2006。
BizTalk Server即將消失。不。類似的誤解是，因為 WF 已發行為未來的工作流程工具，而且BizTalk Server尚未重寫為使用 WF，所以 Microsoft 不再投資BizTalk Server，最終會以新的 WF 型產品取代它。這只是這種情況;BizTalk Server是非常成功的產品，而其目標的企業整合區域會繼續成為 Microsoft 致力於支援的區域。
您必須選擇 BizTalk Server 2006 .NET Framework。不。對於不熟悉 2006 BizTalk Server 2006 的 .NET 開發人員而言，可能很想要選擇 WF 而非 BizTalk Server 2006，只是基於他們想要「單純」.NET。不過，這不是有用的準則;BizTalk Server 2006 本身建置在.NET Framework上。
事實上，BizTalk Server 2006 代表可套用至解決方案的超過 2 百萬行 .NET 程式碼，節省您從頭開始開發其功能的時間、問題及成本。此外，BizTalk Server 2006 程式設計本身是在 Microsoft Visual Studio .NET 內完成，而且元件會編譯並部署為 .NET 元件。此外，最重要的BizTalk Server 2006 專案結合 BizTalk Server 2006 元件與自訂 .NET 元件;因此，BizTalk Server 2006 開發應該被視為特製化 .NET 開發，而不是外部或不同的專案。
真正的問題是，BizTalk Server 2006 功能是否為您的特定工作流程案例提供足夠的價值，以證明授權成本。您不想使用 sledgehammer 來停止回應圖片;您都不想使用汽車器的鐵杆來擷取大型岩石。
功能最成功。選擇不佳。我們可以提出一個功能矩陣，以比較 WF 的細微特徵與 2006 BizTalk Server的功能矩陣。不過，此比較不會很有説明;BizTalk Server 2006 具有這類大量功能，特別以企業整合空間為目標。如果這不是您的目標案例，則功能比較將無意義。 BizTalk Server 2006 可能會勝出功能核取方塊數目;不過，如果這些功能與目標工作流程案例無關，則這是 apples-to-oranges 比較。

通知

我想要感謝 Paul Andrew 和 Kris Horrocks，以及檢閱本文的每個人。

共用方式為

BizTalk Server 2006 或 WF？選擇適合您專案的正確工作流程工具 (英文)

目錄