We give an overview of the components and the execution flow that we will use in the solution. Some components will later be reused. In particular the data holder and the plain page will be reused by the next application. The plain page will play the role of a web service for the next application. The plain page will be used unchanged for the web service and it will thus also make use of the data holder.
We envision a simpler functionality than the one provided by the previous applications. We will not show the dynamically built Prolog query to the end user. This will save us one button. The only button that we will implement is the search button. So basically we only implement the main scenario of the standalone application. But this is not quite true. We will introduce some variation in the setup scheme.
For all the previous applications the setup of the knowledge base
was done as part of initializing the user interface. For the
terminal application the setup was made close to preparing the
terminal reader. For the standalone application and the applet
application the setup was done as part of initializing the
graphical user interface component. Now when we turn to a servlet
we do not have this possibility. The web server that will run the
servlet might even be headless and it is accessed by a physically
Our idea here is that during the first request to the servlet the knowledge base will be setup. If something goes wrong during the setup, the first request to the servlet will see an error message. In practical situation one might prefer another solution, for example initializing the knowledge base on start-up of the web context and logging problems to a file. Such solutions are also possible, but they are less simple. Therefore we went for the deferred setup by the servlet itself:
Picture 13: Servlet Application Flow
The above diagram shows the modified main flow. We see a new component Data which is responsible for caching the knowledge base. This component is also responsible for setting up the knowledge base the first time the knowledge base is demanded. It should also be noted that the servlet is only active as long as the end-user has issued a search. When the search results have been produced, the servlet is ready for another request. In summary the application flow will work as follows:
1. The end-user enters search criteria in the browser.
2. The end-user presses the search button in the browser.
3. The HTML servlet lets the data holder provide the data.
4. The HTML servlet lets the query interpreter build the query.
5. The HTML servlet lets the query interpreter execute the query.
6. The browser shows the result to the end-user.
3a.1. The data holder has not yet initialized its data.
3a.2. The data holder sets up the Prolog runtime.
3a.3. The data holder consults the Prolog code.
3a.2. The flow continues with step 4.
We used an alternative scenario to wrap the requirement that the knowledge base need only be setup once. Again what this technically means is not clear from the execution flow alone. In the following we will walk through the code of the servlet solution. Various details that we have not said in the execution flow will pop up in the actual code.