Websydian Web Server Interfaces

Introduction

This document describes the different ways a Websydian application can communicate with a web server, why the Distributed Websydian Architecture (DWA) was developed, and the advantages it gives compared to Classic Websydian Architecture (CWA).

What is a Web Server Interface?

A web server interface is a protocol specifying how the web server should interact with clients requesting resources.

A good example of a resource request is a user can request a resource from a web server using a browser. In this context a resource is typically an HTML document, an image, a PDF file, or some other file the user wants to view in the browser or download to the local computer. A resource can also be a program executed by the web server, and the program is then responsible for returning a suitable response to the browser (in most cases an HTML document). When a program is executed by the web server the web server will launch the program and transfer all information about the request to the program.

The program launched by the web server will typically be part of an application performing specific tasks and therefore such a program is also known as a web application. The user will then start and use the application through the browser, performing a sequence of requests to the web server. It is then up to the web application to detect which user each request comes from and save information about the session state between each request.

For this to work there must be a protocol specifying how the web server should transfer control and the necessary information about the request to the web application. For the remainder of this document such a protocol is called a web server interface. Today there are several web server interfaces on the market (CGI, ISAPI, NSAPI, Servlets,..) each with their own set of advantages and disadvantages.

Websydian Web Server interfaces

As all other web applications Websydian must also choose a way to communicate with the web server. This is built into the Websydian patterns and the developer can develop the Websydian application without having to think about how the application communicates with the web server. Websydian is said to be transparent to the web server platform and interface.

Classic Websydian Architecture (CWA)

From Websydian 4.0 and forth, CWA changes status from being the primary Websydian architecture, and DWA takes over. CWA will still be supported, but not all new features in future versions of Websydian will be supported in CWA.

The initial web server interface supported in Websydian was CGI on the Windows platform and the iSeries platform. The reason for this is that CGI was and still is supported on all web servers and that it despite its somewhat bleak reputation works quite well and is reliable.

The Websydian CGI interface (supported in Windows and iSeries) is now known as the Classic Websydian Architecture (CWA).

There are some issues regarding the CGI interface in general where the two most important are:

• Performance
  Each time the web server receives a request for the web application a new process is started, and the CGI program is then executed within this process. When the response (typically an HTML page) is returned to the browser the process terminates.
  Starting a new process is a time-consuming task in many operating systems, the effect being that if the web server receives a large number of requests, many CGI processes must be started and stopped leading to a heavy load on the web server.
• Scalability
  In order for the web server to launch the CGI program it must be located on the web server. This makes it difficult to scale a CGI application. One solution to this problem is to use a load balancing mechanism that can dispatch requests to multiple web servers in order to distribute the load of the CGI processes to multiple machines. Tools exist that help accomplish that, however, doing so is not a simple task.

In order to overcome these issues the Distributed Websydian Architecture was developed.

Distributed Websydian Architecture (DWA)

DWA is the primary Websydian architecture from Websydian 4.0 and forth.

The Distributed Websydian Architecture (DWA) separates the web server from the web application by placing a Websydian Web Server Component on the web server. The Websydian Web Server Component is a small component on the web server that dispatches requests to the associated web application (called the Application Service). For more information about DWA please refer to the Distributed Websydian Architecture Overview.

DWA has the following advantages:

• Cross-platform mix'n'match capabilities
  The Websydian Web Server Component and the Application Service uses TCP/IP for the communication rather than using a vendor-specific communication protocol like data queues on the iSeries platform. This makes it much easier to mix and match different platforms for the Websydian Web Server Component and Application Services.
• Central repository enhances control
  DWA uses a Websydian Server acting as a central repository where all Application Services have to register when they start up. The Websydian Web Server Component will then contact the Websydian Server when it receives a request and needs an available Application Service to process the request. With this approach it is possible to dynamically start more Application Services as they at start up will register at the Websydian Server and then be ready for use.
• Applications can be distributed
  It is possible to distribute Application Services over multiple machines where each Application Service registers at the same Websydian Server.

Pros and Cons

This section list the pros and cons for each web server interface in Websydian.

CWA

DWA

Links

http://www.w3.org/Protocols/rfc2616/rfc2616.html

The RFC specification for HTTP 1.1.