BizTalk 2009 ESB Confusion

做~自己de王妃 提交于 2019-12-04 08:42:47

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.

I'm only addressing only your second question:

2) Why do you need itineraries, can you not simply create the same using ports and orchestrations? I am obviously missing something here.

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

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.

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 :)

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!