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 ir 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 wont 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.

I’ve made some changes in the model:
 
 New BTS 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?
 
 New BTS Model Binding
 
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:

 New BTS Model OuterWorld
 
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 Receiver and Sender the terms for describing the message flow. Use Publisher and Subscriber the terms instead!
  • Binding should be learned on the second level of studying the BizTalk. It does not simplify the things if it is used to hide the Publisher-Subscriber model. Try to describe the message flow without Binding and things would be easy.