Online documentation - Websydian v6.0

Users Guide | Patterns Reference | WebsydianExpress | Search
 

Distributed Websydian Architecture Background

Overview    Installation    Operation    Parts    Background   Error Handling

Handling Concurrent Users

The Websydian Server keeps track of the number of concurrent users. 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 user, and the quota of concurrent users will quickly be exceeded.

An user 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

Figure 1 below illustrates the flow of a Websydian application running in a DWA system. 

Figure 1: The Websydian Circle with DWA. Note that for the sake of simplicity the Websydian Server is not shown.

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

Figure 2: The same illustration as above, but with colors indicating the Websydian functions belonging to the Application Service, and the Relay Service belonging to the Web Server. Note that the Application Service Listener function is part of the Application Service.

The Relay Service, 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 implemented on a range of different servers in order to improve application throughput.

DWA Cycle of Operation

The steps involved in processing a request in a DWA environment are described below. After the Relay Service has connected to the Websydian Server, there are two possible routes through the list depending on the implementation and configuration of the Relay Service.

Figure 3: The two different cycles a) and b), depending on the configuration of the Relay Service. a) and b) are described in step 8 in the list below.

Figure 3 above shows the steps from the Relay Service has received a request from the web server. In the table below the steps are described:

 Step # Description
1 Initialization of the Relay Service.

The Relay Service determines the name of the Application Service that is to handle the request, the IP address, and the TCP port number of the Websydian Server.
2 Request Application Service and license information.

The Relay Service contacts the Websydian Server and requests a Token for the required Application Service Name, as well as the license level of the Websydian Server.
3 Get response from Websydian Server.

The Websydian Server then returns a Token or, if an error occurred, an error code specifying the nature of the error. If an error occurred, the Relay Service returns a suitable response to the client browser, and no more steps are taken in the list.
4 Request received: Contact Application Service.

The Relay Service connects to the Application Service through the Application Service Listener identified by the returned token.
5 Request received: Forward to Application Service.

The Relay Service forwards the request to the Application Service Listener.
6 Application Service processes request.

The Application Service performs the required processing necessary to produce a response and sends it back to the Relay Service.
7 Return response to the web server.

The Relay Service relays the response to the web server from where the request originated.
8 Either disconnect from the Application Service or preserve connection.

As described above there are now two possible scenarios depending on the implementation and configuration of the Relay Service :

a) Each time a request has been processed, the Relay Service disconnects from the Application Service Listener and awaits a new request from the web server. As the Websydian Server data is known by the Relay Service, a new request will be processed from step 2.

b) The Relay Service keeps the connection to the Application Service Listener open and awaits a new request from the web server. As the Relay Service still has the token from the Application Service Listener, a new request will be processed from step 5.
9 Return token to Websydian Server.

Once the connection to the Relay Service is broken, the Application Service Listener connects to the Websydian Server and submits its token before it goes back in idle position for new requests from a Relay Service.

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 Relay Service.
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 Relay Service 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 Relay Service 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 Relay Services

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 Relay Services

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 Relay Service 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).