Demystifying Direct Bound Ports - Part 4
Self-Correlating Direct Bound Ports
Self-Correlating direct bound ports are self referential (i.e. the address property includes the service instance identifier of the orchestration) providing the capability of getting messages back to a particular orchestration instance without using a correlation set.
To configure a self-correlating direct bound port select ‘Self Correlating’ as the ‘Partner Orchestration Port’.
The way to use it is to create a receive self-correlating direct bound port in orchestration A. In Orchestration B declare a port as a Send Port Orchestration Parameter of the same port-type as defined in orchestration A. This declaration will create a logical port on your orchestration designer surface with the direction flipped. When orchestration B is called with the ‘Start Orchestration’ shape, 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.
Although this can be done with a Call Orchestration this 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.[1]
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 name of the operation 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 instance of the orchestration.
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.
Figure 10 self-correlating port communication
In the next posting I will explain another way of using self-correlating direct bound ports with dynamic direct bound ports.
[1] Note that you can pass an initialized correlation set as a parameter to a called orchestration and follow the correlation set within the called orchestration. This means that subscriptions and convoys work across call orchestration boundaries. This does not work with started orchestrations.