AXTP: Application eXtensible Transactional Protocol

Revised 1/28/98

Description

AXTP is a flat protocol, making direct use of UDP/IP. It is based on a simplified transaction model, with only one server handling all the elements of any single transaction. However, it includes full recovery capability and nested transactions across multiple servers.

AXTP is characterized by an unreliable client. The server is free to abort a transaction when a client becomes unresponsive. This works well with the Java model of an Applet client and with mobile clients. (In contrast, servers may not abort a nested transaction when the parent server becomes unresponsive.)

Application extensibility is achieved through the use of XML, application-specific structures being caried in the contents of pre-defined messages. The use of XML seems particularly appropriate, as its facilitates the movement of structured data between diverse programs.

AXTP is expected to work in high-bandwidth applications across high-latency networks (long fat pipes, satalite applications). The intent of the design is to facilitate ease of implementation, as well as scalability.

Disclamer

This is a work-in-progress description of AXTP. There are no reference implementations. All descriptions of the protocol are derived entirely from reflections on the design.

Future Directions

Overview

AXTP is described in terms of three subsystems: For any given transaction, the client works with a single TS, though the transaction itself can be broken down into a series of execution requests (X messages). The connection between the client and the TS is treated as unreliable.

Each TS is dedicated to a single server. The TS and server are colocated in a single process, allowing for easy sharing of state and greatly simplifying the recovery process. All communication between a client and server is via the TS. Communication between the TS and its server is considered reliable.

Multi-server transactions are handled using nested transactions. All execution requests for a given transaction are passed to the same (primary) server, but the execution request may indicate an alternate server. When this occurs, the primary server takes on the role of a client, passing a nested transaction to the TS colocated with the alternate server.

Persistent State

To assure scalability, persistent state must be minimized, aside from the data being operated on by the server. Here are the requirements for each of the subsystems of AXTP:

Timeouts

There are three types of timers used by AXTP:

Messages

The messages passed via AXTP are expected to be in the form of XML, which provides for the inclusion of protocol extensions and application specific structures in the content of the X and A messages (defined below).

(For more information dealing with Java and XML, see JXML)

AXTP currently uses the following message types:

Message Fields

Notational Conventions

In the diagrams which follow, squares indicate processing, diamonds are decision points, and circles specify a wait for input (or timeout).

Arrows indicate control flows. The labels on the arrows take the form "c1,c2/m1,m2", which indicate that the control flow occurs when either condition c1 or c2 occurs and that messages m1 and m2 are to be sent. (A condition is either a timeout or the receipt of a message.) The label "-/W" means that message W is sent regardless. And the label "X/-" indicats that the control flow occurs when message X is received, but there is no immediate message sent.

Client

Client logic will need to be customized to the application. What is shown here is intended for illustration purposes only.

  1. Start/End of a transaction. There is no requirement for any persistant state at this point. The client makes the determination that a transaction is to be initiated and sends an X message to TS.
  2. The X message is resent repeatedly until an A or N message is received.
  3. If the A or N message received is a duplicate and not related to the last X message sent, send a Z message for the A or N and continue to repeat the last X message.
  4. Determine if more X messages are to be sent. (Receipt of an N message or an A message with an unexpected result will often cause the transaction to be aborted.)
  5. Generate and send the next X message.
  6. Process the A and N messages received, and send an S or F message depending on the success of the overall transaction.
  7. Continue sending the F message until a W message is received.
  8. Continue sending the S message until aQ or W message is received.

Transaction Server (TS)

While implementations of the TS may vary, it should remain independent of the application.

The graph shown here is specific to each transaction.

  1. At this point there is no persistant state relating to the transaction. Receipt of an X message signals the start of the transaction.
  2. The transaction is active. The TS must retain the maximum value of the XID field from the X messages, for subsequent processing of S and F messages.
  3. The transaction has failed. X messages are ignored. The W message is resent upon receipt of an S or F message from the client.
  4. The transaction has succeeded. X messages are ignored. The Q message is resent upon receipt of an S message.

Server

Only steps 2 and 3 of the server logic will need to be customized to the application.

Note that it is in step 2 where the X message is converted to a nested transaction prior to forwarding it to an alternate TS and server.

The graph shown here is specific to each eXecution request.

(Missing arrow from 4 to 1, labeled "C,R/-".)

(Label on resend arrow for steps 5 and 7 should be "X,Z/-" instead of "X/-".)

  1. At this point there is no persistent state relating to the eXecution request.
  2. The eXecution request is processed. If the request it to be forwarded, the server takes on the role of a client at this point.
  3. It is determined that an error occurred, or that the eXecution request completed successfully (OK).
  4. The N message is sent repeatedly until a Z, C, or R message is received.
  5. Duplicate X and Z messages are ignored. Persistant state is released upon receipt of a C or R message.
  6. The A message is sent repeatedly until a Z, C, or R message is received.
  7. Duplicate X and Z messages are ignored.
  8. The eXecution request is rolled back. All resources are unlocked and all persistent state relating to the eXecution request is released.
  9. The eXecution request is committed. All resources are unlocked and all persistent state relating to the eXecution request is released.