En informática, la componibilidad de servicios es un principio de diseño, aplicado dentro del paradigma de diseño de orientación a servicios , que fomenta el diseño de servicios que se pueden reutilizar en múltiples soluciones que a su vez se componen de 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]
Propósito
El concepto de desarrollar software a partir de componentes existentes de forma independiente fomenta el concepto de composición. Este es el concepto subyacente dentro de la orientación a objetos donde el producto final se compone de varios objetos interconectados que tienen la capacidad de convertirse en parte de múltiples soluciones de software, sin importar cuán compleja sea la solución. El mismo concepto de composición se hereda de la orientación al servicio, mediante el cual un proceso empresarial se automatiza combinando varios servicios. Sin embargo, dentro de la orientación al servicio, existe un enfoque aún mayor en la construcción de servicios que se pueden componer y recomponer dentro de múltiples soluciones para brindar la agilidad prometida por la SOA. Como resultado de este énfasis, se requieren algunas pautas para desarrollar servicios que se puedan agregar de manera efectiva en múltiples soluciones.
El principio de componibilidad del servicio proporciona consideraciones de diseño que ayudan a diseñar servicios componibles con miras a fomentar la reutilización del servicio tanto como sea posible. Las pautas proporcionadas por este principio preparan el servicio para que esté listo para participar en las composiciones del servicio sin requerir más cambios de diseño.
Solicitud
La aplicación del principio de componibilidad del servicio requiere diseñar servicios de modo que puedan utilizarse en una composición de servicios, ya sea como un servicio que controla otros servicios, es decir, un servicio de controlador, o como un servicio que proporciona funcionalidad a otros servicios en la composición sin componer más otros servicios, es decir, un miembro de composición. [2]
Para que el servicio proporcione esta funcionalidad dual, el contrato de servicio [3] debe diseñarse de manera que presente una funcionalidad basada en niveles variables de datos de entrada y salida. En caso de que se requiera participar como miembro de la composición, normalmente los parámetros de entrada al servicio serían 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 muy reutilizado debe ser lo más apátrida posible ( principio de apatridia del servicio ) para que pueda proporcionar un rendimiento óptimo cuando se componga dentro de varias composiciones de servicios.
La efectividad de este principio depende de la medida 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 composición más simple al evitar la necesidad de realizar la transformación 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ía ninguna forma de acoplamiento negativo [5] con el otro servicio de la composición. La aplicación de la autonomía del servicio y los principios de apatridia del servicio aumentan la confiabilidad y disponibilidad del servicio para que pueda reutilizarse en múltiples composiciones de servicio con mayor confianza.
Consideraciones
Para que el servicio sea un controlador de servicio eficiente y un miembro del servicio, la arquitectura de tecnología subyacente debe proporcionar un entorno de tiempo de ejecución que sea escalable y pueda soportar la apatridia que requiere el servicio. De manera similar, a medida que las composiciones de servicios aumentan de tamaño, el almacenamiento y la recuperación de los datos de contexto, relacionados con la interacción en tiempo de ejecución de los servicios, pueden necesitar ser delegados al entorno de tiempo de ejecución en lugar de los servicios que administran estos datos de contexto para hacer que la composición del servicio sea 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 en gran medida. Esto requiere un análisis cuidadoso durante el diseño de las composiciones del servicio y considerar servicios alternativos de reserva para la funcionalidad crítica. Por otro lado, puede resultar difícil desarrollar un servicio que ahora se convierte en 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 proporcionando compatibilidad con versiones anteriores.
Algunos de los factores que determinan el potencial de componibilidad de un servicio incluyen: [7]
- Capacidad para proporcionar funcionalidad a diferentes niveles dentro de un proceso empresarial.
- Patrón de intercambio de mensajes
- Si el servicio admite transacciones y funciones de reversión / compensación.
- Soporte para manejo de excepciones.
- La disponibilidad de metadatos sobre las capacidades y el comportamiento del servicio.
Referencias
- ^ "Composición del servicio" . Archivado desde el original el 11 de marzo de 2010 . Consultado el 4 de marzo de 2010 .
- ^ a b Michael Poulin. Evolución de los principios de orientación al servicio: apatridia en el servicio, parte 7 [en línea]. Fecha de acceso: 21 de abril de 2010.
- ^ "Contrato de servicio" . Archivado desde el original el 1 de mayo de 2012 . Consultado el 4 de marzo de 2010 .
- ^ IBM Red Books Power Systems y 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 vencimiento de contratos SOA [en línea]. Fecha de acceso: 21 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.
- Dino Esposito. The HTML Message Pattern [Online]. Fecha de acceso: 21 de abril de 2010.
- Principios de orientación al servicio
- Anne Thomas Manes. The SOA Manifesto [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: direcciones de investigación de vanguardia y futuras. Journal of Network and Computer Applications [en línea] 45 (octubre de 2014) págs. 134-150. Fecha de acceso: 16 de junio de 2015.