Monday, January 6, 2014

Store and forward web apps

When a back end resource is unable to serve traffic, a front end app server might have the resources to implement a store and forward scheme. A web application that works this way will have a very different user experience: the application is a queue.

Modeling these applications requires an Interaction Unit (I). The Interaction Unit has an interaction sequence with the back end resource, the first step of which may be a Request (Q) from an HTML FORM. The second, terminal, step would be a Response (P). In this case, the store and forward protocol between the application server and the browser would be modeled in the state {Q,P} of the Interaction Unit. When Is = {Q} the browser displays the request state: the HTML FORM. When Is = {P} the browser displays the response state.

The {Q,P} Interaction Unit is like a two packet sequence in a Delay Tolerant Network. The Q packet is stored until it can be processed or forwarded. Sometime in the future a P packet is received in response.

If the front end application server set has the resources to implement the packet cache, and can handle the traffic to serve cached packets, then "store and forward" is a viable solution for a back end bottleneck. The user experience would represent this, and of course the ideal for very high latency would be to send mail when the Response arrives at the front end.

This situation arises from an integration problem. The back end bottleneck is a requirement. Otherwise the back end would have the distributed data character found in many cloud applications, and the interactive process latency would be low enough that the front end would employ data caching as a conventional write through cache.

No comments: