How iSeries Web Server Support Works

Overview     Library     Deployment    Operation

This section is intended for developers who wants to deploy the Websydian application in an iSeries environment, where the Websydian application is driven by an iSeries web server. It will prove valuable to get the big picture of what mechanisms are involved and to understand the outline of how this support is accomplished.  This page will attempt to describe the Websydian iSeries web server support.

Usage of iSeries Data Queues to Separate CGI and Websydian Application

The nature of the Web server CGI interface is to execute and end a complete program for each web request received.  This can cause a significant overhead to be created in a web application if a database connection need to be created, and database tables need to be opened for each and every request.

To overcome this disadvantage of the CGI interface, the Websydian application on the iSeries are separated from the Web server CGI  by iSeries data queues.  This allows the Websydian application to reside in virtual memory and to keep its database connections and tables open and ready.

Basically, the incoming requests are placed on iSeries data queues by a small, mediator CGI program.  These requests are then processed by a vector of resident Websydian application processes, which transfer the HTML output pages back through other data queues.

This queue-involving mechanism is illustrated on the figure below.

Requests and responses to and from the web user is transferred through iSeries queues.

The steps depicted above are the following:

1. The iSeries web server starts the mediator CGI program when a web user submits a request.
2. The mediator CGI program gets a vacant queue, optionally waiting until a free queue becomes available.
3. The mediator CGI program writes the user request and parameters to the input queue, and then becomes dormant.
4. The resident Application Driver associated with the queue calls the also resident Websydian application. The application parses the input and processes the request.
5. The Websydian application generates an HTML output page, which is written to the out queue.
6. The mediator CGI program wakes up and transfers the HTML output to the iSeries web server, which in turn forwards it to the web user.

Websydian Transparency of Target Platform

In the figure above, the box labeled Application constitutes a Websydian application, which could just as well be generated for the Windows platform. It is transparent for the Websydian functions whether it is targeted towards the Windows platform or the iSeries platform.  The Application is surrounded by iSeries objects like the Application driver which make this possible.

If the Websydian application e.g. requests some environment values from the iSeries Web server - which can possible be located on a completely different server - these values are transparently requested and received through the data queues.

Or almost transparent. The developer must test the value of the current Websydian variant and use a different set of Websydian utility functions for the iSeries web server and the PC web server variant.  This is because the iSeries utility functions are delivered as binary objects that are invoked through API calls. Refer to the reference manual.