La falta de estado de los servicios es un principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios , con el fin de diseñar servicios escalables separándolos de sus datos de estado siempre que sea posible. [1] Esto da como resultado una reducción de los recursos consumidos por un servicio, ya que la gestión de los datos de estado reales se delega a un componente externo o a una extensión arquitectónica. Al reducir el consumo de recursos, el servicio puede gestionar más solicitudes de manera confiable. [2]
La interacción de dos programas de software implica mantener un registro de los datos específicos de la interacción, ya que cada interacción posterior puede depender del resultado de la interacción anterior. Esto se vuelve más importante en arquitecturas distribuidas donde el cliente y el servidor no existen físicamente en la misma máquina. En arquitecturas de dos niveles , la responsabilidad de rastrear estos datos específicos de la interacción recaía en los clientes enriquecidos, lo que no era un problema ya que cada cliente solía residir en una computadora individual. [3] Sin embargo, dentro de las arquitecturas de n niveles , la responsabilidad de la administración del estado cambió del cliente a la aplicación o al servidor web . Esto introdujo la necesidad de algunas extensiones de administración del estado de middleware para que el servidor pudiera manejar múltiples solicitudes de cliente simultáneas al diferir los datos de estado específicos de la actividad real a dichas extensiones, por ejemplo, almacenando datos de sesión en una base de datos en aplicaciones ASP .NET . Esto ayuda a liberar los recursos de memoria a favor de aumentar la capacidad de respuesta del servidor y la capacidad de atender más solicitudes de cliente.
En una composición de servicio, un servicio puede necesitar almacenar datos específicos de la actividad en la memoria mientras espera que otro servicio complete su procesamiento. En consecuencia, en el caso de la orientación a servicios, una gestión eficiente de los datos relacionados con la actividad del servicio se vuelve más importante, ya que la orientación a servicios pone mucho énfasis en la reutilización del servicio. El servicio no solo necesita ocuparse de la gestión de los datos de estado, que se crean como resultado de la interacción con un programa de consumidor, en el contexto de un proceso empresarial particular, sino también en relación con las interacciones con otros tipos de programas de consumidor que forman parte de múltiples procesos empresariales. A medida que aumenta la reutilización, también lo hace la sobrecarga de la gestión de los datos de estado. El principio de apatridia del servicio proporciona directrices a favor de hacer que el servicio sea apatridia al trasladar la sobrecarga de gestión del estado de los servicios a algún otro componente arquitectónico externo. Esto ayuda aún más a la escalabilidad general de la solución orientada a servicios.
La correcta aplicación de la apatridia en el servicio requiere una comprensión de los distintos tipos de información de estado que deben gestionarse.
Dentro de una composición de servicio, puede requerirse que el servicio realice un seguimiento de datos específicos de la ejecución de una actividad de servicio particular, que generalmente está vinculada con la coordinación de mensajes, por ejemplo, flujos de trabajo , y las reglas asociadas que rigen cómo se deben interpretar las reglas.
Estos son los datos que se relacionan con el proceso comercial real, ejecutado por la actividad de servicio actual, por ejemplo, registros de clientes, etc. En algunas ocasiones, puede ser necesario almacenar temporalmente este tipo de datos, especialmente si actúan como entrada para la siguiente etapa dentro de la actividad de servicio.
Esto se relaciona con la información de conexión entre los servicios, por ejemplo, cuando los programas y servicios del consumidor se comunican entre sí, puede requerirse algún tipo de correlación para disparar la solicitud posterior solo a la instancia particular del servicio, ya que solo esa instancia conoce la interacción del servicio anterior.
El principio de apatridia del servicio podría aplicarse en distintos grados en relación con el tipo de lógica de solución incluida en el servicio.
Los servicios de tareas contienen una lógica de solución específica para un proceso empresarial en particular y, por lo tanto, su nivel de reutilización es bajo. Sin embargo, estos servicios contienen datos de contexto (reglas de flujo de trabajo) sobre la actividad del servicio, que es directamente proporcional al tamaño de la composición del servicio que administra el servicio de tareas. Como resultado, diseñar dichos servicios con opciones de aplazamiento de estado reduce su consumo de memoria y los hace más receptivos.
Es posible que estos tipos de servicios deban ser con estado para proporcionar apátrida para los servicios de tareas y entidades. [4] Por otro lado, un servicio de utilidad altamente reutilizable, por ejemplo, un servicio de utilidad que actúa como un contenedor para un sistema heredado , debe ser moderadamente apátrida para poder atender múltiples solicitudes simultáneas.
Al ser independientes de cualquier proceso empresarial específico, estos servicios se consideran los más reutilizables. Otro factor importante es que procesan datos relacionados con entidades empresariales y, como tal, requieren mayores niveles de apátrida para no tener que cargar con el seguimiento de los datos empresariales que pueden necesitar conservar para proporcionar la funcionalidad requerida.
La apátrida se puede lograr delegando la gestión del estado a alguna extensión arquitectónica compartida, por ejemplo, un producto de middleware que exista fuera del límite de implementación del servicio, o a un mecanismo dedicado que exista dentro del límite del servicio, por ejemplo, una base de datos dedicada. [5]
Puede que no siempre sea posible ofrecer una opción de aplazamiento estatal dedicada a cada servicio, ya que esto claramente requiere una inversión adicional . Por otro lado, el uso de una opción de aplazamiento estatal compartida puede crear una dependencia para el servicio, lo que puede obstaculizar la evolución del servicio.
El almacenamiento y la recuperación de información de estado pueden afectar inadvertidamente el tiempo de respuesta del servicio, ya que ambas tareas pueden requerir un uso intensivo de recursos computacionales, ya que primero los datos deben convertirse al formato nativo de la extensión de almacenamiento y viceversa cuando se trata de recuperar la misma información.
El diseño de servicios sin estado requiere un esfuerzo y un tiempo adicionales, ya que el servicio debe contener una lógica que interactúe con las extensiones de aplazamiento de estado. Esto, a su vez, requeriría código y pruebas adicionales.