- This topic has 11 replies, 1 voice, and was last updated 9 years, 3 months ago by
.
-
Posts
-
-
I had a query regarding “Itinerary/routing slip” pattern used in biztalk.
If an Itinerary is attached to the message containing a list of the services which should be used e.g A,B and C etc..
Now who is responsible for routing the message from A to B to C ?
1] Is it “A” who will route to “B” after “A” finishes
2] Or does just “A” finish its work and leaves the message and then “B” comes and picks up the message once “A” finishes.
Im not really clear how this is actually done in Biztalk… as u can see Im a newbie to biztalk ESB [:)] -
It really depends on where you’ve set the services to execute. Most of the time, several services are set to execute in the same location like the receive handler or send handler of a port, in which case the esb dispatcher pipeline component will execute all the services one after the other according to the itinerary scheduled. In those cases, routing isn’t really an issue.
When routing is needed because you’re switching locations (say, you’ve got one service set in the receive handler of the receive port, then move to an off-ramp or to a service in an orchestration), then standard BizTalk Pub/Sub handles it based on the message properties and the subscriptions that ESB on/off-ramps and special orchestrations have in place.
-
Thanks for the reply!!
This may be more of “Itinerary/routing slip” design pattern type of a query ..just to understand the overall concept of Itinerary.
Iv’e understood the concept that the Itinerary pattern is used to decouple and allow the message to be routed across services by simply altering the items in the Itinerary.
So instead of going from A–>B–>C
I introduce another step and say it should go from A–>D–>B–>C
Now if this Itinerary pattern is to be succesfull ideally I should just modify the “Itinerary” and rest should be automatically handled.As explained above if the “services are set to execute in the same location” or in the dispatcher pipeline one after the other how does the Itinerary pattern work ?
If the code (either in the receive/send handler or the dispatcher pipeline) was set to execute A–>B–>C and If I introduced another step “D” ; will it handle this change ? will I have to go and modify this if I alter the Itinerary ?
Assuming “B” was a WCF (SOAP) type of a call and now “D” is an Http post how does the code know how to handle the call made after “A”If I have to go and alter the code related to “A” to make it understand that it has to go to D instead of B then whats the purpose of an Itinerary ?
Its like “hard coding” the logic into the service/container to allow it to route/call the next step in the chain…-
The way the ESB toolkit does is that the itinerary (and the state of execution of it) is attached to each message in a special context property. That’s how the various ESB components/pipelines/orchestrations know how to handle the message and what the next step in the itinerary is. If you change the itinerary definition, normally this will just be picked up by messages that arrive after that, not by running itineraries.
In your second example, however, you’re talking more about handling request/response, two-way scenarios, which are also supported by the ESB toolkit. In this case, you need to make sure that the two-way send ports use are using the right send/receive pipelines provided by the ESB toolkit, which use the ESB Itinerary Cache pipeline components so that when the response message is received, the itinerary state/definition left by the request message is attached to the response message so that it can continue to execute. That’s actually covered in the ESB toolkit docs, by the way.
-
Thanks for the reply..I will be a bit a more specific …
[quote user="tomasr"]The way the ESB toolkit does is that the itinerary (and the state of execution of it) is attached to each message in a special context property. That’s how the various ESB components/pipelines/orchestrations know how to handle the message and what the next step in the itinerary is. If you change the itinerary definition, normally this will just be picked up by messages that arrive after that, not by running itineraries.
[/quote]
I understood the part about itinerary is attached to the message and the itinerary attached to a message cannot be altered mid way.
You just mentioned that the various ESB components, piplelines and orchestrations know how to handle the next stap based on the itinerary.
I think this is where my questions are …
1] If there is an orchestration A (for service A), orchestration B (for WCF service B), C (for service C) and D (Http post) etc
2] I create itinerary1 which says A–>B–>C
3] I create a new itinerary2 which says A–>D–>B–>CNow the orcehstrations A, B,C and D will be responsible for :
1] Just executing the corresponding service
OR
2] [Executing the corrersponding sercvice in the itinerary] + [routing to next step in the itinerary]Which of these 2 options is the responsibility ?
To what extent does one orchestration/ESB component corresponding to a service take the responsiblity of executing an itinerary ?
Lets assume Im not a Biztalk developer and Im not concerned with the exact technical detail of how the Biztal code runs..Im just looking for an overview of how this is done in Biztalk ? [:)]
How will Biztalk habdle the itinerary1 and itinerary2 dynamically ?I can simply put in other words as will 1 orchestration/pipleine/ESB component in Biztalk handle all the steps in the itinerary or will each component be responsible for only 1 step in the itinerary.. Seems from your reply its 1 orchestration which will doo all the steps in the itinerary…
Please correct me if Im wrong ?-
You can’t really disassociate the two things: You execute the *next* stage in the itinerary and then *advance* it to the next state. There’s really nothing fancy there. For example, the ESB dispatcher component in a receive pipeline will simply execute all stages in the itinerary until it reaches one that is not set to execute in the port’s receive handler and then simply let’s biztalk carry that message forward as usual. It doesn’t really need to do anything else other than update the itinerary state in the message context and any associated properties.
-
Ok,
If we really want to be loosely coupled one service/ESB component should not even know the other exists.
Im a little confused .. If 1 orchestration executes all the steps in the itinerary , then it would also need to know “how ” to execute all the steps.
So if the itinerary is altered for a message the same orchestration would need to understand the exact way to communicate with the newly introduced steps etc.
How is this dynamic if I need to add a new step to a few of the itineraries and also modify the corresponding orchestrations which are affected ?-
You’re confusing things. I didn’t say that the components knew exactly what to execute. I meant the ESB dispatcher components know how to interpret the itinerary, look up a service and execute it; that’s what the ESB components are for. Of course that part is dynamic, and the esb components know how to handle all of that; it’s not something you have to do by hand for each itinerary.
As for orchestrations, those are not used in the way you thing. It is true that an itinerary can configure a service to run in an orchestration context, but it’s not like a regular biztalk orchestration… it’s an orchestration that needs to be coded in a specific way, registered a certain way with biztalk and the ESB toolkit and a bunch of other things. The ESB toolkit does come with 2 predefined orchestrations to execute routing and transformation services, but that’s it.
-
Ok, if I got this right ..
1] Message has itinerary attached to it.
2] Biztalk ESB contains “x” number of components/orchestrations to handle every step in the itinerary
3] Each component does his job and only “routes” to next but not “executes” the next.
This routing would be as simple as removing the current step or marking the current as complete.
4] As each component does the work corresponding to only 1 step in the itinerary it doesn’t care what the next step is. It finishes its work and hands it back to the central Database
5] The next component simply retreives the message from the central database , executes the step as per the itinerary and lets go..
and so on ..-
Nope, it’s not like that. There’s no routing at all unless the current stage (service) and the next one are configured to run in different contexts (as I explained before). Consider for example this itinerary:
on ramp -> receive handler ( transform1, transform2 ) -> orchestration handler ( routing service) -> off ramp
The way this would execute is:
– The receive port receives the message and runs the ESB receive pipeline
– The ESB pipeline figures out the right itinerary to apply to the message, initializes it and puts it in the context
– The ESB dispatcher component in the pipeline grabs the message and executes the first 2 stages (two Transform Services)
– The pipeline finishes execution and the message goes into the message box
– The ESB Routing orchestration picks up the message from the message box and executes the routing service configured for the third stage, and then drops the message into the message box again
– The Send port (esb off ramp) picks up the message and sends it.Is this any clearer?
-
-
-
-
-
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.