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
-
A provision for rejecting unacceptable transactions without a
committment of resources.
-
Mutual validation.
-
Strong encryption.
-
Multicast.
-
Additional scalability.
Overview
AXTP is described in terms of three subsystems:
-
Client
-
Transaction Server (TS)
-
Server
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:
-
The client is responsible for maintaining the state of a transaction
until the transaction is complete. And while the client may signal
the end of a transaction (Failure or Success messages), it must wait for
a final message (Wipe or Quit) from the TS. If taken down in the middle
of a transaction, the client must resume its prior state when restarted.
-
While a transaction is active, the TS must track the number of X messages
(execution requests) received. When the transaction times out (unnested
transactions only), or when a Failure or Success message is recieved
from the client, the transaction becomes inactive. For inactive transactions,
the TS must associate a single bit with the transaction: its success or
failure. After an appropriate length of time (a week? a month?), the transaction
may be purged entirely from the TS.
-
The server must track the state of each execution request for as long
as the transaction remains active. For nested transactions, connectivity
with the parent server is required for the transaction to become inactive.
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:
-
A - Ack. (Server -> TS -> Client)
Generated by the server when it successfully completes a eXecution request.
Repeated until a Z, R, or C message is received.
-
C - Commit. (TS -> Server)
A series of C messages are generated by the TS upon receipt of a S message from
the client. One C message is generated for each X message associated with the
transaction.
-
F - Failure. (Client -> TS)
Generated by the client to abort a transaction.
Repeated until a W message is received.
-
N - Nack. (Server -> TS -> Client)
Generated by the server when it is unable to complete an eXecution request.
Repeated until a Z, R, or C message is received.
-
Q - Quit. (TS -> Client)
Generated by the TS upon receipt of an S message from the client.
-
R - Rollback. (TS -> Server)
A series of R messages are generated by the TS upon receipt of a F message from
the client (or epiration of T1). One R message is generated for each X message associated with the
transaction.
-
S - Success. (Client -> TS)
Generated by the client to commit a transaction.
Repeated until a Q message is received.
-
W - Wipe. (TS -> Client)
Generated by the TS upon receipt of an S or F message from the client.
-
X - eXecution request. (Client -> TS -> Server)
Generated by the client for each eXecution request to be associated with the transaction.
Repeated until a N or A is received.
A transaction is initiated simply by sending an X message with a new TID field to the TS.
-
Z - sleep. (Client -> TS -> Server)
Optionally generated by a client to acknowledge receipt of an A or N message.
Used when it is not immediately appropriate to send a S or F message.
Message Fields
-
TID - Transaction ID (Messages A, C, F, N, Q, R, S, W, X, and Z)
Uniquely identifies a transaction. Holds the host name and port number of
the client, a timestamp of the client startup time, and the client's sequence
number for the transaction.
-
PTID - Parent Transaction ID (Message X)
Holds the TID of the parent transaction. (Indicates a nested transaction.)
-
XID - eXecution request ID (Messages A, N, X, and Z)
A sequence number of eXecution requests within the context of a single transaction.
-
T0 - retry delay (Message X)
Holds the initial, incriment, and maximum values for the retry delay.
-
T1 - time to live (Message X)
Specifies the time remaining before the transaction is to be terminated by the server.
-
REASON - Reason for failure (Message N)
Holds a text string describing the reason for the failure of the eXecution request.
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.
-
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.
-
The X message is resent repeatedly until an A or N message is received.
-
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.
-
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.)
-
Generate and send the next X message.
-
Process the A and N messages received, and send an S or F message depending on the
success of the overall transaction.
-
Continue sending the F message until a W message is received.
-
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.
-
At this point there is no persistant state relating to the transaction.
Receipt of an X message signals the start of the transaction.
-
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.
-
The transaction has failed. X messages are ignored. The W message is resent
upon receipt of an S or F message from the client.
-
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/-".)
-
At this point there is no persistent state relating to the
eXecution request.
-
The eXecution request is processed. If the request it to be forwarded,
the server takes on the role of a client at this point.
-
It is determined that an error occurred, or that the eXecution request
completed successfully (OK).
-
The N message is sent repeatedly until a Z, C, or R message is received.
-
Duplicate X and Z messages are ignored. Persistant state is released upon receipt
of a C or R message.
-
The A message is sent repeatedly until a Z, C, or R message is received.
-
Duplicate X and Z messages are ignored.
-
The eXecution request is rolled back.
All resources are unlocked and all persistent state relating to the
eXecution request is released.
-
The eXecution request is committed.
All resources are unlocked and all persistent state relating to the
eXecution request is released.