BizTalk 2009 ESB混乱

我对BizTalk有一点经验，正在尝试不使用BizTalk 2009 ESB Toolkit 2来理解它。首先，我想知道是否有人能为我澄清几个概念：

“入口匝道”和“接收端口”之间的区别是什么

为什么您需要行程，您不能简单地使用端口和业务流程创建相同的行程吗？很明显，我遗漏了一些东西

还有几个更一般的问题：

所有消息是否仍必须通过消息框

---

提前感谢您提供的任何见解。

对于一般问题，根据我的记忆，是的，所有消息都通过消息框发送。但我一直在使用BizTalk 2006 R2。看这幅画

---

至于另外两个问题，我自己从来没有完全弄明白。我现在没有时间调查，但如果没有人告诉我们，我可能会这么做：）

我只想回答你的第二个问题：

2） 你为什么需要行程，可以吗 您不能简单地使用 端口和编排？我是 显然这里遗漏了什么

在我上次工作的地方，我们在ESB上工作了大约一年。 itenary的思想是，当消息进入ESB时，它应该神奇地按照正确的顺序进入适当的系统

对于面向业务流程（BPM）的系统，您通常编写编排来指导逻辑流。换句话说，您可以在编排中对消息的行程或路径进行编码。在我们构建的ESB中，业务规则决定了消息的去向。我们仍然有用于端点的编排，但它们通常很短，只进行映射和一些非常基本的功能。在我工作过的其他地方，编排可能相当大

因此，处理消息的规则必须在某个地方。在ESB中，每个端点都应该是完全不可知的，并且不知道其他端点。ESB阵营假定系统需要更动态地更改，而无需重新部署软件（即编排）。因此，使用我们的ESB，您可以更改业务规则并重新部署它们

ESB的一些棘手问题是处理事务、回滚以及通常创建一个常见的错误处理过程

尼尔·沃尔特斯

---

坡道上

入口是基于web服务的接收端口，但它们有点不同，因为它们接受通用XML消息。然而，这些消息将有一个非常特殊的SOAP头（如果您愿意，则为“信封”），它具有所有必要的属性，例如使消息行程成为可能，您可以通过查看“EsbEnvGeneric.xsd”找到所有可能的头

行程

我喜欢这方面的NealWalter回复。不过，我想补充一点，信息行程法可能会节省大量的时间和开发工作。它可以使组织更加敏捷，并简化流程中的更改。如果我们不必开发和部署一个全新的编排，而只需更改一些配置并使用我们现有的位，那么当然可以节省大量时间。在我看来，这是ESB和消息行程的最大价值

消息框

---

BizTalk中的消息必须始终通过消息框发送。在下一个版本中，MS一直在暗示BizTalk中存在低延迟的情况-也许这样我们可以获得更多的控制，但现在消息在通过BizTalk的过程中会被多次持久化，这一点没有什么关系。

还有一些其他视图-

接收端口/接入端口-完全同意Riri的回答，只需添加一个-BizTalk ESB应用程序上下文中的接入端口是接收端口的具体实现；子集；私人案件。它使用一个接收端口来实现来自ESB世界的模式；因此，它们本身并没有什么不同

行程-再次-同意Neal和Riri的意见，并在回答您的问题时添加-BizTalk ESB可以以不同的方式使用行程-一个“组合”客户端可以通过请求消息交付请求的行程；不太复杂的客户机可以简单地传递消息，而ESB基础设施（或者更确切地说，您的实现）可以解析特定请求的相关行程（这可以使用现成的或自定义的解析器来完成，它们将使用不同的方法来决定需要哪个行程）。

---

理论上，如果客户机提供行程，但ESB入口匝道替换/更改了行程，则两者也可以结合起来。

感谢您的响应。是否将行程附加到邮件中？如果是，如何处理行程中的下一步？我想我有点困惑了。我们基于BizTalk开发了自己的自定义ESB。所有传入的数据都映射到一个通用（规范格式），该格式有一个标头，用于标识数据的内容和来源。然后，我们有了一个ESB编排，它将通过检查业务规则、更改头、然后通过直接绑定将消息动态发送到其他编排（由规则确定）来处理消息。当该orch完成时，它将再次调用规则，直到没有返回任何操作为止。我不确定行程如何与Microsoft的ESB指南配合使用。我被告知，您可以避免在2009和ESB中使用消息框，这就是我问这个问题的原因。谢谢