La abstracción de servicios es un principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios para que la información publicada en un contrato de servicio se limite a lo necesario para utilizar el servicio de manera efectiva [ 1 ]. El contrato de servicio no debe contener información superflua que no sea necesaria para su invocación. Además, la información debe limitarse al contrato de servicio (contrato técnico y acuerdo de nivel de servicio ); ningún otro documento o medio debe estar disponible para los consumidores del servicio que contenga información adicional relacionada con el servicio.
Objetivo
Un contrato de servicio que detalla su funcionamiento (por ejemplo, la lógica, la implementación y la tecnología empleada) puede utilizarse de una manera específica, proporcionando al consumidor un mayor conocimiento sobre su funcionamiento. En el contexto de la orientación a servicios, un mayor conocimiento no siempre es mejor. Existe la posibilidad de que la información adicional dificulte la reutilización del servicio, ya que el diseñador podría optimizar su diseño basándose en este conocimiento. Sin embargo, esto afectaría la evolución del contrato, pues el consumidor quedaría indirectamente vinculado a la implementación del servicio, la cual podría necesitar ser reemplazada en el futuro. Esto incrementa el acoplamiento entre el consumidor y el contrato , un tipo de acoplamiento positivo. No obstante, una dependencia excesiva puede repercutir negativamente en la evolución tanto del proveedor como del consumidor del servicio.
La ocultación de información sigue siendo uno de los principios clave del paradigma orientado a objetos, que promueve la abstracción del funcionamiento interno de un programa de software . Un ejemplo clásico sería el uso de clases abstractas para ocultar la lógica real de los métodos. El mismo concepto se aplica mediante el principio de abstracción de servicios para ocultar los detalles innecesarios sobre el funcionamiento del servicio, con el fin de facilitar su evolución. [ 2 ]
Solicitud
La aplicación de este principio de diseño requiere examinar cuatro tipos diferentes de abstracciones que podrían aplicarse a un servicio.
Abstracción funcional
Esta forma de abstracción depende de la cantidad de lógica del servicio que se expone como funcionalidades del mismo. Un ejemplo sería una clase cuyos métodos son privados y otros públicos. Una clase solo expondría como públicos aquellos métodos que considere importantes para sus objetos; los métodos auxiliares que no sean relevantes para los objetos se mantendrían ocultos.
Un contrato de servicios que no se haya sometido a este principio podría denominarse «contrato detallado», ya que revela gran parte de las reglas de negocio y la lógica de validación. Una vez aplicado este principio en la medida justa, el contrato podría denominarse «contrato conciso». La aplicación continua de este principio de diseño daría como resultado un «contrato optimizado» que maximizaría el potencial de reutilización del servicio.
abstracción de información tecnológica
Cualquier información sobre la tecnología subyacente utilizada en el servicio resultaría en una abstracción de información de baja tecnología, ya que el contrato de servicio especifica a los consumidores cómo están diseñadas la lógica del servicio y su implementación. Esta información adicional podría llevar a que los consumidores del servicio se diseñen de forma que se centren específicamente en esa implementación en particular, lo que generaría un acoplamiento entre el consumidor y la implementación .
Abstracción lógica
Es necesario abstraer los detalles programáticos de la lógica del servicio [ 3 ], ya que el conocimiento sobre cómo el servicio realiza su funcionalidad puede llevar a que los consumidores del servicio incorporen esta información y, por consiguiente, se diseñen bajo estas suposiciones. Esto puede obstaculizar seriamente los esfuerzos de refactorización de la lógica del servicio y puede considerarse un antipatrón para la aplicación del patrón de diseño de refactorización de servicios .
abstracción de calidad
La abstracción de calidad se refiere a los detalles proporcionados en el acuerdo de nivel de servicio (SLA) que acompaña al servicio. Es importante centrarse únicamente en la información que realmente ayude a determinar la fiabilidad y disponibilidad del servicio; no se debe incluir información que revele detalles innecesarios, como por ejemplo, detalles sobre cómo se integra el servicio en el proceso empresarial general o qué otros servicios utiliza para cumplir su función.
El nivel de control de acceso aplicado a un servicio determina la cantidad de abstracciones tecnológicas, lógicas y de calidad de servicio implementadas. El acceso abierto permite el acceso libre a cualquier persona interesada en conocer las especificaciones de diseño del servicio. En el acceso controlado, solo las personas autorizadas tienen acceso, y una política de "no acceso" deniega por completo el acceso a los documentos de diseño.
Consideraciones
Si bien ocultar información se considera una práctica saludable, un exceso de ocultamiento puede resultar contraproducente, ya que limita la reutilización del servicio. Esto también puede generar servicios redundantes, dado que los diseñadores no disponen de suficiente información sobre sus capacidades. Por ello, cada contrato de servicio debe diseñarse de forma concisa pero completa, de manera que sus capacidades puedan descubrirse e interpretarse eficazmente, conforme al principio de descubrimiento de servicios .
El tipo de información expuesta en el contrato de servicio también puede generar problemas de seguridad. Por ejemplo, un servicio que propaga detalles sobre la base de datos en uso como resultado de un error interno puede ser víctima de un ataque en el que el atacante utiliza los detalles del error reportado e intenta conectarse a la base de datos. Esto podría abordarse mediante la aplicación de los patrones de diseño de filtrado de mensajes [ 4 ] y protección contra excepciones [ 5 ] .
Referencias
- ↑ "Servicio" . Archivado del original el 1 de mayo de 2012. Consultado el 8 de abril de 2010 .
- ↑ Dennis Wisnosky. Principios y patrones en el Departamento de Defensa de los Estados Unidos [En línea]. Fecha de acceso: 13 de abril de 2010.
- ↑ Kjell-Sverre Jerijærvi. Modelo de madurez de contratos SOA [en línea]. Fecha de consulta: 13 de abril de 2010.
- ↑ Filtrado de mensajes
- ↑ Protección contra excepciones
Lecturas adicionales
- 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.
- Thomas Erl . Orientación a servicios y orientación a objetos, parte II: una comparación de principios de diseño [en línea]. Fecha de acceso: 13 de abril de 2010.
- Tost. et al. Directrices para el uso de tecnologías de contratos de servicios web [En línea]. Fecha de acceso: 13 de abril de 2010.
- Pekka Alho. Aplicación de nuevas tecnologías de diseño e integración de software de automatización en la enseñanza [En línea]. Fecha de acceso: 13 de abril de 2010.
Enlaces externos
- Conceptos de SOA
- Glosario de términos de SOA
- Orientado a servicios (informática empresarial)