BizTalk 2009 ESB 混乱
我对 BizTalk 有一点经验，并且正在尝试在不使用 BizTalk 2009 ESB Toolkit 2 的情况下理解它。首先，我想知道是否有人可以为我澄清几个概念：
- “入口匝道”和“接收端口”有什么区别？
- 为什么需要行程，难道不能简单地使用端口和编排创建相同的行程吗？我显然在这里遗漏了一些东西。
几个更一般的问题：
- 所有消息是否仍然必须通过消息框？
预先感谢您的任何见解。
I have a little experience with BizTalk and am trying to understand BizTalk 2009 ESB Toolkit 2 without using it. Firstly, I am wondering whether anyone can clear up a couple of concepts for me:
- What is the difference between an "on-ramp" and a "receive port"?
- Why do you need itineraries, can you not simply create the same using ports and orchestrations? I am obviously missing something here.
A couple of more general questions:
- Do all messages still have to go through the Message Box?
Thanks in advance for any insight.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我只回答你的第二个问题：
在我工作的最后一个地方，我们在 ESB 上工作了大约一年。
迭代的想法是，当消息进入 ESB 时，它应该神奇地以正确的顺序到达适当的系统。
对于面向业务流程 (BPM) 的系统，您通常会编写编排来指导逻辑流。换句话说，您可以在编排中对消息的行程或路径进行编码。在我们构建的 ESB 中，业务规则决定消息的去向。我们仍然对端点进行编排，但它们通常很短，并且只进行映射和一些非常基本的功能。在我工作过的其他地方，编排可能相当大。
因此，必须在某个地方制定如何处理消息的规则。在 ESB 中，每个端点应该完全不可知并且不知道其他端点。 ESB 阵营认为系统需要更加动态地改变，而不必重新部署软件（即编排）。因此，使用我们的 ESB，您只需更改业务规则并重新部署它们即可。
ESB 的一些棘手问题是处理事务、回滚以及通常创建公共错误处理流程。
尼尔·沃尔特斯
http://BizTalk-Training.com
I'm only addressing only your second question:
At the last place I worked, we worked on our ESB for about a year.
The idea of the itenary is that when a message comes into the ESB, it should magically go in the right sequence to the appropriate systems.
With a Business Process Oriented (BPM) system, you typically write an orchestration to direct the flow of logic. In other words, you code the itinerary or path of the message in the orchestration. In the ESB that we built, the business rules decided where the message would go. We still had orchestrations for end-points, but they typically were short and only did mapping and some very basic functionality. In other places I've worked, the orchestrations can be quite large.
So the rules of what to do with the message have to be somewhere. In the ESB, each end-point should be totally agnostic and unaware of the other end-points. The ESB camp presumes that the system needs to change more dynamically without having to redeploy software (i.e. orchestrations). So with our ESB, you could just change the business rules and redeploy them.
Some of the tough issues with an ESB are dealing with transactions, rollback, and usually creating a common error-handling process.
Neal Walters
http://BizTalk-Training.com
入口
入口是基于Web 服务的接收端口，但它们有点不同，因为它们接受通用XML 消息。然而，消息将有一个非常特殊的 SOAP 标头（如果您愿意的话，可以是一个“信封”），其中包含使消息行程成为可能所需的所有必要属性，您可以通过查看“EsbEnvGeneric.xsd”
< strong>行程
我喜欢 NealWalter 对此的回复。不过，我只是想添加消息行程方法，可以节省大量时间和开发工作。它可以使组织更加敏捷并轻松地改变流程。如果我们不必开发和部署全新的编排，而只需更改一些配置并使用现有的部分，那当然可以节省大量时间。在我看来，这是 ESB 和消息行程的巨大价值。
消息框
BizTalk 中的消息始终必须通过消息框传递。在下一个版本中，MS 一直在暗示 BizTalk 中的低延迟场景 - 也许那时我们可以获得更多的控制权，但是更多，但目前消息在通过 BizTalk 的过程中会被持久化很多次，对此没有什么可说的。
On-ramps
The on-ramps are web service based receive port but they are a bit different as they accepts generic XML messages. The messages will however have a very special SOAP header (a "envelope" if you will) with all the necessary properties to make for example message itinerary possible, You'll find all the possible header by having look in "EsbEnvGeneric.xsd"
itineraries
I like NealWalter reply on this on. I however just like to add the message itinerary approach can potential save a lot of time and development effort. It can make an organizations more agile and ease change in their processes. If we don't have to develop and deploy a whole new orchestration but only change some configuration and use our existing bits that can of course save a lot of time. And this is the big value in a ESB and message itinerary as I see it.
Message Box
Messages in BizTalk always have to go via the message box. In the next version MS have been hinting about a low latency scenario in BizTalk - maybe then we can gain a bit more control, But more but for now messages get persisted many times on their way through BizTalk and there is nothing to about that.
几个额外的观点 -
接收端口/入口 - 完全同意 Riri 的答案，只需添加 - BizTalk ESB 应用程序上下文中的入口是接收端口的特定实现;一个子集；一个私人案件。它使用接收端口来实现 ESB 世界中的模式；所以 - 它们本身并没有不同。
行程 - 再次同意 Neal 和 Riri 的观点，并在回答您的问题时补充一下 - BizTalk ESB 可以以不同的方式使用行程 - “线索明确”的客户端可以通过以下方式交付所请求的行程：请求消息；不太了解的客户端可以简单地传递消息，ESB 基础设施（或者更确切地说 - 您的实现）可以解析特定请求的相关行程（这可以使用解析器、开箱即用或定制，这将使用不同的方法来决定需要哪个行程）。
理论上，两者也可以结合起来，即客户提供行程，但 ESB 入口匝道替换/更改它。
A couple of additional views -
Receive ports / on-ramps - completely agree with Riri's answer and would simply add - an on-Ramp in the context of a BizTalk ESB application is a specific implementation of a receive port; a subset; a private case. it uses a receive port to implement a pattern from the ESB world; so - they are not different per-se.
Itineraries - again - agree with both Neal and Riri and would add, in response to your question - the BizTalk ESB can use itineraries in different ways - a 'clued-up' client can deliver the requested itinerary with the request message; a less clued-up client can simply deliver a message, and the ESB infrastructure (or rather - your implementation of it) could resolve the relevant itinerary for the specific request (this can be done using resolvers, out-of-the-box or custom, which would use different methods to decide which itinerary is needed).
Theoretically the two can also be combined where the client provides an itinerary but the ESB on-ramp replaces/changes it.
对于一般性问题，据我所知，是的，所有消息都通过消息框发送。但我一直在使用BizTalk 2006 R2。请查看此处的图片。
对于另外两个问题，我自己从来没有完全弄清楚。我现在没有时间调查，但如果没有人启发我们，我可能会这样做:)
For the general question, from what I remember, yes, all messages are going trough the message box. But I have been using BizTalk 2006 R2. Look at the picture here.
For the two other question, I never completely figured it out myself. I don't have the time to investigate right now, but I'll probably do it if no one enlighten us :)