Instance management is set of techniques used by WCF to bind a set of messages to a service instance.Instance management is necessary because applications differ in their needs for scalability, performance, throughput, transactions. InstanceContextMode is a property which is available in the System.ServiceModel. InstanceContextMode property is mainly used in the ServiceBehaviour attribute in order to mention what kind of state maintenance your WCF application should provide. There is an enumerator available in the Sytem.ServiceModel library named as InstanceContextMode and it can be used in order to set the property InstanceContextMode.
Per-Call:
Per-call services are the WCF default instantiation mode. When the service type is configured for per-call activation, a service instance, a CLR object, exists only while a client call is in progress. Every client request gets a new dedicated service instance. The benefit with this approach is that the service instance will be caught by client only upto it is being used. So it is possible to dispose service object and expensive resources long before client disposes of the proxy. In order to support per call mode we need to design the service and its contract to support it. Maintaining a state is always a problem with per call mode, because every call creates a new instance of service. So if we want to maintain the session in per call mode also, then on each call we need to fetch the values from som storage( file system, Database) and at end of the call save the values back. But still all the states are not possible to save, For example state containing database connection. Object must reaquire the connection. Per-call activation mode works best when the amount of work to be done in each method call is small and there are no more activities to complete in the background once a method returns. For this reason, you should not spin off background threads or dispatch asynchronous calls back into the instance because the object will be discarded once the method returns. Per-call services clearly offer a trade-off in performance (the overhead of reconstructing the instance state on each method call) with scalability (holding onto the state and the resources it ties in). To use this mode we can explicit add this attribute on service definition.In pre call mode this attribute is optional.
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)]
We can use basicHTTPBinding with it.
Per-Session:
Windows Communication Foundation can maintain a private session between a client and a particular service instance. When the client creates a new proxy to a service configured as session-aware, the client gets a new dedicated service instance that is independent of all other instances of the same service. That instance will remain in service usually until the client no longer needs it. Each private session uniquely binds a proxy to a particular service instance. Note that the client session has one service instance per proxy. If the client creates another proxy to the same or a different endpoint, that second proxy will be associated with a new instance and session. Because the service instance remains in memory throughout the session, it can maintain state in memory. A service configured for private sessions cannot support large number of clients due to the cost associated with each such dedicated service instance.To support sessions, you need to set Session to true at the contract level:
[ServiceContract(Session = true)]
interface IMyContract {...}
Set the InstanceContextMode property of the ServiceBehavior attribute to InstanceContextMode.PerSession to make teh service to be in per session mode.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
class MyService : IMyContract {...}
The session will end once the client closes the proxy or the client is idle for some time(timeout( default is 10 mins)).
Any binding but basichttpbinding will work for it.
Single instance:
When a service is configured as a singleton, all clients get connected to the same single instance independently of each other, regardless of which endpoint of the service they connect to. The singleton service lives forever, and is only disposed of once the host shuts down. The singleton is created exactly once when the host is created. If we are using default constructor, first client will always face time delay in initialization, So to avoid it WCF allows you to create the singleton instance directly using normal CLR instantiation beforehand, initialize the instance, and then open the host with that instance in mind as the singleton service. In singleton as lot many clients are using same service instance so synchronization of methods is always a critical step. We can specify singleton mode by this attribute on service class:
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
Any binding but basichttpbinding will work for it.
No comments:
Post a Comment