07:57:31 PM
3HG16S4A9
Excellent reply, thanks. I had thought "this sounds like the server should be a separate component", but then I thought no, I am just imagining that.
The separate exe idea is great, it gives me the flexibility and separation of client data I need,.
Thanks again.
Tuvia,
The wwAsyncWebRequest component can go anywhere. Sufficiently vague for you? :-) But that's literally true as it's just the 'messaging' component that allows you to store and retrieve data for messaging.
As such it reqiures a client - which submits, requests status and receives a result/failure, and a server that retrieves a request from the 'queue', processes it, updates status and then stores a response.
The 'Server' can be implemented in any way you choose, but it almost always is separate from the Web Connection application - a standalone EXE or another service on another machine that polls the same database for requests. It makes no sense to have an async process in the same process as the Web Connection app since VFP's single threaded nature ties up the CPU when it's processing.
One typical workflow that I've used for this looks like this:
* Web Connection server is the client
* Receives a request from application to start processing
* Creates a new Message for processing
* At the same time starts a separate EXE that knows how to handle one or messages
(this will become your Async 'server' that runs one request)
* The 'server' picks up message and now starts processing the async task
* Server then sends updates into the message object and saves
* Client polls occasionally to see update status or at very least polls for completion
* Server finishes processing and updates message object to say it's completed
* Server exe shuts down
* Client polls and finds server is done
* Client retrieves result data stored in message
* Client displays result
How the server is implemented is up to you really. I like the idea of an EXE started so that EXE is active for the duration of one aysnc request processing. If multiple asyncs are requested new Exes start up. Another alternative is that you can just run a permanent server that is always running and polls for new incoming messages and then processes them one at a time. You can run one or more of these daemons depending on your load.
It works rather well and is pretty flexible actually. I've used this same approach in .NET as well and works there as well. Because the data is stored in plain Fox or SQL data you can also read it from other applications and interact with other technologies.
This component lives in the same space as MSMQ but IMHO is much easier to work with and more flexible.
Hope this helps,
+++ Rick ---
