La abstracción del servicio es un principio de diseño que se aplica dentro del paradigma de diseño de orientación al servicio de modo que la información publicada en un contrato de servicio se limita a lo que se requiere para utilizar eficazmente el servicio [1] El contrato de servicio no debe contener ninguna información superflua que sea no es necesario para su invocación. Además, que la información debe limitarse al contrato de servicio (contrato técnico y el acuerdo de nivel de servicio ) únicamente, ningún otro documento o medio debe estar disponible para los consumidores del servicio que no sea el contrato de servicio que contiene información adicional relacionada con el servicio.
Propósito
Un contrato de servicio que contiene detalles sobre lo que encapsula (p. Ej., La lógica, la implementación y la tecnología utilizada para construir el servicio) puede terminar usándose de una manera particular al proporcionar al consumidor del servicio más conocimiento sobre el funcionamiento del servicio. En el caso de la orientación al servicio, un mayor conocimiento no es necesariamente mejor. Existe la posibilidad de que información adicional pueda impedir la reutilización del servicio, ya que el diseñador del consumidor del servicio puede simplificar su diseño basándose en este conocimiento. Sin embargo, hacerlo afectaría la evolución del contrato de servicio, ya que ahora el consumidor del servicio está indirectamente asociado a la implementación del servicio, que puede necesitar ser reemplazado en el futuro. Esto aumenta el tipo de acoplamiento de consumidor a contrato , que es un tipo de acoplamiento positivo. Sin embargo, tener demasiada dependencia puede afectar negativamente la evolución tanto del proveedor de servicios como del consumidor de servicios.
La ocultación de información sigue siendo uno de los principios clave dentro del paradigma orientado a objetos que promueve abstraer el funcionamiento interno de un programa de software . Un ejemplo clásico sería el uso de clases abstractas para ocultar la lógica del método real. El mismo concepto se aplica por el principio de abstracción del servicio con el fin de ocultar los detalles innecesarios sobre el funcionamiento del servicio con el fin de facilitar la evolución del servicio. [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 de servicio que se expone como capacidades de servicio. Un ejemplo sería el de una clase en la que algunos de sus métodos son privados mientras que otros son 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án ocultos.
Un contrato de servicio que no se ha sometido a este principio podría denominarse "contrato detallado" que revela gran parte de las reglas comerciales y la lógica de validación. Una vez que este principio se haya aplicado en un grado justo, el contrato podría denominarse "contrato conciso". La aplicación adicional de este principio de diseño daría como resultado un "contrato optimizado" que maximiza el potencial de reutilización del servicio.
Abstracción de información tecnológica
Cualquier información sobre la tecnología subyacente utilizada dentro del servicio daría como resultado una abstracción de información de baja tecnología, ya que el contrato de servicio les dice explícitamente a los consumidores del servicio cómo se diseñan la lógica del servicio y su implementación. Esta información adicional podría dar como resultado que los consumidores de servicios se diseñen de una manera que se dirija específicamente a esa implementación en particular, desarrollando así el acoplamiento entre el consumidor y la implementación .
Abstracción lógica
Los detalles programáticos sobre la lógica del servicio deben abstraerse [3] ya que el conocimiento sobre cómo el servicio realmente realiza su funcionalidad puede resultar en consumidores del servicio que tengan en cuenta esta información y, en consecuencia, estén diseñados bajo estos supuestos. Esto puede obstaculizar seriamente los esfuerzos de refactorización de la lógica del servicio y puede considerarse como un antipatrón hacia la aplicación del patrón de diseño de refactorización del servicio .
Abstracción de calidad
La abstracción de la calidad se relaciona con los detalles proporcionados en el acuerdo de nivel de servicio que acompaña al servicio. Es importante concentrarse solo en ese tipo de información que realmente ayudaría a determinar la confiabilidad y disponibilidad del servicio, no se debe incluir ninguna otra información que exponga detalles innecesarios, por ejemplo, detalles sobre cómo se ubica un servicio dentro del proceso comercial general y qué otros servicios que utiliza para cumplir con su funcionalidad.
El nivel de control de acceso aplicado a un servicio decidiría cuántas abstracciones de tecnología, lógica y calidad de servicio se encuentran en su lugar. Un 'acceso abierto' proporcionaría acceso gratuito a todos los que estén interesados en conocer las especificaciones de diseño de un servicio. En un 'acceso controlado', solo las personas autorizadas tienen acceso y una política de 'no acceso' negaría totalmente cualquier acceso a los documentos de diseño.
Consideraciones
Aunque el ocultamiento de información se considera una práctica saludable, sin embargo, ocultar demasiado información podría ser contraproducente, ya que puede limitar el nivel de reutilización del servicio. Esto también puede resultar en servicios redundantes ya que los diseñadores de servicios no tienen suficiente información sobre las capacidades del servicio. Para esto, cada contrato de servicio debe diseñarse de manera concisa pero completa para que las capacidades del servicio se puedan descubrir e interpretar de manera efectiva según lo dicta el principio de descubrimiento del servicio .
El tipo de información expuesta en el contrato de servicio también puede generar algunos problemas relacionados con la seguridad. por ejemplo, un servicio que propaga los 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 hace uso de los detalles del error informado e intenta conectarse a la base de datos. Esto podría solucionarse mediante la aplicación de patrones de diseño de filtrado de mensajes [4] y blindaje de excepciones [5] .
Referencias
- ^ Servicio
- ^ 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 vencimiento de contratos SOA [en línea]. Fecha de acceso: 13 de abril de 2010.
- ^ Selección de mensajes
- ^ Protección de excepciones
Otras lecturas
- 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.
- Thomas Erl . Orientación a servicios y orientación a objetos Parte II: 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 Docencia [Online]. Fecha de acceso: 13 de abril de 2010.