BizTalk: Ports: Questions for BizTalk developers

This is one of the "Questions for interview" articles.
Part 1: "BizTalk 2004, Questions for interview without answers"
Part 2: "BizTalk interview questions and principle"

BizTalk: Ports: Questions for BizTalk developers

Two-way receive ports (Request-response):

* Why do we set up a send pipeline in the Port parameters but a receive pipeline in the Receive Location parameters?
It means we can use different pipelines for receiving requests but only one for send responses. Seems the Receive Location has no notion of the send part of the 2-way connection.
Is it for a purpose?

Send and receive ports (SP and RP):

* Why there is a difference in an object model?

Send port group (SPG) + Send ports and Receive port + Receive locations (RL):

* Why SPG and SP are linked by many to many cardinality but RP and RL are linked only by one to many cardinality?

* Why SPG and SP are only "linked" but RL are "included" in RP?

I can include the same SP in many SPG but if I have a RL I can not create a different RL with the same name inside one Configuration database (no matter in the same RP or in a different RP).
Is it for a purpose?
I could delete SPG but SPs linked with this SPG would not be deleted. And quite opposite, when I delete RP I delete all RLs included in this RP.
Is it for a purpose?

Operations inside Port shapes:

* Are they for grouping the request and response endpoints only or there is some other purpose?

I know about exposing Operations as interfaces to Web-methods of Web-services. It's kinda adjusting of interfaces with Web-srvs.
My question is more about how can I use the Operation layer for something useful.  For example, The Send port group can be used for group enlistment of ports. Can I use the Operations for something like this? Is there some specific methods for them?

If we look at the DB diagram of the Configuration DB (in the SQL Enterprise Manager) we can see at last two real tables working with operations: "bts_porttype_operation" and "bts_operation_msgtype". The operations are on the same "physical layer" as "ports", they are "the objects" in Configuration DB, plus there are the objects/interfaces in API (Microsoft.BizTalk.ExplorerOM namespace).
As I can see the "Operation" is one of the parameters of port. No more no less. But it has a visual face in Orchestration because it as "a visual meaning". Value of this parameter can be One/two way, Request/Response, Request-Response/Solicit-Response. The operation is kinda "part" of orchestration and I can not see and use them from BTS Adm.Console, for example (but I can see one or two-arrow icon, it's kinda "operation type" :) )
My conclusion is we choose an operation for a port and that's all, after creating port we can't change the “operation parameter“ anymore. We can only use port with this type of operation. Operation is a parameter of port with "visualization".

Add: Seems, that answer is in BPEL4WS ( specification. It has an operation inside PortType. In real life by implementation BPEL on BizTalk the Operation was of course implemented no matter how useful it is in real life.

Filters in ports:

* Why they are so different?

The filters for SPs and SPGs located "inside" them. The filters for Orchestrations are located inside Receive shapes in Orchestrations. That means I can change the subscription for SPs and SPGs with help of the binding file at run-time but can change the "orchestration subscription" only at design-time.
Is it for a purpose?

Asymmetry of the ports:

* Why SP and RP have such an asymmetric design?

If you have comments, please, give me a feedback!

Leonid Ganeline
BizTalk Developer


They have different object model: SPG+SP via RP+RL, the objects have different sets of properties, the properties lay on the different objects, on the different levels, the properties have different cardinalities, limits.

Looks like I can not use the operations for any other purpose. They don't have any properties or methods to work with them.
In SPs we have "Send port group" + "Send port", in RPs we have "Receive port" and "Receive location".
Developer/Operator works with them via different interfaces: In BizTalk Explorer and BizTalk Administrative Console there are lists of Send port groups and Send ports, but only a list of Receive ports, the Receive locations are under Receive port nodes.
SPs and RPs have different object model (you can look at it if you create in the Enterprise Manager for SQL Server a diagram on BizTalkMgmDb)
Is it "the historical way" or is there a some meaning which ways to this difference? ["the historical way" means: "We'd like to change this feature but it is too expensive now, there are too many changes linked with this feature." ]
Print | posted on Tuesday, February 7, 2006 4:13 PM


No comments posted yet.
Post A Comment