Lab #14: Controlling Service Instancing

Members:

Rafael Zuniga, Stephen Cave

Summary:

The purpose of this lab is to show how service calls work with PerCall, PerSession, and Single instancing modes.

Procedure:

We begin by opening the solution in Chapter5/Instancing under the labs directory. After successfully building the solution we run the host and client testing out each of the services using no exception. Currently the host is set to serve PerCall so the variable value is not kept between each call by the client:


Services that support sessions display the following:



Next we test the exception handling for each of the types of bindings. The BasicHttpBinding and WSHttpBinding without session behave the same, that is after the exception the client is still able to call the host server. The same is not so with bindings supporting sessions, after the exception is thrown and displayed another error is displayed stating that the communication object has been faulted:



When calling the service using the client's fault button all of the services are able to recover and call again. Modifying the service by setting the InstanceContextMode to PerSession and running the tests again results in bindings without session support not retaining their variable value while those that do support sessions successfully increment the variable to 2. Next we modify the ServiceContract to disallow sessions by setting SessionMode to NotAllowed. This time if we attempt to run the project we are hit with an exception due to certain bindings requiring a session.



Since we can't run the project with the named pipe and TCP bindings we comment them out in the configuration file. Running the tests again we find that disallowing sessions is similar to setting PerCall since for each call, even if the binding supports sessions, the variable is initialized again to 1. Next we modify the service to require sessions. Again an exception is thrown since certain endpoints do not support sessions, such as BasicHttpBinding, so we must comment them out in the application configuration file. Running the tests again we find that the variable value is kept in between calls to the service. Next we modify the service to use a single instance and run the tests again. This time we find that the variable value is kept across all calls, including for bindings without sessions:



Observations:

1. The usual access denied error for TCP connections, have to run Visual Studio with administrator permissions
2. Bindings which use sessions fault when an exception is thrown unless you actually throw a fault exception
3. This lab was one of the few that was actually problem free