Question

I would create a WCF service with some methods. One of these methods (that is, the Connect method) should be the first to be called in order to use the service: in other words, before you can use all other methods of service, must be called the Connect method. For this reason, I defined it with IsInitiating property set to true, and I have defined the other methods with this property set to false.

In addition, the node offering the service must be able to refuse the connection request from another node (for example, if other nodes are already using the service): is there a way to prevent the use of the service?

Thanks a lot!

Answer 1

Well, sure.

First understand that by default, WCF services are an “instance-per-request” construct; The HttpApplications that IIS maintains in the app pool will “new up” a copy of your service contract class, make the call pertaining to the request, then the object will go out of scope and be destroyed. You can override this by stating that your service should run in “instance-per-session” mode:

[ServiceContract(SessionMode = SessionMode.Required)]
public interface IMyServiceContract
{
   ...
}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class MyServiceImplementation: IMyServiceContract
{
   ...
}

Now, when your service is called, a “session” is established between client and server, and a single copy of your class will be created and remain in memory for the life of that session (unless the app pool is refreshed, which can happen automatically or by a manual action within IIS). This is the first step.

Now, you can do one of two things:

• Simply check in any method besides Connect() whether Connect() has been called on this instance since its creation. If not, throw out.

• Have the Connect() method return some instance-scoped token or GUID that the client must then pass to all other method calls. If the GUID the caller provides doesn’t match the one kept in instance memory, then throw out of the method.

Understand that sessions can time out between requests. If this happens, your current instance will leave scope and be destroyed, and a new instance will be created to handle subsequent requests. I would thus opt for the second option even though the system can identify instances based on their session; the GUID ensures that both the client AND service instance have not changed since the last call.