的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入口坡道取代/改变行程。