Gently Motivation

As starting point for our contribution we observe: A type system for HTTP requests connected to the Java type system, and support for the enforcement of this type system. Moreover, the servlet concept is open for polymorphic use of servlets. One servlet can be designed to respond to different sets of CGI parameters. However, the servlet mechanism does not perform any checking on the parameter set. We define a discipline restricting the use of this mechanism to a strongly typed concept which is in compliance with best practices. We propose a formal language called Gently, allowing to document a JSP based dialogue. This language serves as input to a JSP generator, producing templates for a complete type safe dialogue. More formally, our language enables the specification of the system as the signature of a static object system. The template generator maps each object to one JSP and each method offered by this object to a protected region within this JSP. We consider systems with HTTP interface in which the main dialogue functionality is based on basic HTML form techniques or in which the dialogue can be viewed as such. We will use an online bookshop as a running example. We consider the implementation of such systems with Java Server Pages (JSP), which is a proposed standard technique to implement HTTPServlets. The interface of such a system is used in a request/response style by requesting single pages. For simplicity, we suppose that the system is based completely on pages generated by JSPs, and we will call all pages of the system together the pageset of the interface. Technical differences between JSP and servlets are of minor interest in the context of this paper, so we feel free to use these terms mostly synonymously. The HTML form standard offers an untyped, textbased remote call mechanism, which is used as the standard parameter passing mechanism for dynamic websites. This mechanism is commonly, but not quite correctly, referred to as CGI parameter mechanism. We prefer HTML form parameters in the following as precise term for those parameters. The mechanism can be used in HTTP links as well. Servlets offer HTML form parameters to custom code via the HTTPRequest parameter. The user of a HTTP dialogue can be viewed as invoking methods on the system via the browser. However, it is not helpful to view the user as invoking the doGet (or e.g. doPost) methods of the servlet: Applying standard documentation to the customized servlet classes leads only to the documentation of the formal doGet methods. The interesting parameters however are the HTML form parameters provided by the forms and links calling the page, which have to be recognized by the custom code. Each customized doGet implementation may be able to understand different parameter sets. In other words, the servlet mechanism is open for overloading. We define programming guidelines limiting the degrees of freedom in accordance with common best practices, and we define a precise specification methodology, namely a formal language for pagesets. The programming guidelines demand that each servlet must respond only to a fixed set of parameter lists and that the decision must be based on a hidden parameter. Hence, for the specification language, we view each JSP as a static object offering a set of methods with fixed parameter set. A whole HTTP dialogue can therefore be seen as the signature of a static object system, each page being an object. Our language will allow the specification of such a signature and the generation of templates for the JSPs of this system. The described static object system signature is called the dialogue signature of the system. Each method within that signature is called a dialogue method. In well designed systems, dialogue methods and business methods live on different tiers. Dialogue methods invoke business methods. So the dialogue can be changed without changing the business logic. Dialogue methods produce result pages. Note that therefore one JSP will potentially generate as many different result pages as it has methods. Each result page offers to the user the choice between different calls to dialogue methods as the next step in the dialogue. Dialogue methods can be called by links or forms. Forms can be seen as editable method calls offered to the user. For each dialogue method, our language will permit to specify the links and forms contained in the result page. The syntax of these declarations is derived from the Java method syntax. From each specified method declaration and call the generator will produce appropriate code templates.



Background: HTML Dialogues and State Machines

State diagrams have become a common documentation tool for HTTP dialogues, since they seem to show intuitively the essentials of the dialogue. We want to go beyond this intuitive usage of the state diagram formalism and give a precise foundation in the context of HTTP dialogues. We start with recalling some basics about HTTP dialogues. User interaction with the browser can be divided into two classes: Interaction on one page, like filling out a form. We call this input. For itself it is a purely client-side activity, it is not of interest for our considerations, which apply to the server side. On the other hand we consider interaction changing the currently shown page, we call this page change. In case of submitting forms, user input is transfered with this request. As a consequence of this, HTTP interfaces can be specified as a set of pages modeled as states of a state machine and a set of page changes modeled as state changes on this machine. Hence one may think of using the state machine as documentation for the dialogue. But a closer look on many HTTP interfaces shows that they offer almost every state transition, so that state machine modeling becomes almost useless. To circumvent this we propose a classification of page changes into three classes: browser-caused. These are state changes via the browser's history mechanism, bookmarks etc. These changes must be considered by the system designer because they must not make the system unstable. However, it is a quietly accepted pattern of HTML dialogue design that a user should not be forced to use such mechanisms in order to get a meaningful dialogue with the system. menu-supported. HTML interfaces typically have alongside the changing page a menu, which allows the user to branch fairly unrestricted in the system dialogue. The menu is a substitute for the browser history that is provided by the site itself and built with insight into the semantics. But again, the user should at most in exceptional cases be forced to use the menu. The menu should be always at hand for the user's convenience, but the system should propose the most usual state changes within the page itself. page-guided. These page changes are caused by links or buttons on the page and constitute the main alternatives. Navigation along these state changes is what constitutes the use cases \cite{RJB99}. Only these are amenable to meaningful state machine modeling. Gently supports this classification with the menu concept.



Modelling the Use Cases

We consider the distinction between page-guided state changes and the other classes and the reduction of use cases to dialogues along page-guided state changes as essential for a mature model for HTML dialogues. This result is of course not restricted to HTML/HTTP as special technology. In fact it is valid for an abstract class of ultra-thin clients. They can be summarized as page-based clients, in contrast to GUIs based on recursive container structures for GUI elements, where almost every GUI element can have a state of its own. pull-based, i.e. especially the page changes are user driven. Nevertheless elements of the page may be fed with pushed information (a continuosly updated curve for example). Non-modal: the user can suspend or leave the use case and must not stick to page-guided changes. However, restricting the interaction to the page-guided changes must give a senseful modal dialogue. This more abstract model of ultra-thin clients could be called the abstract browser.