Articulo de referencia

Principio de apatridia del servicio

La ausencia de estado en 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 ...

La ausencia de estado en 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 resulta en una reducción de los recursos consumidos por un servicio, ya que la gestión real de los datos de estado se delega a un componente externo o a una extensión arquitectónica. Al reducir el consumo de recursos, el servicio puede manejar más solicitudes de manera confiable. [ 2 ]

Objetivo

La interacción entre dos programas de software implica el seguimiento de los datos específicos de la interacción, ya que cada interacción posterior puede depender del resultado de la anterior. Esto cobra mayor importancia en arquitecturas distribuidas, donde el cliente y el servidor no se encuentran 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 cual no representaba un problema, ya que cada cliente residía en un ordenador individual. [ 3 ] Sin embargo, en arquitecturas de n niveles , la responsabilidad de la gestión del estado pasó del cliente a la aplicación o al servidor web . Esto generó la necesidad de extensiones de middleware para la gestión del estado, de modo que el servidor pudiera manejar múltiples solicitudes concurrentes de clientes, delegando los datos de estado específicos de la actividad a dichas extensiones; por ejemplo, almacenando los datos de sesión en una base de datos en aplicaciones ASP.NET . Esto ayuda a liberar recursos de memoria, lo que permite aumentar la capacidad de respuesta del servidor y la capacidad de atender más solicitudes de clientes.

En una composición de servicios, un servicio puede necesitar almacenar datos específicos de la actividad en memoria mientras espera a que otro servicio complete su procesamiento. Por consiguiente, en el caso de la orientación a servicios, una gestión eficiente de los datos relacionados con la actividad del servicio cobra mayor importancia, ya que esta orientación pone un gran énfasis en la reutilización de servicios. El servicio no solo debe gestionar los datos de estado, que se generan como resultado de la interacción con un programa consumidor, en el contexto de un proceso de negocio específico , sino también en relación con las interacciones con otros tipos de programas consumidores que forman parte de múltiples procesos de negocio. A medida que aumenta la reutilización, también aumenta la sobrecarga de la gestión de datos de estado. El principio de ausencia de estado del servicio proporciona directrices para que el servicio sea sin estado, transfiriendo la sobrecarga de la gestión de estado de los servicios a algún otro componente arquitectónico externo. Esto contribuye a la escalabilidad general de la solución orientada a servicios.

Solicitud

La correcta aplicación del principio de ausencia de estado en los servicios requiere comprender los distintos tipos de información estatal que deben gestionarse.

Datos de contexto

Dentro de una composición de servicios, es posible que se requiera que el servicio realice un seguimiento de los datos específicos de la ejecución de una actividad de servicio en 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 dichas reglas.

Datos empresariales

Se trata de datos relacionados con el proceso empresarial real, ejecutado por la actividad de servicio actual, por ejemplo, registros de clientes, etc. En algunas ocasiones, este tipo de datos puede necesitar almacenarse temporalmente, especialmente si actúa como entrada para la siguiente etapa dentro de la actividad de servicio.

Datos de sesión

Esto se relaciona con la información de conexión entre los servicios; por ejemplo, cuando los programas y servicios para el consumidor se comunican entre sí, puede ser necesario algún tipo de correlación para enviar la solicitud subsiguiente solo a la instancia particular del servicio, ya que solo esa instancia conoce la interacción previa con el servicio.

Apatridia y tipos de servicios

El principio de ausencia de estado del servicio podría aplicarse en distintos grados en relación con el tipo de lógica de solución que engloba el servicio.

Servicios de tareas

Los servicios de tareas contienen lógica de solución específica para un proceso de negocio concreto, por lo que 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, cuyo tamaño es directamente proporcional al tamaño de la composición del servicio que administra el servicio de tareas. En consecuencia, diseñar estos servicios con opciones de aplazamiento de estado reduce su consumo de memoria y los hace más receptivos.

Servicios públicos

Este tipo de servicios pueden necesitar ser con estado para proporcionar ausencia de estado 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 envoltorio para un sistema heredado , necesita ser moderadamente sin estado para que pueda atender múltiples solicitudes concurrentes.

Servicios de la entidad

Al ser independientes de cualquier proceso de negocio específico, estos servicios se consideran los más reutilizables. Otro factor importante es que procesan datos relacionados con entidades comerciales y, por lo tanto, requieren un mayor grado de independencia del estado para no verse obligados a gestionar datos empresariales que podrían necesitar conservar para proporcionar la funcionalidad requerida.

La ausencia de estado podría lograrse 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 ]

Consideraciones

No siempre es posible ofrecer una opción de aplazamiento de estado específica para cada servicio, ya que esto requiere una inversión adicional . Por otro lado, utilizar una opción de aplazamiento de estado compartida puede generar una dependencia entre los servicios, lo que podría obstaculizar su evolución.

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 resultar computacionalmente intensivas, puesto que primero es necesario convertir los datos 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 tiempo adicionales, ya que el servicio debe contener lógica que interactúe con las extensiones de aplazamiento de estado. Esto, a su vez, requeriría código y pruebas adicionales.

Referencias

  1. Wojciech Cellary, Sergiusz Strykowski Gobierno electrónico basado en computación en la nube y arquitectura orientada a servicios [En línea]. Fecha de acceso: 19 de abril de 2010.
  2. IBM Red Books Power Systems and SOA Synergy [En línea]. Fecha de acceso: 21 de abril de 2010.
  3. "Arquitectura de cliente ligero frente a cliente pesado" . RichHewlett.com. 2 de diciembre de 2008. Consultado el 10 de marzo de 2019 .
  4. "Patrón de diseño de servicios con estado" . Archivado del original el 1 de marzo de 2010. Consultado el 28 de febrero de 2010 .
  5. Reddy. et al. Evaluación de activos heredados en el contexto de la migración a SOA [En línea].pp 58.Fecha de acceso: 19 de abril de 2010.

Lecturas adicionales

  • Michael Poulin. Evolución de los principios de la orientación al servicio: la ausencia de dependencia del servicio, parte 6 [En línea]. Fecha de acceso: 19 de abril de 2010.
  • Mauro et al. Integración de dispositivos orientada a servicios: un análisis de patrones de diseño SOA. [En línea], págs.  1-10, 43.ª Conferencia Internacional de Hawái sobre Ciencias de Sistemas, 2010. Fecha de acceso: 8 de abril de 2010.