We give an overview of the components and the execution flow that we will use in the solution. Since this is the last example in this report, there is no subsequent potential reuse of some of the components of the solution. On the other hand the solution makes use of some previously defined components. Namely we will make use of a service page. This service page is built with the same technology that has been used for the HTML page.
We basically envision the same flow as the standalone application. But when it comes to dynamically building the query and executing the query the application will behave differently. Instead of querying the query interpreter we will query the interpreter stub. The interpreter stub will generate a query for the Prolog agent, which will in turn delegate the query execution to the web server and retrieve the results from there. Under the hood typically the HTTP protocol will be used to access the web server.
The above diagram shows the main flow of the client application. We see the new client component and the new stub component. The client component mediates between the user interface pane and the stub. The diagram is not complete. It does not show the flow inside the dynamic service page. We might point to any dynamic service page that can cooperate with the protocol of the Prolog agent.
1. The client application sets up the Prolog runtime.
2. The client application consults the Prolog code.
3. The end-user enters search criteria in the user interface panel.
4. The end-user presses the search button in the user interface panel.
5. The text servlet lets the data holder provide the data.
6. The text servlet lets the query interpreter build the query.
7. The text servlet lets the query interpreter execute the query.
8. The user interface panel shows the result to the end-user.
9. The flow continues with step 3.
The protocol of the Prolog agent is not very flexible. It assumes a predefined set of search criteria. The names of the search criteria cannot vary. Also the column identifications are currently not retrieved from the web server but statically returned by the interpreter stub. Because of lack of space we have opted for such a simplistic solution.
It should also be noted that the example is still a toy example and it is not designed for practical use on the internet. Assume the salary figures were real, one would not want that this data is publicity available on the internet. Real world applications would demand encryption, authentication, authorization and auditing. Further if the application does updates some transaction management would be advantageous.