|
Asynchronous Synchronous Post Feedback Mechanism
|
Asynchronous Synchronous Post Feedback Mechanism (ASPFM) is a mechanism by which truly asynchronous processes, methods, applications or systems can be built for any computer platform or language. This mechanism enables software developers to come up with completely asynchronous components using a Reverse-Service concept which involves a POST - FEEDBACK mechanism to acheive the true asynchronous nature. Every Service has a corresponding Consumer who will ask for some kind of response from the Service either in a Synchronous or an Asynchrnous manner. Our idea of an Asynchronous system is "the Consumer spawns a listener thread which runs in parallel to the actual Consumer operational procedure without disturbing the normal Consumer flow and waiting in a separate thread for the response and the flow after the response is bifurcated to the Listener thread". This type of behaviour is not purely Asynchronous as the Listener will continuously poll the response at regular intervals of time (agreed it might be in a sleep state most of the time the response hasn't arrived) and when response arrives will perform some logic with it. Consider a scenario where we need 100 concurrent Asynchronous processes waiting for some feedback from the Service, we can say that 100 Listener threads are in some kind of poll and sleep state until some response is avaialble. So practically the number of Listener threads increase in proportion to the number of asynchronous processes and this number will keep on increasing with the increase of the latter. This way system resources are allocated to processes which actually spend most of the time in a wait state (poll and sleep). Every thread is allocated system resources, it's own menmory space,cpu time etc, which is not fully utilized by the wait processes. A solution to this problem would be the Service itself notifies the Listener of the response without it having to wait. For this to happen the Listener would have to be configured as a Reverse-Service which will be called by the called Service. This way the Consumer would POST some data to the Service and have a listener registered as a Reverse-Service and the called Service would provide a FEEDBACK to the Listener. After one-way communication between the Consumer and Service, the Service will change its role to being the Consumer and in turn will call the Reverse-Service i.e. the Listener. Thus 2 Synchronous calls would complete an Asynchronous call and this would complete the Asynchronous Synchronous Post Feedback Mechanism flow. A counter-argument to this mechanism would be that, the called Service would have to house the logic to call the Reverse-Service and changes would have to be made to the already available Services. A solution to this problem would be "to have a Layer in between the Consumer and the Service such that", * a Listener is registered for the feedback from the Service call * the Consumer registers a call for the Service to the Layer * the Layer calls the Service and receives response from the Service * the Layer calls the Listener Service with the response This approach would add extra infrastructure to the existing application but when considering huge number of concurrent asynchronous processes this would definitely provide a better alternative solution.
|
|
|