OpenROAD Application Slave (ASO)
The ASO is a single-threaded process that acts as a container for the OpenROAD runtime. This process hosts the 4GL business logic and is responsible for instantiating the OpenROAD image file. Only non-visual OpenROAD runtime classes can be used in this environment.
The ASO supports the same method interface as the SPO. The methods in this interface are:
• ASO Initiate method request
• ASO Release method request
• ASO Call4GL method request
The SPO is responsible for forwarding the appropriate method request to the ASO slave. ASO method behaviors are described in the following sections.
How the ASO Initiate Method Request Works
The SPO creates the ASO as a result of receiving the first SPO Initiate method request for an application signature. The SPO will forward the first Initiate request that it receives for an application signature to the ASO. Subsequent Initiate method requests from other clients with this signature are not forwarded by the SPO to the ASO.
When the ASO receives the ASO Initiate request, it will begin the OpenROAD runtime initialization for the ASO slave. The following steps are taken to process the ASO Initiate method request:
1. The ImageFile parameter of the ASO Initiate method is examined.
2. If the parameter begins with the “{” character, the value is interpreted as an application signature name (ASN) value. (An ASN is a synonym for the application ImageFile plus CmdFlags.)
3. If the ImageFile parameter does not begin with a “{” character, it is interpreted as a standard ImageFile value.
4. If the ImageFile contains an ASN, then the ASN is used to access the registry to look up the real ImageFile and CmdFlags for this application. The ASN also is used to look up any environment variables that must be set before the OpenROAD runtime initialization starts.
5. If the ImageFile parameter contains an actual image file value, then the CmdFlags parameter in the ASO Initiate are used to supply the command flags that will be used to initiate the OpenROAD runtime. There is no provision to supply overriding environment variables when a normal ImageFile value is supplied.
6. The concatenation of the ImageFile value and the CmdFlags value determines the application signature. There is always a one-to-one correspondence between an application signature and either an ASO slave (if there is a single slave in a pool) or an ASO Slave Pool.
7. After the OpenROAD Runtime completes its initialization, if the command flags contain the -d flag, then the value specified is used to connect to the database.
8. If the -L flag is used, then it supplies the name and location of the W4GL log file. If the file name given to the W4GL log file contains a “%” character, this character will be replaced by the ASO slave ID. (Each ASO slave started during the lifetime of the SPO is assigned a unique slave ID.)
9. If the connection to the database is successful, the initialization of the ASO slave continues. If the connection to the database fails, an error is generated and control is returned to the client.
10. If there are no errors up to this point, control is passed to the starting component of the ASO slave. This component must always be an OpenROAD ghost frame. The ghost frame is where any application-specific initialization can take place.
11. When all application initialization processing is completed, the ASO slave is now initialized.
12. When the Initiate request returns control to the SPO, the ASO is ready to process Call4GL method requests.
How the ASO Release Method Request Works
The ASO Release method is sent to the ASO only when the SPO decides to shut down the ASO slave. When this request is received, the ASO slave starts its normal shutdown processing.
When the ASO slave shutdown processing is completed, the SPO is notified that the ASO is now stopped. All queued Call4GL requests are purged and the requesting clients are notified.
How the ASO Call4GL Method Request Works
The OpenROAD Server clients access the 4GL business logic by using the SPO Call4GL method request. Because there could be hundreds or thousands of clients trying to simultaneously access an ASO slave, the SPO is responsible for serially scheduling the requests to the ASO.
When the the ASO slave receives the ASO Call4GL method request, control is given directly to the procedure that is referenced by the value in the ProcName parameter of the ASO Call4GL method. The procedure that is given control is generically called a Service Call Procedure (SCP). The SCP has access to any non-Visual resource contained in the image file.
When processing in the SCP is completed, control is returned to the SPO. If another request is queued to this ASO, the SPO will schedule it into the ASO.
ASO Call4GL requests are typically very fast. Call4GL requests that do not access the database typically complete in approximately 10 milliseconds (mSec). A simple singleton database request typically takes about 30 mSec. (More complicated requests take longer.)
A small number of ASO slaves can be used to support a large number of active clients. The number of clients supported depends on the size of the unit of work (UOW) for the typical transaction profile. Try to keep the UOW size consistent for each application-unique application signature. If you expect some request to have a very large UOW, it might be better to dedicate a unique ASO to process these large UOW requests.
If we assume that each transaction takes 100 mSec (two Call4GL requests and two database query operations), then each ASO slave could support 10 transactions per second. This equates to 600 transactions per minute. Time and motion studies imply that an active user who gets subsecond response time will generate an average of 5 transactions per minute. This means that each ASO slave could support 120 active users using a single database connection. This greatly increases the scalability of an application and reduces the resource consumption as compared to a traditional client/server application.