Working with Direct Bound Ports in Orchestrations: Self-correlating direct bound ports

Direct bound ports are logical one-way or two-way ports that you can use inside your orchestration; such ports are not explicitly bound to physical ports. This allows you to have different communication patterns among your services.  

There are three types of direct bound ports that you can choose as the Partner Orchestration Port:

• Message Box direct bound ports
• Partner direct bound ports
• Self-correlating direct bound ports.

Today we are going to talk about the Self-correlating direct bound ports.

Self-correlating direct bound ports

Self-correlating direct bound ports assist you in designing asynchronous inter-orchestration communication.  Messages sent to a self-correlating direct bound port are routed to the instance of the orchestration that created the receiving end of the self-correlated direct bound port.

Self-correlating direct bound ports are self-referential (i.e., the address property includes the service instance identifier of the orchestration). This means that a self-correlating direct bound port supplies the information that an orchestration can use to send messages back to its enclosing orchestration. When using the self-correlating direct binding, the orchestration engine generates a correlation token on a particular message to the orchestration instance. This provides the capability of getting messages back to a specific instance of orchestration without using a correlation set.

To configure a self-correlating direct bound port, select the Self-Correlating option on the Port Binding window of the Port Configuration wizard.

The way to use it is to create a receive self-correlating direct bound port in Orchestration A.

And set the Port direction to I’ll always be receiving messages on this port.

And in Orchestration B:

• First, on the Orchestration Parameters, create a New Port Parameter

• And declare that Port Parameter to be the same port type as defined in Orchestration A 

And set the Port direction to I’ll always be sending messages on this port.

This declaration will create a logical port on your orchestration designer surface with the direction flipped.

Now, back to Orchestration A:

• When orchestration B is called with the Start Orchestration shape, we need to pass the port as a parameter to orchestration B.

Orchestration B then does whatever business logic it needs to and then can send a message on the port passed in as a parameter.

The message will be sent to the self-correlating port of the instance of orchestration A that originally started orchestration B.

Note: Although this same exercise can be done with a Call Orchestration shape, this self-correlating proof-of-concept would only make sense with a Start Orchestration as it generates an asynchronous instantiation of an orchestration that cannot have out or reference parameters. So the self-correlating port can be used as a means of responding back to the orchestration which instantiated it.

How does this work behind the scenes?

Under the covers, what happens is that at run time, when orchestration A starts:

• A subscription will be created for each self-correlated direct bound port.
• The subscription will look like the following:

BTS.Operation == Operation_1 And
BTS.PartnerPort == selfCorrelated And
BTS.PartnerService == aabbccdd-0011223344-eeff-5566778899aa

• Where Operation_1 is the operation’s name on the port, selfCorrelated is a literal string used as the PartnerPort, and a GUID for the Partner Service that uniquely identifies this port for this orchestration instance.
• When orchestration A starts orchestration B, the orchestration engine will pass the self-correlated port instance information to orchestration B, along with the other orchestration parameter values.
• When orchestration B then sends a message on the self-correlating port that was passed in as a parameter, the orchestration engine will set and promote the properties listed above, allowing the message to be routed back to the instance of orchestration A that originally instantiated the current instance of orchestration B.

You can find a sample solution of Self-correlating direct bound ports on my GitHub here:

• Working with Direct Bound Ports in Orchestrations: Self-correlating direct bound ports