En informática, la componibilidad de servicios es un principio de diseño, aplicado dentro del paradigma de diseño orientado a servicios , que fomenta el diseño de servicios que pueden reutilizarse en múltiples soluciones que, a su vez, están compuestas por servicios compuestos. La capacidad de recomponer el servicio es idealmente independiente del tamaño y la complejidad de la composición del servicio. [ 1 ]
Este principio es directamente responsable de la agilidad prometida por SOA, ya que promueve la composición de nuevas soluciones mediante la reutilización de servicios existentes. [ 2 ]
Objetivo
El concepto de desarrollar software a partir de componentes existentes de forma independiente fomenta la composición. Este es el concepto fundamental de la orientación a objetos, donde el producto final se compone de varios objetos interconectados que pueden integrarse en múltiples soluciones de software, independientemente de su complejidad. La orientación a servicios hereda este mismo concepto de composición, mediante el cual un proceso de negocio se automatiza combinando múltiples servicios. Sin embargo, en la orientación a servicios se hace aún mayor hincapié en la creación de servicios que puedan componerse y recomponerse en múltiples soluciones para proporcionar la agilidad prometida por la SOA. Como resultado de este énfasis, se requieren ciertas directrices para desarrollar servicios que puedan agregarse eficazmente en múltiples soluciones.
El principio de componibilidad de servicios proporciona consideraciones de diseño que facilitan la creación de servicios componibles, con el objetivo de fomentar al máximo su reutilización. Las directrices que ofrece este principio preparan el servicio para que pueda participar en composiciones de servicios sin necesidad de realizar modificaciones adicionales en su diseño.
Solicitud
La aplicación del principio de componibilidad de servicios requiere diseñar servicios de manera que puedan utilizarse en una composición de servicios, ya sea como un servicio que controla otros servicios, es decir, un servicio controlador, o como un servicio que proporciona funcionalidad a otros servicios en la composición sin componer otros servicios adicionales, es decir, un miembro de la composición. [ 2 ]
Para que el servicio proporcione esta doble funcionalidad, el contrato de servicio [ 3 ] debe diseñarse de manera que presente funcionalidad basada en diferentes niveles de datos de entrada y salida. En caso de que se requiera que participe como miembro de la composición, los parámetros de entrada al servicio serán generalmente más precisos en comparación con la situación en la que se requiere que participe como controlador de la composición. Un servicio altamente reutilizado debe ser lo más independiente del estado posible ( principio de independencia del estado del servicio ) para que pueda proporcionar un rendimiento óptimo cuando se compone dentro de múltiples composiciones de servicios. La efectividad de este principio depende del grado en que el resto de los principios de diseño se hayan aplicado con éxito. La aplicación del principio de contrato de servicio estandarizado hace que los servicios sean interoperables con otros y ayuda a mantener el diseño de la composición más simple al evitar la necesidad de realizar transformaciones del modelo de datos en tiempo de ejecución . [ 4 ] Al aplicar el principio de acoplamiento flexible del servicio , un servicio podría recomponerse con la confianza de que no creará ningún tipo de acoplamiento negativo [ 5 ] con el otro servicio en la composición. La aplicación de los principios de autonomía y ausencia de estado del servicio aumenta la fiabilidad y la disponibilidad del mismo, de modo que puede reutilizarse en múltiples composiciones de servicio con mayor confianza.
Consideraciones
Para que el servicio funcione como un controlador eficiente y, a la vez, como un miembro del servicio, la arquitectura tecnológica subyacente debe proporcionar un entorno de ejecución escalable que admita la ausencia de estado que requiere el servicio. Del mismo modo, a medida que aumenta el tamaño de las composiciones de servicios, el almacenamiento y la recuperación de los datos de contexto, relacionados con la interacción de los servicios en tiempo de ejecución, podrían delegarse al entorno de ejecución en lugar de que los servicios gestionen estos datos de contexto, para así lograr una composición de servicios más eficiente.
A medida que se crean más y más composiciones de servicios, existe la tendencia a depender de un servicio que se reutiliza con frecuencia. Esto requiere un análisis cuidadoso durante el diseño de las composiciones de servicios y la consideración de servicios de reserva alternativos para la funcionalidad crítica. Por otro lado, puede resultar difícil evolucionar un servicio que ahora forma parte de múltiples composiciones de servicios. Esto podría abordarse mediante la aplicación del patrón de diseño de Contratos Concurrentes, que aboga por mantener múltiples contratos concurrentes para un servicio. [ 6 ] De esta manera, el servicio puede evolucionar manteniendo la compatibilidad con versiones anteriores .
Algunos de los factores que determinan el potencial de composición de un servicio incluyen: [ 7 ]
- Capacidad para proporcionar funcionalidad en diferentes niveles dentro de un proceso de negocio.
- Patrón de intercambio de mensajes
- Si el servicio admite transacciones y funciones de reversión/compensación.
- Soporte para el manejo de excepciones.
- La disponibilidad de metadatos sobre las capacidades y el comportamiento del servicio.
Véase también
Referencias
- ↑ "Composición del servicio" . Archivado del original el 11 de marzo de 2010. Consultado el 4 de marzo de 2010 .
- 1 2 Michael Poulin. Evolución de los principios de la orientación al servicio: Servicio sin Estado, parte 7 [En línea]. Fecha de acceso: 21 de abril de 2010.
- ↑ "Contrato de servicio" . Archivado del original el 1 de mayo de 2012. Consultado el 4 de marzo de 2010 .
- ↑ IBM Red Books Power Systems and SOA Synergy [En línea]. Fecha de acceso: 21 de abril de 2010.
- ↑ tipos de acoplamiento
- ↑ "Patrones SOA" . Patrones SOA .
- ↑ 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: 21 de abril de 2010.
- Kjell-Sverre Jerijærvi. Modelo de madurez de contratos SOA [en línea]. Fecha de consulta: 21 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.
- Dino Esposito. El patrón de mensaje HTML [En línea]. Fecha de acceso: 21 de abril de 2010.
- Principios de orientación al servicio
- Anne Thomas Manes. El Manifiesto de la SOA [En línea]. Fecha de acceso: 21 de abril de 2010.
- 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: 22 de abril de 2010.
- Sun, L., Dong, H., Hussain, FK, Hussain, OK, Chang, E.: Selección de servicios en la nube: estado del arte y direcciones futuras de investigación. Journal of Network and Computer Applications [En línea] 45 (octubre de 2014) pp. 134-150. Fecha de acceso: 16 de junio de 2015.
- Orientado a servicios (informática empresarial)