Evolving to asynchronous

Blocking programming model is easy to start and understand but it may not be the correct tool for all scenarios. In fact, ServiceTalk assumes that applications typically have a mixed profile where different parts follow different Programming Paradigms. One of the goals of ServiceTalk is to help users evolve from a blocking programming model to a completely asynchronous programming model without the need to completely rewrite the entire application. This document elaborates how to follow such an evolution.

Overview

A mixed profile of application with respect to programming paradigms in essence means that different requests follow different programming paradigms. ServiceTalk allows such paradigms to co-exist while using the same client/server. In addition it aims to optimize these interactions by using the correct Execution strategy.

Design principles

ServiceTalk follows the below principles for providing a path to no offloading:

  1. Turning off offloading is always an opt-in.

  2. All user code (filters, service, etc) will individually opt-out of offloading when applicable.

  3. Explicit opt-in to no offloading to override auto-inference of execution strategy for that entity(aka an http path/route). ServiceTalk will never override that strategy.

Asynchronous and offloading

As described here, in order to achieve safety from inadvertent introduction of blocking code, ServiceTalk assumes presence of blocking user code even when using ServiceTalk’s asynchronous APIs. So, in order to eliminate offloading for a request there are at least the following steps that are required:

  1. Make sure that there is no blocking code for processing of a request.

  2. Only use asynchronous APIs for processing of a request.

  3. Turn off offloading for processing of a request.

(1) is user’s responsibility as ServiceTalk does not infer presence of blocking code and (2) is straightforward, (3) is dependent on different protocols and the methodology is elaborated in respective protocol documentation, eg: HTTP.

ServiceTalk assumes when a user is using any of the above methods, "they know what they are doing" and generally applies the strategy specified by the user "as is".