Websydian v6.1 online documentationOnline documentation - Websydian v6.5

Distributed Websydian Architecture Background

Overview     Licensing     Deployment     Operation     Background     Error Handling

Handling Concurrent Sessions

The Websydian Server keeps track of the number of concurrent sessions. For this to work the Websydian application must implement the SessionControl pattern. If the application does not use the SessionControl pattern, each request is regarded as a request from a new session, and the quota of concurrent sessions will quickly be exceeded.

A session is defined as active either in the entire timeout period from the last request made by the user, or until the user logs out of the application.

In order for the Websydian Server to be able to extract the session id correctly, the Application Service Listener function must inherit from the session pattern. Please refer to the Implementing section for the Application Service Listener for further information on how to implement the Application Service Listener.

Operations Overview

As seen on figure 1 below, the Web Server Component belongs to the Web Server, while the rest (except of course the Web Browser) composes the Application Service.

Figure 1: Illustrating the Websydian functions belonging to the Application Service, and the Web Server Component belonging to the Web Server. Note that the Application Service Listener function is part of the Application Service.

The Web Server Component, the Websydian Server, and the Application Services communicate internally using TCP/IP. In this way, it makes no difference whether the services run on one or multiple machines. Typically, the Application Services are deployed on a range of different servers in order to improve application throughput.

Token States

Once a Token has been registered at the Websydian Server, the Websydian Server will record information about that token until the Websydian Server is terminated. This information includes the state of the Token.

When the Websydian Server is in TRACE mode it will log information about the state of each token in the Websydian Server log. All the possible states of a Token are listed in the table below.

Location State Description
Token present at the Websydian Server Ready Token is active; meaning that it can be delivered to the Web Server Component.
Suspended The Token is suspended; meaning that it will not be delivered to other parties requesting the Token.
Token not present at the Websydian Server In use The Token has been at the Websydian Server but is currently not present at the Websydian Server. Once the Token is returned to the Websydian Server it will go into the Ready state.
Suspending... The token is not present at the Websydian Server but the Web Server Component is in the process of returning the token to the Websydian Server.

Once the Token is returned to the Websydian Server, the Token will be Suspended.
Unknown Failed The Token is in an error state. The only thing that can force the Token out of the error state is if the Application Service identified by the Token resubmits the Token to the Websydian Server.

Comments to Operations Overview

Performance

At first it may seem that there are a lot of steps involved in the interaction, and - in particular - that the steps to obtain and return the Token are superfluous and lead to a degradation of performance.  However, the Websydian DWA Service Protocol supports multiple request-response interactions without breaking the connection, which allows the Web Server Component to simply request and keep a Token as long as it needs it. 

Websydian DWA keeps the Application Service alive between web requests, and thereby preserves all database and communication connections. The overhead in performing the DWA processes (Token exchanges etc.) is minimal compared to the overhead needed to initialize the Application Service each time - as done in CWA.

Stability

The overall system remains in a valid state even if an Application Service fails and therefore does not return its Token to the Websydian Server.

The reason why the design requires the Application Service to return the Token to the Websydian Server is that it simplifies starting and stopping the service, and because it makes the overall operation of the whole system more robust – it must be taken into consideration that a process may somehow fail during interaction, and that a failure may lead to the loss of a Token. Letting the Application Service return the Token to the Websydian Server reduces risk of having a Application Service listening in a ready state while its corresponding Token is lost.

Starting Application Services

Additional Application Services can be started while the Websydian application is up and running, simply by specifying as startup parameters which IP address and TCP port to use as the service port. After initialization they submit their identifying Token to the Websydian Server and block listening for a request to arrive. Application Services can be started on-demand and can be placed on any host, and will immediately enter into the service stream and increase available throughput (provided that some other bottleneck is not blocking an increase in throughput).

Stopping Application Services

The base state of a running Application Service is that of waiting for a request; it never leaves that state unless a request arrives. Stopping an Application Service is therefore done by connecting to its service port and sending a request telling the Application Service to terminate immediately. From an operator point of view, the procedure for stopping a Application Service is to tell the Websydian Server to stop the Application Service. After being informed that an Application Service is to be stopped, the Websydian Server will not give away Tokens for the Application Service in question, and either

a) provided that the Websydian Server holds the Application Service’s Token the Websydian Server  immediately connects to the Application Service and sends a terminate request, or - if the Token is not present at the Websydian Server -

b) the Websydian Server waits for the Application Service to return its Token to the Websydian Server and then sends a terminate packet to the Application Service.

Starting Web Server Components

The Web Server is responsible for initiating the request-response interaction; the mechanism for doing this depends on the Web Server-to-application interface employed.

Stopping Web Server Components

Certain Web Server-to-application interfaces - such as CGI - require the application to terminate after every single request-response interaction. Other permits inter-request process persistence. The stopping mechanism for Web Server Component therefore essentially depends on the HTTP Server-to-application interface employed.

Global Application State During Failure

TCP connections are invariably process-to-process and disappear when either process terminates. Since major failure usually leads to the termination of service jobs and/or processes, the TCP connections employed disappear with them, leaving the global system in a known state from which recovery is relatively straightforward (as long as the Websydian Server remains in correct operation, operation can usually be re-established simply by restarting the Application Services).