Online documentation - Websydian v6.0

Users Guide | Patterns Reference | WebsydianExpress | Search

 

How iSeries Web Server Support Works


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.

Websydian AS/400 implementation with data queues

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.

Division of iSeries Web Server and Websydian Application

Since iSeries data queues can be configured to work seamlessly across two servers, it is possible to place the Websydian application on another machine than the one that runs the iSeries web server, thus achieving true three-tier Client/Server computing:

  1. First tier is the desktop computer of the web user that runs the web browser.
  2. Second tier is the iSeries server that runs the iSeries web server.
  3. Third tier is the iSeries server that runs the Websydian application and that houses the iSeries database.

This requires the data queues to be configured as 'remote' data queues. Commands are delivered with the Websydian iSeries library to ease the task of queue configuration and management; refer to the iSeries product and application installation guides.

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.