|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
Overview Installation Operation Parts Background Error Handling
This section describes the components of a DWA system and gives an overview of how they interact. For more details on this please refer to Websydian DWA Background.
A DWA system consists of three components interacting through TCP/IP. The use of TCP/IP allows the three components to be on the same physical machine or on different machines/platforms.
The individual components are described in more detail below.
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.
[Read more about the Websydian Server]
The Application Services define the individual 'process spaces' in which the Websydian application is executed. The Application Services get the requests from the Relay Service and then perform the processing required to produce and deliver a response back to the Relay Service.
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 Token information can be expressed using an URL notation:
wsydwa://<IP Address>:<TCP Port>/<Service Name>
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 Relay Service and forwarding these requests to the Websydian Dispatcher function.
The Application Listener Function acts as an intermediary station between the Relay Service and the Websydian Application. The Application Listener Function is basically a front end to the Websydian Application in the sense that it calls the Dispatcher function when a request to be processed has arrived from the Relay Service.
See the Installation instructions in the Application Service Listener section for more information on how to implement and install the Listener functionality.
[Read more about the Application Service Listener]
The Relay Service acts as a two-way relay, both relaying requests from a web browser to the Application Service Listener, and relaying 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 Relay Service and then await a response from the Relay Service. From the web server's perspective, the Relay Service 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 Relay Service does not process the request. The request itself is processed by the Application Service facilitated by an Application Service Listener function. If the Relay Service 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 Tokens are occupied the request cannot be handled and an error will be returned to the client browser.
Currently, the Relay Service is implemented as a Java Servlet and in a Windows CGI variant.
Online documentation - Websydian v6.0