> Migration for Web environment - Use of the Engine and Execution

< Single interface in character - Generation and Execution

Migration of Applications for Web Environment - A Practical Approach

Migration for Web environment - Generation

To migrate to the Web environment the solution is the implementation of the layer interface, giving it conditions to run in the new environment. Therefore, it is initiated by changing the layout of the common interface, as shown in Figure 20:

Figure 20 - Common Interface module with Web

With the emergence of module "srv_interface_htm.sh" it is necessary to amend the module "srv_interface.sh" that now presents itself as the figure 21. Now it is possible to note the selection of the type of interface that should be used depending on the verification of the environment variable Cgi "GATEWAY_INTERFACE," [line 3] and according to their existence, run the model "htm" or "txt" , [line 4].

Figure 21 - Module "srv_interface.sh" - modified

Then see the "srv_interface_htm.sh" module, which generates an interface in Html to be executed by the browser, as is observed in the figures 22 to 24.

Initially, can be seen in Figure 22, the concept of the exhibition will be replaced by generation. In default "cadastro", [line 236], there is initially the routines for generating titles, names, values and prompts, [line 238]. Following appears the loop that sends the page generated, [line 240] and awaits the fields of forms returned to the variables of the application through the "envia_recebe," [line 241] and then monitors the keys of editing, [line 242].

Figure 22 - Module "srv_interface_htm.sh" -cadastro

For the cases of generation will be presented only the "gera_nome", as shown in Figure 23. Similarly to the standard character, it is loop that scans the table of names, [line 257] and for each occurrence, generates through the "echo", [lines 262 to 264], redirected to a file transmission, ">> $envia", the text in the pattern Html, "<input ...", [line 262], together with values "value =...", [line 263], and attributes Css, "style =. .. ", [line 264], for placement of the elements.

Figure 23 - Module "srv_interface_htm.sh" - generates

Finally, as shown in Figure 24, is a little explores the session that awaits editing the page generated for the browser, "envia_recebe" where it is observed that after the generation of the page, the interface of the application release the client to display it , "echo okk ...", [line 156] and then enter in a state of waiting the edit of page, "verifica_envia, "[line 158].Continuing, receives the form returned by the browser, "campo_form =", [line 160], separates the contents of the fields, [lines 162 to 165] and finally retrieve the value to the variables of the application, [line 167].

Figure 24 - Module "srv_interface_htm.sh" - envia_recebe

Then, in Figure 25, an piece of the code of the page temporary, resulting from the implementation of the interface model Html with its output redirected to a file. A preview of the code by implementing a browser will be presented more in the "Web environment - execution."

1. Figure 25 - File of transmission generated by "srv_interface_htm.sh"

In terms of interface, the information is ready to be used. But lacking the side of the client. It is necessary to create a mechanism that provides access to these pages in a browser and return the information to the application. It is will be presented below.

Migration for Web environment - Engine Access

To provide a engine access to the interface generated will be used a set of components, which through its integration allows the sending and receiving of pages of forms as the following:

Description of components:

Figure 26 - Components of the engine access

The components shown in Figure 26 and described below may be installed on the same machine or on different machines, depending primarily with issues such as availability of resources, efficiency and security rules.

1. User´s browser. Program Web browser, and as examples, Mozilla Firefox, Internet Explorer or other browser, installed in the station of the user of the system. Through this the user selects the application you want to use, calls his start up, its processing and closing; these steps will be explained in module client application.

2.Web server. Server Web pages, can be represented by Apache, Internet Information Server or any server that can run Cgi programs. Its function is to establish communication between the user's browser program and the program of the client's application, receiving and sending requests in both directions.

3. Server applications. Works in one direction. Runs continuously, checking from time to time, any requests. Receive requests, in the start up phase of the client's application, requesting the initiation of a particular application, a time when executed in the background, or in other words, triggers the application for it to run an autonomous way and returns to its normal function of verification of new requests.

4. Client's application. Works in two directions. Execute the communication between the server pages and the application itself. Must be, according to the proposed model, a Cgi application, which is triggered by the server pages. Its implementation is characterized by three distinct moments. The first time, identified as initialization, which asks the server applications the implementation chosen. In a second, identified as processing, sends the forms received from the server pages to the application, wait new generated pages to be made available to the server pages, and then exit. The processing routine remains re-executed continuously until the user requests its finalization. Here is the third time of the finalization, when the client application sends a form requesting their end.

5. Selected application. This module also works in both directions. It can be materialized by any application that has been selected by the user, such as a system of clients, suppliers, etc.. Must have an interface with the ability to detect the condition to be running in a Web environment, and consequently, to communicate with the client application by sending pages and receiving forms. The operation of the interface should be completely transparent to the application itself, in other words, the system of clients, suppliers, or otherwise does not exist any kind of concern about what kind of environment the interface is interacting. It is the interface called by the application the task of detecting the Web environment, generating the pages that will be read by the client module, awaiting the interaction of the user, then read the forms returned and remain in this cycle until it is requested the closure.

For details about the operation, see Appendix B - Phases of implementation - Engine Access.

> Migration for Web environment - Use of the Engine and Execution

< Single interface in character - Generation and Execution

Migration of Applications for Web Environment - A Practical Approach