|
|
|
|
|
No, in fact, bdfpick is an HTTP-PICK interface, i.e. a program making it possible to transmit requests of HTTP type to a pick system, and to return the answer, i.e. a HTML page prepared by pick, with an HTTP server, and, finally, the customer who made the request.
The customer is thus a ' browser', like Internet Explorer or Netscape. The telnet protocol is used only in-house, for the transfer of the request and the reading of the answer.
|
|
|
|
|
|
The majority of the pick-web interfaces which we tested, before launching our development of bdfpick, were external interfaces, not to say foreign to pick. An external programming language (coldfusion, php...) is used, and the relations with Pick are done either by an ODBC type connector, unsuited to multi-value structures, or by a specially developed connector, but limited by the fact of having to communicate with the external programming language.
Bdfpick uses the capacities of pick in the treatment of the character strings so that the page is elaborated directly in Pick Basic, possibly with the assistance of the ' parser' which we developed.
Thus, no new language has to be learnt, and the possibility of working directly on multi-value structures.
|
|
|
|
|
|
We develop in-house environments in D3 Windows and D3 Linux, our system of production is of type D3 Linux, and we already have customers who use Universe.
Within sight of the operating mode, i.e. the establishment of a telnet connection pool towards Pick, the connection chains to Pick being completely parametrable, bdfpick should be able to be used in the same JBase manner or any other version of the Pick system.
|
|
|
|
|
|
Bdfpick breaks down into a Java part and a Pick part. The environment that we use to make our servlet function is Tomcat, of apache.org, currently version 3.3. It is " free " software, which functions just as well under Windows or under Linux.
As Tomcat is able to compile " just in time " a servlet, it is necessary to also install a complete Java environment, like jdk1.3.1 for example, which is also " free " and provided by Sun.
It should be noted that this environment should not be necessarily installed on the Pick server, and that a configuration with a Pick server and a Tomcat server is thus possible.
Tomcat can function alone, but, in order to improve the performances of the server, in particular for fixed pages and the graphic elements, it is good to also install a Web server, like Apache for example. The parameter setting is however a little more complex, but
remains accessible.
|
|
|
|
|
|
bdfpick has two systems of connection to pick, systems which can be used simultaneously, according to the type of request to be treated :
If the execution time of the request is short (duration lower or much lower than the second) the request is subjected to the pool, via the BdfPick servlet (the operation of the pool will be detailed in another chapter).
For longer times, for the execution of "select" for example, one uses the BdfPickM servlet, which opens a new telnet connection by the physical IP, and subjects the request to this "private" connection. This system certainly consumes more pick channels, but it makes it possible to avoid a clogging of the pool. This channel can, according to the parameter setting, either be released immediately after the execution of the request, or be maintained temporarily active, in order to avoid the re-connection time for a second request by the same user.
|
|
|
|
|
|
On startup, bdfpick establishes " N " connections with pick, " N " being the number of channels of the pool.
Each request is thus forwarded to the first channel available in the pool, by successively scanning the channels on the basis of the first (a system of load-balancing would not have any effect here, since the destination system is single). The percentage of requests submitted to channel " N " of the pool, established over one period of real utilisation, is thus a good system of knowing if it is necessary to add a channel " n+1 " to the pool.
In practice a pool limited to one channel appears dangerous to us, since a long erroneous request subjected to the pool, or a channel blocked following a program error will block all users (90 seconds on average, for an error, with a standard parameter setting, a control every 60 seconds and the disconnection of the occupied channels for 60 seconds, these parameters are possibly able to be modified).
But, by experiment, a configuration of 2 channels, with adapted programming, and by taking care to pass by BdfPickM for the treatments of the type "batch", is enough in the majority of cases. |
|
|
|
|
|
In fact, the usual operating mode of a text application, in mode telnet, is to post information, to position to a zone of entry, and to await the entry by the user. The program is thus on standby for this entry instruction, classically an "input", and resumes its execution only then.
In HTTP mode, this same sequence will translate into 2 program "calls", same for program or distinct programs, one to cover the instructions preceding the "input" instruction, and the other which will return the value entered in the page and which will continue the execution of the program. The problem which this poses is the "continuity" of the program, i.e. transmission of the values of the variables affected before the "input" instruction at the time of the continuation of the execution of the program.
In order to respect the philosophy of the HTTP model and the operating mode of bdfpick, two solutions are possible :
the simplest to implement consists of launching the telnet application on a phantom channel, by replacing the "input" by the consultation of a file updated by an input sub-program called bdfpick. The operation of the program remains identical to the initial operation, and, if the reading file loop is time-lagged, with a 0.1 second interval for example, in order not to not "collapse" the system, the performances are good. But the management of a large number of phantoms, with the blocking problems due to "wild" disconnections or possible programming or execution bugs, can prove to be complex.
the best performance consists in modifying the program, in order to "post" the contents of the variables, i.e. to safeguard these contents, to stop the program when it arrives at an "input" instruction, then to start it again, by restoring the variables and while jumping directly to the instruction according to the "input" instruction. As in the preceding case, these program modifications can be done by program.
|
|
|
|
|
|
bdfpick FAQ