BizTalk Messaging Model



When I've started to master the BizTalk I start to build the different models for what is going on inside the BizTalk with messages. With each new iteration it was a different model.
I've begun with the well-known model:
 
 Old BTS Model
 

Let’s name this model as a “Receiver-Sender model”.
This model is about the Senders and Receivers of the Messages.
Looks like the Receive Locations are the Receivers, the Send Ports are the Senders, and the Orchestrations are the Senders and the Receivers simultaneously. Right?
Wrong. All objects are the Senders and Receivers.
The Receive Locations receive the messages from the “Outer word” and send them to the Message Box.
The Send Ports receive the messages from the Message Box and send them to the “Outer word”.
The Orchestrations receive the messages from the Message Box and send them to the Message Box.
The Message Box receives the messages from the Receive Locations or the Orchestrations and sends them to the Send Ports and the Orchestrations.
 
There was a description of the Publisher-Subscriber model in the BizTalk Help. But the most of attention in the Help is to the Receiver-Sender model.
 
As I could understand, terms the Sender and Receiver confuse me.

To illustrate the ambiguity of Receive and Send the terms in the BizTalk context, I use the quotation from the book « Pro BizTalk 2006 » by George Dunphy and Ahmed Metwally, page 119:

« ... The left side shows the sender configuration, which consists of a static one-way send port to send the business document or message and a static one-way receive port to receive BizTalk Framework 2.0 delivery receipts. The right side shows the receiver configuration, which contains a static one-way receive port to receive the message business document and a dynamic one-way send port that... »  (I’ve highlighted the terms.)


OK. I have to say more about this ambiguity. Terms the Send and Receive means... the same. Are you send the message? Yes. And simultaneously this operation means to receive. This terms have meaning ONLY if they are used WITH source or target the operation. Do we send message? It is no sense in this question. We send message to target_object or from source_object. Do we receive this message? No sense! We receive it from source. Etc.
Subscribe and Publish the terms in BizTalk context always means "respectively the MessageBox". Terms Send and Receive do not have such context.
I don't want to reject Send and Receive the terms completely. But they must be used in pair with the source or target of the operation, absolutely.
That's why in quotation above "the sender configuration" doesn't mean exactly what it should mean. In this context it would be better something like "the left configuration" because it was not SO confusing.

Let's made some changes in the model:  
  • Move the Subscriber and Publisher terms into the first place of the model.
  • This model is explicitly a “Message Box centered”.
  • The Publishers move the messages to the Message Box.
  • The Subscribers move the messages from the Message Box.
  • All actions are across the Message Box.
In this case The Receive Locations and the Orchestration Send Shapes are placed in the Publishers, The Send Ports and the Orchestration Receive Shapes are placed in the Subscribers. And you see how the names are confused here.
 
How does the Binding fit this model?
 
 New BTS Model Binding
 
We've got something like that.
The Binding = the Implicit Subscription.
When we are binding orchestration and port, a Subscription for this Binding is created under scene, and the Publishers ID is used in the Filter expression in the most cases. Actually the Binding can be created explicitly by an explicit filter expression.
The “Binding” term is used for describing the direct link between an Orchestration and a Port. As I understand this term was created for simplifying the model by hiding the additional work of creating the most frequently used operation. Binding creates the One-to-One link when the messages from one Publisher must come to the one Subscriber and only to this Subscriber. Binding makes a step from “pure” Publisher-Subscriber model where the Publishers and the Subscribers do know nothing about each other and have not to know.
 
Here is even more generalized model:

 New BTS Model OuterWorld
 
Here I've shown an Orchestration in two parts. Before that the Send and Receive Shapes were in one Orchestration, which is not always true.
I’ve added “Outer World”, why not? :)
 
This is the Publisher-Subscriber model.
 
Conclusion:
  • Try do not use the Receiver and Sender terms for describing the message flow. Use the Publisher and Subscriber terms instead.
Print | posted on Monday, December 18, 2006 7:38 PM

Feedback

# re: BizTalk messaging model

left by Ashish Khare at 6/8/2007 12:08 AM Gravatar
TOO GOOD..EVERY THING MADE TO UNDERSTAND TOO EASILY...

# re: BizTalk messaging model

left by hung at 8/7/2007 3:46 AM Gravatar
I understood this before you made this post.
However, you did a super job of explaining and I am printing this out for my own reference.

# re: BizTalk messaging model

left by Purnachandra at 9/25/2011 10:07 PM Gravatar
gr8 job..very clear explanation..

# re: BizTalk messaging model

left by srinivas at 9/7/2012 12:19 AM Gravatar
every one can understand
Post A Comment
Title:
Name:
Email:
Comment:
Verification: