Actualités

[08/09/2017] Breaking news ! Smile décroche le label Happy Trainees 2018

Après le label HappyAtWork, Smile s’offre celui décerné par ses stagiaires et alternants !

[21/07/2017] Smile lance les premiers vélos solaires connectés à l’occasion du Sun Trip Tour 2017

Smile, leader des solutions IoT et open source, confirme sa solide expertise sur le marché de l’embarqué en participant activement à la course de vélos solaires du Sun Trip Tour.

[03/07/2017] Smile remporte le Drupagora d'Or 2017 du meilleur site e-commerce

Le vendredi 30 juin, la 3ème édition des Drupagora d'Or s'est déroulée à Paris.

Toutes les actualités picto
       

Vous avez besoin de mettre à jour votre Lecteur Flash Flash 7

Guillemet ouvrant l'actualité des solutions
et des technologies open source Guillemet fermant
picto

Synchrone ou asynchrone ?

La logique SOA crée un tissage inter-applicatif rendant les applications de plus en plus inter-dépendantes. La moindre défaillance peut créer la paralysie d'un ou plusieurs sous-systèmes. Le degré de risque s'accroit avec le nombre de requêtes et les volumes de données échangés. Pour réduire ce risque, il est possible (et fortement recommandé) de découpler les applications pour les rendre moins adhérentes entre elles.

Définissons tout d'abord quelques termes :

D'expérience, on rencontre principalement des intégrations solutions où les appels d'une application à l'autre se font directement via des APIs.

On parle de traitements dits " Temps réel", il s'agit d' actions synchrones bloquantes. La requête envoyée exige un traitement côté serveur. Le client reste en attente de ce traitement tant que celui-ci n'est pas terminé. On comprend facilement que si une défaillance intervient côté serveur (erreur, timeout, dépendance indisponible...), la requête échoue et le client doit être capable de compenser. Par extension, si cet appel fait partie d'une série de traitements effectués en série, c'est l'ensemble des traitements en amont restés en attente d'une réponse qui échouent par effet domino.

Les opérations de compensation nécessaires dans le cas de tels échecs vont du simple traitement par le mépris jusqu'à des opérations lourdes de rollback. Elles peuvent donc être rapidement complexes et couteuses, d'autant plus dans des architectures qui ne seraient pas prévues pour gérer nativement de compensation. Par conséquent le traitement synchrône coûte cher à sécuriser !

Était-il vraiment nécessaire de devoir procéder au traitement immédiat de mes informations ?

Dans de trop nombreux cas, on constate qu'à l'instant de l'envoi les interconnexions n'ont besoin que d'une simple validation de la bonne réception des données. Le traitement peut sans problème intervenir plus tard.

Alors pourquoi faire du synchrône ?

La plupart du temps, le choix du synchrône ne vient pas vraiment d'un besoin fonctionnel imposant des contraintes drastiques en termes de réactivité. Il s'agit plutôt d'un choix technique d'implémentation "au plus simple" du lien inter-applicatif. En effet, la plupart des APIs ne présentent que des interfaces de traitement et non des interfaces de mise en file pour traitement. C'est bien normal ! Le rôle d'une API est de réaliser une interface fonctionnelle de connexion, pas de fournir un service de routage. Et comme il serait illogique "d'empiler les messages" côté client, on appele directement cette API. Ce choix impose d'attendre la fin du traitement serveur, quand bien même son résultat n'est pas nécessairement utile. Par conséquent, si le traitement échoue, c'est le client complet qui en pâtit alors que son travail était achevé et indépendant du traitement serveur.

Que faire alors ?

De toute évidence une requête asynchrone aurait été préférable. Le principe est d'envoyer la requête et ses données à un intermédiaire (routeur, file, ...) qui répond par un simple "Traitement soumis" signifiant qu'il a bien reçu les données. L'intermédiaire est alors chargé de la bonne délivrance de ces données au destinataires qui effectuera le traitement adéquat.

Cette solution offre en outre l'avantage de la centralisation des flux, permettant ainsi des diagnostics et monitoring des échanges plus simples et plus complets.

Quelle typologie de traitement choisir ?

 

Synchrone bloquant

Synchrone

non-bloquant

Asynchrone

bloquant

Asynchrone

non-bloquant

Avantages

Traitement dit "temps réel"

Simple de mise en œuvre

Traitement immédiat

Pas besoin de compensation

Technique moins sensible aux erreurs de traitement

Possibilité de traitements backoffice longs

Technique moins sensible aux erreurs de traitement

Possibilité de traitements backoffice longs

Inconvénients

Sensible aux erreurs (dans le cas classique du temps réel)

Mécanismes de compensation couteux à positionner côté client (alors que ce n'est pas son métier)

Méthode dangereuse : personne ne peut vérifier si le traitement s'est bien terminé

Garantir l'intégrité de l'information et des temps de réponse ultra-courts est extrêmement couteux

Pas de réponse immédiate

Contrainte de traitement la plus forte côté requêteur qui demande un traitement et se met en attente sans savoir quand la réponse arrivera

Pas de réponse immédiate

Nécessite une infrastructure adaptée afin de profiter pleinement d'un système non-bloquant

Usages type

Toutes opérations de lecture de données

Toutes opérations dont le résultat est requis par un tiers synchrone

Toutes opérations ayant des contraintes fortes de vitesse de traitement dans des environnements à très haute disponibilité... En théorie...

Toute opération de traitement dont on a besoin du résultat mais pour lequel on peut attendre (courant en BPM)

Toute communication n'ayant pas besoin d'un traitement synchrone

Exemple

Mettre à jour le contenu d'une boite d'aide à la saisie

Théoriquement possible. En pratique, dangereux et contournable

Systèmes de paiement en ligne hébergé par une banque. L'appel à ce système est asynchrône bloquant du point de vue du processus de paiement en ligne

Prise en compte d'une commande client en ligne auprès de l'ensemble des systèmes internes de traitement (ERP, Facturation, ...)

En résumé, quelques clés pour choisir efficacement

Afin de faciliter le choix, il peut suffir de quelques éléments de réflexion simples :

  • L'échange considéré nécessite-t-il une réponse autre que "Traitement soumis" ? Si oui, il s'agit d'un cas "bloquant"
  • Existe-t-il un impératif de traitement immédiat ? Si oui, il s'agit d'un cas "synchrone"

Dans les autres cas, par défaut, il est recommandé de privilégier un traitement asynchrone non-bloquant car :

  • C'est la méthode qui me permet de sécuriser au mieux données dans les échanges inter-applicatifs
  • Elle me permet d'évoluer immédiatement vers toutes les autres méthodes

Dans tous les cas, tous les efforts menés pour garantir l'intégrité de l'information contribuent à rendre le SI plus robuste et plus évolutif. Le coût de mise en place d'une solution d'échange asynchrone est à comparer aux coûts liés à une architecture trop rigide.

Pour plus d'informations sur ce thème, nous vous invitons à consulter notre livre blanc sur les Middleware Open Source

Patrick Nerden
picto

Commentaires

       
Au moins, là, on comprend enfin la différence entre synchrone et asynchrone !!
Merci pour l'article :)
mardi 31 janvier 2017 @ 17:40
       
Ecrire un nouveau commentaire