Résumé

  • RFC 2371 normalisait l’accord en deux phases entre gestionnaires de transaction, non le transport des demandes métier, leur autorisation ou le reçu vu par l’utilisateur.
  • Un état PREPARED durable et une réponse COMMITTED constituent des preuves fortes mais limitées : ils ne garantissent ni l’enrôlement de tout le travail attendu, ni la réception du résultat final par l’appelant.

Deux conduites pour ne pas confondre les responsabilités

Publié en juillet 1998, RFC 2371 définissait Transaction Internet Protocol, ou TIP, comme un protocole simple de validation en deux phases. Les messages décrivant l’achat, la réservation ou le transfert circulaient par un protocole applicatif. Une autre conduite reliait les gestionnaires chargés de décider ensemble entre validation et abandon. Le texte nommait cette architecture « two-pipe ».

Cette retenue rendait l’interopérabilité abordable. TIP n’avait pas à imposer un vocabulaire métier ou une représentation des données. Il ne prétendait pas davantage remplacer toutes les techniques de validation existantes. Il apportait un langage commun étroit à des systèmes qui conservaient leur propre conversation applicative.

La séparation fixe aussi la portée de la preuve. Un gestionnaire peut répondre COMMITTED alors que l’utilisateur n’a reçu aucune confirmation, qu’une requête attendue n’est jamais partie, ou que l’application a mal défini son unité de travail. La cohérence de la conduite de coordination ne comble pas un manque dans la conduite métier.

L’application décidait ce qui appartenait à la transaction

L’exemple commercial du RFC associe un gestionnaire local à plusieurs gestionnaires distants pour valider ensemble plusieurs commandes. TIP assure l’accord atomique des participants enrôlés. C’est toutefois l’application qui choisit les opérations incluses et le moment où elle demande la validation.

RFC 2372, guide de mise en œuvre associé, insiste sur ce point. Dans un modèle à deux conduites, TIP ne peut pas toujours imposer l’ordre des messages applicatifs. Une application ne doit pas lancer COMMIT avec des appels encore en cours, ni annoncer un succès avant que son gestionnaire local ait été enregistré. Une ressource oubliée hors du groupe ne sera pas découverte par l’atomicité.

La formule « la transaction est atomique » ne signifie donc pas « toute l’intention métier a été correctement mise dans la transaction ».

Une URL TIP servait de rendez-vous

Le contexte pouvait être propagé par PUSH ou PULL. Dans le premier cas, le gestionnaire supérieur demandait au subordonné d’associer une transaction. Dans le second, l’application transmettait une URL TIP, puis le subordonné utilisait l’adresse et la référence pour s’enrôler.

Cette URL devait rester globalement unique pour toujours, sans méthode imposée. Les UUID n’étaient qu’une piste ; RFC 4122, publié plus tard, n’était pas rétroactivement le format obligatoire de TIP. Surtout, TIP lui-même n’exécutait pas l’URL. L’application la transportait dans son propre échange.

La possession d’une référence ne prouvait donc ni la réussite du PULL, ni l’autorisation de la demande, ni la validation d’une ressource. C’était un point de rencontre, pas un reçu.

PREPARED était une promesse durable, pas une fin

TIP fonctionnait normalement sur TCP, pouvait négocier TLS et multiplexer plusieurs transactions sur une connexion. Ses états — Initial, Idle, Begun, Enlisted, Prepared, Multiplexing, TLS et Error — réglaient ce que les deux gestionnaires pouvaient dire ensuite. Ils ne décrivaient pas le parcours commercial complet.

PREPARED avait un poids opérationnel particulier. Le subordonné promettait de conserver assez d’information pour exécuter plus tard la décision du supérieur. Un échec de préparation ne signifiait pas automatiquement ABORT. Une transaction préparée immobilisait des ressources et une obligation de reprise jusqu’à la connaissance du résultat.

COMMIT avait lui aussi un sens borné : la décision du coordinateur dans l’ensemble enrôlé. COMMITTED rapportait l’issue protocolaire du subordonné. Entre les deux et le reçu de l’acheteur demeuraient l’écriture locale, la livraison de la réponse, l’affichage et l’observation ultérieure de l’état métier.

La réussite pouvait perdre sa dernière réponse

RFC 2372 précise qu’un client peut ne pas recevoir le résultat final alors même que la transaction a réussi. L’application doit alors déterminer l’issue par un autre moyen, tel qu’un journal propre à l’implémentation. Le silence n’est pas une preuve d’abandon ; répéter aveuglément l’opération peut dupliquer un effet déjà acquis.

Les enregistrements persistants, RECONNECT et QUERY réparaient la relation entre gestionnaires après une panne. Ils permettaient de retrouver une décision préparée. Ils ne reconstituaient pas toute l’histoire vécue par l’utilisateur. Après la reprise, l’application devait encore rapprocher le résultat transactionnel de son état métier et de ce qu’elle avait annoncé.

La sécurité ne traversait pas automatiquement la jointure

TLS était possible, mais son emploi dépendait des politiques locales. Le RFC avertissait qu’une application protégée pouvait être compromise si le protocole de validation ne l’était pas. Inversement, une session TIP protégée ne prouvait pas l’identité ou l’autorisation derrière l’achat.

PULL pouvait être détourné pour provoquer un abandon. PUSH pouvait multiplier les transactions préparées et épuiser des ressources. Une reconnexion ou une décision falsifiée pouvait corrompre l’issue. Ces risques concernaient l’autorité du canal de coordination, sans transformer TIP en système d’identité métier.

La chaîne de preuve complète distinguait la demande applicative, la propagation du contexte, l’enrôlement, la fin du travail local, l’enregistrement PREPARED, la décision du coordinateur, l’effet sur les ressources, la réponse protocolaire, puis le reçu et l’état métier observés.

La « spécification initiale minimale » de Lu Heng aide à lire cette modestie comme une qualité : normaliser juste assez pour coordonner, sans annexer toutes les sémantiques applicatives. La primauté du code en fonctionnement oblige ensuite à chercher les inscriptions durables, les transitions et la reprise plutôt qu’un nom dans un schéma. Enfin, les couches de réalité interdisent d’assimiler la commande COMMIT, la réponse COMMITTED, le reçu client et l’état ultérieur.

RFC 2371 rendait l’accord plus fiable à l’intérieur d’une frontière précise. Sa ligne COMMIT était un reçu du système de coordination, jamais le reçu métier tout entier.