Or perhaps a better title is the use of two-way Choreography Tasks vs one-way.
We have had the discussion before about how to model async services in BPMN2 Choreography models. One of the more interesting features of the PolicyQuoteProcess is that the DrivingRecordService is async. i.e., it consists of two one-way services.
IMO if your trading partner (i.e., the other participant in the choreography), supports an asynchronous response, this is an important business requirement and should be modeled as part of a choreography. This type of interaction is supported in process orchestration languages. For example, the support for multiple receives, and the Invoke / Receive pattern, has been an important feature of BPEL (supported with the concept of CorrelationSets). In the past I was able to model this behavior in Savara with WS-CDL by having the send and the receive exchanges in different interactions, and use Savara to generate the BPEL Process.
I believe the same should be possible with BPMN2 Choreography. BPMN2 defines the use of correlation data in Messages, as well as two-way Choreography Tasks (see page 324 of spec). However Savara BPMN2 Choreography generation appears to only use (one-way) Choreography Tasks. For example, in the following example both the DrivingRecordService and the CreditCheckService Tasks are one-way.
Instead, what I would like to see is the following Choreography Model generated:
Notice the DrivingRecordService interaction consists of two one-way Choreography Tasks (as Savara currently generates). This would be understood from the Scenario Diagrams because the operation name is different: checkDrivingRecord vs receiveDrivingRecord. You can see I modified the CreditCheckService interaction to have a single two-way Choreography Task named checkCredit. It has both the creditCheckRequest and creditCheckResponse messages. You would read this as " the PolicyQuoteProcess sends the creditCheckRequest to the CreditCheck Service, which responds immediately with a creditCheckResponse".
This model would have implications for the generated artifacts: WSDL (requires two operations), service interface class (requires two methods), switchyard.xml (requires two bindings), and either Java class (requires two methods to implement), BPEL Process (requires two Receive activities, and BPMN Process (requires two Receive Tasks). All this depending on what type of service you are generating.