我对 BizTalk 有一点经验，我想在不使用它的情况下理解 BizTalk 2009 ESB Toolkit 2。首先，我想知道是否有人可以为我澄清几个概念：
几个更一般的问题：
提前感谢您的任何见解。
【问题讨论】：
标签： biztalk esb biztalk-2009
对于一般问题，据我所知，是的，所有消息都通过消息框发送。但我一直在使用 BizTalk 2006 R2。看图here。
对于另外两个问题，我自己从来没有完全弄清楚。我现在没有时间调查，但如果没有人启发我们，我可能会这样做:)
【讨论】：
我只回答你的第二个问题：
2) 为什么需要行程单，可以 你不是简单地使用 端口和编排？我是 显然这里遗漏了一些东西。
在我工作的最后一个地方，我们在 ESB 上工作了大约一年。 itenary 的想法是，当一条消息进入 ESB 时，它应该神奇地以正确的顺序进入适当的系统。
对于面向业务流程 (BPM) 的系统，您通常会编写一个编排来指导逻辑流。换句话说，您在编排中对消息的行程或路径进行编码。在我们构建的 ESB 中，业务规则决定了消息的去向。我们仍然有端点编排，但它们通常很短，只做映射和一些非常基本的功能。在我工作过的其他地方，编排可能非常大。
因此，处理消息的规则必须在某个地方。在 ESB 中，每个端点都应该是完全不可知的，并且不知道其他端点。 ESB 阵营假定系统需要更动态地更改，而无需重新部署软件（即编排）。因此，使用我们的 ESB，您只需更改业务规则并重新部署它们。
ESB 的一些棘手问题是处理事务、回滚以及通常创建一个常见的错误处理过程。
尼尔·沃尔特斯 http://BizTalk-Training.com
【讨论】：
入口
入口坡道是基于网络服务的接收端口，但它们有点不同，因为它们接受通用 XML 消息。但是，这些消息将具有一个非常特殊的 SOAP 标头（如果您愿意，可以是一个“信封”），具有所有必要的属性，例如使消息行程成为可能，您将通过查看“EsbEnvGeneric.xsd”找到所有可能的标头
行程
我喜欢 NealWalter 对此的回复。然而，我只是想添加消息行程方法可以潜在地节省很多时间和开发工作。它可以使组织更加敏捷并简化其流程的变化。如果我们不必开发和部署全新的编排，而只需更改一些配置并使用我们现有的位，当然可以节省大量时间。在我看来，这是 ESB 和消息路线中的重要价值。
消息框
BizTalk 中的消息始终必须通过消息框。在下一个版本中，MS 一直在暗示 BizTalk 中的低延迟场景 - 也许那时我们可以获得更多的控制权，但更多的是，但现在消息在通过 BizTalk 的过程中会被持久化很多次，对此没有任何意义。
【讨论】：
几个额外的视图 -
接收端口/入口通道 - 完全同意 Riri 的回答，并且会简单地添加 - BizTalk ESB 应用程序上下文中的入口通道是接收端口的特定实现；一个子集；一个私人案件。它使用接收端口来实现来自 ESB 世界的模式；所以 - 它们本身并没有什么不同。
行程 - 再次 - 同意 Neal 和 Riri 的观点，并会在回答您的问题时补充说 - BizTalk ESB 可以以不同的方式使用行程 - 一个“成熟的”客户端可以提供使用请求消息请求的行程；不太熟悉的客户端可以简单地传递消息，ESB 基础架构（或者更确切地说 - 您的实现）可以解决特定请求的相关行程（这可以使用解析器完成，开箱即用或自定义，它将使用不同的方法来决定需要哪个行程）。 从理论上讲，如果客户提供行程但 ESB 入口会替换/更改行程，这两者也可以结合使用。
【讨论】：