Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Emulating Synchronous Behavior in Asynchronous Environments

IP.com Disclosure Number: IPCOM000190223D
Original Publication Date: 2009-Nov-20
Included in the Prior Art Database: 2009-Nov-20
Document File: 5 page(s) / 62K

Publishing Venue

Microsoft

Related People

Mohammed Fadel Shatnawi: INVENTOR

Abstract

Whereas it is very common to desire asynchronous behavior within synchronous environments, in order not to wait or block for a lengthy operation, it is rarely the case where an application would block for an asynchronous call to finish. However, the growing appeal of service based computation, and the introduction of platforms and solutions that mediate between applications and services (like WCF), some service calls are designed to be asynchronous, whereas the developer calling them, want to make the call synchronously. An example of such a situation is when a developer wants to create an entity in an external database system, and wants to wait until the creation is complete before populating that entity with data. For such cases, where the environment is inherently asynchronous, but synchronous behavior is required, there is a need to block for the asynchronous call to finish, before moving on with the execution of the application. This work introduces a few ideas on how to emulate synchronous behavior in asynchronous environments.

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 45% of the total text.

Document Author (alias)

Mohammed Fadel Shatnawi (mohammed)

Defensive Publication Title 

Emulating Synchronous Behavior in Asynchronous Environments

Summary of the Defensive Publication/Abstract

Whereas it is very common to desire asynchronous behavior within synchronous environments, in order not to wait or block for a lengthy operation, it is rarely the case where an application would block for an asynchronous call to finish.

However, the growing appeal of service based computation, and the introduction of platforms and solutions that mediate between applications and services (like WCF), some service calls are designed to be asynchronous, whereas the developer calling them, want to make the call synchronously. An example of such a situation is when a developer wants to create an entity in an external database system, and wants to wait until the creation is complete before populating that entity with data.

For such cases, where the environment is inherently asynchronous, but synchronous behavior is required, there is a need to block for the asynchronous call to finish, before moving on with the execution of the application.

This work introduces a few ideas on how to emulate synchronous behavior in asynchronous environments.

 

Description:  Include architectural diagrams and system level data flow diagrams if: 1) they have already been prepared or 2) they are needed to enable another developer to implement your defensive publication. Target 1-2 pages, and not more than 5 pages.  

Synchronous behavior is the default

It is common, in software solutions, to transform synchronous calls to asynchronous ones, so that the caller doesn’t have to block for a lengthy operation or on a contention resource. But it is rarely the case that an asynchronous call needs to be treated as if it was synchronous.

As such, this invention may seem unnecessary, since the foundation of "Von Neumann" architectures is by default synchronous, and work needs to be done to transform calls from synchronous to asynchronous calls. So why change a call from synchronous to asynchronous and then change it again to synchronous?!?!

Asynchronous behavior is the norm in Services

The fact of the matter is that service oriented architectures and software as a service are gaining a lot of appeal in the software industry. And many new services enforce asynchronous call styles in their programming models; that is the only available cross service boundary calls are asynchronous calls.

Developers have no say in this but to comply with this enforced model. But there are many times within such an environment the developer would want to have the enforced asynchronous behavior to behave synchronously. An example is when a developer creates an entity in an external database and wants to wait for the creation to complete successfully before writing data into that entity.

Callback Functions

The de facto methodology to counter the effects o...