Resumen

  • RFC 2371 normalizó un acuerdo de dos fases entre gestores de transacciones, no el transporte ni la autorización de las solicitudes comerciales.
  • PREPARED y COMMITTED eran evidencias operativas sólidas pero acotadas: no demostraban que todo el trabajo previsto se hubiera incorporado ni que el llamante conociera el resultado final.

Dos canales y una frontera deliberada

RFC 2371, publicado en julio de 1998, definió Transaction Internet Protocol (TIP) como un protocolo sencillo de confirmación en dos fases. El contenido de la transacción —una orden, una reserva o una transferencia— circulaba por el protocolo de la aplicación. TIP se ocupaba de que los gestores participantes acordaran confirmar o abortar. El documento llamó a esta separación modelo de “dos canales”.

La ventaja era concreta. TIP no tenía que imponer formatos de datos ni vocabularios para todos los negocios. Sistemas distintos podían conservar sus mensajes y compartir solo una pequeña lengua de coordinación. Tampoco se presentaba como sustituto de todos los protocolos de confirmación existentes.

Esa economía fijaba el límite probatorio. Un gestor podía responder COMMITTED sin saber si el usuario recibió la confirmación, si una petición nunca salió o si la aplicación definió mal su unidad de trabajo. La corrección en el canal de coordinación no rellenaba los huecos del canal comercial.

La aplicación dibujaba la transacción

El ejemplo de compras del RFC reúne un gestor local y varios remotos para confirmar conjuntamente distintos pedidos. TIP ofrece atomicidad a los participantes que se han incorporado. La aplicación decide qué acciones forman el conjunto y cuándo está listo para confirmar.

RFC 2372 desarrolla la consecuencia: TIP no siempre puede ordenar los mensajes de aplicación cuando ambos canales están separados. La aplicación no debe pedir COMMIT mientras queden solicitudes pendientes, ni contestar positivamente antes de registrarse en su gestor local. Un participante esperado pero nunca incorporado queda fuera de la garantía.

Por tanto, “el conjunto inscrito fue atómico” y “todo el trabajo comercial previsto estaba dentro del conjunto” son afirmaciones diferentes.

La URL TIP era un punto de encuentro

El contexto podía propagarse mediante PUSH o PULL. Con PUSH, el gestor superior ordenaba al subordinado asociar la transacción. Con PULL, la aplicación entregaba una URL TIP y el subordinado usaba su dirección y referencia para incorporarse.

La URL debía ser globalmente única para siempre, aunque el método se dejaba a cada implementación. El RFC mencionó los UUID como una posibilidad; RFC 4122, posterior, no fue por ello un formato obligatorio en 1998. Además, TIP no ejecutaba esa URL. La referencia viajaba por el canal de la aplicación.

Tener el localizador no demostraba que PULL hubiera funcionado, que la operación estuviera autorizada o que un recurso hubiera confirmado. Era una coordenada de reunión, no un comprobante.

PREPARED creaba una obligación duradera

TIP funcionaba normalmente sobre TCP, podía negociar TLS y permitía multiplexar transacciones. Sus estados —Initial, Idle, Begun, Enlisted, Prepared, Multiplexing, TLS y Error— regulaban la conversación válida entre gestores. No eran estados completos del negocio.

PREPARED significaba que el subordinado había conservado información de recuperación suficiente para obedecer más tarde la decisión superior. Un fallo al preparar no equivalía automáticamente a ABORT. Una transacción preparada ocupaba recursos y una responsabilidad real hasta resolver su desenlace.

COMMIT también tenía un significado estrecho: era la decisión del coordinador sobre el grupo inscrito. COMMITTED era la respuesta protocolaria del subordinado. Entre ambos registros y el comprobante del cliente estaban la actualización local, la entrega de la respuesta, la presentación de la aplicación y el estado comercial posterior.

Una operación exitosa podía perder su última respuesta

RFC 2372 señaló de forma expresa que el cliente podía no recibir el resultado final aun cuando la transacción terminara con éxito. La aplicación debía averiguarlo por otra vía, quizá un registro propio de la implementación. El silencio no equivalía a aborto, y repetir sin comprobar podía duplicar una operación ya realizada.

Los registros persistentes, RECONNECT y QUERY permitían reconstruir la relación entre gestores después de un fallo. Recuperaban la decisión de coordinación, no toda la experiencia del usuario. La aplicación aún debía conciliar el resultado con su propio estado y con la confirmación que había mostrado —o no— al cliente.

La seguridad no saltaba de un canal al otro

TLS estaba disponible, pero su adopción dependía de políticas locales. El RFC advertía que proteger la comunicación de la aplicación sin proteger el protocolo de confirmación podía socavar la primera. A la inversa, una sesión TIP protegida no autenticaba ni autorizaba por sí sola la compra.

PULL podía explotarse para provocar abortos. PUSH podía retener recursos mediante numerosas transacciones preparadas. Mensajes falsos de reconexión o de desenlace podían corromper el resultado. Eran problemas de autoridad en la coordinación, no pruebas de que TIP fuese el sistema de identidad del negocio.

La cadena completa separa la solicitud, la propagación del contexto, la incorporación de participantes, el final del trabajo local, los registros PREPARED, la decisión, la mutación de recursos, las respuestas y, por último, la confirmación del usuario y el estado observado. TIP reforzó la parte central.

La “especificación inicial mínima” de Lu Heng permite entender esa estrechez como virtud: normalizar solo el acuerdo necesario y no apropiarse de la semántica de cada aplicación. La primacía del código ejecutado obliga a observar registros duraderos, transiciones y recuperación. Las capas de realidad obligan a no llamar del mismo modo a COMMIT, COMMITTED, la confirmación en pantalla y el saldo posterior.

RFC 2371 produjo un comprobante valioso para el sistema de coordinación. Nunca afirmó que ese comprobante fuera todo el resultado comercial.