5

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

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

几个更一般的问题：

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

提前感谢您的任何见解。

4

4 回答 4

5

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

2) 为什么你需要路线，你能不能简单地使用端口和编排创建相同的路线？我显然在这里遗漏了一些东西。

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

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

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

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

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

于 2009-10-12T17:49:35.407 回答
4

入口匝道

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

行程

我喜欢 NealWalter 对此的回复。然而我只是喜欢添加消息路线的方法可以潜在地节省大量时间和开发工作。它可以使组织更加敏捷并简化其流程的变化。如果我们不必开发和部署全新的编排，而只需更改一些配置并使用我们现有的位，当然可以节省大量时间。在我看来，这是 ESB 和消息路线中的重要价值。

消息框

BizTalk 中的消息始终必须通过消息框。在下一个版本中，MS 一直在暗示 BizTalk 中的低延迟方案——也许那时我们可以获得更多的控制权，但更多的是，但现在消息在通过 BizTalk 的过程中会被持久化很多次，对此没有任何意义。

于 2009-10-17T04:37:48.477 回答
2

几个额外的观点 -

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

行程- 再次 - 同意 Neal 和 Riri 并会添加，以回应您的问题 - BizTalk ESB 可以以不同的方式使用行程 - 'clued-up' 客户端可以通过请求消息传递请求的行程；不太熟悉的客户端可以简单地传递消息，ESB 基础架构（或者更确切地说 - 您的实现）可以解决特定请求的相关行程（这可以使用解析器完成，开箱即用或自定义，它将使用不同的方法来决定需要哪个行程）。从理论上讲，这两者也可以在客户端提供行程但 ESB 入口替换/更改它的情况下结合使用。

于 2009-11-09T08:48:15.593 回答
0

对于一般问题，据我所知，是的，所有消息都通过消息框发送。但我一直在使用 BizTalk 2006 R2。看这里的图片。

对于另外两个问题，我自己从来没有完全弄清楚。我现在没有时间调查，但如果没有人启发我们，我可能会这样做:)

于 2009-10-12T17:20:18.210 回答