Biztalk運行時的結構數據庫
BizTalk Server 本質上就是消息處理引擎。我的認爲在瞭解Biztalk以前必需要知道的一部分即是BizTalk Server 的總體架構,只有對架構爛熟於心這樣才能爲往下深刻學習作好基礎。架構
首先來看一下Biztalk的總體架構圖ide
如上圖所示,完整的繪製了Biztalk在接受端口接收到文件後整個處理文件的過程。學習
接下來分開敘述:(參照微軟官方文檔)spa
接收端口和接收位置3d
「接收端口」是一個或多個接收位置的集合,是BizTalk Server 的特定入口點。「接收位置」是接收消息的單個終結點(URL) 的配置。該位置包含接收適配器和接收管道的配置信息。「適配器」負責接收消息的傳輸和通訊部分。代理
「發送端口」是發送管道和發送適配器的組合。發送端口組是發送端口的集合,做用很像電子郵件分發列表。發送到發送端口組的消息將被髮送到該組中的全部發送端口。發送管道用於準備來自 BizTalk Server 的消息以將其傳輸到其餘服務。發送適配器負責使用特定協議實際發送消息。orm
業務流程能夠經過 MessageBox 訂閱(接收)和發佈(發送)消息。此外,業務流程能夠構造新的消息。使用已討論過的訂閱和路由機制接收消息。在填入業務流程的訂閱後,將激活新的實例並傳送消息;對於實例訂閱,若有必要,將解除對該實例的凍結,而後傳送消息。若是從業務流程發送消息,則這些消息將發佈到 MessageBox,發佈的方式如同消息到達接收位置,相應的屬性將插入數據庫以用於路由對象
BizTalk Server 中發佈/訂閱引擎的核心是 MessageBox 數據庫。MessageBox 由兩個組件構成:一個或多個 Microsoft SQL Server 數據庫和消息代理。SQL Server 數據庫爲許多對象(包括消息、消息屬性、訂閱、業務流程狀態、跟蹤數據和用於路由的主機隊列)提供持久化存儲blog
適配器的做用
接收適配器經過讀取數據流和建立消息來啓動接收消息的過程。例如,文件適配器發現某文件已置於其配置的位置中,而後在流中讀取該文件。 適配器將建立消息(Microsoft.BizTalk.Message.Interop.IBaseMessage接口實現)、向該消息添加部分(Microsoft.BizTalk.Message.Interop.IBasePart接口實現)、而後將數據流做爲該部份內容進行提供。
此外,適配器還將寫入和升級到與位置、適配器類型以及其餘內容(與適配器相關)相關的消息上下文屬性。在建立消息及其上下文後,適配器將消息傳遞到終結點管理器。 而後,經過爲接收位置配置的接收管道處理該消息。 在消息由管道處理後,終結點管理器使用消息代理髮布該消息前,使用映射將消息轉換爲所需格式。
儘管初始消息是由適配器建立的,但對收到消息的處理過程大部分發生在接收管道中。管道處理針對消息內容以及消息上下文。 消息內容一般在解碼、拆裝和驗證階段進行處理,而對消息上下文的處理則可發生在全部階段。 可是,管道無需做用於內容或上下文。例如,默認的直通管道並未配置任何組件而且不會對消息內容或上下文進行處理。 爲簡單起見,此文檔將重點介紹拆裝組件,由於這些組件一般對消息路由的影響最大。
拆裝器的工做是處理來自適配器的傳入消息並將其拆裝成多個消息,以及對消息數據進行解析。在傳入消息具備多個較小的消息時,稱爲交換。 經過使開發人員可以配置與包裝內容(即,平面文件拆裝器的頭部架構和尾部架構以及 XML 拆裝器的信封架構)以及(可能重複)正文內容有關的信息,平面文件拆裝器和 XML拆裝器能夠處理交換。 此外,這兩種拆裝器均可將原始消息解析爲 XML 內容。 若是在 BizTalk Server 中不須要作進一步的 XML 處理,則自定義拆裝器無需將內容解析爲 XML。 示例方案包括簡單的路由方案,在此方案中,在特定接收位置進入系統的消息將發送到不具備映射或其餘基於 XML 的處理的特定發送端口
下一章(主機、主機實例)