Friday, February 22, 2008

Modeling HTTP in the mechanics of interaction

HTTP is a rich domain for modeling interaction mechanics because it is both mechanical and interactive.  We can study and learn about both HTTP and Interaction when we regard HTTP as a Network Virtual Machine.  This machine is a Turing Machine in the first case, and an Interaction Machine in the second.

In the first case, maintaining Fielding's REST principles for conventional use, the HTTP methods GET, PUT and DELETE are atomic operations evaluating within the machine as a closed system, making it a Tape Machine. 

In the second case, we can define the HTTP method POST as interacting with another network virtual machine when it makes a GET request to another service.

This model is counter- intuitive for practitioners because the instruction stream originates in the network space and the HTTP context that associate strongly with interaction.  We make distinct the service and its users as individual machines -- and in fact these are individual network hosts, HTTP clients and servers.

Within a service, HTTP's GET, PUT and DELETE methods are (conventionally) elements of a Tape Machine, and only POST is possibly interactive.  Within its user clients, each is interactive when the user employs the service.

Just as within POST as the user of another service, another network virtual machine.

When we follow Fielding's principles for web architecture, GET, PUT and DELETE execute in time appropriate to atomic operations in our network virtual machine.  The user of POST that implies a remote GET intends to maintain the atomicity of the POST, engaging the REST principles as properties of network atomicity.

The elapsed time of execution on a network virtual machine includes time reading the request and writing the response.  The frequency of the network virtual machine is Ten Hertz (cycles per second) when the average elapsed execution time is 100 ms.  And 100Hz when the average execution time is 10 ms.  A network virtual machine perspective reinforces the significance of the REST principles for scalability.

No comments: