This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!
Introduction to Asynchronous Programming Model
Asynchronous programming is a feature supported by many areas of NGWS, namely:
- File IO, Stream IO, Socket IO
- Networking: HTTP, TCP
- Remoting Channels: HTTP, TCP
- ASP+, ASP+ WebServices,
- Messaging Message Queues over MSMQ
- Delegates
As a core concept, the NGWS frameworks and runtime provide an important common design pattern to avoid confusion among developers. This document details this design pattern and demonstrates the pattern using Async delegates.
The basic ideas behind this pattern are as follows:
- It is the caller that decides if a particular call should be asynchronous.
- It is not necessary for a called object to do additional programming for supporting asynchronous behavior by its clients. The NGWS runtime infrastructure should be able to handle the difference between the caller and called object views.
- The called object can choose to explicitly support asynchronous behavior either because it can implement it more efficiently than a general architecture or it wants to support only asynchronous behavior by its callers. However, it is recommended that such called objects follow the asynchronous design pattern for exposing asynchronous operations.
- Type safety. For Async delegates, the compiler generates type safe method signatures for BeginInvoke and EndInvoke.
- The NGWS frameworks and runtime provide services needed for supporting asynchronous programming model. An example partial list of such services is:
- Synchronization primitives such as Monitors and Reader Writer Locks.
- Threads and Thread pools.
- Synchronization constructs such as containers that support Waiting on objects.
- Exposure to the underlying infrastructure pieces such as IMessage objects and Thread Pools.