的BizTalk 2009年ESB混亂

Question

我與BizTalk一點點經驗，想了解2009年的BizTalk ESB工具包2不使用它。首先，我想知道是否有人可以爲我清除幾個概念：

1. 「on-ramp」和「接收端口」之間的區別是什麼？
2. 爲什麼你需要行程，你不能簡單地使用端口和編排來創建相同的行程嗎？我顯然在這裏錯過了一些東西。

一對夫婦的更普遍的問題：

1. 做所有的消息還是要通過消息框？

預先感謝任何見解。

Answer 1

入口坡道

的匝道是基於 Web服務接收端口，但他們有點不同，因爲他們接受通用的XML消息。然而，這些消息會有一個非常特殊的SOAP頭（如果你願意的話，可以是一個「信封」），並具有所有必要的屬性，例如消息行程的可能性，你可以通過查看「EsbEnvGeneric.xsd」

行程

我喜歡NealWalter對這個答覆的。然而我只是想添加消息的行程方式可以節省很多的時間和開發工作量。它可以使組織更靈活，並且緩解他們流程中的變化。如果我們不需要開發和部署一個全新的業務流程，只需要改變一些配置並使用我們現有的部分，那當然可以節省很多時間。在我看來，這是ESB和消息行程中的重要價值。

消息框

在BizTalk消息始終必須通過消息框去。在下一個版本中，MS一直暗示着BizTalk中的低延遲情況 - 也許那時我們可以獲得更多的控制權，但是更多，但是現在消息在通過BizTalk的途中持續多次，並且沒有什麼關於此的。

Answer 2

對於一般性的問題，從我記得，是的，所有的消息都將會槽的消息框。但是我一直在使用BizTalk 2006 R2。看圖片here。

對於另外兩個問題，我從來沒有完全明白自己。我沒有馬上進行調查的時候，但我可能會做的，如果沒有人指點迷津:)

Answer 3

我只是隻解決你的第二個問題：

2）爲什麼你需要行程， 你不是簡單地創建使用 端口和編排？我是 顯然在這裏丟失了一些東西。

在我工作的最後一個地方，我們在ESB上工作了大約一年。 itenary的想法是，當一條消息進入ESB時，它應該以正確的順序神奇地進入適當的系統。

隨着面向業務流程（BPM）系統中，通常寫業務流程以引導邏輯的流動。換句話說，您在編排中編碼消息的行程或路徑。在我們構建的ESB中，業務規則決定了消息的去向。我們仍然爲端點進行編排，但它們通常很短，只做了映射和一些非常基本的功能。在我工作過的其他地方，編排可能會很大。

那麼如何處理此消息後的規則必須某處。在ESB中，每個端點應該完全不可知且不知道其他端點。 ESB陣營假定系統需要動態更改，而無需重新部署軟件（即編排）。所以使用我們的ESB，您可以更改業務規則並重新部署它們。

一些與ESB的棘手問題正在處理交易，回滾，通常創建一個共同的錯誤處理過程。

尼爾·沃爾特斯 http://BizTalk-Training.com

Answer 4

了一些額外的意見 -

接收端口/入口匝道 - 與莉莉的答案完全一致，並會簡單地添加 - 入口匝道在BizTalk ESB應用的上下文是具體實施一個接收端口;子集;私人案件。它使用接收端口來實現ESB世界的模式;所以 - 他們沒有不同。

路線 - 再 - 同意這兩個尼爾和莉莉，還將增加，在回答您的問題 - 在BizTalk ESB可以使用不同的方法行程 - 一「避讓了」客戶端可以與提供所要求的行程請求消息;一個不那麼簡單的客戶端可以簡單地發送消息，而ESB基礎架構（或者說 - 您的實現）可以解決特定請求的相關行程（這可以通過解析器，開箱即用習慣，這將使用不同的方法來決定需要哪個行程）。 理論上，兩者也可以結合在客戶提供行程的地方，但ESB入口坡道取代/改變行程。