Resiliency Considerations for LightWave Solutions

The LightWave Client & LightWave Server products allow NonStop systems to expose and consume REST web services. REST web services use the HTTP protocol over TCP/IP network connections to transport messages between the client and server applications. The HTTP protocol does not guarantee delivery of messages on the NonStop platform or any other. When building resilient applications, there are a number of considerations, some that apply to REST applications running on any platform, and some that are specific to LightWave based applications running on NonStop. This article outlines those considerations.

Considerations for any HTTP Application

1. REST API request/response exchange uses the HTTP protocol over TCP/IP transport. While the TCP protocol guarantees the integrity of the message stream, it makes no attempt to recover from connection failures. In the event of a connection failure, the error is returned to the client and the server application. If a connection error occurs, the client cannot make any assumption about the outcome of the transaction, and the server cannot assume the client received the response.
2. HTTP requests and responses consist of a request & response line, message headers, and optional message content. If the HTTP response is not received by the client in its entirety, the client cannot make any assumptions about the outcome of the transaction.
3. If either of the previous scenarios occurs, recovery is application specific and depends entirely on the nature of the request. For example, if the request simply returned information from a database read, the operation may be retriable. If the request was intended to make a non-retriable update to the database, and an error occurs, the client application may need to query the database to determine if the operation can be retried.

Considerations for LightWave Client Applications

The LightWave Client product allows a NonStop application to act as a REST client, handling the complexities of message content translation and transferring the messages to and from the service using the HTTP and TCP/IP.  In addition to the considerations for all HTTP applications, LightWave Client applications have these additional considerations:

1. The LightWave Client CLIENT process can be deployed as a standalone process or Pathway serverclass. All error handling considerations that apply to any NonStop Server process-to-process or Pathway application also apply to communicating with the CLIENT process.
2. The IPM response from the CLIENT process contains a 16-bit integer reply code indicating the outcome of the request. If the reply code is not 0, then an HTTP, TCP/IP, or message translation error has occurred. When this occurs, the application cannot make any assumption about the outcome of the request. The recovery process is the same as described in item 3 in the Considerations for any HTTP Application section. For more information on LightWave Client error handling, see Error Handling in the LightWave Client Developer Guide.
3. If a TCP/IP error occurs while sending the request or receiving the response, the CLIENT process does not attempt to re-establish the connection and retry the request. As previously described, only the application can determine the appropriate recovery action once transmission of the request begins. An exception to this behavior occurs if the CLIENT process detects a connection error while transmitting the HTTP request line. In this case, because no part of the request has been sent yet, the CLIENT process will attempt to re-establish the connection and begin transmission.

Considerations for LightWave Server Applications

The LightWave Server product allows NonStop process and serverclass applications to act as a REST service, handling the complexities of message content translation and transferring the messages from and to the REST client using the HTTP and TCP/IP.  In addition to the considerations for all HTTP applications, LightWave Server applications have these additional considerations:

1. LightWave Server enabled application processes receive and respond to REST clients, via the LightWave Server SERVER & SWORKER processes, using the same $RECEIVE READUPDATE / REPLY mechanism used by any NonStop server application. When the server application successfully replies to a request, this indicates that the SERVER or SWORKER  process has received the reply. It does not guarantee that the REST client has received the response.
2. When an API operation is configured with automatic TMF transaction handling, the TMF transaction is commited when the TCPIP process acknowledges that the entire response has been sent. If an application error or TCPIP transmission occurs at any time during request processing, any outstanding TMF transaction is aborted.