Freigeben über

Demystifying Direct Bound Ports - Part 4

  • Artikel

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.

Comments