Distributed Websydian Architecture Overview

Overview     Licensing     Deployment     Operation     Background     Error Handling

Introduction

The Distributed Websydian Architecture (DWA) is developed for high performance, scalability, and platform flexibility in Websydian applications. Scalability and platform flexibility is achieved by dividing the Websydian application into separate components easily deployed across platforms and machines, while performance is improved by preserving database and communication connections between requests.

The figure below shows how a Websydian DWA system extends the Websydian Circle:

Websydian DWA integrates into the Websydian circle, inserting a Web Server Component between the Web Browser and the Websydian Application. Note that the Web Server Component (and the Web Browser, of course) is the only component in the figure that is not generated by CA Plex.

The Application Service Listener function is a DWA extension to the Classic Websydian Application (CWA). The Application Service Listener accepts and forwards requests from the Web Server Component to the Dispatcher. The Web Server Component is the mediator between the Web Server and the Application Service Listener.

The Websydian Server is not illustrated on the figure, as the Websydian Server is not part of the Websydian Circle - instead the Websydian Server acts as a repository for application information and as a command central that controls the entire Websydian application.

Different from the Classic Websydian Architecture (CWA) based on CGI, DWA does not terminate the Websydian application process after each web request, and thereby all database and communication connections are preserved.

Websydian Server

The Websydian Server acts as a repository for information on the state of the entire Websydian application and as a command central. For that purpose, the Websydian Server uses Tokens to uniquely identify the different Application Services.

A Token is an object that identifies a specific Application Service in terms of an Application Service Name (or just Service Name), an IP address and a TCP port number. The Websydian Server manages all Application Services and thus all Tokens in the DWA system. This means that when an Application Service starts up, it will contact the Websydian Server and deliver its own Token.

In this way, all running Websydian Application Services are managed by a central application. When the same Websydian Server is used for all running Application Services, the entire Websydian application can be shutdown by suspending all the Tokens at the Websydian Server and sending a shut down request to the running Application Services.

Another advantage of the Websydian Server approach is that if an individual Application Service should fail, the corresponding Token will not be returned to the Websydian Server thereby preventing any subsequent requests from using the hanging Application Service.

Application Services

The Application Services define the individual 'process spaces' in which the Websydian application is executed. The Application Services get the requests from the Web Server Component and then perform the processing required to produce and deliver a response back to the Web Server Component.

A Websydian application is identified by an unique Application Service Name (or just Service Name). Each Application Service that is started for the Websydian application is then uniquely identified by a Token, consisting of the following three values:

• The Application Service Name
• The IP address of the Application Service
• The TCP port where the Application Service listens for incoming connections.

An Application Service is defined by calling an Application Service Listener function which will deliver the Token of the Application Service to the Websydian Server. The Application Service will then become active having the Listener function (see the Implementing the Listener Function document) receiving requests from the Web Server Component and forwarding these requests to the Websydian Dispatcher function.

Currently developers are able to develop Application Services in the following variants:

• Application Services developed for the iSeries in RPG
• Application Services developed for the Windows platform in C++
• Application Services developed in Java for deployment on platforms supporting Java v1.5
• Application Services developed in Java for deployment on servlet engines like Tomcat or WebSphere

Web Server Component

The Web Server Component acts as a proxy, relaying requests from a web browser to the Application Service Listener, and returning the resulting responses back to the browser.

When the web server receives a request from a client browser that is intended for the Websydian application, the web server will transfer the request to the Web Server Component and then await a response from the Web Server Component. From the web server's perspective, the Web Server Component produces the response to the client and returns it to the web server. The web server then forwards the response to the client browser.

The Web Server Component does not process the request. The request itself is processed by the Application Service facilitated by an Application Service Listener function. If the Web Server Component already has a connection to an Application Service Listener function it simply relays the request, otherwise the Websydian Server is contacted to get the Token of an Application Service available to handle the request. If all Application Services are occupied the request cannot be handled and an error will be returned to the client browser.

Currently the following variants of the Web Server Component are available:

• A servlet based Web Server Component for deployment in a servlet engine like the Tomcat of WebSphere
• A CGI based Web Server Component for deployment on the Apache Web Server on iSeries
• A CGI based Web Server Component for deployment on Windows based Web Servers