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:




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.
I’ve made some changes in the model:




Try to move Subscriber and Publisher the terms to 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.


The Publishers move the messages with defined type (namespace + root_node) to the Message Box.
The Subscribers move from the Message Box the messages with parameters defined in the Filter expression.
In this case The Receive Locations and the Send Shapes are placed in the one group the Publishers, The Send Ports and the Receive Shapes are placed in the one group the Subscribers. It is how the wrong names could complicate the things.


How does the Binding fit this model?




I’ve got something like that.
The Binding = the Implicit Subscription.
This Subscription for Binding is created under scene, when the Publishers ID is used as the Filter expression in the most cases. The link via binding is not required; it can be created by an explicit filter expression.
“Binding” the 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 with creating the most frequently used operation, transferring the messages from one point exactly to the second one. 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 make a step from “pure” Publisher-Subscriber model where the Publishers and the Subscribers do know nothing about each other and have not to know.
Binding makes the model more complicated. It simplifies this operation but not a model.
The pure model is accessible in the BizTalk by a Direct port.


I’ve got the more generalized model:



Here I’ve pictured Orchestration in two parts. Before that the Send and Receive Shapes were in one Orchestration, which is wrong.
I have made the sizes of the Shapes and Port/Locations equal. I had sense that the Orchestrations should not be bigger then Ports.
I’ve added “Outer World”, why not? 🙂


This is the Publisher-Subscriber model.


Conclusions are simple:

  • The Receiver-Sender model complicates the things. Try do not use Reseiver and Sender the terms for describing the message flow.
  • Binding should be on the second level of studing the BizTalk. It does not simplify the things if it is used to hide the Publisher-Subscriber model.