Lucky potatoes

We have been given an interesting task: To develop a novel approach for a maintainable and well structured control interface for nothing less than a potato grading machine! A potato grading machine sorts potatoes according to a set of size and quality parameters. In fact it sorts other stuff as well - onions, carrots and various other healthy objects. This article discusses some of our design considerations and technology choices in the project.

The initial thought was, okaaay, that sounds like a fat client of some sort. But while we had experience with enough technologies to choose from: Eclipse Rich Client platform, OpenLaszlo, Swing / Java2D, it was not that simple as there were a couple of important requirements.

- The machine should be accessible from the outside, ie. be part of a LAN, WAN, or on the internet.
- The machine should be controllable from a handheld device.

Consequently we took a turn towards the web technologies we use when making application-based front-ends for our systems. Tapestry, Java Serverfaces, or even Struts.

After initial evaluation we realized, that conventional synchronous web-technology was not nearly good enough. The main reason was a need for a very responsive user interface which could compete with the existing C-based user interface with regards to response time. As we were told "when the a potato farmer pushes the button, he expects to see the machine do what he told it to do -- pronto", so the accepted wait of a couple of seconds on the web is of course not acceptable here.

Even a simple web page, easily rendered, and delivered in full by the webserver in a matter of milliseconds felt slow. The latency, browser setup, content retrieval from network and browser cache and rendering time was simply not quick enough.

Next step was therefore to investigate our options of using any of the various fine ajax frameworks out there: DWR, Prototype, GWT or our own ajax javascript libraries. We chose GWT.

GWT was our preferred choice because it solves a number of our concerns such as internationalization, cross browser support and ease of deployment. An other and equally important reason for using GWT is the fact that everything can be held in a single (new) language, making it easier for us to maintain and develop the system.

Lets take a look at the machine and the new GWT-based application.

The machine itself is controlled by a number of computers connected by an ethernet network. Some units serve as controllers, while others are (control) cameras, digital signal processors and physical I/O's.

Physically the machine is made up of three sections: First potatoes enter an infeed section, secondly they pass through a a camera section, where processing and decision making takes place and finally they exit the machine on a conveyor belt and are tipped into their respective outlets.

We mirror this domain model in the application, where the exact same sectioning including all the inner structure of each section exist at runtime as a java object graph.

The model is queried and manipulated through a facade consisting of a number of GWT RPC Services. To mirror the actual state of the physical machine in this model the model itself communicates directly with the various physical units through low level apis. That makes sure, for example, that when the user sets the conveyor speed to X, this value is first set in the model, then synchronized to a low level C api which in turn changes the state of various I/O ports. Or the other way: when the user pushes an external stop button on the infeed section, to stop taking on potatoes for a while, that state-change is seen by a java object, which in turn can make the gui adapt accordingly.

That last example is implemented with Jetty Continuations, where we park all state-change-monitoring http requests on the server side, but without having to use an entire handler thread just for that. It is done behind the GWT RemoteServiceServlet, and because GWT is not made with extension in mind (final and static methods that we cannot override), we had to tweak it just a little. After opening it up a little we could change it to throw the ResumeExceptions required by the Jetty Continuation implementation.

With that design decision taken we are locked into running the application on Jetty (well, it will run fine on Tomcat, but without the nifty continuation pattern in use). With Jetty being so pleasant to work with and relatively lightweight that is perfectly fine.