WCF: Per-Call and Per-Session services...need convincing that Per-Call is worthwhile_问答_开发者

We are currently doing a review of our WCF service design and one thing that is bothering me is the decision between Per-Call and Per-Session services. I believe I understand the concept behind both, but I am not really seeing the advantage of Per-Call services. I understand that the motivation for using Per-Call services is that a WCF service only holds a server object for the life of a call thereby restricting the time that an expensive resource is held by the service instance, but to me its much simpler to use the more OO-like Per-Session model where your proxy object instance always corrisponds to the same server object instance and just handle an开发者_StackOverflow社区y expensive resources manually.

For example, say I have a CRUD Service with Add, Update, Delete, Select methods on it. This could be done as a Per-Call service with database connection (the "expensive resource") instanciated in the server object constructor. Alternately it could be a Per-Session service with a database connection instanciated and closed within each CRUD method exposed.

To me it is no different resource wise and it makes the programming model simpler as the client can be assured that they always have the same server object for their proxies: any in-expensive state that there may be between calls is maintained and no extra parameters are needed on methods to identify what state data must be retrieved by the service when it is instanciating a new server object again (as in the case of Per-Call). Its just like using classes and objects, where the same resource management issues apply, but we dont create new object instances for each method call we have on an object!

So what am I missing with the Per-Call model?

Thanks

There is no right or wrong in terms of PerCall or PerSession just different strengths and weaknesses. You seem to be approaching from an Object Oriented point of view where PerSession is a natural fit. A typical SOA approach would be a PerCall approach.

All things being equal, the trade-off is performance vs. scalability. PerSession should perform better because the object does not have to be instantiated on subsequent requests. PerCall should scale better because the only objects that are instantiated on the server are doing actual work. It's not just "expensive" resources, it's all of the sessions that are open on the server. e.g. in a PerSession situation you may have 1000 objects instantiated on the server but only 100 are actually in call at any moment. However, in a PerCall situation, there will only be 100 objects instantiated for 100 calls. Instantiated PerSession objects could be a waste of resources and may impact the ability to serve requests under load.

If my service was exposed publicly, I would also prefer not to trust my object lifetimes to the whims of the service consumers; I would worry about the potential for my service to be taken down by either malicious or buggy code.

Another potential benefit of the PerCall approach is system availability. Going back to the previous example, if a PerSession server were to crash then all 1000 clients who have a session on that server would lose their session and be unable to complete their work. In the PerCall situation the only errors that would occur would be to the 100 actual requests that were in progress (assuming fast failover). The other 900 clients could be routed to another server on their next call. This could be important for SLAs.

In short the answer will be stateless and scalability.

Per session works well if you know the environment of how the services will be consumed and yes you can share resources, which make the service stateful. When you need to introduced fail safe server, load balancing and routing the service calls, session service will have issue as the call do not always resolved to the same service object. Also if the service is consumed by client that the workflow is not fixed, how do you know when you release the service object for that session? most time you rely on lease timing out but in heavy load environment, this creates problem itself too of creating object in memory and just idling.

In term of design, it is also good practice to make service call independent of each other. So you dont rely on previous service call to setup the state of the object.