La apatridia del servicio es un principio de diseño que se aplica dentro del paradigma de diseño de orientación al servicio , con el fin de diseñar servicios escalables separándolos de sus datos de estado siempre que sea posible. [1] Esto da como resultado la reducción de los recursos consumidos por un servicio, ya que la gestión de datos de estado real se delega a un componente externo oa una extensión de la arquitectura. Al reducir el consumo de recursos, el servicio puede manejar más solicitudes de manera confiable. [2]
Propósito
La interacción de dos programas de software implica realizar un seguimiento 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 las arquitecturas de dos niveles , la responsabilidad de rastrear estos datos específicos de 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 gestión estatal pasó del cliente a la aplicación o al servidor web . Esto introdujo la necesidad de algunas extensiones de administración de estado de middleware para que el servidor pudiera manejar múltiples solicitudes de clientes concurrentes al diferir los datos de estado específicos de la actividad real a tales extensiones, por ejemplo, almacenar 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 clientes.
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 al servicio, una gestión eficiente de los datos relacionados con la actividad del servicio se vuelve más importante ya que la orientación al servicio pone mucho énfasis en la reutilización del servicio. El servicio no solo debe ocuparse de la gestión de datos estatales, que se crean como resultado de la interacción con un programa de consumidor, en el contexto de un proceso comercial particular, sino también en relación con las interacciones con otros tipos de programas de consumidor que forman parte de múltiples procesos comerciales. A medida que aumenta la reutilización, también aumenta la sobrecarga de administrar los datos estatales. El principio Service Statelessness proporciona pautas a favor de convertir el servicio en apátrida al trasladar la sobrecarga de administración del estado de los servicios a algún otro componente arquitectónico externo. Esto ayuda aún más en la escalabilidad general de la solución orientada a servicios.
Solicitud
La aplicación correcta de la apatridia del servicio requiere una comprensión de los diversos tipos de información de estado que deben gestionarse.
Datos de contexto
Dentro de una composición de servicio, es posible que se requiera que el servicio realice un seguimiento de los datos que son específicos para 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 gobiernan cómo se deben cumplir las reglas. ser interpretado.
Datos comerciales
Estos son los datos que se relacionan con el proceso comercial real, ejecutados 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 una entrada para la siguiente etapa dentro de la actividad de servicio.
Datos de la sesión
Esto se relaciona con la información de conexión entre los servicios, por ejemplo, cuando los programas y servicios del consumidor se comunican de un lado a otro, es posible que se requiera 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 previa con el servicio.
Apatridia y tipos de servicio
El principio de ausencia de estado del servicio podría aplicarse en diferentes grados en relación con el tipo de lógica de solución incluida en el servicio.
Servicios de tareas
Los servicios de tareas contienen lógica de solución que es específica para un proceso de negocio 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, el diseño de dichos servicios con opciones de aplazamiento estatal reduce su huella de memoria y los hace más receptivos.
Servicios de utilidad
Es posible que este tipo de servicios deban tener estado para proporcionar apatridia 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 envoltorio para un sistema heredado , debe ser moderadamente sin estado para que pueda atender múltiples solicitudes concurrentes.
Servicios de entidad
Al ser independientes de cualquier proceso comercial específico, estos servicios se consideran los servicios más reutilizables. Otro factor importante es que procesan datos relacionados con entidades comerciales y, como tales, requieren niveles más altos de apatridia para no tener que hacer un seguimiento de los datos comerciales que pueden necesitar retener para proporcionar la funcionalidad requerida.
La apatridia podría lograrse delegando la gestión del estado a alguna extensión de arquitectura compartida, por ejemplo, un producto de software intermedio que existe fuera del límite de implementación del servicio o en un mecanismo dedicado que existe dentro del límite del servicio, por ejemplo, una base de datos dedicada. [5]
Consideraciones
Puede que no siempre sea posible proporcionar una opción de aplazamiento estatal dedicada para cada servicio, ya que esto claramente requiere una inversión adicional . Por otro lado, el uso de una opción de aplazamiento de estado compartido 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 resultar computacionalmente intensivas, ya que primero los datos deben convertirse al formato nativo de la extensión de almacenamiento y viceversa cuando se trata de recuperar los datos. misma información.
El diseño de servicios sin estado requiere esfuerzos y tiempo adicionales, ya que el servicio debe contener una lógica que interactúe con las extensiones de aplazamiento del estado. Esto, a su vez, requeriría código y pruebas adicionales.
Referencias
- ^ 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.
- ^ IBM Red Books Power Systems y SOA Synergy [en línea]. Fecha de acceso: 21 de abril de 2010.
- ^ "Cliente ligero vs Arquitectura de cliente grueso" . RichHewlett.com. 2 de diciembre de 2008 . Consultado el 10 de marzo de 2019 .
- ^ "Patrón de diseño de Stateful Services" . Archivado desde el original el 1 de marzo de 2010 . Consultado el 28 de febrero de 2010 .
- ^ 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.
Otras lecturas
- Michael Poulin. Evolución de los principios de Orientación al servicio: Apatridia en el servicio, parte 6 [En línea]. Fecha de acceso: 19 de abril de 2010.
- Mauro. et al. Integración de dispositivos orientada a servicios: análisis de patrones de diseño SOA. [En línea], págs. 1 a 10, 2010 43ª Conferencia Internacional de Hawai sobre Ciencias de Sistemas, 2010. Fecha de consulta: 8 de abril de 2010.