Architectural Overview of Iowa
Iowa operates within the traditional request/response paradigm of web interaction. A web browser makes a request. The request is processed and a response to that request is returned to the browser. The user can then choose to make a new request which will ellicit a new response. Repeat. An Iowa application runs as a standalone process, receiving requests and returning responses to those requests. This process need not be running on the same machine as the web server.
The mechanism through which the web server passes the request along to the Iowa application process is currently limited to use of either an Apache content handler written using mod_ruby or the use of a simple CGI program to transfer the request. Research is being done on expanding Iowa so that it can support use through the FCGI protocol, as well.
The Iowa application process listens on either a unix domain socket or a TCP socket for a request. When it receives a request a thread is spawned to handle the request. The request itself is currently carried by a serialized Iowa::Request object that looks and acts very much like an Apache::Request object. A context object encapsulating the context of this individual request/response cycle is created and control passes to the application object.
The application object determines if this request belongs to a current session or if it needs to start a new session, determines whether the objects necessary to handle the request have been loaded in their most current form and reload them if there have been changes, and then passes control into the session object to determine what actions need to be invoked and to assemble the response.
If the request came about from a form submission or clicking on a dynamically generated link then a method specified by the template for the page will be called. This method may yield control to a different component object, or it may do some processing and exit. One way or another, though, following the method invocation, a component object will be generating content.
The content objects encapsulate raw content which is pre-parsed when it is loaded in order to identify which areas are static and which are dynamic. During processing the dynamic portions invoke ruby methods defined within the code file for each component and place the resulting output into the generated content. Once all of the components have had a chance to generate content, execution control migrates back up to where it started, and the request object, now containing a response that will be sent back to the web browser, is serialized and sent through the socket.
The framework maintains a cache of sessions and of pages so that the impact of user load versus resource usage can be managed and so that a suitable level of backtracking support can be provided. If one hits the back button on the browser, one effectively moves execution back to the earlier state, allowing a different action to be undertaken. This works transparently for most applications without needing to write any special code.
Iowa keeps track of a session through the generation of a unique session key. This key is carried within the URL. However, because of the use of the Apache::Request-like Iowa::Request, Iowa applications can also change the HTTP headers that will be sent back to the browser, allowing Iowa application to utilize cookies. For applications where one does not want the session data carried in the URL, work is in progress to allow Iowa to transparently utilize cookies to carry this data. Iowa applications also have access to any parameters passed via a query string, allowing the developer flexibility to choose the method that is most appropriate for the task at hand.
