Within BizTalk 2004 there are not such things as Physical Port and Logical Port. At first these terms started in several whitepapers, then they were “officialy approved” in BizTalk 2006 documentation. Why the Port was divided to Physical and Logical one?
As we try to understand what is “the Port” mean, we have to separate different things under this name. We have one name but different meaning in different contexts. For example, we create Port as a Port shape in Orchestration but it is not a real Port, but something that links us with “real” Port. The “real”, Physical Port works adapter and pipeline (or is it manage them? And this is a different story…) and exists as an independent artifact. By the way, looks like the “real” Port can create Instances (Or this is not a Port but some Messaging Agent? Or not a Port Instance but a Messaging Instance, isn’t it? This is a different story as well…)
We can crate the Port into the Orchestration, it is a part of this Orchestration, isn’t it? And we can create the Port independently with the BizTalk Explorer and the Administration Console. And we can see the Port list in the BizTalk Explorer and the Administration Console.
In this way, trying to differentiate the things in the Orchestration Editor and in the BizTalk Explorer were created terms the Logical Port and Physical Port. Logical Port it is a “Port-shape”, and Physical Port it is a “Full-featured, big” Port in the BizTalk Explorer.
What’s the problem with this model?
The problem is in terms.
Why both a Physical Port and a Logical Port were called the Ports?
Maybe because the BizTalk developers try to make the link between Physical Port and Logical Port as an implicit link. If it works well, we don’t need two different terms, all right. But it doesn’t work, the BizTalk experience is that the link between Physical Port and Logical Port usually an explicit link. For example, the publisher/subscriber pattern requests to separate these terms.
Sometimes hiding the internal mechanism is a way to decrease the model complexity. But in this case it was opposite. Endeavour to hide this mechanism is a way to create additional unnatural terms, to distort the real BizTalk architecture.
I will try to show how BizTalk architecture could be if I use slightly different term set. This model is more easy to me. It would be great to get your feedback on this model.
BizTalk MessageBox (= BizTalk-bus):
This term is used without change. All messages first come to BizTalk MessageBox. Messages are published. Then messages are passed to subscriber. BizTalk MessageBox workss as an Queue Server.
I’ll change term the Port.
Port is the thing linking BizTalk with outer world. Send Port sends information to the outer world. Receive Port receives information from the outer world.
I define the outer world as the different protocols and applications (or more precisely the APIs).
Now this is a new term, the Endpoint. OK, this is not a new term :), we can find it in the SDK to describe the Adapter sample and several low-level things. But this term is carefully hided by the BizTalk architects and documentation writers.
Ports and Orchestrations use the Endpoints to interact with MessageBox.
EP sends data to the MessageBox. EP sends all messages to the MessageBox, and it doesn’t care of the consumers of the messages. If there are any at all.
It’s the duty of the MessageBox to pass the data to the subscribers or suspend it.
ES receives the data from the MessageBox. It receives only subscribed data. A filter on the ES is created for this purpose. It takes responsibility of data passed from the MessageBox to the ES.
Endpoint always has only two sides.
One side is always linked with the MessageBox. The other is linked with a Port or an Orchestration.
Orchestration receives data from the MessageBox through the one kind of Endpoints (the ES) and sends data to the MessageBox through the second kind of Endpoints (the EP). The Orchestration has not any others links with the MessageBox, the Ports, the other Orchestrations, it only has links with the MessageBox through the Endpoints.
Now remember all those port-shape types in the Orchestration. How does it relate to this new model?
Say we create the Port shape in the Orchestration.
New Port: this creates an Endpoint (nothing about Port);
New Configured port / Specify Later : the same;
New Configured port / Specify Now : this creates an Endpoint, then a new Port with the Filter linking Endpoint of the new Port and Endpoint of this Orchestration. Here the BizTalk creators were tried to hide all this mechanism with Ports and Endpoints. And this is helpful in this case.)
New Configured port / Direct : this creates an Endpoint without Filter.
New Configured port / Direct / Routing between Ports… : creating an Endpoint and a Filter linking it with an Endpoint of the Port (Routing between this Orchestration and Port)
New Configured port / Direct/ Self Correlating : this creates an Endpoint and switch on the instance subscription mechanism.
New Configured port / Direct / To receive(send) message to(from) other Orchestration… : creating an Endpoint and a Filter linking those Orchestration and Endpoint (Routing between two Orchestration endpoints)
I’d say couple words about relationship of the old terms and new terms.
The old Port term is a secondary BizTalk artifact. From one side we can create the old port independently in the BizTalk Explorer. But the Orchestration Editor push us to look at the Port as an aftifact belonged to the Orchestration. And BTW, the port type could be saved only together with the Orchestration in assembly “belonged” to the Orchestration.
The old port is only the Port, the New Port is the combination of the Port and the Endpoint.
The old Orchestration can be coupled with Port, the new Orchestration does know nothing about Port.
Now the Port and the Orchestration are terms the same level, the same importance.
“Endpoint” model:
The high-level artifacts: MessageBox, Ports, Orchestrations.
Endpoints: the high-level artifacts should be connected only through the Endpoints and MessageBox.
Port has only one Endpoint. Orchestration has one Endpoint or more.
One side of an Endpoint is always linked with the MessageBox. The other side is linked with a Port or an Orchestration.
Endpoint-Publisher transmits data TO the MessageBox.
Endpoint-Subscriber transmits data FROM the MessageBox.
This is not a new model, it was implicitly used in many BizTalk articles.
Here I’ve tried to use this model explicitly.