BizTalk 2009 ESB混乱

Question

我对BizTalk有一点经验，并试图在不使用它的情况下理解BizTalk 2009 ESB Toolkit 2。首先，我想知道是否有人可以为我清理一些概念：

1. “入口匝道”和“接收端口”有什么区别？
2. 为什么需要行程，你能不能简单地使用端口和编排创建相同的东西？我显然在这里遗漏了一些东西。

一些更普遍的问题：

1. 所有消息是否还必须通过消息框？

提前感谢任何见解。

Answer 1

我只是解决你的第二个问题：

  

2）为什么你需要行程，可以   你不是简单地创建相同的使用   端口和编排？我是   显然在这里遗漏了一些东西。

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

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

因此，有关消息的规则必须在某处。在ESB中，每个端点应完全不可知，并且不知道其他端点。 ESB阵营假设系统需要更加动态地进行更改，而无需重新部署软件（即业务流程）。因此，使用我们的ESB，您可以更改业务规则并重新部署它们。

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

Neal Walters http://BizTalk-Training.com

Answer 2

在坡道

on-ramps 是基于Web服务的接收端口，但它们有点不同，因为它们接受通用XML消息。然而，这些消息将有一个非常特殊的SOAP标头（如果你愿意的话，还有一个“信封”），它具有所有必要的属性，例如消息行程可能，你可以通过查看“EsbEnvGeneric.xsd”找到所有可能的标题< / p>

<强>行程

我喜欢NealWalter对此的回复。我只是想添加消息行程方法可以节省 很多 的时间和开发工作。它可以使组织更加灵活，并简化其流程的变化。如果我们不必开发和部署一个全新的业务流程，但只需更改一些配置并使用我们现有的位，这当然可以节省大量时间。这是我看到的ESB和消息行程中的重要价值。

消息框

BizTalk中的消息始终必须通过消息框进行。在下一个版本中，MS一直在暗示BizTalk中的低延迟情况 - 也许我们可以获得更多的控制权，但是现在消息可以通过BizTalk多次持续存在，而且没有任何关于这一点。 / p>

Answer 3

其他一些观点 -

接收端口/ on-ramps - 完全同意Riri的回答并简单地添加 - 在BizTalk ESB应用程序的上下文中的on-Ramp是接收端口的特定实现;一个子集;私人案件。它使用接收端口来实现ESB世界的模式;所以 - 它们本身并没有什么不同。

行程 - 再次 - 同意Neal和Riri并且会在回答您的问题时添加 - BizTalk ESB可以以不同的方式使用行程 - 一个'clued-up'客户端可以提供请求行程和请求消息;一个不那么简单的客户端可以简单地传递一条消息，ESB基础设施（或者更确切地说 - 您的实现）可以解决特定请求的相关行程（这可以使用解析器，开箱即用或自定义，将使用不同的方法来决定需要哪个行程）。 从理论上讲，这两者也可以在客户提供行程的地方进行组合，但ESB入口会替换/更改它。

Answer 4

对于一般问题，从我记忆中，是的，所有消息都将通过消息框进行。但我一直在使用BizTalk 2006 R2。看一下图片here。

对于另外两个问题，我从未完全弄明白自己。我现在没有时间进行调查，但如果没有人启发我，我可能会这样做：）