The internet expands quickly and every day brings some new users. HTTP and web pages became the most important technology as far as the internet is concerned. In some situations when you say internet you really mean World Wide Web. For programmers WWW has an important advantage: if you write your application in WWW technology, you will no longer have to worry about cross platform compatibility installation and deploy problems and so on. It is enough that a platform has its own web browser and everything works. Above is not exactly true due to browser interpretation of tags differences, but in theory it should be true and browser programmers try to gain the unification. For some appliance the CLP tools are very convenient. They have interesting mechanisms implemented like branch and bound, forward checking and looking ahead . It could be used as discreet optimization tool and continuous optimization tool. In some cases CLP can be efficient ,  and it is a flexible tool  which can be used for modeling various problems. CLP is declarative so the models are easy to modify, that is useful especially when you want to implement different problem variant. Even if new problem variant has not a canonical form yet . It follows that finding a efficient way of PHP and CLP work together would be a good job.
- Proposed approach In the paper a middle ware concept is presented. The ANSI C TCP socket server gets the task from PHP (that serves HTTP query) and runs CLP tool independently. The status of program consulting process can be checked in any time by PHP web page. In this way the separation is gained, that solves the problem of web server timeouts. A web application, that supports GUI can initiate CLP work and control it. During the time of program execution a further interaction with user is possible. There is no need to wait until CLP execution ends and mean while the application can have access to best solution found so far by CLP program. This approach can be useful especially in complex task when execution time of CLP program could be longer then web server timeout. III. THE PROPOSED APPLICATION WORK SCHEMA There is four most important components which are involved in described solution: • Web browser client • Web server / PHP • The middleware socket server • GNU Prolog. The requests are being sent by web browser to web/PHP server. Then PHP application establishes a socket connection to middleware server and a command is sent. Command data is dependent on communication protocol (see III-A).
After middleware server receives appropriate command, it initiates pipeline shell command and starts GNU Prolog for CLP program consulting. The command is ran in a separate thread, so the server could accept further connections in the main thread. Mean time the server sends an acknowledge back to the socket. A. Communication protocol The protocol is very simple. All data are sent in raw text format. There are three commands implemented: • consult – starts CLP program consulting. The additional parameter containing CLP program path have to be sent with consult command. • results – gets CLP program execution results from the server. • stop – stops the middleware server execution.
THE ANSI C SOCKET SERVER The middleware server and GNU Prolog are installed on the same server machine. The main loop of the middle server is presented in listing 1. It operates according to the model: 1) Wait for client connection. 2) After the connection is established read string from the socket. 3) If appropriate command was read, execute the command. 4) Write back a response to the socket. 5) Close the socket.
A PHP application is responsible basically for GUI. It could be any application that demands constraint logic programming aid. It can contain only simple GUI and socket communication or it could be large enterprise solution, that have to support for example some scheduling process. The socket communication from the side of PHP operates according to the model: 1) Establish socket connection. 2) Send command (and parameter). 3) Read server response from the socket. 4) Close the socket. A. Test web application The PHP Test Application consists of HTML form that contains two fields: cmd and param. cmd field is used for specifying command and field param contains prolog program path if the sent command was consult. Above is determined by the communication protocol (see III-A). A results space is located below the HTML form (see figure 2). In this area PHP Application displays the data, that are received from middleware server. The construction of Test Application is quite plain. The part responsible for socket communication and results display is presented in listing 4. The whole block of code will run, if there is the cmd parameter present in $ GET PHP array. At the beginning socket connection between the application and the middleware socket server is established. Next the command that was entered to the HTML form is sent to the socket. If the command was consult, then the additional parameter (param) is sent. Directly after that the server response is being read from opened socket.
The PHP and GNU Prolog were successfully integrated. A small Test Application was developed and reviewed. The separation of web front end and GNU Prolog process is achieved. Problem of web server timeouts is solved. The middleware server was written in ANSI C. It is compiled to native binary file. It is an advantage as far as the performance issues are concerned, but for some users it could cause deploying difficulties. Now the middleware server supports only limited functionality and it forces prolog program implementation to present results as console output, so it could be read from pipeline. A. Future work The server supports single session. The obvious direction of development is to implement multiple sessions support. In described version the middleware server consults goal top. The functionality of consulting different goals could be added. When the top consulting ends, the consult thread is ended. During the execution time only the results is read, nothing is sent to working CLP program. It is possible to implement two-way communication. The feature of CLP program upload, could also be implemented. There have been some assumption, that only limited capacity of few variables is needed. For example result length is limited to 5000 lines. In this case a dynamic memory allocation could be developed as well. An authorization mechanism could be added and server logging could be improved. Other possibilities and needs could be identified during further tests and operation.