Interviewer - Server > Architecture > Web Service tier > Interview Web Service implementation > Interview Web Service behavior
 
Interview Web Service behavior
For performance reasons, the web service uses an InstanceContextMode of Single and a ConcurrencyMode of Multiple. This means that a single class is used to handle all requests and that class methods must be thread safe in order to be called concurrently by multiple clients. The single instance of the interview web service class holds the necessary resources in memory for use by multiple requests (for example, the HTML Player and engine registration information).
The Interview Web Service is fully asynchronous. This includes the web service's HTTP GET and POST handlers. The asynchronous HTTP request handlers are implemented via the [OperationContract(AsyncPattern = true)] attribute. The web service implements the BeginXXX() and EndXXX() methods for each URI. The service has a SingleServer and Distribute mode (like mrIWeb). When configured for SingleServer mode, the Interview Web Service creates an in-process instance of the Session Engine object and uses is for servicing requests. When configured for Distributed mode the Interview Web Service makes requests to mrIEngWS on the engines. The service uses the registration information to determine the engine URLs (see Session engine usage.). Session Engine calls are made by adding mrIEngWS as a web reference and using the web service's BeginXXX() and EndXXX() method pairs (for example, BeginPostInterviewEvent() and EndPostInterviewEvent()).
The Interview Web Service is stateless across URL requests. The design is such that all information required to handle subsequent requests is included in the response. For example, the response includes the engine from which to direct the next request and the project name so that another hosting engine can be found if the original engine fails. This eliminates the need for the Interview Web Service to maintain the information.
See also
Interview Web Service implementation