3 Replies Latest reply on Apr 2, 2013 4:46 AM by objectiser

    How to model asynchronous service interactions?


      Often it is known early on in the service development lifecycle that there is an existing service that must be consumed as part of the business process (choreography), for which the service will respond asychronously. The question then is when to capture this requirement and how to express it. In WS-CDL I expressed this through having unique Interactions for both the request and the asynchronous response (each with an exchange). It is not clear how to model this in the scenario diagrams, e.g, should a separate Participant be introduced at this stage to receive the asychronous response?


      On the other hand, is this an implementation detail that should be left to a later stage? If so, this will most likely require manual augmentation of Savara generated implementation artifacts (e.g. BPEL or BPMN2 process definitions).

        • 1. Re: How to model asynchronous service interactions?

          Jeff DeLong wrote:


          e.g, should a separate Participant be introduced at this stage to receive the asychronous response?



          I don't think a separate Participant is necessary, as at the end of the day, the originating Participant will want to receive the response. Therefore, within the scenario, it could be expressed in a similar way - i.e. link from A to B representing the request, and another link from B to A representing the reply. So the scenario is independent (to a certain extent) to how the choreography and process models will implement those interactions.


          Currently, if the operation name on both links is the same, then it is assumed to be a synchronous request/response. Therefore when generating to the choreography representation, it can be modelled as a synchronous invocation. However we have the capability in the BPMN2 choreography generator, to indicate that interactions should be represented using send/receive messages rather than ServiceTasks, therefore this could be dealt with asynchronously. So in this case a general configuration property is used to control how the generation occurs.


          In the reuse situation, it may be appropriate to take into account an existing service behaviour, when generating the choreography, such that client Participants correctly use synchronous or async (callback) behaviour.


          The other approach is for the scenario to use a different operation name for the callback interaction, in which case it will be treated as two separate one-way requests - but still makes sense to respond back to the originating Participant.


          I think the problem is that generally a callback one-way request would have a different operation name, to clearly distinguish it from the original request. But as operation names are significant, from scenarios through choreographies to process models, it would appear that generally the decision about async vs sync invocations need to be made upfront (i.e. in the scenarios), and therefore also taking into account how existing reusable services have been implemented.




          • 2. Re: How to model asynchronous service interactions?

            So in the PolicyQuote example, the DrivingRecordService interaction is asynchronous, and in the scenario the response has a different operation name - checkDrivingRecord in the requiest and receveDrivingRecord in the response. The CreditCheckService interation is synchronous, and in the scenario both request and response have operation name checkCredit. When I generate the choreography, all interaction as modeled a ChoreographyTask.




            When I generate BPEL, it does not model the DrivingRecord interaction with an Invoke followed by a Receive (though it did in earlier version from the WS-CDL model). When I generate a BPMN2 process model, both the DrivingRecordService and the CreditCheckService are modeled with ServiceTasks.

            • 3. Re: How to model asynchronous service interactions?

              Not sure there is an issue with the choreography, as the only other option would be to model the request and response on the same ChoreographyTask - however this assumes there is no other observable activities occurring within the scope of the request/response. So in general I think it is easier to just represent each interaction (request or response) as a separate choreography task.


              Sounds like there may be a bug in the BPEL generation, as not sure how it is making the association between the request and 'response' if the operation names are different. Could you please create a jira for this, attaching the models and generated BPEL?