An Overview of Web Interfaces to Distrix Systems

Modern software systems often have a need to present an HTTP-based interface to the world, as this is frequently the medium chosen for end-user interfaces. While Distrix excels at quick and efficient communications between devices and software processes, the information within a Distrix system can also easily be exposed via a web interface. This can be useful as a way of rapidly creating a user interface to a Distrix system that is accessible to anyone with a web browser.

When adding a web interface to a Distrix system, there are some decisions to be made regarding the choice of web server. The type of data to be served must also be considered, as should the frequency of updates. Other considerations are whether the web users will have the ability to manipulate the data and whether the information is available as state within a Distrix object or whether it must be retrieved through remote method calls.

If ease of deployment is a consideration a web server can be embedded directly into a Distrix agent. Embeddable web servers are available for many languages (for example, Mongoose for C/C++, Jetty for Java or cherrypy for Python), and can often be run as a separate thread within the agent. This provides the advantage of no external dependencies or configuration (the agent can provide the web interface wherever it is running with no additional software installed). The downside is that many embeddable libraries do not provide all of the features of a full-fledged web server (higher performance, SSL support, authentication, etc.). If these features are necessary, a Distrix agent is interfaced with an external web server using a protocol such as FastCGI to allow the web server process to communicate with the Distrix agent process for the purpose of handling HTTP requests.

The data to be served by the web interface is another area to consider. In the ideal case, the agent would subscribe to Distrix objects from elsewhere in the system, and serve up data direclty from the Distrix objects. This approach would be very simple to implement (an incoming HTTP request can be handled merely by processing the local data in the proxy objects into a meaningful response) and horizontally scalable (multiple copies of the agent could be run to handle increased load, and they would be consistent by virtue of not maintaining any internal state). In cases where it is not feasible to do this and data must be retrieved as necessary via Distrix remote method calls, incoming request handling is still a fairly simple matter of dispatching the method call and then blocking until the desired result is returned. This pattern can also be used to allow the web user to manipulate the state of the Distrix system via remote method calls. You can see an example of this pattern below.

In a system in which the data is changing frequently, it can be desirable to keep the user's view of the information constantly up to date. In web applications, this is often done using a technique known as long polling or comet. We'll be exploring a means of providing this capability within a Distrix system in a future article.