BizTalk 2009 ESB Confusion

Question

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:

1. What is the difference between an "on-ramp" and a "receive port"?
2. 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:

1. Do all messages still have to go through the Message Box?

Thanks in advance for any insight.

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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.