Async vs synch in choreography models

[jeffdelong]

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.

[objectiser]

Sorry for the delay in responding to this post.

I agree that the modified diagram is more appropriate where a synchronous invocation is required, however the BPMN2 modeller currently has an issue (https://bugs.eclipse.org/bugs/show_bug.cgi?id=424857) with creating choreography tasks with boundary events - which are required to represent fault handling for the sync operations.

However the description of the interactions as separate choreography tasks does not prevent synchronous operations being modelled. The generated service interfaces take into account the fact that the separate request and response choreography tasks have the same operation name, and therefore infers the synchronous operation. The only difference is that the use of a single choreography task would be more explicit.

So once the BPMN2 modeller issue has been fixed, we can generate the synchronous operations in this way - but that shouldn't prevent them being modelled as you require now. To confirm this, if you check the generated wsdl from the choreography, it should show a single synchronous operation for the credit check service.

[jeffdelong]

I see that synchronous interactions can be modeled with separate choreography tasks, but cannot model asynchronous interactions. That is, even if the operation name is different in the scenario diagram, as in checkDrivingRecord and receiveDrivingRequest, the generated service still has a single operation:

   <wsdl:binding name="DrivingRecordServiceBinding" type="pns2:DrivingRecordService">

        <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

        <wsdl:operation name="drivingRecord">

            <soap:operation soapAction="http://www.savara.org/policyQuote/DrivingRecordService/drivingRecord"/>

            <wsdl:input>

                <soap:body use="literal"/>

            </wsdl:input>

            <wsdl:output>

                <soap:body use="literal"/>

            </wsdl:output>

        </wsdl:operation>

    </wsdl:binding>