絕大多數現代業務流程都或多或少地依賴於其它軟件。盡管其中部分流程僅由單個應用程序支持，但其他許多業務流程都依賴於不同的軟件系統。在許多情況下，已使用不同的技術在不同時間、不同平台上創建了此軟件。若要使這些業務程序實現自動化，則需要連接不同系統。BizTalk 可以將不同的系統組合到有效的業務流程中，有效的解決企業應用集成的問題。
BizTalk支持如下兩種方式的應用程序集成，即企業應用程序集成 (EAI)和企業對企業 (B2B) 集成；
企業應用程序集成(EAI)用於連接單個組織內的應用程序。
圖-1 企業應用程序集成 (EAI)
企業對企業 (B2B) 集成，用於連接不同組織中的應用程序。
圖-2 企業對企業 (B2B) 集成
應用程序集成歷史及集成模型
為了更好的理解biztalk server 和它帶來的益處，我們來簡單的了解一下應用程序集成的發展過程，這樣可以更好的了解biztalk的設計模型。在很早以前，每個單位組織使用的都是單獨的軟件。這些軟件產生的相互隔離的信息用來滿足特殊的需求，比如財務管理和資源管理。它們彼此是自包含的無需進行交互。這個時候的集成包括冗余數據條目(redundant data entry)（轉椅集成(swivel-chair)）和文件轉儲(file dumps)等，簡單的將信息從一個系統轉移到另外一個系統。應用程序之間的壁壘森嚴，真正的無縫集成很少，同時也很難實現。
隨着時間的推進，不同的組織單位使用的應用程序通過點對點的集成方式聯系越來越緊密。數據可以更方便的在不同的應用程序之間流動。然而，要實現這種集成方案需要耗費大量的時間和精力。不同的軟件開發人員需要通力合作建立技術約定、共享數據模型、交互的方案和協議等。
圖-3 點對點應用程序集成模型
盡管實現實現成本比較高，但點對點集成模型仍然流行起來了。然而，這種模型有一些劣勢和固有的脆弱性。如果一個系統的約定改變了，那么其他每個連接的系統也必須進行改變。隨着集成節點的增多，點對點集成將變得很難管理（如圖-4），這樣強迫相關的組織單位將更多的IT資源用於集成的維護工作而不是解決新的和緊急的業務需求。隨着單點連接數目的增多，該節點的版本管理意味着隨客戶端數目增加而不斷更新。版本管理和最終遺棄一些系統，這些在最初的設計時往往並沒有考慮到，從而導致了成本和風險的增加。
圖-4 復雜的點對點集成
隨着時間的推進，點對點集成中引入了hub-and-spoke模型(如-5)。在這個模型中，消息需要先發布到中心的hub服務，然后由hub服務將消息發送給其他的接收者。現在消息的發送者和接收者的關系可以通過配置或者發布訂閱規則進行定義。這個模型使發布消息的應用程序無需關注接收者，消息接收者也無需關注發送者。
圖-5 hub-spoke模型
假如一個在線的訂單處理系統接收到了訂單並向hub服務發送消息。一個數據倉庫執行系統可以訂閱這些消息並在接受到消息的時候進行處理。現在這兩個應用程序的操作時相互獨立的。他們之間是松耦合的、它們彼此之間沒有進行直接的交互。所有的消息交互都是通過中心的hub，而且它們也不需要知道對方是否存在。現在考慮一個銷售跟蹤的商業智能應用程序。它也可以訂閱相同的訂單消息並獨立的進行處理，並不需要知道其他兩個程序的存在。
在這個模型中，共享的約定信息還是需要的。如果在線的訂單處理系統更改了訂單的結構化定義，必須要有相關的策略保證任何訂閱者的正常運行。這可以通過一個合理的版本控制策略進行控制。依賴於具體的實現方案，約定信息可以發布到一個中心部署庫或者hub，這樣可以更方便的進行維護。
圖-6 hub-bus集成模型
Biztalk server 2004引入訂閱發布模型作為混合中心總線架構的一部分，該架構利用消息總線拓撲連接不同的中心輻射模型。在這個中心總線模型中，功能可以分布在多個機器上。每台機器都是一個物理的集線器，它們共享同樣的中心消息總線而不會有單點故障。分布系統的配置都是集中地，如捕獲操作和業務度量等功能。從概念上說，你可以認為一個biztalk server 主機就是一個邏輯中心集線器。單獨的biztalk server 機器運行一個本地實例。這些實例使用消息總線進行協作。總線連接了biztalk的Message Box 和管理配置數據庫以及管理操作的功能和工具。
從功能分層的角度看，biztalk server可以跨越多台機器組合眾多的主機實例提供接受、處理、發送消息的功能。當來自外部源的消息被某個主機實例接收，這些消息會保存在中心的Message Box中。其他的主機實例可以訂閱這些消息並對它們進行處理。一些主機實例可能共享同一個訂閱。在這種情況下，運行在每個機器上的消息代理通過執行協作算法，會自動的選中某個特定的主機實例。完成這些工作后，如果願意，主機實例可以發布經過處理的消息到Message Box以作進一步的路由。另外，主機實例也有可能會給外部目標發送恢復消息。
中心總線架構解決了早先的方式的很多局限性。例如，高度的可伸縮性。你可以通過增加機器增強處理能力，你也可以通過移除機器進行縮減。你可以通過定義新的主機實例並把主機實例放入指定的主機，就可以為不通的功能建立不通的主機。Message Box 、配置數據庫、BAM跟蹤基礎設施都是使用sql server實現的。
這種架構當然也有某些局限性。例如，將集線器進行地理分布往往是不可行的，因為他們共享同一個后端的數據庫同時需要較低的網絡延遲。此外，盡管biztalk server 2004提供的最初的模型支持動態消息路由，但是缺乏對服務總線設計模式的運行時支持。這些模式只能通過在biztalk server 的上層創建額外的自定義功能模塊來實現。Biztalk后續版本會引入ESB Toolkit，以一種統一的方式解決這種需求，並提供一種通用的架構作為動態ESB平台。
BizTalk提供的功能
1. 適配器
不同的系統使用不同的方式發送和接受信息。biztalk通過使用單獨的適配器層分離中心總線模型對此的關注。為了使適配器可以與biztalk server進行交互，biztalk提供了一個管理適配器實例的主機環境，同時也提供了一種編程框架來創建或者擴展現存適配器的功能。除此之外，biztalk為不同的協議、數據庫系統、第三方ERP和CRM等提供了一個開箱即用的擴展類庫。
2. 消息中介
biztalk server使用的模型的一個優勢是為消息中介提供了一個合理的位置。消息中介可以編碼、解碼、校驗和潤色消息。除此之外，消息中介的功能還包括轉換消息的格式、拆分消息、組合消息的能力。biztalk使用管道提供了一種通用的可擴展的框架來擴展消息通道。
消息中介的一個主要的方面就是將消息和有用的元數據進行關聯。這些被稱為消息上下文的元數據被用來路由。消息上下文會隨消息一起穿過消息總線。為了實現徹底的解耦合和更高的性能，訂閱引擎評估消息上下文而不是消息內容。通常的做法是在管道里處理消息，並將相關的值從消息內容中拷貝到上下文中來實現基於內容的路由。
3. 異常處理
Biztalk server提供了很多不同方面的異常處理。例如，當消息不能向外部系統回復時，biztalk內置支持自動重試。消息傳遞期間，失敗的消息可以暫停、發送給一個次級傳輸或者路由到一個異常處理程序。當一個批處理中的一個單獨的消息失敗了，biztalk既可以配置為使整個批處理失敗或者單獨的處理這個失敗的消息。
處在同一個事務中的所有的消息都持久化到Message Box數據庫。這提供了基本的機制實現暫停失敗的消息，以便稍后可以重新提交。使用biztalk的編排特性可以實現更多異常處理的高級模式和錯誤恢復。編排特性基於BPEL標准中支持的Saga模型進行擴展，提供了一種可以實現自定義錯誤處理的邏輯和補償方案的機制。
4. 編排和編制
編排經常被用來實現自動化的處理流程。其可能展現為特定的業務流程或者簡單的自動化信息交換的某些方面。為了更好的分離關注點和重用、促進某些高級形式的消息交換，一個父編排可以分解成不同的子編排。不同的編排可以在單獨的消息總線上通力合作。編排是使用圖形模型驅動開發技術創建的。編排展現了BPEL標准的超集，並且對BPEL進行了增強。
服務編制給編排提供了一種互補的模型。它是之中參與服務之間定義交互協議的非中心化的方法。biztalk通過使用ESB工具管理和創建的路線圖來實現編制。每個路線都代表一個可以擴展和通過中心存儲進行管理的路由策略。路線圖往往與消息關聯，並在管道和編排中使用。它們也可以被非biztalk服務（例如web服務）創建、查詢、消費，從而實現更廣闊的企業級合作模型。
5. 性能和可伸縮性
很多組織單位經常需要處理以便的工作負載，但是又不希望招致大量的額外的話費和擴展重構已存的系統。可以使用很多的技術來實現可伸縮性和提供更好的性能。這些技術包括負載均衡、數據處理分區、分布處理過程等技術。biztalk在內部使用這些技術，同時也支持在外部使用這些技術。
6. 安全性
鑒於業務的需要和客戶的需求，系統常常必須交換敏感的信息。解決方案可能使用傳輸級別或者消息級別的安全機制保護消息或者特定的數據值。它們需要確保敏感數據只能在需要的地方進行解密。
Biztalk提供的開箱即用的適配器提供了傳輸級別的安全。消息級別的安全是通過wcf適配器提供的.WCF適配器也可以用來支持統一身份驗證，一個組織單位的用戶驗證可以通過訪問跨組織托管提供的服務實現，而不是使用集中地用戶賬戶驗證。
解決方案架構通過定義信任邊界來簡化安全模型和減少風險。Biztalk使用不同的邏輯主機實現信息邊界的建模。外部系統可能實現了他們自己的身份驗證和授權機制。即使它們與信心邊界發生沖突，biztalk也必須遵守這些安全模型。鑒於這個原因，biztalk提供了一個單點登錄服務器來將安全主題映射為目標系統需要的憑證。
7.洞察力
集成的環境可以很復雜並且難以理解和管理。技術的細節可以使我們難以檢驗整個解決方案是否滿足業務需求。組織需要洞察了解他們解決方案的狀態、形勢、行為。他們需要監視系統的性能和健康，維護分布式業務活動的審計，確保商業和法規的遵從性。
追蹤和監控提供了基本的分析和洞察的能力。Biztalk提供了工具跟蹤消息流、鑽取每次交互的細節、重啟失敗的交互。BAM框架支持業務管理和通過收集、聚集分布式業務活動中的事件數據的態勢感知。業務規則引擎將決策邏輯從流程和消息流中分離出來單獨管理和修改。規則展現的方式允許它們直接追蹤到業務策略。
8.電子數據交換
集成常常涉及到不通組織間數據的電子交換。Biztalk為使用最廣泛的EDI（電子數據交換）標准提供了擴展支持。它對標准的EDI架構、批處理、確認和其他問題提供了可擴展的、可定制的支持。這些特征連同更新、改進貿易合作伙伴管理的特性使biztalk server 2010擁有捕獲和建模有關貿易伙伴、業務檔案、B2B社區廣泛使用的協議的信息的能力。
9.RFID（無線射頻識別）事件處理
Biztalk提供一個無線射頻識別設備的管理和事件處理平台。這是一個單獨的邊緣的服務器，跟用於消息交換和編排的中心總線架構是不同的。除了支持各種RFID的工業標准，biztalk還提供了一種用來支持部署、管理、監控不通種類的設備的基礎架構和高效靈活的事件過濾和探測的事件處理框架。它同時也提供了像業務規則引擎和BAM等其他的biztalk的特性。Biztalk 2010還支持在RFID手持設備和移動設備上進行傳感應用程序開發。