WCF: servicios por llamada y por sesión ... necesitan convencer que Per-Call vale la pena

Question

Actualmente estamos haciendo una revisión de nuestro diseño de servicio WCF y una cosa que me molesta es la decisión entre Per-Call y Servicios por sesión. Creo que entiendo el concepto detrás de ambos, pero realmente no veo la ventaja de los servicios Per-Call. Entiendo que la motivación para usar los servicios Per-Call es que un servicio WCF solo contiene un objeto de servidor durante la vida de una llamada, lo que limita el tiempo que la instancia de servicio tiene un recurso costoso, pero para mí es mucho más fácil de usar el modelo más parecido a OO por sesión donde su instancia de objeto proxy siempre corresponde a la misma instancia de objeto de servidor y simplemente maneja los recursos caros de forma manual.

Por ejemplo, supongo que tengo un servicio CRUD con Add, Update, Delete, Select methods en él. Esto podría hacerse como un servicio Per-Call con conexión de base de datos (el "recurso costoso") instanciado en el constructor de objetos del servidor. Alternativamente, podría ser un servicio por sesión con una conexión de base de datos instanciada y cerrada dentro de cada método CRUD expuesto.

Para mí no es un recurso diferente y simplifica el modelo de programación ya que el cliente puede estar seguro de que siempre tienen el mismo objeto de servidor para sus proxies: se mantiene cualquier estado costoso que pueda haber entre llamadas y no se necesitan parámetros adicionales en los métodos para identificar qué datos de estado debe recuperar el servicio cuando está instanciando un nuevo objeto de servidor nuevamente (como en el caso de Per-Call). Es como usar clases y objetos, donde se aplican los mismos problemas de administración de recursos, pero no creamos nuevas instancias de objetos para cada llamada de método que tenemos sobre un objeto.

Entonces, ¿qué me falta con el modelo Per-Call?

Gracias

Answer 1

No es correcto o incorrecto en términos de PerCall o PerSession simplemente diferentes fortalezas y debilidades. Parece que se está acercando desde un punto de vista orientado a objetos donde PerSession es un ajuste natural. Un enfoque SOA típico sería un enfoque PerCall.

En igualdad de condiciones, la compensación es el rendimiento frente a la escalabilidad. PerSession debería funcionar mejor porque no es necesario crear una instancia del objeto en solicitudes posteriores. PerCall debería escalar mejor porque los únicos objetos que se crean instancias en el servidor están haciendo un trabajo real. No se trata solo de recursos "caros", sino de todas las sesiones que están abiertas en el servidor. p.ej. en una situación de PerSesión, puede tener 1000 objetos instanciados en el servidor, pero solo 100 están realmente en llamada en cualquier momento. Sin embargo, en una situación PerCall, solo habrá 100 objetos instanciados para 100 llamadas. Los objetos PerSession instanciados podrían ser un desperdicio de recursos y pueden afectar la capacidad de atender solicitudes bajo carga.

Si mi servicio fue expuesto públicamente, también preferiría no confiar en la duración de mi objeto a los caprichos de los consumidores del servicio; Me preocuparía la posibilidad de que mi servicio sea eliminado por un código malicioso o defectuoso.

Otro beneficio potencial del enfoque PerCall es la disponibilidad del sistema. Volviendo al ejemplo anterior, si un servidor PerSession fallara, los 1000 clientes que tienen una sesión en ese servidor perderían su sesión y no podrían completar su trabajo. En la situación de PerCall, los únicos errores que se producirían serían las 100 solicitudes reales que estaban en progreso (suponiendo un failover rápido). Los otros 900 clientes podrían enrutarse a otro servidor en su próxima llamada. Esto podría ser importante para los SLA.

Answer 2

En resumen, la respuesta será sin estado y escalabilidad.

Por sesión funciona bien si conoce el entorno de cómo se consumirán los servicios y sí puede compartir recursos, lo que hace que el servicio sea completo. Cuando necesite introducir el servidor a prueba de errores, equilibrar la carga y enrutar las llamadas de servicio, el servicio de sesión tendrá problemas ya que la llamada no siempre se resuelve en el mismo objeto de servicio. Además, si el cliente consume el servicio de que el flujo de trabajo no es fijo, ¿cómo sabe cuándo libera el objeto de servicio para esa sesión? la mayoría de las veces usted confía en el tiempo de espera del arrendamiento, pero en un entorno de carga pesada, esto crea el mismo problema de creación de objetos en la memoria y simplemente al ralentí.

En términos de diseño, también es una buena práctica hacer una llamada de servicio independiente una de la otra. Por lo tanto, no confíe en la llamada de servicio anterior para configurar el estado del objeto.