I know I can return a one-to-one flag to activate it, but how does AWS do the job under the covers? How are subsequent calls identified so they can be routed to the correct workspace instance? Is there a timeout on this association, and how long is it? Do we need to do anything special to clean up left-over instances occasionally? Do we get any notification of external shutdown so we can close out open resources? Can we get any other program control over the situation?

In short, this is a big mysterious black box that I need to know more about before I start using it to service clients.

For the benefit of others who may be reading this thread, I have provided some background and expanded detail.

APLWeb services is designed to provide 'waiting and ready' server-side application system 'instances' of APL+Win functions to service the transaction requests of web clients. The number of, and resources associated with, each instance of a server-side application system is determined by the 'load balancing' needs of the organization providing the web service. Where necessary additional servers, essentially identical to the portal server can be deployed to handle larger numbers of web client requests using 'busyid' property of the APL WebServices workspace configuration section.

Generally web services applications provide for two modes of operation, that can apply to web client / web server interaction in which the web client is either a human responding to a browser-based GUI or a another web server.

State-less operation occurs when the web client makes a complete request in one transaction to the next available instance of the server-side application and that server side application instance responds back to the web client as part of the same transaction. Immediately after responding to the web client, that instance of the server-side application is available to service another web client.

Assuming it is permitted by the web service, state-ful operation occurs when the web clienlt makes a persistant connection to the next available instance of the server-side application and maintains that connection throughout a series of transactions between client and server. When the interaction is completed, the web client terminates the 1:1 connection and the server-side instance of the application is now available to service another web client. During the interval of 1:1 client / server interaction the server-side instance of the application is not available to serve any other web client. The maximum duration of the 1:1 state-ful operation may have a time out established by the server-side application.

When a web client needs to maintain a state-ful connection to a particular instance of APL+Win running behind APL WebServices, the 1:1 relationship must be established, by returning the 1:1 flag (=1) via a function call from the client to the server. This function, typically named "START_SINGLE_SESSION", will be in the virtual server path for the APL+Win application being supported by APL WebServices.

Interspersed between the start of a 1:1 connection and the end of a 1:1 connection, the web client can perform any transactions (effectively calling server-side APL+Win functions) supported by the particular web service and be assured that the data manipulations affected by the prior interspersed transaction will still be resident in the server-side APL+Win workspace.

Similarly when that 1:1 relationship is no longer required by that web client, it should be terminated byt the web client, by returning the 1:1 flag (=0) via an analogous function, typically named "END_SINGLE_SESSION', in the virtual server path for the APL+Win application being supported by APL WebServices.

The APL WebServices configuration file for doing this would include a section analogous to the following xml. The APL+Win functions "START_SINGLE_SESSION" and "END_SINGLE_SESSION" would exist in the server-side APL+Win workspace. The APL WebServices configuration file is easily maintained using the APL WebServices configuration GUI. The 'MESSAGE_TO_CLIENT" function result is merely a cosmetic element of the implementation.

Of course the virtual path names in the APL WebServices configuration need not be the same as the actual names of the APL+Win functions in the server-side APL+Win workspace, but it helps to keep them so to avoid confusion.

Now to the answers to your questions:

The APL+Win workspace does not maintain the 1:1 relationship. It knows nothing about web traffic. The APL+Win workspace is a 'slave' COM application instantiated by APL WebServices. Barring un-anticipated errors from within the application system functions in the APL+Win workspace, an instance of the APL+Win workspace, created as a COM client of APL WebServices, lives or dies under the control of the APL WebServices server which is a Microsoft .Net application.

The APL WebServices .Net application:

Instantiates the instance of the APL+Win workspace(s) as COM clients either when APL WebServices is started based on the programmer-created APL WebServices configuration file settings for number of instances or on demand by a request of a web client. Note that the intialization of instances of the APL+Win application at start-up of APL WebServices is one reason for the excellent performance of the APL WebServices / APL+Win ensemble. When a request arrives from a web client, APL+Win is already started-up and ready to go.

The APL WebServices .Net application instantiates each instance of APL+Win as an independent thread, because .Net is multi-threaded. The Windows operating system automatically allocates threads to multiple processors unless barred from doing so by the machine's administrator. This means that APL WebServices provides multi-threading and multi-processor support to APL+Win.

Thie .Net application converts the 1/0 return value from the APL+Win START_SINGLE_SESSION/END_SINGLE_SESSION functions value that can be received by the web client to indicate the start/end of the state-ful session.

The .Net application also keeps the state-ful session open until the server-side-controlled timeout occurs or the web client ends the 1:1 session.

There are three 'time-out's in the APL WebServices configuration file:
<server><connection-timeout>...
and
<workspace><timeout>...
and
<server>
<enable-content-expiration>...
<expire-content>...

The 1:1 relationship timeout is controlled by the <workspace><timeout>... tag in the APL WebServices configuration file, which is in units of milliseconds, but can be set to high values. For debugging purposes, I often set this value quite high, so that I can examine what is happening on the server-side APL+WIn. Note however, that implementing a web service application permitting state-ful operation which lasts more than a short while means that significant server-side resources are being tied up by the web client as they ponder the screen. In many cases it is possible to split the presentation to the web client of the GUI and the submission of the filled GUI into two web services transactions supported by different server-side APL+Win functions.

Assuming that the server-side APL+Win functions handling the transaction ensemble are properly configured to refresh global variables in the workspace whenever a new ensemble of transactions is processed, the only 'clean-up' necessary would be to have the web client call 'END_SINGLE_SESSION'.

The information necessary to maintain this 1:1 relationship between the web client and the particular instance of APL+Win running on the server is contained in a 'cookie'.

If by 'shut-down' you mean an un-anticipated error on the server side, then this is handled by having the web client listen for exceptions from the server in addition to expecting the anticipated results of the transaction call from the web client to the web server. Such exceptions on the server side may require transaction recovery methodology in the server-side APL+Win functions. For example, if the server-side APL+Win application is manipulating data in an SQL Server database, then those manipulations should be encapsulated into an SQL Server database 'transaction' so that partial manipulations are reversed and the SQL Server database data remains consistent.

A 'shut-down' caused by an anticipated error on the server side, e.g. validation of invalid web client input, should be handled by the anticipated return result of the transaction rather than by an exception thrown by the server-side application.

For server-to-server communication, the APL+Win 'Notifiy' method can be used to inform the server communicating with APL WebServices of exceptions. The []elx of the APL+Win application can be set to create/capture the appropriate error message and then transmit it as an exception to the other server and, if desired, shut-down the current instance of APL+Win. Syntactically: '#' []wi 'Notify' ('<aplresult><aplmethod>kill2aplcom</aplmethod><apldata>',x,'</apldata></aplresult>'), where x is any (string) data result to be sent back to the calling server.

What other 'program control over the situation' would you need or like to have?

Actually APL WebServices is not that mysterious. It is based upon the Microsoft IIS (Internet Information Services) model, which itself is based upon the multi-vendor-endorsed www.w3.org standards for web services. The pre-existing APL+Win ActiveX/Com interface does the work on 'translating' between the data types of APL+Win and Win32 datatypes of COM. APL WebServices uses the .Net Framework to translate between the COM data types and the .Net datatypes and finally the www.w3.org web services structures which are all string-based.

Here is a bit more detail on the state-ful operation of APL WebServices:

(1) The 'workspace timeout' option in the APL WebServices configuration is considered only if the 'workspace debug' option is off (value = 0).

(2) The 'workspace timeout' option, when it is considered, will limit the server-side processing time that a single external (i.e. web-client initiated) call to an APL WebServices 'virtual path' (i.e. a call to a server-side APL+Win function) can take.

If a web-client makes a call to a specific 'virtual path' exposed by APL WebServices and if the 'workspace timeout' option applies and if the server-side processing of that call takes longer than the APL WebServices administrator's setting of the 'workspace timeout', that server-side instance of APL+Win which is performing the processing will be ended.

(3) If a web-client initiates a 1:1 (single session) interaction with a service exposed by APL WebServices that provides that option and as long as the 'workspace timeout' condition does not apply, the 1:1 interaction will end only when the web-client indicates it should end.

Note that when 1:1 interaction is in effect, there may be more than one 'external' call to one or more APL WebServices 'virtual paths'. If the server-side processing time of any one of these calls exceeds the 'workspace timeout' in effect the server-side APL+Win session serving this web-client will end and the 1:1 interaction will be terminated.

So AWS keeps cookies (session-only, I assume) going to the user's browser to keep track of the connection. Does it hide those cookies from me, or do I need to make sure I perpetuate them myself? Also, what happens if a user submits a second request (perhaps from a cloned copy of their window) while a previous request is still in progress? Does AWS hold the second request until the first one finishes so that it can deliver the request to the same workspace? Or does it spin up a second 1:1 copy of the workspace (which is now no longer 1:1), or what?

It's interesting to know that the workspace timeout value is used for two completely different purposes simultaneously. I guess it's a good thing that I don't need (at present) both features with different timeouts, but I can see where that could be needed. This could at least use documenting. (In fact, all the documentation seems to be a bit difficult to use. Each piece seems to be keyed toward one specific use and doesn't give you any help elsewhere.)

To clarify my question about cleanup/notification, I was talking about when AWS decides that my time is up and shuts down that 1:1 copy of the web application. Since my application typically has things open and in process, do I get some kind of notification from AWS before it kills me that I can use to do any cleanup work before going away? A trivial example of this would be to logout of the database or cleanly close other kinds of files.

1. The cookies that are used by APL WebServices to keep track of a 1:1 connection between a web-client and a specific server-side instance of APL+Win are:
â€¢ Not hidden
â€¢ Automatically managed by APL WebServices
â€¢ Need no programmer intervention.
â€¢ Are relevant only for a specific browser session or APL WebTransfer instance.

2. The server-side order of servicing web-client requests depends on whether the web-client requests are submitted as synchronous or asynchronous requests. All transactions received by APL WebServices are queued up and processed as instances of APL+Win become available. The initial number of instances and the maximum number of instances of server-side APL+Win are programmer controlled. A separate queue is established for a web-client that has established a 1:1 connection to a specific server-side instance of APL+Win.

a. Synchronously-requested transactions:
i. For any specific web-client, a sequence of synchronously-requested transactions will be processed in order and their results will be received in order at the web-client side. The n-th transaction will commence processing only after the (n-1)th transaction has been processed. The client-side program synchronously-submitting requests will stop after each request and wait for a response associated with that request before it can begin submitting the next request.

ii. If a specific web-client has established a 1:1 connection to a specific server-side instance of APL+Win, synchronously-requested transactions submitted by that web-client are all processed by that instance of APL+Win.

2. Indirectly by using APL WebTransfer functions such as 'Send' or 'SendObject'

b. Asynchronously-requested transactions:

i. If a specific web-client has established a 1:1 connection to a specific server-side instance of APL+Win, then a sequence of asynchronously-requested transactions is treated as if they were all synchronously-requested because the 1:1 connection means that a specific instance of APL+Win is servicing that web-client's requests.

ii. If a specific web-client has not established a 1:1 connection to a server-side instance of APL+Win, then a sequence of asynchronously-requested transactions is processed as if they were submitted by separate web-clients, i.e. in the order that server-side instances (not necessarily the same) of APL+Win become available. These requests may not be processed in the same order as submitted and may not return results in the same order as submitted. It is this feature of APL WebServices which provides multi-threaded (and if available multi-processor) support to APL+Win running behind APL WebServices.

iii. The web-client becomes aware of the completion of processing of an asynchronously-submitted request to the server, if that web-client subscribes to the server-side-generated event indicating this completion. Event handling is necessary because when an asynchronous request is submitted by a web client, the client-side program does not wait for a response, but is free to submit the next request.

iv. A web-client may submit a request asynchronously:

1. By initiating independent web-browser sessions

2. Indirectly by using APL WebTransfer functions such as 'ASend' or 'ASendObject'

3. How can a browser use APL WebTransfer?

For example by pointing the web-clientâ€™s browser to an an .asp (Win32) or .aspx (.Net) web page, such as might be supported by Microsoft IIS, which then creates an instance of the APL WebTransfer class and submits the web-clientâ€™s request to APL WebServices as a â€˜server-to-serverâ€™ transaction.

The intermediate web page need not be .asp or .aspx, however in order to use APL WebTransfer to communicate with APL WebServices, the intermediate web page must be able to use .Net or ActiveX/Com.

The advantages of having APL WebTransfer between the web-client and APL WebServices include:

a. Asynchronous transaction mode can be used
b. Events generated by the web-server can be handled
c. Data quantities can be transmitted from web-client to server which are in excess of those which can be incorporated in a limited-length url of the form http://.../arg1=.....

4. The â€˜workspace timeoutâ€™ has only one purpose - to end the web-clientâ€™s connection to a server-side instance of APL+Win if the processing of a specific transaction request takes more than the programmer-set â€˜workspace timeoutâ€™ value.

If a web-client has a 1:1 connection to a specific server-side instance of APL+Win, then each of the transactions requests submitted to the server by that web-client will be individually subject to the â€˜workspace timeoutâ€™ and each such transaction will individually have available the full time limit of the â€˜workspace timeoutâ€™.

So a 1:1 connection can be ended as a result of a â€˜workspace timeoutâ€™ condition, but only if the server-side processing time one of the web-client-initiated transactions exceeds the â€˜workspace timeoutâ€™ limit.

The only purpose of a 1:1 connection would be to support the web-client that needed to submit more than one transaction to the server during the same web-client session.

If a â€˜workspace timeoutâ€™ occurs it will be signaled by to the client as follows:

a. If the web-client request came directly via a browser url, the browser will handle the timeout, probably by displaying a standard error page such as â€œInternet Explorer cannot display the webpageâ€

The maximum character length of such a url is limited, so that other means are necessary when the amount of data to be transmitted to an APL WebServices web-server is larger than that which can be accomodated using the above-described url method.

When a string url cannot transmit the required data some alternatives are:

(1) Creating an html page with fields and a submit button pointing to a web server. The web-server function called for this transaction when the submit button is clicked must be configured to accept each of the form fields. The server-side APL+Win function referenced in the APL WebServices virtual path will have multiple right (string, integer or float) arguments which correspond in name and order to the fields in the html page.

(2) Pointing the web-client browser to an asp(Win32) or aspx(.Net) web page, housed in Microsoft IIS, which then creates an instance of APL WebTransfer to transmit the request to the web server. APL WebTransfer functions such as Send, SendObject, ASend and ASendObject provide arguments which can be filled with large data arrays to be received by a an APL WebServer configured to receive them. The data serialization options available for an APL WebServer include SOAP encapsulation, binary serialization and XML format.

1. Ok, so the cookie is generated by AWS when I set the 1:1 return result and passed back to the browser. On the next call, the browser sends back the cookie which AWS reads and knows to route to my waiting dedicated application session. But if the cookie is not hidden (to my application), then I need to know to ignore it when it comes to me (so I'll need to know its name, which I should be able to determine empirically). And when I return a result (often with cookies of my own), do I need to return AWS's cookie as well (since it's not hidden)? What if I don't return it, or change its value before returning it? Does AWS ignore that particular cookie if I return it and provide/substitute its own?

2. Very completely described. It answered my question well by telling me that multiple asynchronous 1:1 calls are queued up and processed sequentially (serializing them).

4. Ok, I think I'm confused again here. The workspace-timeout value keeps a single APL application call from running too long before returning a result. If it exceeds the timeout, it terminates the APL session and returns a failure message to the user. Right?

But that wasn't quite the question that I'd originally asked... If a user sends a request to my APL application, I'll service it and return a result to him, but set the 1:1 flag so I stay "connected" to him. Now he's looking at what I sent him, but it's lunchtime so he goes to have a long two-martini lunch and comes back in a couple of hours. He then wants to press a button and make another request to his 1:1 session. Is it still waiting for him, hours later, or has it "timed out" in the meantime? Most web servers have a limited time that their stateful sessions can last, after which they're disposed of. Does AWS have such a limit? If so, how long is it and can it be changed? If not, why not and how do abandoned 1:1 sessions ever get cleaned up?

You also spoke about signaling the user about a timeout, but I was asking about signaling my APL server application that has remained open and active in a 1:1 configuration. You did talk about that as well, and even mentioned "the request to 'terminate'", but only as an aspect of the end effect of termination, not as HOW I was informed that it was in process. For example... if AWS terminates my APL application due to an exceeded timeout, do I get any notification that it's going away. For instance, does the system object '#' trigger an onClose, onDestroy, or onDelete event (or something like that) before my application is actually removed from memory? I guess I could do as you say and experiment with all the system event handlers by trial and error to see if one of them tells me what I want to know. I just thought it'd be easier to ask and get a simple onXXX answer.

Davin asks:
1. Ok, so the cookie is generated by AWS when I set the 1:1 return result and passed back to the browser. On the next call, the browser sends back the cookie which AWS reads and knows to route to my waiting dedicated application session. But if the cookie is not hidden (to my application), then I need to know to ignore it when it comes to me (so I'll need to know its name, which I should be able to determine empirically). And when I return a result (often with cookies of my own), do I need to return AWS's cookie as well (since it's not hidden)? What if I don't return it, or change its value before returning it? Does AWS ignore that particular cookie if I return it and provide/substitute its own?

Answer:
Why do you feel you need to know to ignore it (the cookie)? Are you destroying cookies or otherwise modifying them in the interaction between client and server?
You do not need to return AWS's cookie, its managed by the underlying .Net http request.
Why would you want to change its (the cookie) value?

Davin asks:
4. Ok, I think I'm confused again here. The workspace-timeout value keeps a single APL application call from running too long before returning a result. If it exceeds the timeout, it terminates the APL session and returns a failure message to the user. Right?

Answer:
The 1:1 connection is affected by the 'workspace timeout' only if one of the web-client-submitted transactions requested during a 1:1 session have a web-server-side processing time which exceeds the programmer-determined 'workspace timeout' in the AWS configuration for that web service. If the 'workspace timeout' condition occurs, the web-client user receives an error message.

Davin asks:
But that wasn't quite the question that I'd originally asked... If a user sends a request to my APL application, I'll service it and return a result to him, but set the 1:1 flag so I stay "connected" to him. Now he's looking at what I sent him, but it's lunchtime so he goes to have a long two-martini lunch and comes back in a couple of hours.

He then wants to press a button and make another request to his 1:1 session. Is it still waiting for him, hours later, or has it "timed out" in the meantime? Most web servers have a limited time that their stateful sessions can last, after which they're disposed of. Does AWS have such a limit? If so, how long is it and can it be changed? If not, why not and how do abandoned 1:1 sessions ever get cleaned up?

Answer:
As long as there is no transaction being processed, the 1:1 session remains in force as far as APL WebServices is concerned.
Note however, that most ISP's have their own session timeout which will likely come into play if the lunch is my type of lunch, i.e. several courses with wine and then a nap. Also underlying APL WebServices are .Net http methods and properties and .Net has overall limits the values that can be set for the ConnectionTimeout property in the APL WebServices webserver properties. You can research this in the System.Net and System.Web namespaces.

Davin asks:
You also spoke about signaling the user about a timeout, but I was asking about signaling my APL server application that has remained open and active in a 1:1 configuration. You did talk about that as well, and even mentioned "the request to 'terminate'", but only as an aspect of the end effect of termination, not as HOW I was informed that it was in process. For example... if AWS terminates my APL application due to an exceeded timeout, do I get any notification that it's going away. For instance, does the system object '#' trigger an onClose, onDestroy, or onDelete event (or something like that) before my application is actually removed from memory?

I guess I could do as you say and experiment with all the system event handlers by trial and error to see if one of them tells me what I want to know. I just thought it'd be easier to ask and get a simple onXXX answer.

Answer:
As you note, I indicated that the 'request to terminate' issued by APL WebServices when a 'workspace timeout' occurs is handled by APL+Win performing as an ActiveX server. I could not immediately answer the question "If the onClose or onDelete events can be trapped when an APL+WIn ActiveX server session is 'requested to terminate'?", as this is really an APL+Win question, which I have not thusfar researched. When time permits, I will investigate this question further.

Also note that whenver I have implemented an APL WebServices application, there has been a customer requirement that the entire server-side calculation be performed within a few seconds. Generally the attention-span of a web-browser-based client is less than 15 seconds when waiting for a reponse from the server-side.

According to the APL+Win Windows Interface documentation, the APL+Win system object (#) does not have an onDelete event

joe_blaze wrote:Why do you feel you need to know to ignore it (the cookie)? Are you destroying cookies or otherwise modifying them in the interaction between client and server?You do not need to return AWS's cookie, its managed by the underlying .Net http request.Why would you want to change its (the cookie) value?

I'm setting my own cookies and have to do them one at a time (don't I?), so if I need to return extra cookies I need to have a special place to put it. Apparently, I don't have to worry about that part.

I'm also accepting in all my cookies and checking them for validity. If there's an extra cookie in there that I need to be aware of, that's why I'm asking if it's being passed to me.

Also, if I'm being passed an extra cookie and since I'm changing cookies during processing, I wanted to know what would happen if I accidentally changed the wrong cookie. This will help me understand how your code is working under the covers so I can answer some of my own questions when they come up during coding.

joe_blaze wrote:As long as there is no transaction being processed, the 1:1 session remains in force as far as APL WebServices is concerned.

This would be a "bad thing" if it never timed out a session - most of the sessions you started would never go away and they'd be occupying resources until the next server reboot (or crash, which would be more likely with thousands of dead APL servers out there).

joe_blaze wrote:Note however, that most ISP's have their own session timeout which will likely come into play if the lunch is my type of lunch, i.e. several courses with wine and then a nap.

I don't see how this has anything to do with my question, as ISPs can't even "see" logical sessions maintained by cookies. Perhaps you're talking about a long-term SPX connection (which isn't the same thing)?

joe_blaze wrote:Also underlying APL WebServices are .Net http methods and properties and .Net has overall limits the values that can be set for the ConnectionTimeout property in the APL WebServices webserver properties. You can research this in the System.Net and System.Web namespaces.

Ok, this sounds more promising, although I'm having trouble sorting through the rather large number of timeout features to find what I want. I also can't figure out how to set a WebServer.ConnectionTimeout property from anywhere that I am since I'm not using .Net for anything here. Finally, that doesn't look like it applies to the problem I'm having because it's talking about a Socket timeout, not a "logical session" timeout.

joe_blaze wrote:As you note, I indicated that the 'request to terminate' issued by APL WebServices when a 'workspace timeout' occurs is handled by APL+Win performing as an ActiveX server. I could not immediately answer the question "If the onClose or onDelete events can be trapped when an APL+WIn ActiveX server session is 'requested to terminate'?", as this is really an APL+Win question, which I have not thusfar researched. When time permits, I will investigate this question further.

I have tried deleting an ActiveX copy of APL and trapping any events that occur. But I cannot find any events occurring that warn me of the impending deletion of my APL ActiveX session. If AWS terminates me, I need to be able to clean up my session before going away. I can't see any way to do that. Can you tell me specifically how to accomplish that (from the ActiveX side)?

joe_blaze wrote:Also note that whenver I have implemented an APL WebServices application, there has been a customer requirement that the entire server-side calculation be performed within a few seconds. Generally the attention-span of a web-browser-based client is less than 15 seconds when waiting for a reponse from the server-side.

You seem to be talking here about how long my ActiveX server has to respond to the client request, but that's not at all what I've been asking about. I want to know how long my 1:1 session will remain in memory if they STOP making requests to it. There really needs to be a "no longer in use" timeout to keep APL ActiveX sessions from staying open indefinitely if the user simply closes his browser.

Am I making any sense yet? This is really the primary question as everything else hangs on the answer to this issue.

Joe says:
Actually if you are using APL WebServices, you are using .Net. APL WebServices is based on .Net. It has to be so because APL+Win itself is based on Win32 and it was not designed to do multi-threading. Multi-threading is the way APL WebServices can respond to many web-clients, i.e. by establishing as many independent threads each associated with an instance of APL+Win running as an ActiveX server. The web-client may not be .Net-based, but the server-side instances of APL+Win are running under APL WebServices (.Net) control.

The 'Connections Timeout: (in seconds) setting in the APL WebServices properties for a specific web service is setting the WebServer.ConnectionTimeout property for you as the APL WebServices administrator. A bit more on this item is provided below.

Davin says:
I have tried deleting an ActiveX copy of APL and trapping any events that occur. But I cannot find any events occurring that warn me of the impending deletion of my APL ActiveX session. If AWS terminates me, I need to be able to clean up my session before going away. I can't see any way to do that. Can you tell me specifically how to accomplish that (from the ActiveX side)?

Joe says:
I did some testing on my own in the interval since our last discussion and I also found no such event which can be trapped by APL+Win running as an ActiveX server when it receives a request to close. This behavior of APL+Win running as an ActiveX server has no relation to and is not caused by APL WebServices. Thus there are two issues here:

(1) Can APL+Win running as an ActiveX server trap the event of a request to close itself issued by the program which started APL+Win as an ActiveX server? I will ask our APL+Win developers this question. I doubt that there will be such an event, because how can a server resist the imperative to end its existence when that might be caused by any number of failures like power, hardware, etc. ? Remember that APL+Win running as an ActiveX server is an encapsulated object which only knows it's being requested to terminate and not why, so separating a 'friendly' request to terminate from an initiating program and an 'imperative' request from an environment failure may not be possible.

(2) How do web services, not just APL WebServices, handle 'dead' or 'dropped' web clients? You probably won't like my answer, but whenever web services are involved there is an element of 'unreliability' which must be factored into the design of the web service. The web service must assume that dropped connections, timeouts, malware, power and hardware failures will occur. The various timeout settings are employed to conserve server-side resources by limiting the time that a web client can engage the server-side resources. To mantain a level of integrity of server-side resources, the server-side program will adopt strategies like:

(a) Adjusting the 'granularity' of the operation so that there are definite separation zones around critical steps in the process being requested of the web service. In this way these sections of the process are very likely to run to completion because they take little time and correspond to key web-client input triggers . For really critical applications, each of these sections is designed so that processing can be restarted at the beginning of any one of the sections and indicator values are saved when any section is completed, so that it is clear which is the 'next' section to process. This is why many web services which have a web-client GUI are much like 'wizards' with 'Next' or 'Continue' buttons marking the sections of the application system process.

(b) When critical server-side database updates are performed, these are enclosed in 'database' transactions with definite 'rollback' capabilities. Commercial databases like Microsoft SQL Server or IBM DB2 do not instantiate database updates immediately, but instead queue up database changes into transaction files which are buffered until all elements of the transaction are in the buffer and then they are acted upon and made effective in the physical datastore only if they represent a 'complete' transaction. This strategy can be employed even when not using a commercial database, for example, web-client requests can be queued up into a transaction file by the client-connected web service. The valid transaction would contain a keyed 'start-of-transaction' header, followed by one or more transaction instructions to be completed on the server side, followed by an 'end-of-transaction' footer with the same key. Another web service can process these transactions, but only if they are complete, i.e. contain both an identically-keyed 'start-of-transaction' header and an 'end-of-transaction' footer. If the transaction block is not complete it is trashed or if really important can be placed in a secondary recovery queue. Note that the client-connected web service can loose its connection to the client, but as long as the transaction block was 'complete' the transaction will be processed. The initiating web service or a subsequent and appropriately-configured web-client session, can find out about completed transactions by either subscribing to an event which will be triggered by the second web service performing the processing or by looking for an indicator field in the data store.

Davin says:

You seem to be talking here about how long my ActiveX server has to respond to the client request, but that's not at all what I've been asking about. I want to know how long my 1:1 session will remain in memory if they STOP making requests to it. There really needs to be a "no longer in use" timeout to keep APL ActiveX sessions from staying open indefinitely if the user simply closes his browser.

Joe says:

There is such a timeout. It is the 'Connections Timeout: (in seconds) discussed above.

Somehow, I still don't think we're talking about the same thing. For simplicity, let's just consider this scenario:

1) A user opens their web browser and makes a request to my web server (which is running AWS & an APL workspace).

2) The browser opens an SPX socket to my server. AWS accepts that socket, retrieves the web request, and passes it to the (only) running copy of my WS.

3) My WS takes a few seconds to compose an HTML reply, which it then returns to AWS along with a 1:1 flag. AWS passes the answer back to the user's browser across that still-open socket. It includes a cookie so that it knows when the same user makes his next request.

4) AWS then closes the SPX socket. One HTTP transaction is now complete.

5) The user examines the reply for a minute or two, and then decides to make a second (related) request by clicking on something on my earlier web page.

6) The browser opens a new SPX socket to my server. AWS accepts that socket and sees a cookie coming back from the browser that it recognizes. AWS matches up the returning user with the previous 1:1 session and forwards the request on to the same running copy of my WS.

7) My WS takes another few seconds to compose another reply, which it returns to AWS and continues to assert the 1:1 flag. AWS passes the answer back to the user's browser across the requesting socket, along with any cookie data to maintain that logical connection.

8) AWS then closes the SPX socket and the second HTTP transaction is complete. So far, no timeouts of any kind have had a chance to occur.

9) The user now goes off to do other tasks and leaves his browser window open on his machine. He returns 6 hours later and resumes work on the web site.

10) He presses another button or makes another selection on his browser to start a third request to my web site, many hours after his last interaction with it.

11) Again, the browser opens up an SPX socket and contacts my server. AWS receives the request and sees the identifying cookie requesting a route to my waiting WS.

12) NOW, the question at this point is, after being completely idle for 6 hours, does AWS still recognize that cookie and is my WS still in memory, reserved, and waiting for the next request? Or has AWS disposed of the memory of that cookie and possibly my ActiveX WS along with it?

The answer to this one simple question will lead me to my next question. Hopefully that simplification will get us talking about the same subject.

(1) The service your server is offering, i.e. what settings you have set on the server-side. If you have set the timeouts to tolerate 6 hours then your server will reserve that instance of APL+Win for up to that time

(2) The connection service your web-client is using to connect to your web service and the associated settings, which may not be under the control of the web-client.

Surely you have made a plane reservation or used a web purchase system which eventually, depending on the timeouts which have been established on both the server- and client-sides, will indicate to the web-client that the 'page has timed out'. At that point, depending on how the web service was configured, after the user reconnects, it may be able to retrieve a cookie from the client with the partially completed input data or maybe not.

The 'simple' answer to your 'simple' question is that timeout settings, some under your control as the provider and configuration adminstrator of the web service, some under the control of web-client and others under the control of the connection service will determine if the connection will hold for 6 hours. As the provider of the web service you cannot know all of these variables, so you must design your web service to handle disconnections at any time. 'Handling' in this case is up to the designer, from trashing the partially-completed transaction to more elaborate transaction grouping which was discussed earlier.

So it is possible, but highly unlikely, that the connection will be maintained for 6 hours, for the reasons outlined above, but should that be the case, then the APL+Win instance associated with the 1:1 websession will be ready and waiting to service that web-client's request.

The fact that the first few transactions described in your scenario were successfully completed between the web-client and your web-server during the 1:1 session, does not mean that any future ones will be as successful.

There is simply no way that a web-server can absolutely 'know' that there is an active client on the other end of the connection at any time 't'. That's why timeouts were invented.

There is nothing 'different' about the web services made possible by APL WebServices from any other web services tool, except that APL WebServices facilitates the use of multi-threaded APL+Win server-side instances to satisfy the requests of the web-clients. All the benefits and foibles of web-based interaction apply to any web service anywhere anytime.

By the way, you could actually try this scenario out - you have a browser and you have APL WebServices. See what happens, but the result will be anechetdotal and not in-general conclusive.

joe_blaze wrote:(1) The service your server is offering, i.e. what settings you have set on the server-side. If you have set the timeouts to tolerate 6 hours then your server will reserve that instance of APL+Win for up to that time

Ok, so if that's the case (that I can control AWS's timeout from my end), how do I do it (ignoring any other possible timeouts that may be elsewhere in the network)? Can you please tell me the exact command or configuration entry to type in to set that one value? I'm sorry I'm still not getting it.

I thought that the setting methodology should not be buried at the end of the current discussion, so I created a new topic to contain just the technical details of making the setting. We can keep discussing your issues here and keep the other topic as pure documentation.

joe_blaze wrote:I thought that the setting methodology should not be buried at the end of the current discussion, so I created a new topic to contain just the technical details of making the setting.

That's a good idea.

And I'll try the setting you suggested (as soon as my ISP fixes the network they broke), but I thought sure that's exactly what you were telling me before that would NOT work, which is partly why I've been so confused.