“L’atomicité des transactions Acid (*) n’a de sens que dans un contexte synchrone sur des transactions de courte durée. Une relation entre plusieurs partenaires peut très difficilement reproduire ce synchronisme sans une réservation coûteuse de ressources dans chaque système”, explique Jean-Christophe Bernadac, directeur technique de Cosmosbay. De plus, le protocole HTTP ne fournit pas la fiabilité et la stabilité requises au niveau du transport pour gérer convenablement des transactions fortement couplées, qui nécessitent une qualité de service très élevée.Les spécifications Business Transaction Protocol (BTP), soutenue par l’Oasis, et WS-Transaction, présentée par IBM, Microsoft et BEA, proposent un modèle transactionnel assoupli et mieux adapté à internet et aux transactions longues. Mais elles sont immatures et aucune entreprise ne les utilise encore. Bien que des éditeurs comme BEA, Collaxa ou Systinet les exploitent déjà.
Un découpage fonctionnel en trois temps
Pour contourner cette lacune, les entreprises recourent à une architecture asynchrone à base de middleware orienté message (MOM). C’est le cas notamment de Météo France, d’Eastman Chemicals et de B2Boost. Le découpage fonctionnel est toujours le même. L’invocation du premier service ?” la prise de commande, par exemple ?” s’effectue via un appel RPC synchrone. Ce dernier ne renvoie pas la réponse à la requête, mais un identifiant. Un deuxième service fournit au client l’état d’avancement du traitement sous-jacent ?” la commande est prête ou non ?” grâce à cet identifiant. Ce découplage permet à la fois de mieux monter en charge et de prendre en compte le fait que certains traitements exposés par des services web peuvent parfois nécessiter plusieurs heures, voire plusieurs jours de calcul. Lorsque ce traitement est achevé, un troisième service web récupère le résultat de la requête. Le déclenchement de la récupération du résultat auprès du troisième service web s’effectue toujours grâce au deuxième, qui fournit l’état de la commande. “On peut soit l’interroger régulièrement, soit lui demander d’envoyer une alerte lorsque le résultat est prêt “, précise Michaël Tartar, consultant chez Andersen.Bien qu’un moteur d’orchestration ne soit pas toujours nécessaire pour gérer cet asynchronisme, l’offre ne manque pas dans ce domaine, de Biztalk à Web Service Orchestration Server de Collaxa, en passant par les produits de Cape Clear, d’Avinon, d’Intalio, d’Instansis ou de Cypress Logic. Ces moteurs sont chargés de deux tâches très importantes. La première consiste à orchestrer les appels asynchrones aux différents services. Ils appellent l’ensemble des services, stockent les résultats en base ou dans une pile du MOM, puis continuent d’exécuter le processus lorsqu’ils le peuvent. Leur seconde mission est de gérer des mécanismes de compensation qui équivalent peu ou prou au “ rollback ” d’une transaction traditionnelle. En fait, chaque compensation n’annule pas les actions qui ont déjà eu lieu, mais propose plutôt une nouvelle action censée corriger les erreurs générées. Une compensation n’étant rien d’autre qu’un processus.(*) Acid : Atomicity, Consistency, Isolation, Durability.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
