WCF:Per-Call 和 Per-Session 服务……需要说服 Per-Call 是值得的 [英] WCF: Per-Call and Per-Session services...need convincing that Per-Call is worthwhile

问题描述

我们目前正在审查我们的 WCF 服务设计，让我困扰的一件事是在 Per-Call 和 Per-Session 服务之间做出决定.我相信我了解两者背后的概念，但我并没有真正看到按呼叫服务的优势.我知道使用 Per-Call 服务的动机是 WCF 服务只在调用的生命周期内持有一个服务器对象，从而限制了服务实例持有昂贵资源的时间，但对我来说使用起来要简单得多更像 OO 的 Per-Session 模型，其中您的代理对象实例始终对应于相同的服务器对象实例，只需手动处理任何昂贵的资源.

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 any expensive resources manually.

例如，假设我有一个带有添加、更新、删除、选择方法的 CRUD 服务.这可以作为具有在服务器对象构造函数中实例化的数据库连接(昂贵的资源")的 Per-Call 服务来完成.或者，它可以是 Per-Session 服务，在每个公开的 CRUD 方法中实例化和关闭数据库连接.

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.

对我来说，它在资源方面没有什么不同，它使编程模型更简单，因为客户端可以确保它们始终具有相同的代理服务器对象:调用之间可能存在的任何廉价状态都得到维护和当服务再次实例化新的服务器对象时(如 Per-Call 的情况)，在方法上不需要额外的参数来标识服务必须检索哪些状态数据.就像使用类和对象一样，存在相同的资源管理问题，但我们不会为对象上的每个方法调用创建新的对象实例！

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!

那么我在 Per-Call 模型中缺少什么?

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

谢谢

推荐答案

PerCall 或 PerSession 没有对与错，只是优点和缺点不同.您似乎是从面向对象的角度出发的，其中 PerSession 是一个自然的选择.典型的 SOA 方法是 PerCall 方法.

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.

在所有条件相同的情况下，权衡是性能与可扩展性.PerSession 应该表现得更好，因为不必在后续请求中实例化对象.PerCall 应该可以更好地扩展，因为在服务器上实例化的唯一对象正在执行实际工作.这不仅仅是昂贵"的资源，而是在服务器上打开的所有会话.例如在 PerSession 情况下，您可能在服务器上实例化了 1000 个对象，但实际上只有 100 个在任何时候都在调用中.但是，在 PerCall 情况下，对于 100 次调用只会实例化 100 个对象.实例化的 PerSession 对象可能会浪费资源，并可能影响在负载下处理请求的能力.

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.

PerCall 方法的另一个潜在好处是系统可用性.回到前面的示例，如果 PerSession 服务器崩溃，那么在该服务器上拥有会话的所有 1000 个客户端都将丢失其会话并且无法完成其工作.在 PerCall 情况下，唯一会发生的错误是正在进行的 100 个实际请求(假设快速故障转移).其他 900 个客户端可以在下一次调用时路由到另一台服务器.这对于 SLA 可能很重要.

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.

这篇关于WCF:Per-Call 和 Per-Session 服务……需要说服 Per-Call 是值得的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！