|
|
To start an Application Service on the Windows platform, an EXE wrapper for the Application Service Listener function should be generated. See Implementing an Application Service Listener for details on how to do this.
Before starting the Application Service make sure that the DWA Windows run-time dll (WsydDwa21.dll ) has been copied to either the folder where the Application Service resides.
There are two ways to transfer parameters to the Application Service: Through the Application Service Listener INI file or by specifying arguments on the command line.
If both ways are used parameters on the command-line has higher precedence.
When the INI-file is used to configure the
Application Service the following parameters should be added to the
HTML section of the INI file in addition to the
standard parameters in the INI file as shown in the samle
configuration below:
[HTML] WEBSYDIANSERVER_IPADDR = 127.0.0.1 WEBSYDIANSERVER_PORT = 8189 AUTO_RECOVER = Y SOCKET_TIME_OUT = 0 WEBSYDIANSERVER_CONNECTION_TIMEOUT = 30
| Parameter | Description |
|---|---|
| Websydian Server IP address | The IP address of the machine where the Websydian Server is started. |
| Websydian Server port | The TCP port on which the Websydian Server listens. |
| Recover from error | A value of 'N' will force the Application Service to shut down
whenever an error occurs.
For the value 'Y' the Application Service will try to recover from simple errors such as an illegal packet or an error in the packet protocol. |
| Socket time out | Time-out in seconds for read/write operations on the TCP
socket.
The default value is 0 which means that the Application Service will not time-out on socket operations. |
| HTTPBodyEncoding | When a request is received from the web server it will be
encoded using a character encoding. If the character encoding is
not specified with the request, then the encoding specified by this
parameter will be used.
This parameter is also used to translate the response from the local character set to the character set expected by the browser, if no character set was specified by the application. Example values:
|
| Websydian Server Timeout | When the Application Service is started it will connect to the
Websydian Server to register itself as running.
If this connection fails (e.g. because the Websydian Server is not started), then the Application Service will wait the specified number of seconds before making another attempt to connect to the Websydian Server. The Application Service will try 3 times before terminating if it is not possible to connect to the Websydian Server. |
When the INI-file has been configured, the Application Service is started by executing the EXE-file. Remember to start the Websydian Server before starting the new Application Service. Otherwise the Application Service will fail to initialize when attempting to connect to the Websydian Server.
When the Application Service has started successfully, it will deliver it's own Token to the Websydian Server. This can be verified by looking in the Websydian Server log file when the log level is set to TRACE or INFO.
For backward compatibility the following parameters can be used
instead of the SERVICE_URL parameter:
SERVICE_PORT = 11001 SERVICE_NAME = WEBDEMO SERVICE_IPADDR = 127.0.0.1
If both methods are used the URL notation has higher precedence.
As with all Plex generated EXE files the Application Service Listener EXE can be executed from a command prompt and input parameters transferred as command-line arguments. The syntax is:
ASL <Dll> <Impl name> <Return> <Websydian Server IP> <Websydian Server port> <Websydian Server encoding> <Websydian Server connection> <IP> <port> <Service name> <Time to live> <Service URL> <Socket time out> <Recover> <Encoding> <Default character set>
| Parameter | Description |
|---|---|
| ASL | Name of the Application Service Listener executable file |
| Dll | Name of the Application Service Listener dll file |
| Impl name | Plex implementation name of the Application Service Listener function |
| Return | *Returned status field. Any value can be inserted here |
| Websydian Server IP | IP address of the machine where the Websydian Server is started |
| Websydian Server TCP | TCP port that the Websydian Server listens on |
| Websydian Server encoding | Encoding used when communicating with the Websydian Server |
| Websydian Server connection | Time in seconds Application Service will wait before reconnecting to the Websydian Server |
| IP | IP address of the Application Service Listener |
| Port | TCP port used by the Application Service Listener |
| Service name | Application Service Name |
| Time to live | Token time to live |
| Service URL | Alternative to the IP, Port, and Service name parameters. The syntax is "wsydwa://<IP>:<Port>/Service name" |
| Socket time out | Time out on the socket connections |
| Recover | Automatic recovery from minor errors (Y or N) |
| Encoding | Not used on the Window platform |
| Default character set | Not used on the Window platform |
Command-line parameters must be specified in the above sequence. If some of the trailing arguments are omitted the corresponding values will be read from the INI file.
Example:
dwasvc dwasvc dwasvc - 127.0.0.1 8189 " " 30 "<default>" 11001 myApp 0 " " 0 Y " " " "
The sequence " " is used to send a blank value ( *Blank ).
By default the Application Service will send errors to the stderr device. In order to be able to read this it is possible to redirect stderr to a file when launching the application service. This is done by appending a redirect command to the end of the command that launches the Application Service.
dwasvc [optional command line parameters] 2> error.txt
With the above command eventual errors will be written to the file error.txt.
In the previous section it was documented how to start a single instance of an Application Service. In a real world DWA system, this is a very unlikely scenario since an application is capable of handling only as many simultaneously HTTP requests as there are Application Services.
It is not possible to start multiple instances by simply activating the same executable as the second instance of the Application Service then will try to listen on the same TCP port that is occupied by the first instance - which will result in a failure of the second instance.
One approach is to use command-line arguments. Since it can be cumbersome to specify all these parameters and because only the port differs from each Application Service, it is only necessary to specify parameters up to the Port argument.
Example:
listener.exe listener listener - 127.0.0.1 8189 " " localhost 11001
It is assumed that the implementation name and file name of the Application Service Listener function is listener.
When starting a new instance of the Application Service the last port value should be changed so a new TCP port is used.
Another approach is to make a copy of the Application Service Listener executable and INI files and then launch the different instances using the following approach:
listener1.exe listener listener listener2.exe listener listener ...
Online documentation - Websydian v6.1