WF 4或BizTalk 2010？

Question

我有一個問題 - BizTalk或WF？讓我澄清一下，我意識到前三個工件背後的類似技術，並意識到我可以構建它們，但是我沒有發現它們是WF內置的，所以我試圖理解爲什麼我會使用它技術在另一方面。

1. 轉換
2. 綁定
3. 端口/適配器
4. 的BizTalk未來

轉換

這是相當不錯的BizTalk原生支持，增強的設計師開機，生成模式和地圖的能力。此外，我喜歡這樣一個事實，即所有內容都被轉換了，因爲我不必擔心我的工作流程中的集成點，因爲它始終採用一致的格式，因爲我的集成變異會降低風險 - 我只需重構模式和映射。

相比之下，使用WF，我沒有那種內置豪華的功能，所以我錯過了一些東西，或者BizTalk在這裏有+1嗎？

綁定

綁定是在BizTalk另一個完全封裝件的功能。我可以從字面上將我的工作流程設置爲具有我想要的任何綁定，因爲上述工件意味着在測試期間我可以綁定到文件系統，並且在生產期間我可以綁定到服務。

相比之下，使用WF，我沒有那種奢華的內置功能，所以我錯過了一些東西，或者BizTalk在這裏有+2嗎？

端口/適配器

這很可能是存在的BizTalk最大的神器 - 恕我直言。將您的物理連接抽象爲衆多具體實現所花費的工作量，尤其是在一個非常大的組織中，其中一些具體實現通過基本文件系統（比如SOAP/REST和IBM Mainframe和MSMQ）。 BizTalk的物理端口適配器，在向工作流發送消息之前通過轉換自動運行原始數據，非常簡單，優雅。

相比之下，與WF，我沒有那種豪華的內置，所以我錯過了什麼或BizTalk有+3在這裏？

的BizTalk未來

最後，我想提一提，從我的研究在同一支球隊中所建立起來的BizTalk人們正在建設WF - 這是偉大的！此外，微軟的長期願景是這個新的熱門詞彙「集成服務器」，實際上是一系列鬆散耦合的框架，提供了BizTalk今天所做的。由於Azure的努力，這一努力對我來說很有意義 - 我相信這是對此做出的貢獻。然而，我需要實現一個解決方案今天將從現在起15年工作，但我還需要了解如果我通過BizTalk利用WF，我將不得不使用哪些組件。請向我提供您的經驗。

Answer 1

（免責聲明 - 我的WF經驗僅限於WF3。0，所以我可能會落後於最近的WF開發）

BizTalk最適合於系統間，部門間和公司間的集成+業務流程工作流程（BPEL） - 即企業問題。 迄今爲止，IMO WF已經定位了更多的內部系統或應用問題。 但無疑，越來越多的灰色地帶正在向Azure + Appfabric方向發展。

看來你在尋找WF進行整合？

轉換 - 無疑在BizTalk一件好事 - 因爲你可以在XSLT映射無論是視覺上或直接，你可以快速變換的端口或業務流程的信息格式，並留下作爲一種事後的物理技術 - 即你可以在邏輯層面上實現您的設計，並且不會陷入任何特定技術（MQ，WCF，SQL，FTP等）中。

一個警告 - 管理模式可能會變得非常痛苦 - 每條消息都有一個模式，它需要BizTalk上所有應用程序的唯一XMLNS＃Root。你可以是'不可知論的'，並且爲你的內部流程使用規範的模式 - 所以需要好的命名，配置和管理規則。 如果將BizTalk耦合到很多WCF/WebService服務，則架構管理變得尤其繁重 - 將爲每個所使用的服務提供一個請求和響應模式（如果使用MessageContract，您可以共享公共模式）。

綁定 - 你幾乎得到它。另外，如果使用直接（消息框）綁定，則可以選擇有多個傳入接收位置，或通過簡單地添加具有適當過濾器的新端口來發送目標。這種pub-sub功能構成了Bizalk ESB工具包的基礎。不同環境的綁定（Dev，UAT，Prod等）也很好地管理。

適配器 - 同意 - 從文件切換到MQ系列與更改端口配置一樣簡單。 BizTalk與MSMQ和IBM MQ很好地協作。此外，請不要低估管理和維護EAI/BP解決方案的努力量 - 集成通常對企業至關重要，跟蹤錯誤並避免停機是至關重要的。的BizTalk具有以下業務優勢：

• 運營管理 - 跟蹤/跟蹤，管理掛起的消息的，SCOM集成包，等等
• 可伸縮性/集羣/故障轉移功能，適配器重試，自動節流等
• 業務監控和三項賽 - BAM

IMO大 '缺點' 到BizTalk是：

• 成本
• 加速時間變得熟練的發展（BTS有它的怪癖，例如，殭屍和XLS和XML文件定義BAM定義）
• 加速時間爲網絡/管理專業人員得到熟練的運營管理

底線：如果你是2級或3的應用程序之間做整合的小非關鍵性消息的數量然後是專有或WF路由，但是如果您正在尋找企業範圍的解決方案，像BizTalk這樣的EAI/BPEL引擎將是前進的方向。

Answer 2

好帖子和答案。

現在WF Manager是否可用，人們是否開始看到客戶將WF用於集成項目？以前的ID從來沒有真正看到任何人認爲WF + WCF除了小規模或小生境之外的任何東西，因爲缺乏成熟的託管環境。人們開始看到現實世界的變化嗎？

我還可以在stuart提及的缺點上添加我的觀點。我不同意100％的評論。

• 成本

成本不是一樣大問題，因爲它曾經是。 Azure上的BizTalk可以爲您改變這種情況，因此您可以在模型中使用付費設置。雖然當您考慮解決方案類型的範圍時仍然存在許可證費用（每月），那麼您可以構建其不錯的性價比。我認爲人們經常難以量化定製構建解決方案的成本，並且只是假設，因爲biztalk獲得了許可證，它必須更昂貴。當人們爭論BizTalk的成本時，我經常問他們爲什麼會使用Sharepoint進行協作，只要他們可以使用共享文件夾和電子郵件。我認爲成本是相對的，對於一些公司來說，如果你只有幾個整合流程，它可能比你會得到的價值更多，但對於其他公司而言，它可能是一筆很好的投資。

• 緩升/開發

我同意的BizTalk是一家專門技能，但它不是真的那麼不同，以在任何其他平臺的開發人員。有時候一家公司希望把一個沒有經驗的.net開發人員加入到分享點或動態CRM中，然後想知道他們爲什麼會犯錯誤，你不需要成爲一名真正的genuis。有一些很好的資源可以幫助你成爲一名biztalk開發者，尤其是與某些競爭對手的產品相比，id認爲這是一種超越WF的力量，我認爲。關於BizTalk開發的關鍵風險是，如果你不知道你在做什麼，你可以很容易地做到這一點。這是該行業常見的錯誤，但是我已經看到這與其他平臺實現已經完成了很多次

（關於「WF作爲競爭對手」的注意事項我將WF視爲BizTalk的子集上的競爭對手，但長期我想他們會相互補充一些情況太）

• 斜坡上升/聯繫

這個心不是真的，你會被引入任何新產品有什麼不同，你的公司需要一起工作您的IT專業人員爲了讓他們能夠支持和維護您使用過的任何產品。獲得一個好的BizTalk管理員並不是最容易的事情，但是有很多資源用於培訓人員，並且如果您想將它外包，可以在此空間中提供合作伙伴。

雖然WF是一個簡單的產品我不是很確定，從管理員的角度執行這方面將是一大堆簡單。你仍然需要一個SQL Server的地方，這將表現得非常好。管理員的WF工具還不夠成熟，我不認爲WF管理的支持空間已經成熟。

你可能想簽出低於賬面其中有一個場景一章（7我認爲），他們考慮的BizTalk或WF + AppFabric中，一些有趣的討論點

http://www.packtpub.com/applied-architecture-patterns-microsoft-platform/book#chapter_7